Every engineer knows the rule: secrets don’t go in prompts. API keys, database URLs, session tokens, internal credentials: none of it should ever reach a model provider. It’s the kind of rule nobody argues with and almost nobody enforces, because enforcement was never the hard part. The hard part is that secrets end up in prompts anyway, through paths no one designed and no one is watching.

This isn’t a hypothetical. It’s the default behavior of the systems most enterprises are shipping right now.

The rule that doesn’t hold

OWASP now ranks Sensitive Information Disclosure as the #2 risk for LLM applications , and it names security credentials explicitly among the data types models expose. The same guidance makes a point worth sitting with: restrictions written into a system prompt “may not always be honored and could be bypassed via prompt injection.” Telling the model not to leak secrets is not a control. It’s a suggestion, and an unreliable one.

The reason secrets keep arriving in the first place is that the surrounding software puts them there. Credentials get hardcoded into source, pasted into config, and echoed into logs and error output, and the volume of machine-generated code keeps climbing as developers work alongside AI assistants. Every line of that code is another place a live credential can be captured and, eventually, forwarded to a model. The tooling that produces enterprise code has quietly become a contributor to enterprise secret sprawl.

Where it actually leaks

If secrets only reached the model through prompts a human typed, this would be a training problem. It isn’t. The leak paths are structural, and they sit inside the agent machinery itself.

  • Debug output. In a study of 17,022 LLM agent skills, debug logging alone accounted for 73.5% of the credential-leak patterns found, and 89.6% of the leaked credentials were immediately exploitable. A print statement left in a skill is not a bug in the conventional sense. It’s a live exfiltration channel.
  • Tool outputs and error messages. A survey of 10,655 MCP servers found 12.4% exhibited privacy-leakage risk , with credentials the single most common leaked data type at 56.22%. Values get silently folded into serialized tool outputs and error messages; once the client forwards them, the remote model treats them as legitimate context.
  • Inter-agent chatter. Multi-agent systems leak through channels that never appear in the final answer. The AgentLeak benchmark measured total system exposure at 68.9% , with internal messages between agents leaking far more than the outputs a user actually sees. An audit that only inspects the final response misses most of it.

The common thread: none of these paths run through a prompt a reviewer would ever read. The secret is in the traffic, not the transcript. You cannot catch it by inspecting what your developers wrote, because your developers didn’t write it.

Why this is a control-plane problem

The instinct is to fix this at the edges: scan repos harder, train developers, add a linter, write a stricter system prompt. Each helps at the margin. None of them sees the actual egress, because the actual egress is the stream of requests leaving your environment for a model provider, request by request, agent by agent.

That gap has a price attached. IBM’s 2025 Cost of a Data Breach report found shadow AI was a factor in one in five breaches, adding an average of $670,000 to breach cost, and of the organizations that suffered an AI-related breach, 97% lacked proper AI access controls. That last figure is the real story. The problem is rarely that a company decided AI traffic didn’t need governing. It’s that there was no place to put the control, so it never got put anywhere.

Secrets in prompts are one instance of a broader truth: the boundary between your applications and your model providers is now a data-egress boundary, and for most enterprises it is completely uninstrumented. Every other egress path you have (email, endpoints, cloud storage) sits behind something that inspects it. AI traffic, for now, does not.

What good looks like

The fix isn’t a smarter prompt or a better-behaved model. It’s treating AI traffic like every other kind of sensitive traffic: as something that passes through a control layer on its way out. Concretely, that means:

  • Inspection in flight, at the boundary, independent of any single application or agent, so coverage doesn’t depend on every team remembering to opt in.
  • Sensitive data caught and stopped before it reaches a provider, rather than discovered later in someone’s logs.
  • Visibility across every leak path (prompts, tool outputs, inter-agent messages), not just the final response a user sees.
  • Enforcement that lives outside the model, because anything living inside it can be talked out of the rules.

OWASP’s own mitigation guidance points the same direction: detect and redact sensitive content before it is processed, rather than trusting the model to hold a line. That is a job for a control point in the path, not a policy in a prompt.

Secrets were never supposed to be in prompts. They end up there anyway: through debug logs, tool errors, and agents talking to each other in channels no one is watching. The only reliable place to catch that is the boundary the traffic crosses on its way out. That boundary is exactly where Milgram sits.