Table of Contents
Agent Sandboxing Patterns That Survive a Pentest
Most agent sandboxing in production is a container with a wide egress policy and a credential file mounted where the agent can read it. That is a speed bump, not isolation. Three disclosures in July 2026 showed what the speed bump costs. GitLost turned GitHub's own agent into a confused deputy that copied private repositories into a public comment, with no credentials and no code on the attacker's side. Hugging Face disclosed an autonomous agent that ran more than 17,000 actions, harvested credentials, and moved laterally across internal clusters over a single weekend. Pillar Security published seven sandbox escapes across four coding agents in one week. None of these needed a novel exploit. Each needed one control the team assumed was present and was not.
Here is the whole piece in one line: a control you cannot map to a specific attack is theatre, and a pentester will say so before lunch. The rest of this guide is the map. Every pattern below names what it stops and, more usefully, what it does not. If you own the agent rollout and the blame when it stalls, this is the artifact you forward to your security team so the review is about tradeoffs instead of vibes.
The threat model, in four attacks
You are defending against four things. Name them, because every control you buy either stops one of them or it does not.
The confused deputy is prompt injection with a purpose. Untrusted text reaches the agent's context, and the agent acts on it using its own legitimate permissions against you. GitLost is the reference implementation: a public issue body told GitHub's agent to fetch private repo contents and post them, and the agent obliged because it drew no boundary between instructions and user-supplied data, per Noma Security.
Tool misuse is the deputy holding a sharper knife. The agent calls a real, approved tool with attacker-chosen arguments: a delete, a funds transfer, an outbound POST. The tool worked exactly as designed. That is the problem.
Credential exfiltration is the agent reading a secret it holds and sending it somewhere it should not go. In the Hugging Face breach the framework harvested cloud and cluster credentials and used them to keep moving, per Hugging Face's disclosure.
Lateral movement is the runtime itself becoming a pivot. The agent's sandbox can reach a network, and something on that network trusts it. Pillar's Docker-socket finding (GHSA-v4xv-rqh3-w9mc) handed agents in three separate products a daemon running entirely outside any sandbox, per BleepingComputer.
Keep these four in view. The isolation ladder below stops some of them and is silent on others, and the silence is the part vendors skip.
The isolation ladder
Isolation is a ladder, not a switch. Each rung costs more and buys a specific reduction in blast radius. None of them, on their own, stops the confused deputy, because prompt injection operates through the agent's granted permissions rather than around them.
| Rung | What it stops | What it does NOT stop | Cost |
|---|---|---|---|
| Process isolation (separate uid, seccomp, no shared mounts) | A crashed or misbehaving agent from trampling other processes on the host | Anything that shares the kernel; a trusted host tool executing a file the agent wrote; egress | Cheap. An afternoon of config |
| Container | Filesystem and process-namespace bleed between the agent and the host | Kernel-boundary escapes; a mounted socket (the Docker-daemon case); host tools that later read agent-written files | Low. Already in most stacks |
| microVM (Firecracker, gVisor-style) | Kernel-boundary escapes; a compromised agent breaking out to the host OS | Prompt injection; credential misuse; egress to the internet; anything inside the guest's own reach | Medium. Cold-start latency and per-VM memory you pay on every task |
| Separate account or project boundary (own cloud project, scoped repo or bucket, own IAM role) | Lateral movement and cross-tenant reach. This is the GitLost lesson: the agent had cross-repo scope it never needed | The agent misusing what is legitimately inside its scope | Operational. Provisioning and lifecycle work per agent |
| Network egress policy (orthogonal; applies at every rung) | Exfiltration and command-and-control, including the confused-deputy path | Reads and writes that stay inside the allowlist you granted | Medium. Real allowlist maintenance |
Read the table top to bottom and the pattern is blunt. The cheap rungs stop clumsy failures. The escapes Pillar documented all live in the "does not stop" column of the container row: the agent writes a config file or an interpreter that a trusted host tool picks up and runs outside the box. As Pillar put it, an agent's blast radius is not the agent process; it is everything the agent can write that the host later trusts, per Pillar Security. A microVM raises the escape cost, and Cursor's fix shipped in v3.0.0 while OpenAI's Codex CLI patch shipped in v0.95.0, but neither the microVM nor the patch touches the deputy or the egress path. Those need their own controls.
If you are choosing where the agent runs, the sandbox cloud comparison covers the managed options at the microVM rung. The rung matters less than pairing it honestly with the two controls the ladder cannot provide: the credential boundary and egress.
The credential boundary
An agent that can read its own long-lived credential is a data-exfiltration path with extra steps. This is not hypothetical hardening. It is the exact move the Hugging Face intruder made after initial access: harvest what is reachable, then walk.
Three rules hold up under a pentest.
Use short-lived tokens over mounted secrets. A static API key sitting in a file the agent process can cat is a permanent liability that survives every restart and every log leak. A token with a short TTL, minted per session from a broker the agent authenticates to, shrinks the exfiltration window from forever to minutes. What this does not stop: misuse inside the token's lifetime. A fresh token in the hands of a confused deputy is still a valid token.
Scope credentials per tool, not per agent. The common shortcut is one fat service account the agent uses for everything, because it is easy to provision. Under attack it means one stolen credential unlocks every integration at once. Scope the read-a-ticket token to read tickets and the deploy token to deploy, and a compromise leaks one capability instead of all of them. What this does not stop: an attack that only needs the one capability the agent legitimately holds.
Never let the agent hold a secret it does not actively need this task. Secrets the agent is not using should not be in its environment, its mounts, or its context window. The context window is an attack surface, and anything in it can be read back out by a well-phrased injection.
The honest limit of the whole boundary: it caps how much a compromise leaks and how long it lasts. It does nothing about whether the compromise happens. That is what egress is for.
Egress is the control you skipped
Default-deny egress with an allowlist is the highest-payoff control on this list and the one most teams do not have. It is also the one that most directly answers the confused deputy, because exfiltration and command-and-control both require an outbound connection to somewhere you did not intend.
The reason it gets skipped is a bad argument that sounds reasonable: the model would not do that. The model is not the actor. GitLost is the existence proof. The agent did precisely what the attacker's text told it to, using permissions you granted, and "the model would not do that" was the entire security posture that failed. "The model would not do that" is not a control. It is a hope with a container around it.
What default-deny egress buys you: the agent can reach the four hosts on its allowlist and nothing else, so an injected instruction to POST your repo to an attacker's server hits a wall it cannot argue with. The Hugging Face intruder staged command-and-control on public services precisely because outbound reach was open; an allowlist turns that from a weekend of lateral movement into a logged, blocked connection. What it does not stop: exfiltration through a host that is already on the allowlist. If the agent can write to a storage bucket it is allowed to reach, an attacker can stage data there. Allowlist the destinations, then watch what moves to them.
Egress policy is orthogonal to the isolation rung. You can and should run it at every level, and it is a cheap, large win for a team that already has a container and thought the job was done.
What your security team will ask
Governance review is the number-one blocker in enterprise agent adoption, and the review goes faster when you arrive with the answers pre-mapped. These are the four questions that decide sign-off, the control that answers each, and the concrete artifact to hand over. Forward this table.
| The question | The control that answers it | What you hand them |
|---|---|---|
| Blast radius: if this agent is fully compromised, what can it reach? | Separate account or project boundary plus egress allowlist | The IAM scope and the egress allowlist, as committed config |
| Revocation path: how fast can we cut its access, and who can? | Short-lived tokens plus a documented kill switch | Token TTL, the revocation runbook, and who holds the button |
| Audit trail: can we reconstruct what it did? | A structured, retained action log | The log schema and retention window. Hugging Face reconstructed its full attack timeline because it had one |
| Data residency: where does the agent's data, and any hosted-model call, actually go? | A region-pinned or self-hosted model plus the egress allowlist | The model host, its region, and the destination allowlist |
The data-residency row carries a lesson most incident plans miss. When Hugging Face tried to use commercial hosted frontier models to analyze the attack log, provider safety guardrails blocked the requests, because those systems cannot tell an incident responder submitting real exploit payloads from an attacker. The team ran the forensics on an open-weight model on its own infrastructure instead. Vet a capable model you control before you need it, both to dodge the guardrail lockout and to keep attacker data and credentials inside your environment.
What breaks first
Under a real pentest these controls do not fail at random. They fail in order, the corner that was cheap to cut going first, and each failure has an earliest symptom you can watch for before the report lands.
- Egress, first and most often. Earliest symptom: the agent makes an outbound connection to a domain no one allowlisted, and you find it in the egress log. If there is no egress log, you find it in the breach disclosure. This breaks first because it is the control teams most often never built.
- The credential boundary, second. Earliest symptom: a token that should have expired still authenticates, or a secret the agent never needed shows up in its output or a log line. The tell is a credential living longer or reaching wider than the task required.
- The account or project boundary, third. Earliest symptom: the agent successfully reads a repository, bucket, or dataset outside its intended scope. GitLost is this failure exactly. Cross-scope reads that succeed are the alarm.
- The sandbox kernel, last. Earliest symptom: a trusted host tool executes a file the agent authored, as in every one of Pillar's escapes. This ranks last not because it is unimportant but because it is the hardest rung to reach and the most actively patched. If an attacker is escaping your microVM, they walked through the three cheaper failures above to get there.
The order is the priority list. Fix egress before you shop for a fancier sandbox.
Map it before they do
The NIST AI Risk Management Framework (AI 100-1, January 2023) gives you the vocabulary your auditors already use: Govern, Map, Measure, Manage. Sandboxing lives mostly in Map and Manage. Map is the honest inventory of what the agent can reach, which is the isolation ladder and the credential scope written down. Manage is the revocation path and the egress allowlist you can change under pressure. Measure is the pentest that tells you which column of the ladder table your real deployment sits in.
Do the cheap, high-payoff thing first. Turn on default-deny egress, allowlist the handful of hosts the agent actually needs, and log every denied connection. That single control does more against the confused deputy than another rung of kernel isolation, and it is the one your last security review probably skipped. Then walk the credential boundary and the account scope, and only then argue about microVMs.
For the layers underneath this one, the security section goes deeper: TrustFall on how a single trust prompt became a one-click RCE, the agent-skill security scanner for vetting skill files before they run, the GitHub Agentic Workflows audit for the config behind GitLost, and prompt-injection defense in production for the deputy problem in full. This guide is the platform layer that sits above them, and it feeds the enterprise agent playbook where governance is one blocker among several.
A sandbox that survives a pentest is not the strongest rung. It is the honest one, where every control names the attack it stops and the team already knows what the next control has to catch.