← Blog3 min read

Query Budgets and Kill-Switches: Blast-Radius Control for Agents

Read-only enforcement and allowlists decide what an agent can run. Budgets and kill-switches decide how much and whether it keeps running. They are the controls you reach for when the failure mode is not a single dangerous query but a flood of ordinary ones.

Agents fail in volume. A retry loop that re-runs a failing query, a planning step that fans out into hundreds of lookups, a misjudged pagination that walks a forty-million-row table one page at a time. None of these is a "dangerous" query on its own. The danger is the multiplier.

Budgets cap the multiplier

A query budget sets a ceiling per credential: queries per hour or per day, and rows per result. When the credential hits the ceiling, the next query is refused at the wire, with an error the agent can read.

This changes the worst case from unbounded to bounded. An agent stuck in a retry loop spends its hourly budget and stops, instead of running until someone notices the database is on fire. A query that would return forty million rows returns the row cap and a clear limit, instead of streaming the whole table into a context window and the network in between.

The row cap matters specifically for agents. A human who writes SELECT * FROM events without a WHERE clause notices the result is enormous and cancels it. An agent does not flinch. It will happily try to consume the entire table. The cap is the flinch you install on its behalf.

Kill-switches cut it off

A budget is a ceiling you set in advance. A kill-switch is the lever you pull in the moment. PgBeam gives you two:

  • Per-credential: stop one agent. The next statement from that credential is refused.
  • Project-wide: stop every credential on the project at once.

The next statement is rejected immediately. There is no credential rotation, no deploy, no coordinating a password change across services. You flip it, and the access is gone until you flip it back.

This is the control you want during an incident. An agent is behaving in a way you do not like, a credential may be compromised, or you simply need everything to stop while you investigate. One click, and the database stops receiving queries from that principal, while your application keeps running on its own credential.

Why at the wire, again

Both controls work because the proxy is counting and gating every statement in one place. A budget enforced in application code only counts the queries that went through that code path. A budget enforced at the wire counts every query the credential ran, from any tool, through any driver. The kill-switch works the same way: it does not matter how the agent connected, the refusal happens at the layer all connections share.

The pattern

Set a conservative budget on every agent credential by default. Most agents have a normal volume, and the budget should sit comfortably above it, low enough that a runaway loop hits the ceiling fast. Wire the audit log and webhooks so that when a budget is exhausted or a kill-switch trips, you find out and can react, instead of discovering it in next month's bill.

Combined with read-only by default, allowlists, and masking, budgets and kill-switches complete the picture: you have bounded what the agent can do, what it can see, how much it can read, and you can stop it instantly. The worst case is now a number you chose, not a surprise.

Try PgBeam or see the full feature set.

Give your agent Postgres it can't wreck

Connect a database, issue a credential, and watch the audit log fill up. No credit card. 14-day trial.