Every other prompt-injection defense argues about whether it caught the attack. This one doesn't care. It starts from the assumption that the injection worked — the model read the malicious text and decided to comply — and asks a different question: when it does, what can it actually do? If the answer is “nothing worth doing,” you have a security property instead of a detection rate.
The move is least-privilege tooling plus removing the exfiltration channel. Give the agent only the tools its job requires, keep secrets out of its runtime, and cut its outbound network to a default-deny allow-list. A successful injection lands on a sandbox with nothing to steal and nowhere to send it.
The lens: remove two legs, not one
Simon Willison's lethal trifecta says an injection turns catastrophic only when an agent holds all three of: access to private data, exposure to untrusted content, and an external communication channel. Privilege separation — dual-LLM, CaMeL — attacks leg two, the untrusted content. This pattern attacks the other two, and it does it with plumbing rather than architecture.
- Leg 1 — private data in the runtime. If there are no API keys, no cloud credentials, and no write-scoped tokens mounted into the environment, there is nothing for a coerced agent to read out.
- Leg 3 — the egress channel. If outbound network is default-deny with a narrow host allow-list, there is nowhere for stolen data to go, even if the agent tries.
You can't remove leg two — the whole point of a code agent is to read the repo, the issue, the PR comment. So you make it irrelevant by deleting the two legs that turn exposure into a breach.
Why this is worth building: the 2025 code-agent breaches
This isn't theoretical. In 2025 a wave of “comment-and-control” attacks hit Claude Code, Gemini CLI, and GitHub Copilot: an attacker plants instructions in a GitHub issue or a PR comment, the agent dutifully reads them as part of its task, and — because it was running with credentials in its environment and open network access — it can be steered into leaking secrets or code to an attacker-controlled endpoint.
The common shape is exactly the trifecta: the agent read attacker-controlled text (leg 2), held tokens in its runtime (leg 1), and could reach the network (leg 3). No classifier caught it, because “fetch the file and post it here” is an ordinary instruction until you know where it came from. Take the credentials out of the runtime and cut the egress, and the identical injection fires into a vacuum.
The reference implementation already exists
You don't have to invent the mechanism. GitHub and VS Code hit this problem first with hostile repositories — a cloned repo that runs code the moment you open it — and their answer was isolation, not detection: Workspace Trust and restricted mode, which strip capabilities from untrusted folders, and Dev Containers, which run the whole workspace in a sandbox you control. The lesson transfers directly to agents: don't try to decide whether the content is safe; run it somewhere it can't hurt you.
In practice that means an ephemeral clone that's rm -rf'd when the run ends, a read-only checkout instead of a write-scoped token, no secrets in the environment, and no outbound egress except the handful of hosts the task genuinely needs. A reviewer agent, in particular, has no business holding a shell or a write token at all.
The honest limitations
We're not going to oversell it. Isolation stops exfiltration and execution; it does not stop the model producing wrong analysis. Three limits matter in practice:
- The model can still be lied to. A sandboxed reviewer with no tools can still be talked into approving malicious code or writing a poisoned summary. You've protected the system, not the judgment — pair this with output validation and a human on the high-risk writes.
- Egress is leakier than it looks. A DNS lookup, an allowed package registry, a whitelisted image host, an error-reporting endpoint — every permitted outbound path is a candidate side channel. The allow-list is the boundary; log it and keep it tight.
- Scope creep re-arms the trifecta. The token added “just to post a comment,” the
~/.awsmounted “for one test” — each convenience quietly restores a leg. Least privilege is a posture you defend, not a switch you flip once.
What we tell clients
If you're shipping an agent that touches a repository, build this before you build anything else. It's the cheapest high-leverage control we know of — infrastructure, not research — and it neutralizes the entire class of exfiltration attacks that hit the major code agents in 2025. Low-to-medium cost, and a whole category of breach becomes a no-op.
Be ruthless about the two legs. Grep the agent's environment for anything sensitive and take it out. Set egress to deny-all and add hosts back one at a time, with logging. Give a reviewer no shell and no write access. Then respect the ceiling: a sandbox stops the leak, not the lie, so keep validation and human review on anything that ships. When a bypass eventually happens — and it will — you want it landing on a system with nothing to steal and nowhere to send it.
This is one of the load-bearing patterns in our Defense Architecture catalog. The pattern page for Least Privilege & Isolation has the trust boundaries, threat surface, and architecture diagram in full.