Code execution is the most powerful capability you can give an agent. In security terms it has a blunter name: arbitrary code execution, the thing every other part of your stack is built to prevent.
The difference is that here you are handing it out on purpose, to a component that takes direction from untrusted input. That makes the sandbox not a nicety but the whole control, and worth looking at squarely.
Three ways model-written code goes wrong
The code an agent runs is written by a model, and a model produces unpredictable code, especially under pressure or manipulation. The chapter that builds this capability names three failure modes, and none requires malice.
A wrong path, by accident. The model means to clear a temp folder and writes a delete against the wrong directory. Run on your host, that is your files gone.
A runaway, by accident. An infinite loop, or code that allocates memory without limit, freezes the machine it runs on.
Malicious code, on purpose. A model steered by injected input, a poisoned document, a crafted tool result, can be led to write code that reads your secrets, reaches the network, or attacks the host. The same prompt-injection channel this series has traced throughout now ends in a Python interpreter.
The first two are reliability problems. The third is the security one, and it is the reason a sandbox is mandatory rather than advisable.
Why the model cannot be the safeguard
The tempting shortcut is to instruct the model: "only write safe code, never touch the filesystem outside the working directory." This series has made the point before, and it is sharpest here.
An instruction to write only safe code sits in the same buffer as the attacker's text, and the attacker's text can be more persuasive in the moment. Worse, the output is a program, and a program that looks benign can do harm on a line the model, or you, skimmed past. You cannot prompt your way to safe code execution, because the thing writing the code is the thing under attack.
So the safety cannot live in the model or the prompt. It has to live in the environment the code runs in.
The prompt asking for safe code sits beside the attacker's text. The boundary has to be the sandbox, not the instruction.
The sandbox is the control
A sandbox is an isolated environment the code runs in, and it is the actual safeguard. It does three things instruction cannot.
It hides the host. The sandbox cannot see your SSH keys, your /etc/passwd, or the API keys in your
host environment. Code that tries to read them finds nothing, regardless of what the model was talked
into writing.
It caps resources. CPU, memory and wall-clock time are limited, so a runaway hits a timeout and dies instead of taking the machine with it.
It is disposable. Whatever the code did inside, you throw the sandbox away and make a fresh one. The blast radius is one disposable container, not your host.
The point to hold: the sandbox does not care how the dangerous code got written, whether by an honest mistake or a clever injection. It bounds what any code can do, which is exactly the property a prompt cannot provide.
A sandbox you can trust, and one you cannot
Not every "sandbox" is one. A misconfigured isolation gives a false sense of safety, which is worse than none, because you stop watching.
| A real sandbox | Theatre |
|---|---|
| Isolated from the host filesystem | Runs in a container with the host mounted in |
| Resource-limited, runaways killed | No CPU, memory or time caps |
| Disposable, remade per run or per task | Long-lived and shared across tasks and users |
| Network locked down by default | Open egress to anywhere |
| The agent holds no host credentials | Host secrets sitting in the sandbox's environment |
The right-hand column is not a sandbox with a few gaps. It is running arbitrary code with extra steps. The next post takes the boundary itself, network and secrets, apart in detail, because a sandbox that isolates the filesystem but leaves the network and credentials open is exactly the false comfort to avoid.
Isolation, resource limits, disposability and a locked-down network. Miss one and the sandbox is theatre.
What this touches
For the frameworks, this maps directly to T11 Unexpected RCE and Code Attacks, which the pack defines as exploiting an agent's code-execution environment to inject malicious code, trigger unintended behaviour, or run unauthorised scripts. That is precisely the surface a code-execution agent opens. In the OWASP Agentic Top 10 the anchors are ASI04 and ASI05.
On the regulatory side, framed as scope rather than a citation: system security, access control and change management are foundational obligations across GCC rulebooks, and running unvetted, model-generated code is a system-integrity exposure those rules already govern, even though they pictured deployed software rather than code written at runtime by a model. Which obligations apply depends on your regulator and architecture, and that mapping is an advisory estimate until someone checks it properly.
The part worth keeping
Code execution is a genuine leap in capability, and the chapter builds it for good reason. An agent that can write and run code does things a tool menu never could. Nothing here says withhold it.
The point is that code execution and sandboxing are one feature, not two. Handing a model an interpreter without an airtight sandbox is arbitrary code execution driven by untrusted input, dressed up as a productivity gain. Build the sandbox first, verify it isolates the host, caps resources, and locks down the network, and only then let the agent write code. The power is worth having. The boundary is what makes it safe to have.