PostgreSQL · MCP ServerMost Postgres MCP servers hand an agent a connection string.
That credential can read every table and drop half of them — and so can the agent. Bytebase moves the MCP server in front of the governance layer: the agent connects to Bytebase, Bytebase connects to Postgres.
Strip away the protocol and a typical Postgres MCP server is a thin wrapper around a connection string. Three things fall out of that, none of them good:
Over-privileged credential
Nobody provisions a least-privilege role per agent for a five-minute setup. They paste the connection string they already have — the one that can read and drop anything.
Every agent is one principal
Postgres sees a single login. Which agent ran that DELETE, on whose behalf, after which prompt? The audit trail is identical login records.
Read-only isn't
A 2025 survey found read-only transactions defeated by semicolon-delimited payloads — COMMIT; DROP SCHEMA public CASCADE; closes the transaction and runs unguarded.
The prompt is an attack surface
The agent reads data, ingests untrusted content, and sends it back out — the lethal trifecta in one shot. A scoped credential can't stop an injection that asks for data it's allowed to read.
Governed MCP in Bytebase
The agent connects to Bytebase, never to Postgres directly.
The agent badges in under its own identity — OAuth and a service account, not a shared connection string — and inherits exactly the permissions that identity carries. The same machinery your humans pass through now applies to the agent, enforced at the MCP boundary.
Per-agent identity
The agent authenticates as itself, not as a connection string. Scope follows the identity — only the projects, databases, and tables its role allows.
Masking on the read path
Sensitive values are masked before they reach the model. A restricted SSN comes back as ******, so it can't leak what it never saw.
Writes become proposals
A change doesn't run on send. It opens a Bytebase issue, where SQL review and approval apply just as for a human-authored migration.
Run the support-ticket injection against this and it fizzles — the SELECT runs, masking returns ******, scope caps the reach, and the audit log names the identity that tried.
What the agent sees
Same query through MCP. Masked by identity.
The agent calls the query tool over MCP; the result comes back masked for the agent's role, with no change to the table:
// Agent calls the Bytebase MCP "query" tool
{ "sql": "SELECT id, email, ssn FROM customers LIMIT 2" }
// Result returned to the model — masked for this identity
id | email | ssn
----+---------------------+-------------
1 | a******@example.com | ***-**-4801
2 | m******@example.com | ***-**-2210An exempted human running the same query in the SQL Editor sees cleartext. Both reads land in the audit log — under the agent identity and the user it acted for.
Audit with two identities
Every action traces from result to prompt to principal.
Because the agent badges in under its own identity, every query and proposed change is logged twice — under the agent and under the person it acted for. A result traces back to the prompt that triggered it and the principal that ran it.
This is why regulated teams reach for it first. When the regulator asks which agent saw which customer record, “we pasted a connection string” is not an answer.
PostgreSQL MCP server questions
Common questions.
- What is a PostgreSQL MCP server?
- An MCP (Model Context Protocol) server exposes Postgres to an AI agent as tools — typically a query tool the model can call. A raw one wraps a connection string and runs whatever SQL the model asks. A governed one, like Bytebase, sits in front of the governance layer so identity, masking, review, and audit apply to every call.
- How is this different from the official Postgres MCP server?
- The reference server connects directly with a connection string — convenient on a throwaway local database, wide open against production. Bytebase connects the agent through itself: per-agent identity, masking on the read path, writes routed to review, and audit under two identities. Same database, same agent; the difference is where the MCP server sits.
- Does it mask sensitive data before the model sees it?
- Yes. Masking runs on the read path at the MCP boundary, so restricted values are transformed before they reach the model. A masked SSN returns as ******. The model cannot leak what it never received.
- Can the agent write to the database?
- Not directly. A schema or data change opens a Bytebase change issue instead of executing on send, where SQL review and approval apply just as for a human-authored migration. The agent proposes; the pipeline governs.
- Which PostgreSQL flavors are supported?
- Any Postgres Bytebase can connect to — community, RDS, Aurora, Cloud SQL, AlloyDB, managed forks. Governance runs in Bytebase, in front of the database, so there's no extension or superuser requirement on the cluster.
Go deeper
Related reading.
Governed MCP vs. Raw MCP
The MCP server is the one place agent database access is governed or wide open. The full argument, side by side.
How to Govern AI Agent Database Access
The read path: identity, authorization, masking, and audit for an agent that queries your data.
Database Governance for AI Agents
Agents as a new kind of user — ephemeral, autonomous, at machine scale. Governance extended from teams to agents.
PostgreSQL Data Masking
The masking the MCP server enforces on the read path — role-based, without an extension.