The Postgres MCP server lets Claude, Cursor, ChatGPT, and AI agents query your PostgreSQL database in plain English. Here's the setup, the real security risks of agent SQL access, and how to govern it with column-level redaction at the MCP layer.
.webp)
SELECT can return whole columns straight into the model's context. Most MCP servers expose SQL with no row filtering and no redaction in the path.The Postgres MCP server is a Model Context Protocol implementation that exposes a PostgreSQL database to AI agents as a set of standardized tools. Once connected, an agent like Claude can list schemas, describe tables, read column types, and execute SQL — turning your database into something an AI client can query in natural language.
There isn't one canonical server, and the difference matters. The community reference postgres server wraps queries in a read-only transaction and exposes table schemas as resources. AWS's official Aurora and RDS for PostgreSQL MCP server translates plain-English questions into Postgres SQL and supports read-only access or optional read/write, scoped by the database role you connect with. There are also several third-party servers with their own tool surfaces and their own defaults. Check the specific server's docs for its exact tool list and whether writes are enabled.
From the user's seat, the agent suddenly understands the database — it answers questions about live data without anyone exporting a CSV. From the security seat, the agent now holds query access to whatever the connected Postgres role can read, and possibly write.
That's the value. It's also exactly where a control layer belongs.
Point an agent at a Postgres MCP server and it works the real database directly, turning plain-English questions into SQL against the tables the connected role can touch. In practice it can:
Every one of those runs through Postgres's own SQL engine and the privileges of the role you connected — which is what makes it genuinely useful, and exactly why the regulated data those queries return needs an inspection layer in the tool-call path.
The risks here are sharper than most SaaS MCP servers, because Postgres is the raw production database — not a curated app view of it. Five categories every healthcare, fintech, and enterprise security team should price in:
1. It's the production database, in the raw. A SaaS API hands back a shaped, permission-filtered object. Postgres hands back rows. The agent sees the users table the way your application's data layer sees it — every column, including the ones the UI never renders.
2. PII and secrets sit in plaintext columns. Email, SSN, date of birth, full card numbers, password reset tokens, API keys, and session secrets routinely live as plain text and varchar columns. A SELECT * returns them verbatim; the agent can't tell a regulated column from a benign one.
3. Read-write servers let agents mutate production. When the server is configured for read/write (AWS's supports it; others default to it), the agent isn't just reading — an UPDATE, DELETE, or INSERT generated from a misread prompt lands on live data. Read-only is a real configuration choice, and many deployments don't make it.
4. There is no row or column filter in the path. SQL has no WHERE not_regulated = true. Whatever the connected role can read, a single query returns — and a wide SELECT across a million-row table pulls regulated data in bulk straight into the model's context window.
5. Bulk SELECT is one prompt away. "Show me all customers and their payment details" is a valid query. Without a guardrail, the agent runs it, and thousands of regulated rows flow to the model in a single tool response — far more than any human would copy by hand.
The DLP a company already runs — network edge, file share, SaaS-native rule engine — does not sit in the SQL path between an agent and Postgres. The query result goes straight from the database into the AI agent's context window. That reach is precisely why each agent's access to Postgres must be governed: controlled (which tables and columns it can touch, and whether it can write or bulk-export), the sensitive data it returns protected, and every query audited. That is where Strac Postgres MCP DLP lives.
Strac's Postgres MCP DLP is the governance layer that sits between AI agents and the Postgres MCP server. Strac governs every query: it sees exactly what each agent runs, controls what it can reach and do, protects the sensitive columns it touches, and logs every call as audit evidence. In-policy, non-sensitive queries flow through untouched.
What this looks like in practice, mapped to See / Control / Protect / Prove:
orders and accounts but never payment_methods or auth_tokens. Writes (UPDATE / DELETE / INSERT) and bulk exports above a row threshold are blocked or routed for approval, so a misread prompt can't mutate production or vacuum a whole table.SSN column returns masked, a card_number tokenized, a secret vaulted behind a short-lived retrieval link — the agent still gets a usable result set, but the regulated values never enter the model context.The same Strac MCP DLP layer covers your other data warehouses and SaaS surfaces — Snowflake MCP, Databricks MCP, and BigQuery MCP — one control plane across every place AI agents query your regulated data. See the MCP DLP pillar for the full control model.
MCP DLP governs the AI-agent query surface. Strac's native Postgres DLP governs the data at rest — the same database, but discovered and classified so you know where the regulated columns are before any agent ever queries them. This is DSPM for Postgres, and most teams run both: native discovery to map and label the sensitive data, MCP DLP to govern how agents reach it.
What Strac's native Postgres DLP includes:
notes field holding clinical data or a metadata blob hiding tokens is caughtFor the broader practice this sits inside, see DSPM for AI. For every SaaS, cloud, database, and endpoint surface Strac covers, see strac.io/integrations.
The screenshot below shows Strac's MCP DLP redacting sensitive data from a real Claude session — customer emails, identifiers, and credit card numbers tokenized inline before the model received them. The same inspection pattern runs on every Postgres MCP query routed through Strac, applied column-by-column to the returned rows.
Setup is agentless and takes under 10 minutes.
json
"mcpServers": {
"postgres": {
"url": "https://mcp.strac.io/postgres",
"auth": { "type": "bearer", "token": "<your-strac-token>" }
}
}
For Cursor, OpenAI Agents, and custom agents — same endpoint, same auth.The same Strac Postgres MCP DLP control produces evidence mapped to every major compliance framework.
For the broader AI-data-governance program this sits inside, see AI DLP.
There are several, and the choice is a security decision, not just a tooling one. The community reference postgres server runs every query inside a read-only transaction — a sensible default that prevents the agent from mutating data. AWS's official Aurora/RDS PostgreSQL MCP server supports read-only and optional read/write, scoped by the role you connect with, and AWS explicitly recommends a dedicated least-privilege role rather than a superuser. Several third-party servers default to read/write. None of them — read-only or read-write — redact regulated columns from the rows they return; read-only still streams plaintext PII straight to the model. So the answer is: pick read-only unless you genuinely need writes, always connect a narrow role, and put a DLP layer like Strac in front so the rows themselves are inspected, not just the privileges.
The Postgres MCP server is a Model Context Protocol implementation that lets AI agents (Claude, Cursor, ChatGPT, Perplexity, custom agents) query a PostgreSQL database through standardized tool calls — listing schemas, describing tables, running SQL, and on some servers writing back. It's how an AI assistant gets live, natural-language access to your production data.
By itself, no — not without a governance layer. The server honors the connected role's privileges but returns whatever that role can read, including plaintext PII, credentials, and financial data, with no row or column filtering. For production use against regulated data you need an MCP-layer control like Strac Postgres MCP DLP that scopes table and column access, blocks risky writes and bulk exports, and redacts sensitive columns before any row reaches the model.
Postgres's built-in controls — role privileges, row-level security, column grants — gate what a role is allowed to read. They don't inspect the contents of the rows that come back. A role granted SELECT on users returns every SSN in that table in plaintext. Strac inspects the actual returned rows and redacts regulated columns inline, and it adds the controls Postgres lacks for agents: write-blocking, bulk-export thresholds, and a per-query audit log. It complements least-privilege roles; it doesn't replace them.
Yes. Strac exposes a standard MCP endpoint, so any MCP-aware AI client routes its queries through it with one configuration change. No SDK changes, no application code changes.
Yes. Strac inspects the SQL before it executes. Write statements (UPDATE, DELETE, INSERT, DDL) can be blocked outright, allowed only on specific tables, or routed for human approval — so even a read-write server can't let a misread prompt mutate production. Bulk reads above a row threshold are gated the same way.
PII (SSN, driver's license, passport, address, phone, email), PHI (clinical notes, MRN co-occurrence, ICD-10 codes adjacent to identifiers, lab values), PCI (full and partial card numbers via Luhn check), credentials (API keys, AWS / GCP / Azure access keys, OAuth tokens, JWTs, SSH keys, private keys — 48+ patterns), and custom detectors trained on your internal classifications. Detection runs column-by-column across the returned rows, including text inside JSON/jsonb columns.
Redacted values are replaced inline in the result set. Optionally, a sensitive column value can be vaulted — swapped for a short-lived retrieval link only authorized users can resolve — so the original is recoverable for legitimate use without ever entering the AI context. Vaulted data is stored encrypted at rest in your Strac tenant; you control retention.
Under 10 minutes for the first database. Connect Strac with a least-privilege Postgres role, paste the Strac MCP endpoint into your AI client's config, pick a policy template, done. No application changes, no schema migration, no Postgres re-grant.
The Postgres MCP server is fast becoming the way AI agents read — and sometimes write — your production database. That surface is the rawest, most regulated data your organization has: plaintext PII, credentials, and financial rows, one SELECT away from the model's context window. Running Postgres MCP in 2026 without an MCP-layer governance control isn't a question of if the first incident reaches your security team; it's when.
Strac Postgres MCP DLP gives you the control plane — see every query, scope every agent, protect every regulated column, prove every call — so your team can use PostgreSQL with Claude, Cursor, ChatGPT, and any future AI client without making each one a separate security exception.
If you are running — or about to run — Postgres MCP in production, book a 30-minute demo. We'll walk through the architecture, the read-only-vs-read-write decision, the policy templates, and a deployment plan for your specific database and AI clients.
For the broader MCP DLP control plane across every data surface, see the MCP DLP pillar. For more data-platform deep dives: Snowflake MCP, Databricks MCP, BigQuery MCP.
.avif){kind=icon}
.gif)
