A sandboxed agent is safe. And unemployed.
The whole point of an AI agent is that it can touch real systems: your repos, your servers, your data. Lock it in a disposable VM and it is perfectly safe, and cut off from the work you hired it for. Runtime guardrails take the other path: let the agent work on the real machine, and enforce the rules below it, where a compromised agent cannot reach.
The trade, dimension by dimension.
| Sandbox | Runtime guardrails | |
|---|---|---|
| What it protects | Everything outside the box, by keeping the agent away from it | The real machine the agent works on, while it works |
| Agent usefulness | Limited to what you copy into the box | Full: real repos, real servers, real data |
| Escape risk | Sandbox escapes exist; one bug and there is nothing behind it | Nothing to escape: rules enforced below the process, in the kernel |
| When it fails | Silently: the agent simply can't do the job you wanted | Loudly: a denied action, logged, attributed, and alerted |
| Best for | Running untrusted code you never want near production | Agents doing real work on infrastructure you care about |
When a sandbox is the right call
Honestly: sometimes. Running code from strangers, evaluating untrusted models, CI for pull requests you haven't read, put that in a box and burn the box. If the work never needed to touch real systems, isolation is free safety. Use it.
When you need guardrails instead
The moment the agent's job description includes your actual infrastructure: deploying, operating, fixing, shipping. Then the box defeats the purpose, and the safety layer has to move below the agent: screened actions, kernel enforcement on Linux, and an audit trail of everything it did.
InnerWarden is the second path, self-hosted, source-available core, installed in one command. Read the thesis in Runtime guardrails, not prompt guardrails or see what a hijacked agent's day looks like in What happens when an AI agent gets hacked.