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 MCPALLOWSCHEMAS=public,

SELECT FROM secret.salaries was refused while describetable 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 391k 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.

Shortened. The full README is on GitHub.