PostgreSQL (hardened, read-only) MCP server

postgres-mcp-hardened

### 🚧 Version 0.1.10 — the rest of an outside review, and a fix that was too blunt Published: binaries for five platforms with checksums, Sigstore signatures and build provenance; .mcpb bundles for one-click install; an image on ghcr.io for amd64 and arm64; a package on npm; and an entry in the official MCP registry. 0.1.8 and 0.1.9 closed six bypasses that four independent reviewers found in 0.1.7, none of them found by us. Two days of our own adversarial work had come back mostly clean the day before. Passing the tests you thought to write is not the same as looking. The one that mattered most needs no privileges at all: with a column redacted, a join on it through USING answered whether a given value was present, which is a complete equality oracle against the least-privilege reader this project tells you to configure. 0.1.10 closes the three findings that were left open. With MCP_ALLOW_SCHEMAS=public, SELECT * FROM secret.salaries was refused while describe_table handed over every column, type and default of that same table. An ordinary connection string carrying no sslmode used the driver's prefer, which sends everything in the clear whenever the server declines TLS, and anyone on the wire can make it decline. And MCP_SSLROOTCERT added a private certificate authority to 242 public ones instead of replacing them, so an operator who believed they had pinned trust to their own issuer had not. The first version of that TLS fix was wrong in a way worth reading about. It asked "is this loopback" and demanded TLS from everything else, which took down six PostgreSQL version jobs, the conformance run, the container check and the adversarial corpus in a single push. All of them reach the database the way ordinary deployments do: postgres://user:pass@postgres:5432/db, a service name on a private network. Docker Compose and Kubernetes are not the public internet, and a server that demands TLS from a container on a bridge network is a server people switch off entirely. The question is now whether somebody untrusted can sit on the wire, not whether the address is loopback, and a real socket to a PostgreSQL reachable only by service name is in the test suite, because a rule about networks should be tested over a network. A resource limit is documented and not solved, in `THREAT_MODEL.md`: 49 bytes of SQL make PostgreSQL fold a constant into 5.9 GB of backend memory during planning, and a five second statement_timeout does not stop it. The obvious shapes are refused; the general problem is upstream of anything this server can do. Every change here was reproduced against a running server before being fixed, and each is in `CHANGELOG.md` with the query. Everything here is 0.1.x because nobody outside this project has run it against their own data.

The official Postgres MCP server was deprecated in 2024 and still gets 467k downloads a month. Its entire defence is one database-level read-only transaction — and that alone does not stop every write. This is a maintained Rust replacement with defence in depth.

A drop-in Model Context Protocol server that lets an AI agent query PostgreSQL — read-only, enforced at the database level, with real SQL validation, timeouts, cost limits, OAuth 2.1, and an audit trail. Speaks Streamable HTTP and stdio, and negotiates the MCP revision: 2026-07-28 (current, and the default since upstream released it on 2026-08-03), 2025-11-25, and 2025-06-18 — what most shipping clients still speak today. A client asks for what it knows; it is not negotiated down.

Try to break it — one command, no database

The read-only guard has an offline mode. Hand it a statement and it says what it decided: no database, no configuration, nothing installed permanently.

npx postgres-mcp-hardened --validate "/* comment */ DROP TABLE users"
# REJECT: non-read-only statement: Drop

npx postgres-mcp-hardened --validate "SELECT 1; DROP TABLE users"
# REJECT: multiple statements are forbidden

npx postgres-mcp-hardened --validate "WITH d AS (DELETE FROM t RETURNING *) SELECT * FROM d"
# REJECT: non-read-only statement: non-read-only query (CTE / SELECT INTO / FOR UPDATE)

npx postgres-mcp-hardened --validate "SELECT * FROM orders WHERE id = 1"
# ALLOW

If something that writes comes back `ALLOW`, that is the most valuable thing anyone can send us. It needs no working exploit and no write-up — one line of SQL and "this should not be allowed" is a complete report. Anything that gets past the guard goes through `SECURITY.md`; everything else is an ordinary issue, and the bar for opening one is *this looks wrong to me*, not *I am certain*.

The fuzzer is deterministic and prints its seed, so whatever it finds reproduces on a machine that has never seen yours — a million mutations take about a minute:

npx postgres-mcp-hardened --fuzz 1000000
# fuzz: 1000000 iterations, seed 1592594996, slowest validation 8 ms
# RESULT: 0 invariant violations

For the whole thing against a real database, docker compose -f examples/docker-compose.yml up -d brings up PostgreSQL with sample data and the server in front of it, connecting as a role that holds SELECT and nothing else.

Every bypass found so far lives in the MUST_REJECT corpus in src/validate.rs and runs on every commit, recorded with what it cost rather than tidied away. Yours would join them.

Why

@modelcontextprotocol/server-postgres is deprecated on npm (last publish December 2024) and still sees 475,790 downloads in the 30 days to 9 August 2026. Credit where it is due: its approach is not naive — it wraps each query in BEGIN TRANSACTION READ ONLY and always ROLLBACKs, which is a real defence and one this server now adopts as well.