Session budgets for AI agents
querying PostgreSQL

ValkDB tracks rows returned, query count, tables and columns touched per agent session, then blocks when the budget is exhausted.

Every query can be valid. The session can still be unsafe.

Request controlled access See the demo
valkdb — session overview
agent_id analytics-agent-v2
session_id sess-7f3a9b2c
task_id daily-report-2026-05-05
status ⚠ warning (84%)
rows 420 / 500 (80 remaining)
queries 7 / 10 (3 remaining)
tables_touched users, orders
columns_touched users.email, users.name, orders.total
last_decision allowed
audit_mode hash_only — raw SQL not stored

Per-query controls were built for humans.
Agents behave like processes.

A human asks one query. An agent keeps asking. Each query may pass RLS, read-only access, and validation. The session can still consume more data than intended.

1 SELECT name, email FROM users LIMIT 100 OFFSET 0 ✓ valid
2 SELECT name, email FROM users LIMIT 100 OFFSET 100 ✓ valid
3 SELECT name, email FROM users LIMIT 100 OFFSET 200 ✓ valid
… repeated valid queries can walk through large parts of a table over time

Each query is valid. The behavior is the problem.

Keep your existing controls.
Add session budgets.

ValkDB complements your existing stack. It does not replace it.

RLS
Controls what rows can be seen
Read replica
Prevents writes
Allowlist
Controls query shape
API gateway
Controls tool and API calls
Token budget
Controls LLM cost
ValkDB
Controls cumulative database consumption over time

Use RLS. Use read replicas. Then add a session budget.

Agent identity → session budget →
circuit breaker → audit evidence

The complete control loop for agent database access.

Agent and session identity

Track which agent, session, and task is querying. Budget scoped to logical identity, not database connection.

Row and query budgets

Cumulative row limits and query counts per time window. Warning at 80%. Blocked at limit. Budgets are enforced across the session, not just per request.

Tables and columns touched

AST-level tracking of every table and column accessed, including through aliases, CTEs, and subqueries.

Warning and exhausted states

Active → Warning (≥80%) → Exhausted. Clear status at every point. No ambiguity about where the session stands.

Circuit breaker

Further queries from the exhausted session are blocked until the budget window resets. No ambiguity. Hard enforcement.

Hash-only audit logs

Query hashes and decision metadata. No raw SQL stored in production. No query results stored. Traceability without exposure.

Know what the agent touched before deciding
whether it should continue

Monitoring tells you what the agent did. ValkDB lets you decide when it must stop.

agent_idanalytics-agent-v2
session_idsess-7f3a9b2c
task_iddaily-report
rows_returned420
rows_budget_used420 / 500
query_count_used7 / 10
tables_touchedusers, orders
columns_touchedusers.email, orders.total
decisionallowed (warning)
query_hashsha256:a1b2c3d4...
block_reason—
log_modehash_only

Built for sensitive data workflows

ValkDB does not store query results. In production hash-only mode, raw SQL is not stored by default; audit logs store query hashes and decision metadata.

◇
No query result storage
◈
Hash-only audit logs
#
Query hash always present
☰
Decision metadata recorded
◎
Agent/session traceability
⊞
Postgres-focused

ValkDB should be used alongside scoped DB credentials, RLS, read replicas, and least-privilege access.

Valid query. Valid query. Valid query.
Blocked session.

Watch an agent consume its budget until blocked.

1 Agent runs valid query ✓ allowed — 50 rows
2–8 Budget accumulates across queries ✓ allowed — 400/500 rows
9 Warning threshold reached (≥80%) ⚠ warning — 450/500 rows
10 Budget exhausted ✗ exhausted — 500/500 rows
11 Next valid query is blocked ✗ BUDGET_EXHAUSTED

ValkDB blocked the session because the agent kept asking.

Audit log records: query_hash + decision + block_reason + budget state. No raw SQL.

Controlled technical preview

Pricing is not active yet. We are currently validating whether session budgets are useful for AI agents querying PostgreSQL.

No production use is expected. No paid plan is available during the preview. If you try it, the only thing we want is blunt technical feedback.

  • Invited-only. No public sign-ups while validation is open.
  • Infra runs in us-west2 (Oregon); expect 1–2s per request from Europe/South America. Warm ValkDB overhead ~3ms.
  • Hash-only audit logs in production mode. Raw SQL is not stored.
  • Feedback goes to feedback@valkdb.dev.

Commercial packaging (cloud, self-hosted, enterprise) will be published after the preview. Until then, assume pricing is undefined.

ValkDB does not replace RLS, read replicas, identity providers, DLP, or API gateways. It adds session budgets, circuit breakers, monitoring, traceability, and audit logs for AI agents querying Postgres.

Give your agents a budget
before they touch real data

Request controlled access Read quickstart