Skip to content
Sandbox vs guardrails

Two ways to stop an AI agent doing damage: lock it in a box, or guard the machine it works on.

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, in the kernel on Linux, where a compromised agent cannot reach.

Sandbox vs guardrails
What it protects
SandboxEverything outside the box
WardenThe real machine, while it works
Agent usefulness
SandboxLimited to what you copy in
WardenFull: real repos, servers, data
Escape risk
SandboxOne bug and nothing is behind it
WardenOn Linux, enforced in the kernel, below the process
When it fails
SandboxSilently: the job just does not get done
WardenLoudly: a denied action, logged and attributed

Same trade, four dimensions. The full table is below.

Side by side

The trade, dimension by dimension.

DimensionSandboxRuntime guardrails
What it protectsEverything outside the box, by keeping the agent away from itThe real machine the agent works on, while it works
Agent usefulnessLimited to what you copy into the boxFull: real repos, real servers, real data
Escape riskSandbox escapes exist; one bug and there is nothing behind itNo second boundary to break out of: on Linux the rules are enforced in the kernel, below the process
When it failsSilently: the agent simply can't do the job you wantedLoudly: a denied action, logged and attributed
Best forRunning untrusted code you never want near productionAgents doing real work on infrastructure you care about
When to use which

Both are real tools. The job decides.

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.

Get started

Keep the agent on the real machine. Move the rules below it.

InnerWarden is the second path, self-hosted, with the free Community core (inner-warden, Apache-2.0), 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.

The rules below the agent
  • workFull usefulness: real repos, real servers, real data.
  • kernelOn Linux, the rules are enforced in the kernel, below the process.
  • denyWhen it fails, it fails loudly: a denied action, logged and attributed.