The Proxy Is the Right Place to Make Agent Database Access Safe

Nobody wants to hand an AI agent a superuser connection string. The agent is useful exactly because it can run arbitrary SQL, and dangerous for the same reason. The question is where you put the thing that decides what the agent is allowed to do.

There are four candidate layers. Three of them have a fatal gap. The fourth is the PostgreSQL wire protocol, which is where PgBeam lives.

Inside the agent

The first instinct is to constrain the agent itself: a careful system prompt, a tool that only exposes "safe" operations, a model fine-tuned to be cautious.

This is the weakest possible boundary. A prompt is a suggestion, not an enforcement mechanism. The agent can be jailbroken, can misread its own instructions, or can be handed a tool that turns out to be more powerful than you thought. Worse, the boundary lives in the same process as the thing you don't trust. If the agent decides to run DROP TABLE users, the only thing standing between that intent and your data is the agent's own judgment. That is not a control. That is hope.

Inside the application

The next layer down is the application that hosts the agent: wrap the database client, allowlist queries in code, strip sensitive columns before they reach the model.

This works until it doesn't. Every code path that touches the database needs the same wrapper, applied consistently, forever. A new feature, a background job, a quick script someone wrote to debug an incident: each is a place the guardrail can be forgotten. And the guardrail is only as good as the engineer who wrote it. You are reimplementing access control, in application code, for every app that touches the database. Auditors hate this, and they are right to.

Inside the database

The most rigorous layer is Postgres itself: roles, GRANT, row-level security policies, column privileges. Postgres has a real, battle-tested permission system.

The problem is reach and ergonomics. Database-native controls only work on databases you fully control. If your data lives on RDS, Aurora, Cloud SQL, or a managed provider, you get whatever subset of the permission system the vendor exposes, configured the vendor's way. And Postgres roles are coarse and static: spinning up a scoped, revocable, time-limited credential per agent, with per-credential query budgets and a kill-switch, is not something the GRANT system was built for. You can approximate it with enough roles and triggers and a lot of discipline. You cannot do it quickly, and you cannot do it the same way across every database you run.

It also gives you nothing on the observability side. Postgres will enforce a privilege, but it will not hand you a structured audit log of every statement an agent ran, with the decision and the reason, queryable in a dashboard.

The wire

Between the agent and the database is the PostgreSQL wire protocol: the frontend/backend message format that every client, driver, and ORM speaks. A proxy that sits on the wire sees every query before the database does, and every result before the client does.

That is the leverage. At the wire:

• You can read the SQL and decide to allow it, block it, or rewrite it, before the database ever sees it.
• You can inspect the result and mask a column in flight, so the agent receives a redacted value the application never had to think about.
• You can issue a scoped credential that maps to a policy, not to a Postgres role, so revoking it is one click and the database never knew it existed.
• You can record every statement with its decision and outcome, because every statement passes through one place.
• You can do all of this for any Postgres host, because the wire protocol is the same whether the database is RDS, Aurora, self-hosted, or a managed provider.

None of this requires the agent, the application, or the database to change. The agent connects to a normal-looking Postgres endpoint. The application uses its normal driver. The database serves normal queries from what looks like a normal client. The policy lives in the one layer all three have in common.

Why "zero code changes" is the whole point

The reason the wire is the right place is not just that it is technically capable. It is that it is the only layer where the control is both enforced (unlike a prompt) and universal (unlike app code or database roles tied to one host).

PgBeam is a wire-protocol proxy. It speaks the PostgreSQL frontend/backend protocol natively, terminates TLS, handles the startup handshake and authentication, and then maps the session onto a policy and a pooled upstream connection. From the agent's side it is a connection string or a hosted MCP endpoint. From your side it is a policy engine you configure once.

This is the same architecture that made connection pooling and query caching work for any database without an SDK. The pivot to agent safety is not a new product. It is the realization that the layer that was already inspecting every query is the right layer to enforce every policy.

The agent gets real access. You get real guardrails. They meet on the wire.

Try PgBeam or see the full feature set.