I've seen it happen more than once in production logs: an AI agent, given access to a database or a third-party API via MCP, returns a payload that includes not just the requested data, but also a session token, an AWS secret, or an obscure API key. It feels like a minor oversight until you realize that this high-entropy string is now sitting in your LLM provider's logs, potentially part of a training set, and visible to anyone with access to your chat history.
The problem isn't just about the data itself; it's about how we handle tool outputs. When we build MCP servers, our instinct is to be helpful—we return everything necessary for the LLM to complete its task. But as soon as you give an agent 'read' access to a system, you are effectively opening a window into that system's sensitive metadata.
You can try to solve this with regex. You could write patterns for SSNs, emails, or common API key formats like Stripe or AWS. This works for deterministic data, and tools like the PII Redaction Deterministic Scrubber handle that well enough. But secrets are fundamentally different. They don't follow a fixed schema. A developer might rotate an auth token to a format you didn't account for in your regex library yesterday.
