Guardrails shape what an agent tries to do. Sandboxes limit what it can do even when it tries something harmful. You need both, and when they disagree, the sandbox wins, because it does not depend on the model behaving. This checklist helps you test each one on your own agent.
What is the difference?
A guardrail is a check on inputs, outputs or tool calls, such as a filter, a policy rule or an approval step. It works by inspecting behavior, and it can be wrong or bypassed. A sandbox is a boundary: the agent runs with limited files, network, credentials and permissions, so even a fully hijacked agent has little to reach.
OWASP's LLM06 on excessive agency frames the problem. Damaging actions can follow unexpected, ambiguous or manipulated model output from causes such as hallucination or prompt injection. Its three root causes are excessive functionality, excessive permissions and excessive autonomy. Notice that two of the three are about what the agent is allowed to do, which is sandbox territory, and one is about verification, which is guardrail territory.
What does OWASP recommend?
Minimize the tools an agent has, and the functions in each. Avoid open ended tools such as shell execution or URL fetching when a narrow tool would do. Limit permissions on downstream systems, for example read only database access. Run actions in the user's context with least privilege scopes. Require human approval for high impact actions. Enforce authorization in the downstream system, not by asking the model whether something is allowed. OWASP adds that logging, monitoring and rate limiting do not prevent excessive agency but can limit the damage.
The checklist
Sandbox
- List every tool the agent can call. Remove any it does not need this week.
- Replace general tools with narrow ones: a "read ticket" tool instead of a shell.
- Give the agent its own identity with the lowest scopes, not a developer's token.
- Restrict file access to a working directory and the network to an allow list.
- Use short lived credentials that expire on their own.
- Check that the downstream system rejects an out of scope request even if the agent sends it.
Guardrails
- Put approval in front of destructive or irreversible actions, such as deletes, payments and external messages.
- Check tool call arguments against a schema and an allow list before they run.
- Filter outputs that might carry secrets or personal data.
- Log every tool call with the identity, arguments and result.
Test
- Try a request that asks the agent to exceed its scope. Confirm the sandbox blocks it, not only the prompt.
- Disable each guardrail in a test and see what the sandbox still stops. The gap is your real exposure.
Where do teams go wrong?
The usual mistake is relying on a system prompt that says "never delete files" while the agent holds delete rights. Another is a sandbox so loose that it is decoration, such as a container with host credentials mounted. A third is approvals that fire so often people click through.
How does this relate to MCP?
Agents often reach tools through MCP servers. Tool level access control and logging at that layer, covering which agent can call which tool, give you a place to enforce the checklist. Safeguard offers an MCP server at mcp.safeguard.sh, and the same principles apply to any tool server.
What to do
- Inventory agent tools and permissions.
- Remove or narrow anything beyond need.
- Move the agent to its own low scope identity.
- Add approvals for irreversible actions.
- Validate tool arguments before execution.
- Log every call and review the log weekly.
- Run the scope escape test each release.
Quick check
If I have a sandbox, do I still need guardrails?
Yes. A sandbox limits damage, while guardrails reduce harmful attempts and catch mistakes inside the allowed area, such as sending a wrong but permitted email.
Which should I build first?
Start with permissions and tool minimization. They hold even when the model misbehaves.
Sources
Last reviewed: 18 October 2026.
