A LangChain SQL agent, with a ceiling on what it can pull

Client

a LangChain SQL agent

Policy shape

row caps and query budgets

An agent writes its own SQL in a loop, and a bad plan or a retry storm can pull far more data than anyone intended.

A LangChain SQL agent takes a connection string, so there is no MCP client to configure: point it at PgBeam instead of at your database and every statement it writes runs through the policy. That matters more here than in the MCP recipes, because a SQL chain generates statements in a loop and the loop is where volume problems come from.

Wire it up

No client library changes. The agent keeps whatever SQLDatabase or engine construction it already has, and only the connection string moves.

1. 1

   Create the policy with the caps

   Three different windows, doing three different jobs. max-rows bounds one statement, the query budgets bound a burst and a day, and the egress budget bounds the total volume regardless of how it was split up.

   TerminalCopy

   pgbeam policies create \
     --name langchain-analyst \
     --mode read_only \
     --allow public.orders --allow public.order_items --allow public.products \
     --max-rows 1000 \
     --budget-queries-per-hour 300 \
     --budget-queries-per-day 5000 \
     --egress-bytes-per-day 524288000 \
     --statement-timeout-ms 10000

2. 2

   Issue a credential

   One per agent, so a runaway loop in one does not spend the budget of another.

   TerminalCopy

   pgbeam agents create --name langchain-analyst --policy pol_xxx --expires 30d

3. 3

   Point the agent at it

   Any driver, any ORM, any framework. PgBeam speaks the Postgres wire protocol, so this is a connection string change and nothing else.

   EnvironmentCopy

   DATABASE_URL=postgresql://agent_x:pba_...@<project>.proxy.pgbeam.app:5432/mydb

4. 4

   Watch the ceiling get hit

   The audit trail records the statement, the decision, rows returned and bytes out, so the first place to look after a surprising bill is what the agent actually pulled.

   TerminalCopy

   pgbeam audit list --event blocked --limit 20
   pgbeam agents usage

Row-returning MCP results carry a budget block with the limit, the amount used, the remainder, and the reset time for each capped window. A well-behaved agent can pace itself with that instead of discovering the wall.

Where each ceiling bites

The same agent, three moments in a run. Only the first is a policy refusal, and that is the point: caps mostly shape a result rather than reject a statement.

1  SELECT * FROM public.orders                       (2.4M rows in the table)
2  the same query, 400 times in an hour, in a retry loop
3  SELECT * FROM public.customers

1  runs, result truncated at 1000 rows
2  the 301st statement in the hour is refused: queries-per-hour budget exhausted
3  Verdict: block    Rule: table_not_allowed
   Reason:  table "public.customers" is not in this credential's allowlist

What this does not cover

• Budget counts are per-region approximations rather than a globally coordinated ledger, and the egress figure can trail the last statement by a moment. Leave headroom rather than setting a limit you intend to run right up to.
• A row cap truncates a result. It does not make the query cheap: the database still planned and executed it, so a cap is a bound on what leaves rather than on what your database does.
• Budgets are per credential. Two agents sharing one credential share one budget, and the first one to spend it stops the second.

More recipes

Questions