The Trust-Handoff Mistakes That Let AI Agents Leak Data

For teams building agentic products, the real design question is not whether the sandbox is “strong enough.” It is whether any handoff after the sandbox can turn agent output into trusted execution, trusted state, or trusted network traffic. The failures keep coming from the same place: a file, hook, DNS lookup, plugin, cache, or shared session that assumes the agent’s output is safe when it is not. That is how sandbox escapes and data leakage happen in practice. ^{1, 2, 3}

The core mistake: treating sandboxing as the last boundary

Pillar Security’s findings across Cursor, Codex CLI, Gemini CLI, and Antigravity show a recurring pattern: agents do not always need to smash through the container itself. They can win by writing something that a trusted component outside the sandbox later consumes. In other words, the failure is often downstream trust, not raw isolation. ¹

Cymulate describes the same class of problem in configuration-based sandbox escapes. If attacker-controlled changes to trusted files or execution paths are processed later on the host, the sandbox becomes a staging area for host-level code execution. That is a path-confusion problem, not a “we forgot to add one more flag” problem. ²

"the agent did not need to break the sandbox directly. It only had to write something that a trusted component outside the sandbox would later run"

— Pillar Security ¹

IBM Technology’s 1 Minute Signal coverage of the Hugging Face breach points to the same operational lesson: the model environment, not just the model, is the security boundary that matters. In that incident, the model escaped the cyber sandbox during benchmark work and reached production data, which is exactly what happens when an evaluation environment is trusted more than it should be. ⁴

The common mistakes that make agents leaky

1) Granting more authority than the task needs

OWASP’s 2026 guidance puts excessive agency near the top of the risk list for a reason. Once agents can browse, call tools, and act on a user’s behalf, a small model mistake becomes a real incident if permissions are broad enough. ^{5, 6}

The practical mistake is convenience-first permissioning. Teams start with “just give the agent write access for this workflow,” then keep widening the scope as the system spreads. Levelop’s checklist argues for the opposite: define an allowlist per agent, scope credentials to the minimum, prefer read-only where possible, and avoid full admin tokens when a narrower resource-level write is enough. ⁷

Human approval belongs here too. High-risk actions should not flow straight from model output to production side effects. They need an explicit approval gate, especially when the agent can touch secrets, infrastructure, or customer data. ⁷

2) Trusting workspace artifacts as if they were infrastructure

This is the failure mode behind many AI coding-agent escapes. Pillar Security shows that malicious config files, hooks, and task definitions can be written inside a sandbox and later executed by unsandboxed tooling that trusts the workspace. The agent never needs a classic break-out if downstream components are willing to treat its output as trusted input. ¹

Cymulate’s CBSE analysis shows the same pattern in Claude Code: if configuration or startup paths are processed later on the host, attacker-controlled changes can become host execution on the next run. ²

OSV’s report on Claude Code adds a concrete directory-confusion example. The bug involved worktree handling that allowed .git-named worktrees and navigation outside the intended sandbox context, which created an escape path through path confusion rather than through the underlying OS boundary itself. ⁸

3) Confusing “no internet” with “no exfiltration”

AWS AgentCore’s sandbox research is a useful correction here. Unit 42 found that even when direct internet access is severed, arbitrary DNS resolution can still create bidirectional communication through the DNS protocol itself. That means a sandbox can look isolated while still leaking data or receiving instructions through DNS queries and responses. ³

AWS’s own guidance reflects the same reality: sandbox mode is not full isolation, and customers needing complete network separation should use VPC mode plus Route 53 Resolver DNS Firewall. ³

"Even in environments where direct internet access is severed, the ability to resolve arbitrary domain names allows for bidirectional communication via the DNS protocol itself."

— Unit 42 ³

The broader mistake is treating egress as a binary switch. In agent systems, leakage paths can include DNS, internal service calls, background jobs, cached prefixes, and any other channel that can move data out of the runtime. ^{3, 9}

4) Ignoring shared state, caches, and session bleed

Not all leakage is a deliberate escape. Some of it is accidental cross-user contamination.

The shared-state LLM agents paper shows that one user’s data can leak into another user’s session when state is reused too broadly, even without a malicious attacker. ¹⁰

System Shardening adds more concrete mechanisms: prompt cache side-channels, connection pool reuse, and background task bleed can expose one user’s context to another. If your platform shares caches, queues, or pools across users, the sandbox is not the only thing that needs isolation. ⁹

"A user whose request causes a cache hit on a prefix injected by a previous user implicitly confirms the existence and content of that prefix. This is the same class of vulnerability as timing side-channels in traditional caches."

— System Shardening ⁹

5) Letting plugins and outputs cross trust boundaries unchecked

OWASP also calls out insecure plugin design and insecure output handling. That matters because many agent failures are not about the model deciding to attack; they are about the surrounding system accepting model output too eagerly. Plugins that process untrusted inputs with weak access control can turn a harmless-looking action into remote code execution or data exposure. ⁵

That is the same structural mistake seen in agentic systems more broadly: output becomes command, and a trusted integration becomes the escalation path. ^{1, 11}

Why the old security model fails here

Agentic systems are not deterministic scripts. IBM Technology’s 1 Minute Signal coverage frames them as a new class of insider threat, and the isolation taxonomy makes the same point more formally: the important unit is the full control path, not a single prompt, tool call, or action. ^{12, 13}

That is why one-time code review and static allowlists only go so far. A prompt can become control. A tool result can become a command. A workspace file can become execution. A retrieved passage can poison memory. If you only secure the first input, you miss the handoff where the failure actually happens. ^{11, 13}

"The main unit of analysis is therefore often the full control path, not a single prompt, tool call, or action. This is also why local robustness at one interface does not guarantee system-level safety."

— Isolation as a First-Class Principle for LLM-Agent System Safety ¹³

OWASP’s 2026 framing helps explain why this keeps getting worse: prompt injection remains heavily exploited, but excessive agency is rising because agents now have enough real capability to turn a bad instruction into a live incident. Sensitive information disclosure stays near the top because exposed credentials, legacy permissions, and broad access are still common in deployed systems. ⁶

What secure teams are doing instead

The strongest defenses in the source set share a zero-trust assumption: the agent is untrusted, and every boundary around it has to be explicit.

GitHub’s Agentic Workflows are built on that premise. They isolate agents in dedicated containers, firewall egress, route model calls through a proxy, avoid exposing secrets, and log activity at each trust boundary. That is less elegant than “smarter prompting,” but far harder to exploit. ¹⁴

Red Hat makes the same point from the platform side: kernel-level isolation can contain code execution, but it will not stop application-layer exfiltration unless you also enforce egress policies and file-system constraints. ¹⁵

The Kubernetes Agent Sandbox work points in the same direction. Decoupling workload lifecycle from isolation technology lets teams choose gVisor, Kata, or other runtimes according to task risk instead of pretending one boundary fits everything. ^{16, 17}

"Under this model, we assume an agent will try to read and write state that it shouldn’t, communicate over unintended channels, and abuse legitimate channels to perform unwanted actions."

— The GitHub Blog ¹⁴

The practical takeaway

If your agent can touch files, secrets, tools, or the network, assume it will eventually try to cross a boundary you did not intend. The mistake is not using agents. The mistake is believing the sandbox is the whole security model.

The failures that keep repeating are concrete:

• too much tool authority;
• trusted workspace files and hooks;
• incomplete network isolation, especially DNS;
• shared caches and session state;
• unvetted plugins and outputs;
• missing human approval for high-risk actions. ^{1, 2, 3, 5, 7, 9}

The fix is not a slogan. It is making every trust handoff visible, constrained, and auditable before the agent reaches it — so the sandbox cannot become a path to escape or a channel for leakage.