Isolation — running untrusted agent code safely
The moment your agent writes and runs code, browses the web, or calls tools, you have a security problem: the instructions came from a language model that can be manipulated. A prompt injection hidden in a web page can make the agent run an attacker's code. So production agent infra treats every execution as zero-trust and isolates it in hardware. This chapter is how.
1 · Why isolation is mandatory
LLM-generated code and tool calls are untrusted user input — treat them like a form field from a stranger. The threat is real: indirect prompt injection (malicious instructions embedded in content the agent reads) is a documented attack. If a compromised agent runs arbitrary code with access to your systems, the blast radius is whatever that process can touch. So each session runs in its own sandbox, destroyed on completion — the only question is how strong.
2 · The isolation ladder — pick your threat model
Stronger isolation costs more overhead. Tell the demo your situation and it highlights the right rung:
3 · Isolation is necessary but not sufficient — the lethal trifecta
Hardware isolation stops code escaping the box, but the agent still needs data and network access to be useful. The famous failure mode: data exfiltration via injection needs three things at once. Toggle the legs — you'll see it only takes breaking one to be safe:
Isolation + resource limits + network egress control + least-privilege scoping + immutable audit logs + human approval for high-risk actions. Snapshot restore (5–30ms vs 125ms cold boot) is what makes per-session microVMs practical at scale.
We've kept the agent safe and scalable. But it still forgets everything between calls. Next: memory — engineering continuity around a stateless model.