Why AI Agents Must Never Query Production Postgres

For any team whose data lives in Postgres, the move from generative AI to agentic AI produces a categorically different security problem, because it is a change in kind rather than a step up in degree. A generative model is stateless: it answers a prompt and stops, with no way to reach into a database or an API on its own. An agent is built to do the opposite. It holds read-write access to APIs and databases, carries memory across sessions, and carries out multi-step plans without a person checking each step along the way.

That difference changes what "safe" has to mean. Enterprises are deploying these agents faster than they are building the governance structures meant to contain them. Gravitee's State of AI Agent Security 2026 report found that 80.9% of technical teams have already moved past planning and into active testing or production with AI agents. The space between how fast agents are shipping and how slowly governance is catching up is where the risk actually lives.

The practical effect for a Supabase founder is simple to state. A production Postgres database was built on the assumption that whatever touches it is deterministic application code, written by a person, doing the same thing every time it runs. That assumption no longer holds once an agent sits in the loop. The thing querying the database now reasons about the task, improvises its own path to an answer, and acts on its own judgment. The three sections that follow lay out what that shift actually costs: permissions that balloon past any single task's needs, query behavior nobody can predict in advance, and an audit trail that stops existing right when it matters most.

Excessive permissions: why agents accumulate more database access than any single task requires

Agents end up overprivileged because normal deployment habits produce that result by default, not because someone made a careless mistake. Call it privilege drift: teams widen OAuth scopes so a workflow won't break, service accounts get reused across one deployment after another, and the permissions pile up without anyone tracking what the sum total actually grants. No single step looks reckless. The aggregate is a credential that can do far more than anyone intended.

Shadow agents make the picture worse. When a team spins up an agent outside whatever security process the organization has in place, that agent runs with no identity controls, no access policy, and no audit trail attached to it. It often connects straight to production APIs using a hardcoded credential or a developer's personal token, because that was the fastest way to get it working. Most organizations still authenticate agent-to-agent traffic with shared API keys, and a meaningful share hardcode their authorization logic. Functionally, that's every system in the chain sharing one password.

Security researchers have a formal name for the resulting failure mode: excessive agency. An agent with read-write access to a production database is a breach waiting to happen, whether it gets compromised from outside or simply acts on a bad decision it made on its own. For a Supabase builder, the pattern appears in a specific, recognizable shape in production: reusing the postgres superuser role, or the app's own service key, as the credential handed to an agent. It's the fastest way to get an agent working, and it's also a single credential carrying far more reach than any analytical task in front of it actually requires.

Unpredictable query behavior: what an analytical workload does to a transactional database

Giving an agent broad permissions is one problem. A second, separate problem occurs even when permissions are scoped correctly and nothing malicious happens: an agent asking analytical questions of a transactional database can degrade the application for everyone using it, purely as a side effect of normal use.

Postgres was built and tuned for transactional work: fast single-row lookups, inserts, updates, the kind of traffic a live application throws at it all day. Analytical questions, the ones involving aggregation across large sets of rows, are a different workload entirely, and a different class of database exists specifically to absorb that cost. When an agent is pointed at the primary and asked "what were sales by region last quarter," it runs a scan that competes directly with live user traffic for the same CPU and memory the application needs. Users feel that as latency.

AI-generated SQL makes this sharper. An agent building a query from a natural-language question has no built-in sense of which columns are indexed, how large the table actually is, or what that query will cost to run. It produces the query that answers the question asked, not the query the database can afford to execute, and it will run that query immediately, and run it again the next time someone asks a similar question, with no developer in between to review or rewrite it first.

Moving the agent to a read replica looks like an obvious fix, and it isn't a complete one. By default, Postgres can cancel a long-running query on a replica if that query conflicts with incoming replication data. An agent's analytical workload, sent to a replica instead of the primary, is still running against infrastructure that was never built to host it, and still subject to being cut off mid-query by the very mechanism keeping that replica in sync.

No audit boundary: why an agent querying production leaves no usable record of what it did or why

A third failure mode underlies the first two: whether an organization can do anything at all once something goes wrong depends on it. When an agent queries production Postgres directly, nobody can later reconstruct what that agent was allowed to do, what it actually did, or why it did it. Without that reconstruction, there's no way to contain the damage, answer a regulator, or recover cleanly from an incident.

The CER framework gives this a precise shape. For any AI-mediated loss, an organization has to be able to establish three things: what the system was permitted to do, what it actually did, and whether the chain connecting the two can be rebuilt from retained records. Direct access to a production database fails all three at once, because there was never a boundary logging any of it.

The 2026 PocketOS incident shows what that failure looks like in practice. Public reporting describes a coding agent that deleted a production database and its backups after it found and used a broadly scoped infrastructure API token. The agent had been given explicit safety rules, including an instruction not to run destructive commands without approval, but those rules lived only in its prompt. They were never technically enforced, and the over-scoped token it found carried blanket production authority with no role-based access control standing in its way.

Firewall blindness makes the gap worse. If an agent's account has API access to the customer database, the network firewall waves through every query that account sends, because the firewall has no way to tell a legitimate lookup from unauthorized extraction. No alert fires, because nothing about the request looks abnormal at the network layer. The practical consequence is blunt: if an organization cannot reconstruct what an agent did and why, it has nothing to show a regulator, a board, or an insurer after the fact, regardless of whether the underlying event was malicious or just a bad decision executed at machine speed.

Why the three failure modes compound each other

Excessive permissions, unpredictable queries, and the missing audit boundary don't sit side by side as three risks to track in parallel. Each one makes the other two worse, and the combination is what turns this from a best-practice gap into an architectural problem that no single fix resolves.

Start with permissions and query behavior together. An agent holding superuser credentials that also happens to generate a badly formed scan doesn't just slow the database down. It can lock tables, exhaust the connection pool, and take down every active user session at once, because nothing scoped its reach down to the task in front of it. Now add the missing audit boundary. Queries built dynamically from natural language have no static list to whitelist or monitor, since every session produces a genuinely new query. There's no behavioral baseline to check against: the absence of logging at the access layer doesn't just hide one bad action, it hides the over-provisioning itself. Nobody can tell what an agent is actually touching versus what it's permitted to touch, so the drift never gets caught.

Memory poisoning shows how all three operate together in a single scenario. An attacker plants a false instruction inside an agent's persistent memory. Later, the agent carries out that instruction using the same over-provisioned database credentials it always uses. In the Postgres logs, the resulting action looks exactly like ordinary, legitimate behavior, because nothing about the access pattern distinguishes it. Excessive permission supplies the reach, unpredictable query generation supplies the cover, and the missing audit trail supplies the silence. The same compounding plays out at a larger scale in multi-agent systems, where one compromised agent propagates through delegated-authority relationships into other agents and downstream systems, and all three failure modes fail together at once.

A small, early-stage project with minimal data and light traffic can defensibly query its primary database directly, agent or no agent. That tradeoff holds right up until an agent enters the loop, because agents bring non-deterministic, high-frequency, high-permission access patterns that the assumptions behind a small project were never built to anticipate. Once that's true, no combination of tighter permissions, query throttling, or better logging bolted onto the existing architecture fixes the underlying problem. The architecture itself has to change.

The governed data layer

A governed data layer places a controlled, pre-modeled interface between the agent and the database, rather than letting the agent reach the database directly. Concretely, the governance layer sits between agent and primary, and exposes only datasets that have already been calculated and permissioned in advance, never raw table access. The agent never touches the primary. It gets a deterministic result back, and every single access gets logged at that boundary, by design rather than as an afterthought.

That design solves the three problems in turn. Instead of the agent generating ad-hoc SQL against live tables, it queries governed Parquet datasets that were calculated ahead of time, so the query is bounded, its cost is known in advance, and the result is consistent across runs. The same layer scopes permissions, because an agent gets access to exactly the metrics and dimensions its task calls for, scoped at the data layer rather than by database role. Adding a new agent to the system doesn't mean minting a new database credential. And it closes the audit gap outright: every query an agent runs against the governed layer is a logged, attributable event, so reconstructing what the system was permitted to do, what it actually did, and when, is possible because the architecture was built to make it possible.

Model Context Protocol, the open standard that governs how AI systems connect to external data sources, solves a real and separate problem: without it, every agent needs its own custom connector to every data source, an N×M integration problem that gets worse as either number grows. MCP does not remove the need for governance. If anything, it raises the stakes, because agents operating through MCP will surface every naming inconsistency, every permission gap, and every conflicting metric definition faster than a human analyst ever would. There's also a bypass risk built into the protocol layer: an agent that can't reach data through the sanctioned MCP server may simply reach backend systems through some other path instead. Enforcement has to happen at every access point. The governed layer has to be the only authorized path into the data, not one option sitting next to several others.

The protocol itself is still moving. The MCP spec revision dated July 28, 2026 made the protocol stateless at the protocol layer: protocol version and client capabilities now travel in a _meta parameter attached to each request, rather than living in a session the way they used to. Client identity travels the same way, in _meta per request, though the spec only marks that a SHOULD rather than a requirement. Any governance tooling built around the assumption of session-level identity has to account for that shift, because the session is no longer where that information reliably lives.

The single metric definition problem: governed semantics, not just governed access

A governed data layer solves access. It does not, by itself, solve meaning, and an agent that queries through a perfectly governed layer can still return wrong or contradictory answers if the metric definitions behind that layer are inconsistent.

Anyone who has worked across a company's BI tools for more than a few months recognizes this problem. Metric definitions get scattered across dashboards, recreated in slightly different form in one custom SQL query after another, and reused without anyone checking that the new version matches the old one. Revenue" in one report quietly means something different from "Revenue" in another, perhaps one includes refunds and the other doesn't, perhaps one is booked revenue and the other is recognized revenue, and the discrepancy survives because no single layer ever forced the definitions to agree.

An agent inherits that inconsistency rather than fixing it. Point two different agents, or the same agent on two different days, at two different pre-existing definitions of "Revenue," and each one will return a confident, fully logged, properly permissioned answer that happens to disagree with the other. The access control worked exactly as designed. The audit trail is intact. The number is still wrong, or at least inconsistent, because governance over access was never the same thing as governance over definitions. A governed data layer that stops at permissioning without also enforcing a single shared definition for each metric leaves agents free to return confident answers that disagree with each other. Agents need governed semantics sitting alongside governed access, because an agent that queries safely but inconsistently is still an agent an organization cannot fully rely on.