Execution Sandboxing
Running agent-generated code in an isolated environment that cannot harm the host, leak data, or escape its bounds. The reframe: an agent runs untrusted code with your credentials, so isolation by default -- ephemeral containers, microVMs, scoped credentials -- is the precondition for letting agents run unattended.
The Pattern
"Strip away all the hype, strip away the AI framing. What we are actually doing is running untrusted code from the internet." -- Harshil Agrawal, Cloudflare (source)
Execution sandboxing is the platform discipline of running agent-generated code in an isolated environment that cannot harm the host, leak data, or escape its bounds. The reframe is the whole point: an LLM is a black box that emits text which looks like code, and you then run it with your credentials -- something you would never do with a snippet from a random website (Harshil Agrawal, Cloudflare).
The threats are neither hypothetical nor only adversarial. With no bad actor at all, hallucinated code can blow the stack, spin an infinite loop, or import a package that crashes the process; an over-helpful agent can take destructive actions; and prompts can be adversarially manipulated. The platform answer is isolation by default -- ephemeral containers or microVMs, per-run git worktrees, and tightly scoped credentials -- so a wrong action stays contained. Managed runtimes (AWS Bedrock AgentCore, Cloudflare's sandbox, hardened JS runtimes) now offer this as infrastructure.
Why It Matters
Unattended loops make this non-negotiable: a loop running unattended is also a loop failing unattended, and isolation is what bounds the blast radius when it does. Sandboxing is the precondition for autonomy -- you can only let an agent act without a human watching if the worst it can do is contained. It is the execution substrate the AI SDLC runs its construction stage inside.
Sources
Last reviewed: 2026-06-24