MCP Server Security: PII Sanitization on the stdio Transport
The Model Context Protocol uses JSON-RPC 2.0 messages. Its stdio transport has the client launch the server as a subprocess and exchange newline-delimited messages over standard input and output. That local boundary is a natural place to sanitize traffic before it reaches a model.
Summary
With stdio, the MCP client starts the server as a child process and writes JSON-RPC messages to its stdin while reading responses from its stdout. The server may write logs to stderr. Nothing other than valid MCP messages may be written to stdin or stdout.
A ZTDS gateway wraps that boundary. Tool results that flow back toward the model are tokenized before the client forwards them, and tool arguments that come back from the model are restored locally. The model sees surrogates; the local tools operate on real values.
Message Flow and Sanitization Points
| Flow | Content | Gateway action |
|---|---|---|
| Server to client (tool result) | Records, file contents, and query results that may include PII or secrets. | Tokenize before the result is placed into model context. |
| Client to server (tool call) | Arguments chosen by the model, which may contain surrogates. | Restore surrogates locally so the tool receives real values. |
| Server stderr | Diagnostic logs. | Excluded from model context; review logging separately. |
| Remote transports | Streamable HTTP servers run outside the local boundary. | Out of this page scope; apply the same step in the client before forwarding. |
How ZTDS Applies
Deployment pattern for a local agent client:
- Configure the client to launch the gateway as the stdio command, with the original server as its child.
- Keep the token map in the gateway process memory only (Invariant 3).
- Verify no cleartext appears on any network interface using the perimeter scanner.
- Document which tools are wrapped and which are not.
What This Control Does Not Cover
- It does not defend against prompt injection embedded in tool output.
- It does not constrain what an authorized tool is allowed to do. That is an authorization question.
- Remote servers outside the local process boundary need the same sanitization in the client before forwarding.
- The protocol details here follow the public MCP specification; verify against the version your client implements.
Frequently Asked Questions
How does the MCP stdio transport work?
The client launches the MCP server as a subprocess, writes newline-delimited JSON-RPC messages to its standard input, and reads responses from its standard output. The server can write diagnostic text to standard error.
Where should PII sanitization sit in an MCP setup?
At the local boundary between the tool output and the model context, so surrogates reach the model while tools keep working with real values.
Does stdio sanitization protect against malicious tool output?
No. It reduces personal data exposure. Injection and tool authorization risks need separate controls.
Related Specifications and Tools
- MCP Security Architecture — In-RAM gateway for Model Context Protocol traffic.
- AI and RAG Blueprints — Integration recipes for agent and retrieval stacks.
- ZTDS RFC v1.0 Specification — The four invariants referenced on this page.
- Framework Mappings Hub — All framework mappings in one index.
- OWASP LLM02 Sensitive Information Disclosure — Maps pre-egress tokenization to OWASP LLM02:2025 and states what it does not cover.
- NIST AI RMF Generative AI Profile — Places ZTDS across GOVERN, MAP, MEASURE, and MANAGE for generative AI data privacy risk.
- EU AI Act Article 10 Data Governance — Describes how pre-ingestion sanitization supports Article 10 data governance practices.
- GDPR Articles 25 and 32 for AI Prompts — Explains data protection by design and security of processing for prompts sent to AI providers.
- HIPAA Safe Harbor for LLM Prompts — Shows how 18-identifier removal applies to clinical text sent to language models.
- RAG Pipeline PII Sanitization — Places sanitization at ingestion, retrieval, and prompt assembly stages of a RAG pipeline.
- Client-Side Sanitization vs Proxy DLP — Compares client-side in-memory sanitization with network proxy and cloud DLP approaches.