--- title: "Launching PgBeam: Safe Postgres for AI Agents" description: "Your agent does not need your superuser connection string. PgBeam issues a scoped one, enforces read-only access, allowlists, PII masking, and budgets in the Postgres wire protocol, and records every statement. Any Postgres, no code changes." canonical: "https://pgbeam.com/blog/launching-pgbeam" last-updated: "2026-09-09T11:37:53.000Z" --- # Launching PgBeam: Safe Postgres for AI Agents > Your agent does not need your superuser connection string. PgBeam issues a scoped one, enforces read-only access, allowlists, PII masking, and budgets in the Postgres wire protocol, and records every statement. Any Postgres, no code changes. URL: https://pgbeam.com/blog/launching-pgbeam Published: 2026-07-25 Author: Alexis Rico Tags: launch, ai, security, mcp The last step before an agent touches a real database is the one I always felt worst about. You have the agent working. You have the database. Between them goes a connection string, and the one in your hand can read every table, write every row, and drop the schema. You can write a careful prompt asking it not to. A prompt is a suggestion. It is not an enforcement boundary. PgBeam is the enforcement boundary. It sits in the Postgres wire protocol between the agent and your database, authenticates a scoped credential that PgBeam issued, checks every statement against a policy, and only then forwards it upstream. Today it is live. This post is the announcement, so it is short and it is dated. The mechanism does not age the way an announcement does, so it lives at How PgBeam works instead: the path of a statement, why the policy belongs in the wire rather than in the database, and how pooling, caching, and nearest-region routing keep the guard fast enough to leave in the path. If you are here to find out how the thing works, read that page, not this one. ## The 60-second version Connect a database, create a policy, issue a credential: That last command hands you two front doors to the same policy engine: Paste either one into Claude Code, Cursor, LangChain, or psql. Every Postgres driver and ORM works unchanged, because the thing on the other end speaks Postgres. There is no SDK, no extension to install in your database, and no migration. ## The receipt Here is what the agent gets when it tries to write through a read-only credential. This is the actual message, not a paraphrase: Two things matter about that string. First, the statement never reached your database. Second, it tells the agent what happened and what it may do instead, so a blocked call becomes a self-correcting step in the loop rather than a dead end. Errors written for an LLM consumer are a feature, not a nicety. Masking works the same way, in flight. Name a column, choose `redact`, `null`, or `hash`, and the agent receives masked values it can still join and group on while your own application keeps reading the real ones. The agent never sees the plaintext, because the plaintext never leaves the wire. ## What the policy decides Read-only or read-write, per credential. Writes and DDL are refused before your database sees them. Which schemas, tables, and columns the credential can reach. Everything else is blocked. Which rows: a row-level policy appends a `WHERE` predicate to every query, so a per-tenant agent cannot read outside its tenant no matter what SQL it generates. What gets masked: `redact`, `null`, or `hash`, matched by `schema.table.column`. How much it can spend: queries per hour or day, and a row cap per result. A looping agent hits a ceiling instead of your primary. Whether a write needs a human. Approval queues hold a statement until someone signs off. Where writes land. A write can go to an isolated instant branch, or run in a transaction that always rolls back, so an agent can write freely without touching production. Every statement, allowed or blocked, is recorded with its decision, reason, rows, bytes, and latency. The log is SHA-256 hash-chained, so editing or deleting an entry breaks the chain and a verify endpoint reports the first broken row. It streams to Splunk HEC, Datadog, or Elastic, or to any endpoint over signed webhooks. And there is a kill-switch: stop one agent or every agent on a project, and the next statement is refused. No credential rotation, no role changes. The step-by-step version of how a statement gets through all of that, from TLS handshake to audit row, is in How PgBeam works. ## What I am not claiming PgBeam is not SOC 2 or HIPAA certified. You get masking, a tamper-evident hash-chained audit log, SCIM and SSO, and per-organization data residency. You do not get a certificate, and I am not going to imply otherwise. Masking is `redact`, `null`, or `hash`. There is no partial masking that shows the last four digits. Relation allowlists do not see through views. If you want a view reachable, allowlist the view. `SET search_path` is blocked for agent credentials, because allowing it would let an agent walk around an allowlist. Query budgets are enforced per region, so on a globally distributed workload treat them as a close approximation rather than a globally coordinated counter. Binary-format result columns are masked to `NULL` rather than a redaction token, since a redaction string is not a valid binary value. I would rather you hit these in this list than in production. ## Start The dashboard is at pgbeam.com. New signups start on a 14-day free trial with no credit card. If you want to watch the policy engine make decisions before connecting anything of your own, the live demo is a real LLM agent running against a real database through PgBeam, with no signup, so you can watch it get allowed, masked, and blocked. If you are wiring an agent into a production database this week, the honest question is not whether the agent is well behaved. It is what it is allowed to do when it is not.