# Stop Leaking Secrets into your LLM Context Windows > Source: > Published: 2026-08-02 11:21:21+00:00 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. This is where we have to move from deterministic pattern matching to probabilistic detection. We need to look at the randomness of the string itself. I recently started working with the Tool Output Entropy Sanitizer, an MCP server specifically designed to catch these high-entropy segments before they ever hit the LLM context window. It doesn't care what the secret *looks* like; it cares how much information density is packed into a specific segment of text. The core engine here uses Shannon entropy calculation. If you aren't familiar, entropy in this context measures the unpredictability or randomness within a string. A standard English sentence has relatively low entropy because certain characters and patterns (like 'the', 'and', spaces) appear with predictable frequency. An API key or a base64-encoded secret is almost pure noise; its character distribution is highly uniform, driving the entropy score up. The server operates on a threshold of 4.5. When it scans text, it uses a sliding-window analysis to identify segments that exceed this limit. It's not just checking the whole string at once—that would be useless if you had a long, low-entropy email followed by one high-entropy key. By sliding a window across the input, it can pinpoint exactly where the randomness spikes. If you use the `sanitize_text_output` tool, it returns the sanitized text and metadata about what was redacted. One detail that engineers usually appreciate is how it handles the redaction itself: instead of just deleting the characters—which destroys the structural context for the LLM—it replaces segments with a structured pattern like `[REDACTED_HIGH_ENTROPY:length]` . This tells the agent, "Something was here, and it was this long," allowing the model to maintain its reasoning about the surrounding text without actually seeing the sensitive payload. When you're building production-grade toolsets, you have to deal with edge cases. You can't just set an infinite window size. If your window is too small, you miss the pattern; if it's too large, you create massive latency and potentially include low-entropy noise that triggers false positives. The server enforces strict operational bounds: any proposed window size must be between 16 and 64 characters. You can use the `verify_window_bounds` tool to audit your configurations before deployment. This isn't just about preventing errors; it's about ensuring predictable performance in an agentic loop where latency spikes can break the entire orchestration layer. If you need to audit a specific substring without modifying its contents—perhaps during a debugging session or for auditing purposes—the `evaluate_segment_entropy` tool allows you to get the entropy score and high-entropy flag directly. This is useful when you're trying to fine-tune your threshold settings. You can find the full implementation of this server at: [https://vinkius.com/mcp/tool-output-entropy-sanitizer](https://vinkius.com/mcp/tool-output-entropy-sanitizer) Security in MCP shouldn't be an afterthought or a single wall; it should be a series of checks. If I'm building an agentic workflow that touches sensitive CRM data, my pipeline looks like this: The goal isn't to make the LLM "blind," but to make it "context-aware without being credential-exposed." As we move toward more autonomous agents—agents that can trigger actions in Salesforce, GitHub, or WhatsApp Business—the surface area for accidental data leakage grows exponentially. We are moving away from simple 'chat' and into 'action.' Every tool call is a potential leak vector. If you're still relying on manual oversight or basic regex, you're leaving too much to chance. Implementing a layer of entropy-based detection allows your agents to be powerful without being liabilities. It turns the problem from "How do I prevent my agent from seeing secrets?" into "How do I mathematically define what a secret looks like?" It is a harder problem than regex, but it's the only way to scale security at the same rate we are scaling agent capability. *MCPs are the music of AI Agents. We built the catalog. Discover Vinkius MCP Catalog.*