Changelog

A well-behaved agent has no reason to read a table nobody told it about. That makes an untouched table a useful tripwire.

Mark any relation as a honeytoken and PgBeam enforces the trip in band: an agent that references it is stopped at the proxy and the event lands in your audit log and webhooks. You find out from the alert, not from the audit trail three weeks later.

This is worth pointing at the tables an exfiltration attempt would go looking for first, the ones with names like customer_cards or api_keys_backup. Nothing legitimate reads them, so a hit is unambiguous.

Agents invent column names. The usual result is a failed query, an error the model has to interpret, and two or three more round trips before it gets there.

validate_sql checks a statement against the schema the credential is actually allowed to see and reports unknown relations and columns without executing anything. It is oracle-safe: a column the policy masks or denies does not become discoverable by asking whether it validates.

That brings the hosted MCP endpoint to eight tools: query, validate_sql, list_tables, describe_table, explain, schema_catalog, search_docs, and read_doc. The catalog also now carries your own table and column comments, so an agent reading your schema gets the descriptions your team wrote rather than guessing from names.

Writing a policy from scratch means guessing which tables an agent needs. Guess too wide and the policy does nothing. Guess too narrow and you spend a week loosening it one column at a time. Your audit log already knows the answer, so PgBeam now reads it for you.

• Right-size: generates a least-privilege policy from the traffic a credential actually ran. Tables, columns, and statement types come from observed queries, not from a blank form.
• What-if: evaluates a draft policy in the editor and shows which of your recorded statements it would allow, mask, or refuse, before the policy is live.
• Replay: runs recorded agent traffic against a candidate policy and reports every difference against the policy in force. This is how you tighten a policy on a working agent without discovering the breakage in production.

All three are reachable from the policy list in the dashboard and from the API. There is also a new pgbeam policies lint command that flags risky rules (over-broad allowlists, missing row caps, write access nobody asked for) so you can run the check in CI instead of remembering to look.

Three things that come up in every security review before a team lets an agent near production data.

• Tamper-evident audit trail: each audit record is hash-chained to the one before it, so an entry cannot be altered or removed without breaking the chain. Older records move to cold storage automatically, which is what makes longer retention windows affordable.
• Data residency: a project can be pinned to US or EU processing, and the proxy enforces it rather than treating it as a preference. Region discovery keeps a connection from being served outside the residency you set.
• SCIM 2.0: provision and deprovision org members from your identity provider. Paired with separation-of-duties roles, so the person who approves a policy change does not have to be the person who can also rotate credentials.

To be explicit about what these are: they are the controls a reviewer asks for. PgBeam is not SOC 2 or HIPAA certified, and none of this claims otherwise.

Read-only access is the right default, but some work genuinely needs writes: a migration you want an agent to test, a data fix you want to see applied before it touches production, a schema change you want to review as a diff.

Branches give the agent somewhere to do that. A branch is a copy of the database the agent can write to freely, with its own credential and its own policy. When the task is done you delete it, and nothing it did reaches your primary.

Idle branches suspend on their own, so a branch you forgot about is not a branch you keep paying for. Each plan includes a branch allowance.

A spend limit that only shows up on the invoice is a notification, not a limit. It now stops traffic: when your organization reaches its spend limit, the proxy refuses further queries rather than letting a looping agent keep spending.

Per-plan limits are enforced the same way, including the number of agent credentials and the audit retention window your plan includes.

This is a behaviour change, so it is worth checking the limit on your organization before an agent finds it for you. If you would rather be warned than cut off, set the limit above your expected spend and watch the usage page.

PgBeam is generally available. The technical preview label is off the dashboard, the site, and the terms of service.

Nothing about your setup changes. The connection string, the credentials, and the policies you already have keep working exactly as they did.

Masking works well once you know which columns hold personal data. Finding them across a schema you inherited is the slow part.

Scan for PII reads your schema and flags the columns that look like personal data (emails, names, phone numbers, addresses, and similar), then proposes a masking rule for each one. You review the list and apply what you agree with. It is a starting point you edit, not a decision made for you.

Masking itself is unchanged: a column can be redacted, nulled, or hashed in flight. Masked values still join and group correctly, so an agent can run GROUP BY email and get honest counts without ever seeing an address. Hashing is the mode to reach for when you need the same input to produce the same value across queries.

The audit surface also picked up filters, per-row detail, and CSV export in the same release.

The proxy used to run in one place. If your agent ran in Singapore and the proxy sat in Virginia, every round trip paid for the distance twice.

It now runs across a global footprint (12 regions today) and a connection is routed to the nearest one. Region names follow the familiar convention, so us-east-1 and eu-central-1 mean what you expect. The connection string does not change: the same host reaches whichever region is closest to the client that dialed it.

Your database has not moved, so this does not shorten the hop from the proxy to your primary. What it removes is the detour on the way in, which is the part you were paying for on every statement.

The reason PgBeam exists. Instead of pasting a DATABASE_URL into an agent and hoping, you issue that agent its own credential and decide what it can do.

Every control runs in the Postgres wire protocol, at the proxy, before your database sees the statement:

• Scoped credentials: a username and password per agent. Your real database credentials never move.
• Read-only enforcement: INSERT, UPDATE, DELETE, and DDL refused outright.
• Table and column allowlists: the agent reaches what you allow and nothing else.
• Column masking: redact, null, or hash a column in flight.
• Query budgets and row caps: an hourly and daily ceiling per credential, so a looping agent hits the ceiling instead of your primary.
• Kill-switch: stop one agent or every agent in a project immediately, with no credential rotation.
• Audit log: every statement recorded, queryable in the dashboard, over the API, and from the CLI.

The same policy applies whether the agent connects over the wire protocol or over the hosted MCP endpoint, which is one URL that works in Claude Code, Cursor, and any other MCP client with no install.

Also in this release: human-in-the-loop approvals for statements you want a person to sign off on, anomaly detection against a per-credential baseline, and webhooks with HMAC signing that emit in Splunk, Datadog, and Elastic formats. Enforcement applies to cached results too, so a masked column stays masked on a cache hit.