About PgBeam

PgBeam is the safe Postgres gateway for AI agents. You hand an agent a scoped connection string or a hosted MCP endpoint instead of your superuser one, and PgBeam decides what that credential is allowed to do before the query reaches your database.

What is PgBeam?

PgBeam is a proxy that speaks the PostgreSQL wire protocol. It authenticates a PgBeam-issued credential, applies the policy attached to that credential, and only then connects upstream to your database. The policy decides the access mode (read-only or read-write), which statement types are allowed, which tables and columns the credential can touch, which rows come back, what gets masked, and how many queries it can run. Every statement is recorded with its decision and the reason for it.

Because enforcement happens at the protocol rather than inside the database, PgBeam works with Postgres you already run: RDS, Aurora, self-hosted, or a managed provider. There is no extension to install, no schema change, and no SDK. Drivers, ORMs, and agent frameworks connect unchanged. The full control surface is listed on the features page.

Why does it exist?

Teams are wiring AI agents into production databases and have no good way to limit the blast radius. The two common answers are a hand-rolled read-only Postgres role, or an MCP server pointed at a full-privilege connection string. Both are blunt. Neither can mask a column, cap query volume, record what the agent actually ran, or be revoked without rotating a role that other things depend on.

A guard in the wire is a better place for those rules, because it is the one place every client has to pass through and the one place that can see the statement before the database does. That is the whole idea, and it is the reason the product is a proxy rather than a library.

Who is it for?

Platform and AI engineers who are putting an agent (Claude Code, Cursor, LangChain, or something in-house) in front of real data, and who need the access scoped before it ships. And the engineering lead or security owner who has to approve that access, and wants read-only enforcement, masking, a per-agent record, and a kill-switch before signing off.

The same controls apply to a person at a psql prompt. Nothing about the enforcement path assumes the client is a model, which is why an analyst credential and an agent credential are configured the same way.

What principles does the enforcement follow?

Fail closed. If a statement cannot be parsed and proven safe against the policy, an agent credential is refused. A guard that guesses is not a guard.

One policy engine, two front doors. The guarded connection string and the hosted MCP endpoint share a single policy and a single enforcement path. A rule you set once cannot be true on one door and false on the other.

Enforce at the wire, not in the database. No extension, no schema change, no privileged migration to install. That is what lets the same policy cover a managed provider and a Postgres you administer yourself.

Everything is recorded. Allowed, masked, and blocked statements all land in the audit log with their reason, hash-chained so an edit or a deletion breaks the chain.

Say what it does not do. The limits below are demoable, so they are published rather than discovered.

Where does it run?

The gateway runs across 12 metros worldwide, and a connection is routed to the nearest one so the guardrails cost little wherever your agent runs. The control plane (the dashboard, the API, and the audit store) runs in us-east-1. Cached query results stay in the region that produced them, and organizations on a residency requirement get that routing honored per organization.

Live latency numbers, measured from serverless functions in 20 regions rather than quoted from a slide, are on the benchmark page.

How is it priced, and what happens to your data?

Subscriptions on published prices, starting at $9 per month with a 14-day trial. The tiers and their limits are on the pricing page. Query contents are not sold or shared. Cached results are held in memory only and are never written to disk, and your upstream database password is encrypted at rest and never logged. The details are in the privacy policy and the DPA.

What does PgBeam not claim?

PgBeam keeps a tamper-evident, hash-chained audit log and honors audit retention, but it does not hold a SOC 2 Type II certification. Relation-level allowlists do not see through views, so views have to be allowlisted explicitly. SET search_path is blocked for agent credentials because it is an allowlist evasion. Query budgets are enforced per region and are an approximation, not a globally coordinated counter. The security page goes through the rest.

How do you get started?

Connect a database, issue a scoped credential, attach a read-only policy, and point the agent at it. The quickstart walks through it, and hosted MCP covers the one URL you paste into an MCP client. A coding agent can do the whole setup unattended from /skill.md. For anything else, the contact page lists which address handles what.