Controlling PII Disclosure in Database MCP Connectors

Abstract

Database connectors for the Model Context Protocol (MCP) let large language model (LLM) agents run SQL against production data, and they return rows verbatim into the model's context window with no filtering. This paper contributes a reproducible benchmark and reference-gateway design, evaluated on synthetic data, for what controls at that boundary can and cannot do. Working over a synthetic-PII SQLite database seeded with canary records and a minimal, MCP-style JSON-RPC client/server, we build a six-rung defense ladder, from an unprotected passthrough to a gateway that combines engine read-only, a single-statement SQL guard, a server-authenticated disclosure policy driven by AST source-column lineage, deterministic reversible tokenization, and egress redaction, and measure each rung's marginal effect with a leak oracle that shares no code with the gateway. Two findings are the point of the paper. First, controls that look sufficient are not: an engine-enforced read-only connection blocks writes but leaves over-exposure unchanged, and a naive allow-list keyed on the output column name drops benign over-exposure to zero yet is defeated by nearly half of our 17-attack suite through trivial aliasing and encoding (SELECT hex(ssn) AS x, SELECT password_hash AS x, two bypasses raised in peer review of an earlier draft). Only when disclosure decisions are made on source columns recovered from the SQL AST (resolving aliases, expressions, aggregates, unions, and CTEs) does attacker success on this suite fall to zero while over-exposure stays at zero. Second, masking direct identifiers is not de-identification: on our data, tokenizing names and emails still leaves 99.2% of customers uniquely re-identifiable from three quasi-identifiers, until date-of-birth is generalized (to 12.5%) and then minimized away (to 0%). Alongside, we report an egress PII detector whose held-out F1 is 0.986 but whose recall on adversarially transformed PII is only 0.20, quantifying why value-level detection must be a backstop, not the primary control. We do not evaluate the current MCP specification/SDK, real MCP server implementations, or real LLMs; those, and a faithful reproduction of the disclosed PostgreSQL connector vulnerability, are stated as future work. All numbers are measured on synthetic data; no real personal data is used.