Sandboxing

What is sandboxing?

Once an agent can run code, risk walks in the door — what if it executes malicious code, or a bug takes the whole system down? Sandboxing is the answer: it isolates the execution environment in a controlled "cage", limiting what the code can touch to the resources you allow.

Why is it necessary?

Code isn't trusted
An agent may run code from a user or downloaded from the network, and nobody can promise it's safe.
Failures spill over
Without isolation, one infinite loop or a single delete command can bring down a whole server.
Security and permissions need a boundary
A sandbox draws a hard line around "what's allowed", and anything past it gets blocked.

Common sandboxing techniques

Containers
Wrap the runtime in a container like Docker, isolated from the host.
Virtual machines
Spin up a separate VM — stronger isolation, but heavier.
Restricted runtimes
Limit access to the network, filesystem and system calls, allowing only what's on the whitelist.
Timeouts and resource limits
Cap CPU, memory and runtime to prevent runaway or exhausted resources.

What's the cost?

Sandboxing adds some performance overhead and operational complexity, but compared to running bare, it's a bargain — especially anywhere an agent executes arbitrary code.

Bottom line: sandboxing puts an agent's code in a cage — let it thrash around, but it can't break out or hurt the system.