--- title: "A Field Guide to Least-Privilege Database Access for AI Agents" description: "Least privilege is an old principle with a new urgency now that the principal is an autonomous agent. Here is the practical sequence for granting an agent the minimum database access it needs, and nothing more." canonical: "https://pgbeam.com/blog/least-privilege-database-access-for-ai-agents" last-updated: "2026-09-13T16:16:22.000Z" --- # A Field Guide to Least-Privilege Database Access for AI Agents > Least privilege is an old principle with a new urgency now that the principal is an autonomous agent. Here is the practical sequence for granting an agent the minimum database access it needs, and nothing more. URL: https://pgbeam.com/blog/least-privilege-database-access-for-ai-agents Published: 2026-09-01 Author: Alexis Rico Tags: ai, security, engineering Least privilege is not new. Grant a principal the minimum access it needs to do its job, and nothing more. What is new is the principal. An AI agent runs SQL you did not write, retries in loops, can be redirected by a prompt injection, and copies whatever it reads into a context window you do not fully control. The principle holds. The stakes are higher. This is the practical sequence I use for putting an agent in front of a database. Each step narrows the grant. Start at the most restrictive and widen only when the agent's job demands it. ## 1\. Give it its own credential Never share a credential between the agent and anything else, and never hand it your application's `DATABASE_URL`. Issue a scoped credential that belongs to this agent alone. The agent never sees your real database password, and when something goes wrong you revoke one credential without touching the database or rotating anyone else's access. ## 2\. Make it read-only Default to read-only enforcement. Most agents only need to read, and a read-only credential makes every `INSERT`, `UPDATE`, `DELETE`, and DDL impossible at the wire. This single step removes the entire category of destructive-write failures. Only relax it when writing is genuinely the agent's job, and even then, send the writes to a branch or use always-rollback rather than opening up production. ## 3\. Allowlist the tables and columns Scope the credential to the exact schemas, tables, and columns the agent needs. Allowlists mean the agent cannot wander into the billing or auth tables it was never meant to see, even if its generated SQL goes looking. Everything off the list is blocked at the wire. ## 4\. Constrain the rows If the agent should only see a slice of a table, a tenant, a region, a customer, add a row-level policy. PgBeam appends the predicate to every query, so the agent only ever sees its rows no matter what SQL it generates. This is what makes a single per-tenant agent safe to run for every tenant. ## 5\. Mask what it does not need to read For columns the agent must query but should not actually see, like an email it needs to group by but not read, apply masking. Redact, null, or hash the value in flight. The agent works on the shape of the data; the raw PII never reaches the model's context. ## 6\. Bound the volume Set a query budget and row cap. An agent in a retry loop spends its budget and stops instead of hammering the database. A query without a `WHERE` clause hits the row cap instead of dumping the whole table. The worst case becomes a number you chose. ## 7\. Harden the auth Use SCRAM-SHA-256 so the credential proves itself without ever sending the password over the wire. An agent's secret passes through more software than a human's; SCRAM shrinks the number of places a reusable password could leak. ## 8\. Watch and react Turn on the audit log so every statement is recorded with its decision. Stream it to your SIEM and fire webhooks on blocks, exhausted budgets, and tripped kill-switches. Add anomaly detection to catch the agent drifting from its baseline. When something looks wrong, the kill-switch stops it in one click. ## Why the proxy is what makes this practical Every step above is something you could, in theory, assemble from database roles, application code, and bespoke tooling, per database, and maintain forever. The reason to do it at the wire instead is that the controls are enforced (not requested), universal (any Postgres host, any driver, any framework), and composable (a credential can be read-only, allowlisted, row-scoped, masked, budgeted, and SCRAM-authenticated all at once, decided in a single pass). You configure least privilege once, on a credential, and it travels into whatever tool you paste it into. The agent gets exactly the access its job requires. You get a credential whose blast radius you can describe in a sentence. That is the whole goal: minimum grant, deliberate escalation, full visibility. Try PgBeam or see the full feature set.