Read-Only by Default: The Safest Credential You Can Give an AI

Start with the smallest grant that does the job, then widen it only when you have to. For an AI agent touching a database, the smallest useful grant is almost always read-only.

Think about what agents actually do most of the time: answer a question, summarize a table, check a value, build a report, explore a schema before writing code. None of that requires a write. Yet the default path, pasting a DATABASE_URL, hands the agent the power to DROP TABLE along with the power to SELECT. You gave it write access it never needed and exposed yourself to every mistake that access enables.

What read-only removes

A read-only credential in PgBeam blocks every INSERT, UPDATE, DELETE, and DDL statement, per credential, in the wire protocol. The write never reaches your database. It is refused at the proxy, before the upstream connection sees it.

That single setting removes an entire category of agent failure:

• The hallucinated UPDATE with a wrong or missing WHERE clause.
• The "cleanup" DELETE the agent decided to run on its own.
• The schema change a coding agent generated and then executed against production instead of a branch.
• The prompt injection that tries to turn a question-answering agent into a destructive one.

You do not have to anticipate which write the agent might get wrong. You make all of them impossible.

Enforced, not requested

The important word is enforced. A read-only system prompt is a request: "please only read." The agent can ignore it, be tricked past it, or be handed a tool that writes anyway. Read-only enforcement at the wire is not a request. The proxy parses the statement, sees that it mutates, and rejects it. There is no code path from the agent's intent to a changed row.

When a write is blocked, the proxy returns an error the agent can read and act on. A coding agent sees that the statement was refused and why, and can correct course instead of looping on an opaque failure. The block is a guardrail and a hint at the same time.

When read-only is too strict

Sometimes the agent's job is to write: a backfill, a migration, a generated UPDATE you want to test against real data. Read-only would refuse all of it, which is correct, but unhelpful when writing is the point.

That is not a reason to hand over a write credential to production. It is a reason to give the agent somewhere safe to write. PgBeam's answer is an instant branch: a throwaway copy of the database the agent can write to freely, which you discard when the session ends. Or always-rollback mode, where the agent's writes run inside a transaction that is never committed. Either way, production stays read-only, and the write happens somewhere it cannot do damage.

The default that scales

Read-only is the credential you reach for first because it is the one with the smallest blast radius and the least to reason about. Layer the rest on top of it: table and column allowlists to narrow what it reads, masking to redact what it sees, budgets to cap how much it reads. But the foundation is the same one a careful operator has always started from. Read first. Write only where it is safe.

This is the same instinct behind least-privilege access for agents in general: grant the minimum, escalate deliberately.

Try PgBeam or see the full feature set.