postgres-mcp-hardened

postgres-mcp-hardened

🚧 Version 0.1.0 — released, not yet used by anyone but us

The first release is out: binaries for five platforms, with checksums, Sigstore signatures andbuild provenance. It is not in the MCP registry yet.

What is actually proven, in the sense that something other than an opinion checks it: theread-only rules (a fuzz harness over 200k mutations, an adversarial corpus of every bypass foundso far, PostgreSQL 13–18); the authorisation path end to end; protocol conformance, checked by theofficial MCP SDK rather than by our own tests; the release path, whose signatures have beenverified by hand — including that a tampered file and a wrong identity are both rejected; and thepublished binary itself, downloaded from the release page and run against a live database.

What is not: nobody outside this project has run it against their own data. That is the wholereason this is 0.1.0 and not 1.0. Every adversarial round run against this code so far has foundsomething real, including rounds run after the previous one came back clean — the day of therelease itself produced four, one of which handed a superuser role to anyone who could create atable. The honest reading is that the next round would find something too.

Known limits, and the places we were wrong, are written down rather than tidied away:THREAT_MODEL.md, docs/AUDIT_2026-07-26.md.If you find something, SECURITY.md says how to say so.

The official Postgres MCP server was deprecated in 2024 and still gets ~440k 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: 2025-11-25 (current), 2025-06-18 (what shipping clients speak today), and 2026-07-28 behind a switch while it is still a draft.

Why

@modelcontextprotocol/server-postgres is deprecated on npm (last publish December 2024) andstill sees ~440,000 downloads a month. Credit where it is due: its approach is not naive — itwraps each query in BEGIN TRANSACTION READ ONLY and always ROLLBACKs, which is a real defenceand one this server now adopts as well.

The problem is that it is the only defence, and it is not complete:

• A read-only transaction does not block every write. PostgreSQL executespg_import_system_collations() inside SET TRANSACTION READ ONLY without raising SQLSTATE 25006— it inserted 874 rows into pg_collation in our tests. gin_clean_pending_list() rewrites indexstructures; pg_backup_start() puts the server into backup mode and survives DISCARD ALL. Therollback saves you from the first case, not from the side effects that live outside transactionsemantics.
• No statement timeout, no cost guard, no row limit — one query can run until the server gives up.
• No authentication, no audit trail, no handling of prompt injection through returned row data.
• 113 lines, unmaintained since 2024, no test suite.

This server keeps the rollback, adds AST validation in front of it, and adds the operational layersthe original never had.

postgres-mcp-hardened vs the archived original

Install

Three ways in, in the order most people want them.

Through npm — shortest, and the one your MCP client config can point at directly. There is noNode runtime involved at run time: the package is a launcher that fetches the native binary for yourplatform and verifies its checksum before running it.

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "postgres-mcp-hardened", "--stdio"],
      "env": { "DATABASE_URL": "postgres://readonly_user:PASSWORD@localhost:5432/mydb" }
    }
  }
}

The connection string goes in env, not in args, on purpose: arguments show up in ps output andin shell history on a shared machine, and a database password does not belong there.

A binary from the releases page — one static file, nothing to keep up to date, and the option totake if your machine has no Node at all. Every release carries builds for Linux, macOS and Windowson x86-64 and arm64, each with a checksum and a signature; verifying them is the next section.

From source — cargo build --release in a clone. Not cargo install: this crate is not oncrates.io, and an instruction that fails is worse than one that is missing.

Checking what you downloaded

Every released binary is signed with Sigstore keyless signing — thereis no private key for us to lose, and the certificate names the workflow, repository and tag thatproduced the file. Each artefact ships with a .sig and a .pem beside it:

F=postgres-mcp-hardened-x86_64-unknown-linux-gnu.tar.gz
cosign verify-blob "$F" --bundle "$F.bundle" \
  --certificate-identity-regexp '^https://github.com/Eszetael/postgres-mcp-hardened/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Pin the identity, not just the signature. Without --certificate-identity-regexp and--certificate-oidc-issuer the check answers "somebody signed this", which is not the question.A verified certificate names the workflow, the repository and the tag that built the file — youcan read it with base64 -d "$F.pem" | openssl x509 -noout -text (cosign writes the certificatebase64-encoded, which surprises people who try openssl on it directly).

Older cosign builds predate --bundle; separate .sig and .pem files are published alongsidefor them, used as --signature "$F.sig" --certificate "$F.pem". Current cosign marks those flagsdeprecated, so prefer the bundle.

Public releases additionally carry SLSA build provenance, verifiable withgh attestation verify <file> --repo Eszetael/postgres-mcp-hardened.

Use it in Claude Desktop / Cursor (stdio)

{
  "mcpServers": {
    "postgres": {
      "command": "postgres-mcp-hardened",
      "args": ["--stdio"],
      "env": { "DATABASE_URL": "postgres://readonly_user:YOUR_PASSWORD@localhost:5432/mydb" }
    }
  }
}

Or run it as a remote server (Streamable HTTP)

DATABASE_URL="postgres://readonly_user:YOUR_PASSWORD@host:5432/mydb" \
MCP_ADDR="0.0.0.0:8080" \
postgres-mcp-hardened
# POST /mcp   ·   GET /health   ·   GET /ready   ·   GET /metrics

TLS: connections to PostgreSQL are encrypted whenever the server supports it, andsslmode=require, verify-ca and verify-full are all accepted (the certificate chain andthe hostname are always verified, so require behaves like verify-full) — so managed Postgres (RDS, Supabase, Neon, Render)works out of the box. Certificates and host names are always verified — verified (acceptance: "a certificate naming another host is refused, by name"); for a private CA, pointMCP_SSLROOTCERT at the PEM bundle. There is no "trust anything" switch.

Tip: point DATABASE_URL at a least-privilege read-only role. The server enforces read-only itself, but a scoped DB role is defense-in-depth.

Or run it on a container platform (Apify Standby)

The server needs no code changes to run as an Apify Actor in Standby mode. It reads the port theplatform assigns from ACTOR_WEB_SERVER_PORT and binds 0.0.0.0 there — that port wins overMCP_ADDR, loudly, on stderr, because binding anywhere else means the run is never marked ready andthe failure looks like a mysterious timeout. GET / answers the platform's readiness probe(x-apify-container-server-readiness-probe) without touching the database: container readiness isnot database readiness, and a probe that waits on a busy pool turns a slow database into a containerthat never starts.

Input is a JSON-RPC request in the POST body — initialize, tools/list, tools/call,resources/list, resources/read, server/discover. Output is a JSON-RPC response; from2025-11-25 a refused statement comes back as a tool execution error (isError: true) with thereason in the content, so the model can rewrite the query. tools/list is the authoritativedescription of every argument.

Authentication there is the platform's, not ours. Apify checks the caller's token before routingto the container, so the server does not additionally demand MCP_BEARER_TOKEN — requiring a secondsecret would mean an agent that finds this server cannot call it. That exemption is narrow: it needsboth APIFY_IS_AT_HOME and ACTOR_WEB_SERVER_PORT, one alone changes nothing, and the servercard then reports "type": "apify-platform" rather than claiming a lock we do not hold. Everywhereelse the server still refuses to start on a network address with no authentication. SetMCP_BEARER_TOKEN as well if you want a second lock on the same door.

The other start gate is unchanged and matters more here: a role that can write is refused a networklistener. Point DATABASE_URL at a read-only role — --print-setup-sql writes the statements.

Migrating from the deprecated server

The most-discussed problems reported against @modelcontextprotocol/server-postgres werereproduced against this server; here is how each behaves:

Testing

Beyond unit tests, the repository carries two harnesses that run in CI on every change:

• --fuzz — a deterministic fuzzer that mutates a corpus of known writes with transformationsthat do not change SQL meaning (comments, case, dollar-quoting, invisible Unicode, parentheses)and asserts that none of them ever becomes an allowed statement.
• tests/acceptance.sh — an end-to-end suite that starts its own PostgreSQL and checks 43behaviours: every write-bypass reported against the deprecated server (including theCOMMIT/END injection), truthful results, schema introspection, protocol conformance,configuration mistakes failing loudly, audit tamper detection, fair use under load, andmulti-database deployments.

Every reported problem, answered

docs/COMMUNITY_ISSUES.md is the complete ledger: every problemreported against the deprecated server and every open issue against the maintained alternatives,each with what happens here — including the handful we could not fix in code, said plainly.

What we learned from the alternatives

Every server in this space has an issue tracker, and those trackers are a map of what goes wrong.The ones we deliberately built against:

• A published image that lags the code. The most-supported open complaint against the leadingalternative. Our container is built and pushed from the same tag that produces the binaries, soit cannot drift.
• A hardcoded query timeout. Also among their most requested settings. MCP_STATEMENT_TIMEOUTis configurable and validated at startup.
• Unrestricted access by default. Some servers default to read/write and rely on the operatorto restrict it. This one has no write path at all.
• Credentials in the client configuration. MCP_PASSWORD_FILE keeps the password out of it.
• Tables in a non-default schema silently not found. MCP_SEARCH_PATH fixes the lookup, andthe tools take an explicit schema anyway.
• Deprecated transport. SSE was replaced by Streamable HTTP in the 2025-06-18 specification;we speak the current one.

Troubleshooting

Answers to the questions people actually asked about the deprecated server, so nobody has to openan issue to find them.

spawn npx ENOENT / "which Node version do I need?" — none. This is a single static binary.Download it from the releases page and point your clientat the file. There is no node_modules, no npx, nothing to keep up to date.

"The server starts but nothing is listening on a port." — that is stdio mode, which is correctfor Claude Desktop and Cursor: the client talks to the process over its standard input and output,not over a socket. If you want a network endpoint, start it without --stdio; it then printsMCP HTTP listening on http://… and speaks Streamable HTTP.

"Can my client on another machine reach the database?" — yes: run the server next to thedatabase in HTTP mode, expose it, and enable OAuth (JWT_PUBKEY_PEM, JWT_AUD, JWT_ISS). Thedatabase credentials then never leave the host the server runs on.

"Could not attach to MCP server." — the process exited before the handshake. Run the samecommand in a terminal: a configuration mistake prints its reason and exits with status 2 ratherthan dying quietly, and a connection problem is reported on the first query with the cause.

self-signed certificate in certificate chain / unable to verify the first certificate —your provider uses a private CA (Supabase, GCP and RDS all do). Download their CA bundle and setMCP_SSLROOTCERT to it. The error message names the step for your provider. We do not offer a"trust anything" switch.

Managed providers

This server always verifies the database certificate, including with sslmode=require. That isa deliberate deviation from libpq, where require encrypts without verifying and a machine in themiddle can therefore read and rewrite every query and result without anyone noticing. The cost ofbeing strict is that a provider with a private CA needs one extra step; the cost of being lax isthat you never find out. If you disagree with the trade-off, verify-full with the bundle below isthe same amount of work and leaves no doubt either way.

Not sure which case you are in? Ask the server itself, before configuring anything:

echo | openssl s_client -starttls postgres -connect YOUR_HOST:5432 2>/dev/null \
  | openssl x509 -noout -issuer

A well-known issuer (DigiCert, ISRG, Google Trust Services) means it will just work; anythingnaming your provider means you need their bundle.

With a connection pooler (Supavisor, PgBouncer) in transaction mode, note that this server setsstatement_timeout and idle_in_transaction_session_timeout per session and runs every query in anexplicit read-only transaction. Both are compatible with transaction pooling; session-levelSET outside a transaction is not, which is why we do neither.

no pg_hba.conf entry … no encryption — the server accepts only TLS connections for thathost and user. Add ?sslmode=require to the connection string.

INVALID_URL / invalid connection string — a password containing @, :, /, # or ?must be percent-encoded (@ → %40, : → %3A, / → %2F, # → %23).

"My table has hundreds of partitions and the list is unusable." — partition children are hiddenby default; the parent is listed. Set MCP_SHOW_PARTITIONS=1 if you need them.

"I need production and staging at the same time." — either run one server per database (theyare distinguishable: set MCP_SERVER_LABEL), or configure both in one server withMCP_DATABASE_URLS and pass database in the tool arguments.

Resources

Every table and view is exposed as an MCP resource (postgres:///<schema>/<table>/schema), so aclient can browse the schema without issuing a query — the same capability the deprecated serveroffered, plus column comments, primary keys and foreign keys in the payload.

Tools

• explain_query — the execution plan; with analyze it runs the statement and reports realtimings and buffer usage, which is safe here because the statement is validated read-only and runsinside a transaction that is always rolled back. The plan comes with a summary: which node spentthe time (self time, not inclusive), and where the planner's row estimate was furthest fromreality — because a bad estimate is usually why the plan is bad.
• database_health — cache hit ratio, connections (this database and the cluster), the longestrunning statement and the longest abandoned transaction as separate figures, vacuum backlog,invalid indexes, sequences near their ceiling, replication lag, tables that have never beenanalysed (no planner statistics — the usual reason a database looks healthy and runs slowly), andthe window the counters cover. Anything the role cannot see is declared rather than returned as aconfident zero.
• analyze_indexes — unused indexes, duplicates, and tables scanned sequentially often enoughthat an index would pay off.
• top_queries — the heaviest statements, from pg_stat_statements.
• security_posture — what this deployment is actually able to do to your database, asked ofPostgreSQL rather than assumed: whether the role can write, bypass row-level security or reachserver files; whether the transport is authenticated; whether the audit chain is keyed; whether theconnection is encrypted. Returns a grade — the worst finding, never an average — and, for anythingwrong, the command that fixes it. The same summary reaches the model through initialize, becauseunder stdio nobody sees stderr and the agent is the only messenger the operator has.
• query — run a read-only SQL query (validated, auto-LIMIT, cost-guarded). The responsestates what it did: returnedRows, appliedLimit, truncated, plus requestedLimit when alarger request was capped at the 10000-row maximum, offset when paging, and redactedColumnswhen masking is configured — so an agent never has to guess whether it received the whole answer.
• list_schemas, list_tables, describe_table — progressive schema discovery(parameterized, injection-safe). describe_table returns the schema comments(COMMENT ON TABLE/COLUMN), primary keys, foreign keys and defaults, so the agent reads what acolumn means and what it points at instead of guessing from its name — and a missing table is anerror, not an empty column list.

Protocol revisions

The server answers initialize with the revision the client asked for when it implements it, andwith its newest otherwise. Over HTTP the revision comes from the MCP-Protocol-Version header, perrequest — one client's negotiation cannot change the contract another client is served under.

If a request carries no header, the server does not fall straight back to the oldest contract. Itreads the revision this session agreed on at initialize, which is what the transportspecification asks for: the default applies only "if the server does not receive anMCP-Protocol-Version header, and has no other way to identify the version — for example, byrelying on the protocol version negotiated during initialization". A session is that other way, so aclient that negotiated 2025-11-25 and then omitted the header keeps the contract it agreed torather than being silently demoted.

A header we cannot parse is a different matter from a header that is absent, and the specificationis explicit about it: "If the server receives a request with an invalid or unsupportedMCP-Protocol-Version, it MUST respond with 400 Bad Request." A version we do not implement —2025-03-26 or not-a-date — is refused with 400and the list of revisions we do speak, rather than served under a contract the client never agreedto. Falling back is for silence, not for disagreement.

Only a request with neither a header nor a session falls back, and it falls back to 2025-06-18 —the oldest revision this server implements — rather than the 2025-03-26 the specification names.That revision is not implemented here, and answering under a contract the server cannot honour wouldbe worse than answering under the oldest one it can.

The difference that matters is where a refusal goes. Under 2025-06-18 "this statement is notread-only" was a JSON-RPC error: the client saw a broken call and the model often never saw thereason. From 2025-11-25 (SEP-1303) it arrives as a tool execution error — isError: true with thereason in the content — so the model rewrites the query instead of handing the user a failure. Whatdoes not change is the audit: the refusal is recorded by the code that refuses, and the acceptancesuite asserts both halves together, so friendlier errors can never quietly mean a quieter log.

Mcp-Method and Mcp-Name are held to agreement, not presence. The draft requires them; earlierrevisions do not, and demanding them would break every client shipping today. But a gateway thatroutes or authorises on Mcp-Method while the server executes the body has decided about adifferent request than the one that runs — and that is true whatever revision is in force. So aheader that is present must match the body under every revision, while a client that sends none isuntouched.

Protocol failures stay protocol failures. A malformed envelope, an unknown method or a missing tokenis not something a model can fix by rewriting SQL, and a client's error handling expects those wherethey have always been.

The next revision, before it lands

2026-07-28 is the largest break MCP has had: no initialize, no session header, no ping. Thatidentifier comes from LATEST_PROTOCOL_VERSION in the draft schema, and it is not a release date —MCP names a revision for the last date a backwards-incompatible change was made, so it describes thedraft's history rather than a schedule. Every request carries its own protocol version in _meta,and a new server/discover replaces the handshake. We implemented it early behind a switch, becausea draft moves and a server advertising support for a moving target will be wrong in public. Upstreamcut schema/2026-07-28 on 2026-08-03 — the released schema differs from the draft we had verifiedagainst in four documentation URLs and nothing else — so the switch is gone and this is what theserver speaks by default. Clients on 2025-11-25 and 2025-06-18 are answered as before.

server/discover answers under every revision, because the specificationexpects clients to use it as a backwards-compatibility probe — which only works if older serversanswer it. Ours answers with the revisions we speak and, in _meta, the full security posture. Thatis deliberate: a client can learn it is talking to a server connected as a superuser before itsends a query, as structured data rather than prose a model has to notice.

Two of the draft's rules are security controls here, not formalities. Mcp-Method and Mcp-Namemust agree with the request body, and we refuse the mismatch (-32020) — the headers exist so agateway can route and authorise without parsing the body, and if header and body may disagree, thenthe thing that authorised and the thing that executes saw two different requests. And a clientstating a version we do not implement is told so (-32022) rather than quietly served under acontract it never agreed to.

What the safety costs

Measured, not asserted: tests/bench/, against the pg driver running the same query on the samemachine (PostgreSQL 18 in Docker, 50k-row table, 300 sequential requests, rate limit off).

About 4 ms per query, and the shape of that number matters more than the size: it is nearlyconstant. If the AST validation were the cost, it would grow with the query. It does not. The timegoes on round trips — the session is reset, the timeouts and read-only flag are set, a read-onlytransaction is opened, the cost guard plans the statement, then the query runs and the transactionis rolled back. Five or six exchanges where the driver has one.

That is a deliberate trade and you can see exactly what it buys. For an agent making tens of callsit is invisible; if you are putting this in front of a latency-critical serving path, you are usingthe wrong tool, and it is not one.

Under concurrency the interesting number is not throughput but what happens past the limits: at 8concurrent clients it served 373 requests/second and turned away 192 more with "too many requests inflight", which is the in-flight cap doing its job rather than a queue growing until something fallsover.

Would this index help? — answered without creating one

The one capability the leading alternative is genuinely known for is index tuning: it can tell youan index would pay off before you build it. It gets there by defaulting to a connection that cancreate real indexes — safe only if you remembered to restrict it.

simulate_index answers the same question from a connection that cannot write anything.hypopg registers a hypothetical index in backend memory: theplanner sees it, storage never does, and it is gone when the call returns. You get the plan and costwith and without, and — separately — whether the planner actually reached for it, because a costthat barely moves and an index the planner ignored are different answers.

The tool takes a table and a list of columns. Not a CREATE INDEX statement. The definition isassembled server-side from identifiers the catalogue confirmed exist, quoted by PostgreSQL itself,so there is no path from a tool argument to arbitrary DDL — a column name carrying SQL dies on thecatalogue lookup, and there is a test that fires exactly that. The numbers are planner estimates:treat a large improvement as a reason to test the index, not as proof.

Conformance is checked by somebody else's client

Every other test here is our harness talking to our server. If we misread the specification, wemisread it the same way in both halves and everything passes. So CI also drives the server with theofficial MCP SDK — the client library the ecosystem uses — over stdio and Streamable HTTP:handshake, tool listing and schemas, a read, a refused write arriving as a tool execution errorrather than a protocol one, resource listing and reading. A protocol mistake shows up as a clientthat cannot talk to us. tests/conformance/.

Working on this

git config core.hooksPath .githooks   # once, per clone

.githooks/pre-push runs format, clippy, the unit tests and the documentation-claim checks beforeanything leaves your machine. It exists because of a specific mistake: a commit went out with afailing clippy lint, and the first anyone knew of it was a failure email. Note that cargo testpasses on that code — clippy lints are not compiler errors — so "it builds locally" is not thesame answer as "CI will be green".

It deliberately skips the acceptance suite and the PostgreSQL matrix: those need Docker and abouttwenty minutes, and a hook people cannot afford to run is a hook people bypass. CI runs everything.git push --no-verify when you want to see something fail in CI on purpose.

Setting up the role

DATABASE_URL=postgres://admin@host/mydb postgres-mcp-hardened \
  --print-setup-sql --role mcp_reader --schemas public --redact ssn,email > setup.sql
# read it, then:
psql -v pw="$(openssl rand -base64 24)" -f setup.sql mydb

Run with a connection string and the table and column lists come from the catalogue; without one youget the same document with placeholders. The difference matters most for redaction: the columns togrant back have to be read from the database, because writing them from memory is how a column meantto stay hidden gets handed back.

The output ends with checks that return no rows when it worked, and a reminder that the server itselfwill tell you what the role can do the moment you point it at the database.

Limiting what the server can reach

MCP_ALLOW_SCHEMAS and MCP_ALLOW_TABLES restrict which relations a query may touch. Either oneturns the allowlist on; schema.* and schema.table both work.

MCP_ALLOW_TABLES='public.customers,public.orders,analytics.*'

The check reads the query plan, not the SQL. That is the whole design: the planner has alreadyapplied search_path, resolved every alias, expanded views to base tables, and knows that a CTEnamed customers is not the table customers — so WITH customers AS (SELECT 1) SELECT * FROM customers runs and touches nothing, while WITH x AS (SELECT * FROM salaries) SELECT * FROM xis refused. Reading the statement instead is what lost three rounds of adversarial review.

Two consequences worth knowing before you turn it on:

• A partition rides on its parent. You allow events; PostgreSQL decides which children to read.
• A view needs its base tables allowed too, because the plan names those. Allow both, and let thedatabase privileges keep the base table unreachable directly — that is the boundary in any case.

pg_catalog and information_schema are outside the surface unless MCP_ALLOW_CATALOG=1: an agentthat can still read the catalog can enumerate exactly what the allowlist was meant to hide. Theschema tools keep working, because they run fixed queries rather than caller SQL.

That covers three routes to the same facts, because for a while it covered only one. A catalogue viewplans to scans over real relations and the plan names them — but pg_settings plans to a singleFunction Scan on pg_show_all_settings, naming no relation at all, and current_setting() is ascalar call that never appears as a scan. Both used to return the server's configuration under anactive allowlist. Functions whose name begins with pg_, plus current_setting, inet_server_addrand inet_server_port, are now refused alongside the catalogue relations, and MCP_ALLOW_CATALOG=1opens all of them together. Ordinary set-returning functions — generate_series, jsonb_each,unnest, regexp_split_to_table — carry no such prefix and are unaffected. current_user,session_user, current_database and version stay readable on purpose: an agent already knows whatit connected to and as whom.

The corpus of things that got through

Every shape that defeated a control during review lives in tests/adversarial/, with the round inwhich it stopped working. It runs on every build, and — because the cases are written againstplaceholders rather than our fixture — you can point it at your own database:

ADV_URL='postgres://…' ADV_TABLE=people ADV_REDACT_COL=ssn ./tests/adversarial/run.sh

A security claim you can only check by reading our source is a claim you have to take on trust, andthis project's own history is the argument against that.

Security model

The full statement of what this server guarantees, what it does not, and which control enforceswhich promise is in THREAT_MODEL.md — including the controls that have beendefeated in review and are therefore described as depth rather than as boundaries.

• Encrypted transport: TLS to PostgreSQL via rustls (no OpenSSL in the image), certificateverification always on, private CAs via MCP_SSLROOTCERT.

• Read-only, two ways: every statement is parsed with sqlparser and rejected unless it's a SELECT/WITH/EXPLAIN/SHOW; the DB session is additionally set default_transaction_read_only = on.

• Anti-DoS: enforced statement_timeout, auto-injected LIMIT, and an EXPLAIN-based cost guard that rejects expensive plans before they run.

• Sensitive columns — defence in depth, and honest about it: MCP_REDACT_COLUMNS masks valuesat every depth and refuses to run a query that references those columns, including the ways roundit that an adversarial panel actually found — renaming (SELECT password AS pw), wrapping(md5(password)), serialising the whole row (row_to_json(t), t::text, json_agg(t)), andnaming the column as a string rather than an identifier (to_jsonb(t) ->> 'password',#>> '{password}', $.password), whole-row wildcards (ROW(t.*)::text) and positional renaming((SELECT * FROM staff) AS x(c1, …, c9)). It is still name-based filtering, and name-basedfiltering cannot be a boundary against the whole SQL language — three adversarial rounds each gotpast it through a shape nobody had listed.

  So the server stops asserting and asks the database: at startup it reports every table wherethe connected role can still read a redacted column, with the exact statements that fix it, andMCP_REDACT_REQUIRE_REVOKE=1 turns that report into a refusal to run. Note the fix is a table-levelREVOKE followed by a GRANT of the columns that stay — a bare REVOKE SELECT (password) ON staffis silently a no-op while the role holds SELECT on the whole table. With column-level grantsPostgreSQL then refuses SELECT * on that table, so callers name columns instead; describe_tablelists them and marks the redacted one.

• Prompt-injection aware: row data is returned inside a trusted="false" provenance block with delimiters escaped, so a malicious cell can't hijack the agent.

• It generates the role you should be running as: --print-setup-sql writes the DDL for a rolethat inherits nothing, bypasses nothing, creates nothing, reads only the relations you name, and —where you have named sensitive columns — has them revoked in the order that actually works. Itprints; it never executes. Applying this needs administrative rights, and a tool whose wholeidentity is "read-only" has no business holding an administrator's password.

• It will not expose a role that can write: when the listen address is reachable from thenetwork, the server asks PostgreSQL what the connected role is actually allowed to do — superuser,BYPASSRLS, membership of pg_write_all_data and friends, and write privileges on a bounded sampleof tables — and refuses to start if the answer is more than "reader", naming each reason andpointing at --print-setup-sql. It refuses an unauthenticated network listener for the same reason.Loopback and stdio are left alone: there the caller is the operator. The overrides(MCP_ALLOW_EXCESSIVE_ROLE, MCP_ALLOW_ANONYMOUS_NETWORK) take the literal valuei-accept-the-risk so they cannot be switched on by a typo, and they are recorded in the audit log.This server enforces read-only itself, but that enforcement is code, and code has been wrong before;a role that cannot write is the part no bug of ours can undo.

• A browser cannot reach it: a request carrying an Origin is refused with 403 unless theoperator listed that origin, and on a loopback listener a Host that is not localhost is refusedtoo — the shape a DNS-rebinding attack takes when it aims at a database server on your laptop.

• The audit knows the configuration: the chain opens with a startup record naming the version,the transport and every setting in force, with connection passwords stripped and secrets reduced tofingerprints, plus a config_fp an operator can pin across restarts. A log that says what happenedbut not under which settings cannot answer the first question an incident asks.

• The audit notices being shortened: a hash chain proves entries were not altered, but a logwith its tail cut off is internally consistent — recomputing it finds nothing wrong. AlongsideMCP_AUDIT_LOG the server therefore keeps <log>.hwm, a one-line record of the last sequencenumber and hash it wrote, updated only after the entry is durably appended. On start the two arecompared, and a disagreement is reported: entries missing from the end, a rewritten last entry, ora log that has gone away entirely. This is not proof of tampering — an unclean shutdown looks thesame — but a tamper-evident trail owes you the question, not the verdict. Keep the sidecar withthe log when you archive or move it; deleting it only loses the truncation check, never an entry.The offline verifier is unchanged and still needs an external anchor:--verify-audit <file> --expect-last <hash>.

• A wrong setting is fatal, not merely wrong: an unparsable listen address, an audit file thatcannot be written, sslmode=disable to a database on another machine, a metrics token that is alsothe database credential, a boolean spelt yes — each used to be accepted and quietly do somethingother than what was meant. Startup now stops and names the setting.

• A misspelt setting is fatal: MCP_REDACT_COLUMN (singular) used to start the server withredaction quietly switched off. Unknown MCP_* variables now stop startup and name the intendedspelling; MCP_X_* is reserved for the operator's own use.

• No schema leaks: database errors are mapped to structured, actionable messages that never echo table/column names.

• OAuth 2.1: optional RS256 bearer-token validation (signature, exp, aud, iss) with scope enforcement; disabled when unconfigured for local/self-host use.

• Audit: every tool decision is logged as a tamper-evident, hash-chained JSON line (no raw SQL).

• Supply chain: dependency licences, sources and advisories enforced in CI (cargo deny,cargo audit); a CycloneDX SBOM is attached to every release.

• Runtime: ships as a distroless, non-root container (~34 MB, built and smoke-tested in CI).

Footprint

Measured on an ordinary VPS against a 16k-row sample database, so you can check the "written inRust" claim rather than take it:

A twelve-minute soak of mixed traffic (reads, refusals, errors, aborted requests, session churn)left resident memory flat and file descriptors unchanged.

Configuration

License

MIT — see LICENSE.