Nothing to Steal, Nowhere to Send It
Give the agent only the tools it needs, no secrets in the runtime, and no way out. A successful injection lands on a sandbox that can't leak.
The Conventional Framing
Most defenses try to stop the injection from happening. This one assumes it already did. You cannot reliably detect an attack in untrusted text — so instead you engineer the blast radius to zero. Give the agent the minimum viable capability for its job: a reviewer gets no bash, no write-scoped token, no shell. Then you remove the two things an exfiltration needs — private data in the runtime and a way to send it out.
Concretely: run the agent in an ephemeral sandbox that's rm -rf'd when it exits. No secrets mounted into the environment. No outbound network egress except an allow-list of hosts the task genuinely needs. A read-only clone instead of a write-scoped token. This is exactly how GitHub and VS Code answered hostile repositories — Workspace Trust, restricted mode, and Dev Containers — rather than trying to classify every file as safe or not.
What This Buys You — and What It Doesn't
Map it straight onto Simon Willison's lethal trifecta: an injection only becomes catastrophic when the agent has (1) access to private data, (2) exposure to untrusted content, and (3) an external communication channel. Least privilege and isolation delete leg 1 and leg 3 at the same time — there are no secrets in the runtime to steal, and no egress to send them through. Leg 2, the untrusted content, is the one leg you can't remove, so you make it irrelevant.
The 2025 wave of code-agent breaches — Claude Code, Gemini CLI, and GitHub Copilot driven by malicious instructions planted in GitHub issues and PR comments — is the motivating case. In every one, the agent read attacker-controlled text, held credentials in its environment, and could reach the network. Remove the credentials and the egress and the same injection fires into a vacuum.
But be honest about the limit: this stops exfiltration and execution, not wrong analysis.
- The model can still be lied to. A sandboxed reviewer with no tools can still be talked into approving malicious code or emitting a poisoned summary. Isolation protects the system, not the judgment.
- Egress is leakier than it looks. DNS lookups, a whitelisted package registry, an allowed image host, an error-reporting endpoint — any permitted outbound path is a potential side channel. The allow-list is the security boundary; treat it like one.
- Scope creep re-arms the trifecta. The reviewer that “just needs” a token to post a comment, the sandbox that mounts
~/.awsfor “one test” — each convenience quietly restores a leg. Least privilege is a posture you defend, not a switch you flip once.
Architecture
Components:
- Sandboxed runtime— ephemeral container/Dev Container that is rm -rf'd on exit; nothing persists across runs
- Least-privilege toolset— only the tools the task needs — a reviewer gets no bash, no shell, no write access
- Egress policy— default-deny outbound network; explicit host allow-list for the few endpoints the task requires
- No-secrets environment— no API keys, cloud creds, or write-scoped tokens mounted into the agent's runtime
Trust Boundaries
- Untrusted content → sandboxed agent — injection enters here; the runtime holds no secrets, so there is nothing to exfiltrate
- Agent → egress policy — the critical boundary — default-deny outbound with a host allow-list; every permitted path is a watched side channel
- Runtime → host — no write-scoped tokens, no mounted credentials, ephemeral clone destroyed on exit
Threat Surface
| Threat | Vector | Impact |
|---|---|---|
| Credential theft | Injection instructs the agent to read env vars, ~/.aws, or a mounted token | Nothing to read — secrets were never in the runtime |
| Data exfiltration | Injection tells the agent to POST repo contents to an attacker host | Egress denied — the host isn't on the allow-list |
| Egress side channel | Exfil hidden in a DNS query, allowed registry request, or image URL | Leak succeeds if the allow-list is too broad or unmonitored |
| Privilege creep | A token or mount added for convenience re-arms leg 1 or leg 3 | The trifecta is restored; injection becomes catastrophic again |
| Wrong analysis | Sandboxed model coerced into approving malicious code or a poisoned summary | Not mitigated — isolation stops exfil/execution, not bad judgment |
The ZIVIS Position
- •Assume the injection succeeds.Detection tops out below 100%, so design for the miss. Engineer the runtime so a successful injection has nothing to steal and nowhere to send it.
- •Least privilege is per-role.A reviewer needs no bash and no write token. A patcher needs a branch, not the org. Scope tools to the job, not to the platform's default grant.
- •Egress is the boundary.Default-deny outbound, allow-list the few hosts the task needs, and audit every permitted path. DNS, registries, and image hosts are all exfil channels.
- •Keep secrets out of the runtime.No API keys, cloud creds, or write-scoped tokens in the agent's environment. If it isn't mounted, it can't be read out.
- •It doesn't fix the reasoning.This stops exfiltration and code execution — it does not stop the model producing wrong or attacker-steered analysis. Pair it with validation and human review on high-risk writes.
What We Tell Clients
This is the cheapest high-leverage control on the board. It's infrastructure, not research: an ephemeral sandbox, a default-deny egress policy, and a runtime with no secrets in it. Low-to-medium cost, and it turns the entire class of exfiltration attacks — the ones that hit Claude Code, Gemini CLI, and Copilot in 2025 — into no-ops. If you build only one defense before shipping an agent that touches a repo, build this one.
Start from GitHub and VS Code's answer to hostile repos: Workspace Trust, restricted mode, Dev Containers. Then be ruthless about the two legs you're removing. Grep your 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. And remember the ceiling: a sandbox stops the leak, not the lie. Put Structured Output & Validation and a human on the high-risk writes so a coerced-but-contained agent still can't ship you something malicious.
Related Patterns
- Sandboxing— the isolation primitive this pattern is built on
- Capability Tokens— scoped, least-privilege grants instead of ambient write access
- Dual-LLM & CaMeL— privilege separation that removes leg 2 of the trifecta
- Output-Rendering Hardening— closing the render-side exfiltration channels this pattern's egress control complements
References
Frequently Asked Questions
How do least privilege and isolation defend against prompt injection?
Instead of trying to detect the injection, they assume it already succeeded and engineer the blast radius to zero. You give the agent only the minimum tools its job needs, run it in an ephemeral sandbox that is destroyed on exit, mount no secrets, and allow no outbound network egress except an allow-list of required hosts. A successful injection then fires into a vacuum with nothing to steal and nowhere to send it.
How does this map to the lethal trifecta?
The lethal trifecta is exposure to untrusted content plus access to private data plus an external communication channel. Least privilege and isolation delete the private-data leg and the egress leg at the same time, since there are no secrets in the runtime and no way out. Untrusted content is the one leg you cannot remove, so you make it irrelevant.
What does least privilege and isolation NOT protect against?
It stops exfiltration and code execution, not wrong analysis. A sandboxed reviewer with no tools can still be talked into approving malicious code or emitting a poisoned summary. Isolation protects the system, not the model's judgment, so it must be paired with structured output validation and a human on high-risk writes.
Why is egress the security boundary in this pattern?
Because any permitted outbound path can become a side channel. DNS lookups, a whitelisted package registry, an allowed image host, or an error-reporting endpoint can all carry a leak if the allow-list is too broad or unmonitored. Default-deny outbound, add hosts back one at a time with logging, and treat scope creep, such as mounting credentials for one test, as re-arming the trifecta.