AgentGuards
← Blog

Your PII Leak Isn't in the Output. It's Between the Agents.

July 16, 2026· dev@alphaops.devpiimulti-agentllm-securitydata-leakageowasp

A benchmark published this year put a hard number on something a lot of teams suspected but couldn't measure: 41.7% of privacy violations in multi-agent LLM systems happen in internal channels while the final output passes every check. That figure comes from AgentLeak, a full-stack privacy benchmark run across 4,979 execution traces on five different LLMs. Read it slowly. Nearly half of the leaks slip past the exact place most teams put their one and only scanner: the response going back to the user.

If you're screening model output for PII and calling it done, you're auditing the one channel that leaks least.

The output is the safest place PII goes

AgentLeak breaks a multi-agent run into seven channels where sensitive data can escape. Two of them are internal: inter-agent messages (agents talking to each other) and shared memory. The rest are external: final output, tool arguments, tool return values, logs, and persisted files.

Here's the part that should reorganize your threat model. The leakage rates weren't close:

ChannelLeakage rate
Final output to user27.2%
Shared memory46.7%
Inter-agent messages68.8%

Inter-agent messages leaked PII at 2.5 times the rate of the final output. The place you're not watching is the place data actually escapes. When a planner agent hands a task to a worker agent, it tends to forward the entire context, unredacted, because that's the path of least resistance for getting the job done. A customer's tax ID that would never appear in the polished final answer rides along in the handoff payload, gets written to shared memory, and sits there as context for the next task, possibly for a different user.

The one-line version

Output filtering asks "is there PII in the answer?" In an agent system, the more useful question is "is there PII in the message agent A just sent agent B, or in the memory both of them read?" Those are different questions, and the second one is where the leaks live.

Why frameworks make this worse by default

The usual orchestration frameworks propagate full task context between agents with no data minimization step in between. AgentLeak measured inter-agent leakage in benign scenarios (no attacker, no injection, just normal task completion) across CrewAI, AutoGPT, LangChain, and MetaGPT, and every one of them leaked in roughly 28% to 35% of runs. Nobody had to attack anything. The data moved because moving it was the default.

A stripped-down version of the pattern:

code
# Planner agent has the full customer record in context
record = {"name": "J. Okafor", "ssn": "xxx-xx-1234", "issue": "refund"}

# It delegates. The whole dict goes with it.
worker.run(task=f"Resolve this: {record}")

# The worker only needed the issue type.
# The SSN is now in an inter-agent message AND in shared memory.

The worker needed issue. It got the SSN too. Multiply that across a few handoffs and a persistent memory store and you have PII fanning out through channels no output filter will ever see.

A second paper this year, "Got a Secret? LLM Agents Can't Keep It", found the problem compounds over time. In their controlled testbed several models hit leakage rates approaching 50 to 60% at 50 tool calls, and even with explicit privacy instructions in the prompt, leakage stayed above 37.8%. They also documented a social-contagion effect: an agent was roughly 8 times more likely to disclose private info after seeing a peer agent do it (12.8% vs 1.6%). Longer sessions leak more, and telling the model to be careful barely moves the needle.

What OWASP actually recommends

OWASP LLM02:2025 Sensitive Information Disclosure names PII leakage explicitly and its mitigations are more specific than "be careful." It calls for data sanitization and tokenization to detect and redact confidential content before processing, plus strict input validation to filter sensitive data on the way in. Note the direction: before processing, on the way in, not only on the way out.

OWASP is also blunt that prompt-level guardrails ("don't reveal PII") get bypassed via injection and shouldn't be trusted as the control. That matches the 37.8% number above. The instruction is not the enforcement.

Screen every boundary, not just the last one

The fix that follows from the data is unglamorous: treat every model boundary as a checkpoint, not just the final response. Prompt in, tool output in, inter-agent message, memory write. If a scanner only sees channel C1, it is structurally blind to the 41.7% of violations AgentLeak found everywhere else.

That's the design goal behind AgentGuards: screen text at each boundary inline, in under 50 ms, so PII and secrets get caught in the handoff and the memory write, not just the reply. You can point our PII detector at any string, an inter-agent message included, and get back what it found before that string travels further. For coding agents, the same checks run as a hook or MCP tool at each tool call rather than only on the final answer, and we map the agent-specific failure modes in the OWASP Agentic Top-10 guide.

▶ Watch: AI Attacks Get Blocked in Real Time shows the inline-blocking model in action.

One honest caveat on the numbers: AgentLeak and the "Got a Secret" study use different setups (execution traces vs. a simulated social platform of 2,533 agents), so their rates aren't directly comparable and shouldn't be averaged. What they agree on is the shape of the problem. PII in agent systems leaks laterally, through channels between components, and it leaks more the longer the system runs. Watching only the exit door misses most of it.

If you run anything multi-agent, the cheap first move is to instrument the handoffs. Log what one agent actually sends another, run it through a PII check, and see how much sensitive data is moving through a channel you were never scanning. The benchmarks suggest you'll be surprised.