A sandbox limits where an AI agent can act, such as which files and network hosts it can reach. A guardrail governs what the agent may do, such as which tools it can call and with what arguments. They stop different failures, so serious deployments use both.
What does a sandbox do?
A sandbox is a boundary enforced outside the model. Claude Code's documentation describes its sandbox as a boundary that the operating system enforces around shell commands, with limits on the files and network domains those commands can reach, and notes that limits apply even to the processes those commands start. Because the operating system enforces it, the model cannot talk its way past it.
The same page also says what the sandbox does not cover: file tools, MCP servers and hooks run outside it. That gap matters. Always read what your sandbox actually wraps.
What does a guardrail do?
A guardrail sits in the decision path. It checks a tool call or a model output against rules before it takes effect. OWASP's LLM06 entry on excessive agency lists the root causes a guardrail targets: excessive functionality, excessive permissions and excessive autonomy. Its prevention advice reads like a guardrail spec: limit tools to what is needed, avoid open-ended tools like arbitrary shell, use least-privilege credentials, require human approval for high-impact actions, and enforce authorization in downstream systems "rather than relying on an LLM to decide if an action is allowed or not."
Where does each one fail?
A sandbox does not understand intent. It will let an agent send an email, delete a record or call an API if the network and permissions allow it. A sandbox cannot tell a good call from a bad one.
A guardrail can be bypassed by a path it does not see. If the agent can reach a tool the guardrail does not govern, such as a second connector or a shell, the rule does not apply.
Both depend on configuration. A sandbox with every domain allowed and a guardrail with an empty rule set are decoration.
A worked example
An agent has a database tool and a web fetch tool. Someone plants hostile instructions on a web page the agent reads.
- Sandbox only: the fetch is allowed because the domain is on the list, and the instructions reach the model. The database tool, with write access, does what the model asks.
- Guardrail only: the database tool call is checked and a delete is refused or sent for approval. But the agent's shell is unwrapped and can read local credentials.
- Both: the delete needs approval, the credentials are unreachable, and the logs show the attempt.
This is an illustration, not a report of a real incident.
How does Safeguard fit?
Safeguard's MCP Guardrail, an early access capability, generates guardrail proxy URLs for MCP servers so agent tool traffic can be governed. Safeguard does not replace a sandbox, which is an operating system or environment control you choose.
See it at /demos/mcp-guardrail.
What to do
- List every tool and connector your agent can use, and what each can change.
- Wrap command execution in a sandbox, and read what it does not cover.
- Put guardrail rules on tool calls: allowed tools, argument limits, approval for high impact.
- Use least-privilege, short-lived credentials for every tool.
- Enforce authorization in the downstream systems, not in the prompt.
- Log tool calls and review denials weekly.
Quick check
If I have a sandbox, do I need guardrails?
Yes. A sandbox limits reach but does not judge actions inside that reach.
Can a guardrail replace human approval?
Not for high-impact actions. OWASP advises human approval for those.
Sources
Last reviewed: 18 October 2026.
