Comparison
PgBeam vs human database access governance
Bytebase, Teleport, and Cyral govern how people reach production Postgres: a console or gateway session, an approval workflow, an audit organized around who did what. An agent has none of those. It has a connection string in an environment variable, and PgBeam is what makes that string safe to hand it.
human database access governance: Bytebase, Teleport, and Cyral are database access-governance platforms: allowlists, masking, and audit for human operators reaching a database through a console or gateway, usually with an approval workflow in front.
Put the feature lists side by side and these look like the same product. The difference is the consumer, not the control. Access governance is built around a person: someone opens a console or connects through a gateway, a request is approved, the session is recorded, and the audit answers who did what. An agent does not open a console, does not have a person's identity, and does not stop to wait for anyone. It reads a connection string from an environment variable and runs a loop. PgBeam is built for that consumer, which is why the two coexist rather than compete.
PgBeam vs human database access governance, side by side
| Capability | PgBeam | human database access governance |
|---|---|---|
| Primary consumer | An autonomous agent | A human operator |
| How access is delivered | A scoped DSN and a hosted MCP endpoint | A console or gateway session |
| Adoption cost | An env-var change | A platform change |
| Hosted MCP endpoint | Yes | No |
| Read-only enforcement | Yes | Yes |
| Table and column allowlists | Yes | Yes |
| PII masking in results | Yes | Partial |
| Row-level filters | Yes | Partial |
| Query and egress budgets | Yes | Partial |
| Audit trail | Per statement, per agent | Yes, human-focused |
| Approvals | Per statement, inline | Per access request |
| Governs your human operators | No | Yes |
The artifact is different, and that is the whole story
A governance platform's output is a session. A person asks for access, someone grants it, and for a while that person can reach the database through the path the platform controls. The controls hang off an identity that belongs to a human being and a request that a human being made.
PgBeam's output is a credential a program consumes. It is an ordinary Postgres connection string and an ordinary MCP endpoint, so every driver, ORM, and agent framework works unchanged, with no SDK and no code to write. The credential carries its policy with it, can be issued with an expiry, and is marked as belonging to an agent rather than a person, so agent traffic is separable in the audit trail from the start.
An approval a program can act on
Approvals exist on both sides, at different grain. A governance tool approves a request for access: a person waits, then works. PgBeam approves a statement: the write is held on the connection while a reviewer decides, with a timeout, and with an auto-approve threshold for writes touching at most a set number of rows. Approval mode is off, writes, DDL, or everything.
The rest of the time no person is involved, which is the point. A refused statement returns SQLSTATE 42501 and a message written for a model to read, so the agent's next turn is a narrower query rather than a stalled ticket. A refusal that a human has to interpret is a dead end when the consumer is a loop running at three in the morning.
When human database access governance is the better fit
These are mature platforms solving a problem PgBeam does not touch: how the people on your team reach production. Access requests, approval workflows, session records, and an audit organized around a person's identity are their product, and PgBeam has none of it. There is no console session, no request-and-grant flow for an engineer who needs an hour on the primary, and no answer to the question of which humans can reach this database. If that is the question your security review is asking, it is asking for one of these tools, and adding PgBeam does not answer it. PgBeam also enforces in the Postgres wire protocol and stops there, so it has nothing to offer for any other engine you govern the same way. Run both. They govern your people; PgBeam governs the programs your people point at the same database.
Add PgBeam next to the governance tool you already run
Nothing has to be migrated or replaced. The governance platform keeps the human path exactly as it is, and PgBeam becomes the path for the credentials that go into agents.
Draw the line by consumer, not by feature
Sorting the two tools by capability produces an argument, because the capability lists overlap. Sorting them by who is on the other end produces a boundary, because a console session and an environment variable are not interchangeable.
Who is on the other endgovernance engineers, on-call, analysts, contractors governance access requests, approvals for a person, session records governance the question "which humans can reach this database" pgbeam agents, copilots, background jobs, MCP clients pgbeam a scoped connection string and a hosted MCP endpoint pgbeam the question "what did the agent run, and what came back"Create the agent policy
Access mode is a ceiling that the statement rules narrow within and never lift. Masking is what protects a sensitive column, because the table allowlist matches on relation names and naming a masked column is never itself the reason a query is refused.
Terminalpgbeam policies create \ --name support-copilot \ --mode read_write \ --allow public.accounts --allow public.customers \ --mask customers.email=redact \ --max-rows 500 \ --budget-queries-per-day 5000 \ --approval-mode writes \ --approval-auto-max-rows 1 \ --approval-timeout-seconds 300Issue the credential and paste it in
This is the step that has no equivalent on the governance side. The output is a connection string and an MCP token, and the change on the agent's side is one environment variable.
Terminalpgbeam agents create \ --name support-copilot \ --policy pol_xxx \ --expires 30d \ --principal-type agent # then, for an MCP client pgbeam agents mcp-config --url https://abc.proxy.pgbeam.app/mcp \ --mcp-token pba_xxx --client cursorVerify the credential is what you believe it is
inspect resolves the credential against its policy the way the proxy does and prints the effective answer, so a read-only credential listing update in its statement rules is still shown as blocked. dry-eval then checks one statement at a time against the real policy engine.
Terminalpgbeam agents inspect agt_xxx pgbeam policies dry-eval --policy pol_xxx --sql "SELECT email FROM public.customers" pgbeam policies lint --policy pol_xxx
Leave the governance platform in charge of human access. If you want one timeline across both, PgBeam streams its audit trail to Splunk HEC, Datadog, Elastic, or any endpoint over signed webhooks, and every entry carries a principal type so agent traffic and human traffic stay distinguishable after they are merged.
One agent session, four outcomes
This is a support copilot answering a customer question, on the policy above: two tables allowed (public.accounts and public.customers), customers.email masked, writes held for approval. No human requested this session and no human is watching it. The audit is what a reviewer reads afterwards.
SELECT id, total FROM public.orders WHERE account_id = 42;
SELECT email, full_name FROM public.customers WHERE account_id = 42;
UPDATE public.accounts SET plan = 'enterprise' WHERE id = 42;
DELETE FROM public.customers;TIME EVENT RULE SQL
09:14:02 blocked table_not_allowed SELECT id, total FROM public.or...
09:14:03 masked SELECT email, full_name FROM pu...
09:14:31 approval_requested approval_requested UPDATE public.accounts SET plan...
09:14:50 approved approved UPDATE public.accounts SET plan...
09:15:07 blocked whereless_write DELETE FROM public.customersThe first statement is refused because public.orders is not on the allowlist, even though it is an ordinary read that any human analyst would be allowed to run. The agent gets the reason on the same connection and its next statement is narrower. The unit of enforcement here is the statement, where a governance tool's unit is the session that a person asked for.
The second statement runs. The row the copilot needed comes back and the email column comes back as [redacted], because masking rewrites the result rather than refusing the query. That distinction matters for an agent: a refusal costs a turn, a mask costs nothing and still keeps the value out of the model's context, out of the provider's systems, and out of your own logs.
The third and fourth entries are the one place a person appears. The write was held on the connection for a reviewer, approved twenty seconds later, and then ran. That is an approval on a statement, not on a person's access, so it does not require the agent to have a human identity or a session anyone requested.
The last statement never reaches the database. A DELETE with no WHERE clause is refused ahead of the access-mode check, so even a read-write credential cannot issue one by accident, and the entry that lands in the trail names the rule that fired rather than a generic denial.
Which tool answers which question
The honest version of this comparison is a list of questions, because for several of them the answer is the other product.
We already run Bytebase, Teleport, or Cyral for production access
Keep it, unchanged. PgBeam does not sit in the human path and does not want to. It issues credentials for the programs your engineers point at the same database, which is traffic the governance tool was not built to receive.
Where this stops: PgBeam does not govern your people at all. There is no console session, no access-request workflow, and no session recording for a human operator, so it cannot be the answer to a review asking who on the team can reach production.
Can we just give the agent an account in the governance tool?
You can, and some teams do. What you get is an agent wearing a person's shape: its statements are attributed to whatever identity you created, its access is granted at the grain a human session uses, and the audit reads as if a person did it. PgBeam issues per-agent credentials marked as agent principals, so the trail separates the two without anyone reconstructing it later.
pgbeam agents create --name nightly-report --policy pol_xxx --principal-type agentWhere this stops: If your agent count is one and it runs a fixed query on a schedule, a governed service account is a reasonable answer and a second product is overhead. The case for a per-agent credential grows with the number of agents and how much of their SQL a model wrote.
We need an approval before an agent writes anything
Set approval mode to writes or to everything. The statement is held on the connection while a reviewer decides, with a timeout you choose, and writes touching at most a set number of rows can auto-approve so routine single-row updates do not page anyone.
pgbeam policies create --name deploys --mode read_write \
--write-mode rollback --approval-mode ddl --migration-safety warnWhere this stops: An approval hold needs the simple query protocol. A statement sent as a prepared statement in the extended protocol is refused with a message telling the agent to resubmit it as a simple query, which is a real change for a client that prepares everything by default.
We want one audit trail across humans and agents
PgBeam records every agent statement with its decision, rule, rows, bytes, latency, region, credential, and timestamp, hash-chained per project so an edited or deleted row breaks the chain and a verify command reports the first bad entry. It exports to Splunk HEC, Datadog, Elastic, and signed webhooks.
pgbeam audit verify
pgbeam audit export --format jsonWhere this stops: It records what crossed PgBeam. A person connecting with the database's own credentials is invisible to it, which is exactly the traffic the governance tool exists to see. One trail means shipping both into the same destination, not picking one product.
The agent queries through a view we already allowlisted the table for
Allowlist the view by name. Relation-level allowlists match the relations a statement names, so a view is its own entry rather than an inherited grant from the table underneath it.
Where this stops: This is a published limit rather than a bug, and it is the one most people meet first. Changing search_path is also refused for agent credentials, because it is the shortest route around a relation allowlist.
Questions
Safe Postgres access for your agents
Start with a 14-day free trial. No credit card required.
Get Started