Agent Sandboxing vs Tool Allowlisting: Containing What AI Agents Can Do

Teams securing AI agents often treat sandboxing and tool allowlisting as interchangeable, then discover that each one leaves exactly the gap the other was meant to close. A sandbox limits what code can touch at run time; a tool allowlist limits which actions the agent is offered in the first place. They sit at different layers, fail in different ways and cost different amounts to run. This guide compares the two as containment strategies: the threat each one answers, how each is built, the escape and bypass routes, the residual risk that remains inside an allowed tool, and how to layer them. It is written for platform engineers, AppSec leads and architects deciding where to spend effort on an agent platform. Isolation technology detail lives in the AI Agent Sandboxing and Code Execution Guide and tool threats in the AI Agent Tool and Plugin Security Guide; this page is about choosing and combining.

Key takeaways

• Different questions, different layers. Tool allowlisting answers "which actions may this agent request?"; sandboxing answers "if code runs, what can it reach?". Neither answers the other's question.
• An allowed tool is still a weapon. Allowlisting does nothing about a permitted tool being called with hostile arguments, so the residual risk sits in tool scope, credentials and server-side authorisation.
• A sandbox is only as tight as its exits. Network egress, mounted secrets, metadata endpoints and reachable internal services are how agents leave a sandbox without any kernel exploit.
• Open-ended tools force the decision. A shell, code interpreter or URL fetch tool cannot be made safe by allowlisting alone; once one is allowed, a sandbox becomes mandatory.
• Layer by default, weight by workload. Use a narrow allowlist for every agent, add isolation wherever code or binaries execute, and put credential scoping and egress control under both.

The short answer

Use tool allowlisting for every agent, because it is cheap and shrinks the attack surface before anything runs. Add sandboxing whenever the agent can execute code, run a local tool server, open files from untrusted sources or call any open-ended tool, because from that point the allowlist no longer describes what can actually happen. For agents that only call narrow, purpose-built API tools with tightly scoped credentials, a sandbox around the agent process adds less than investment in server-side authorisation. For coding agents, data analysis agents and anything processing untrusted documents, the sandbox is the control that decides the worst case and the allowlist is the control that keeps the common case predictable.

OWASP LLM06:2025 Excessive Agency frames the root causes as "excessive functionality", "excessive permissions" and "excessive autonomy". Allowlisting attacks excessive functionality. Sandboxing limits the consequences of all three when the functionality includes code execution. Credential scoping attacks excessive permissions, and approvals attack excessive autonomy. See the OWASP LLM Top 10 LLM06 Excessive Agency Guide.

Side by side comparison

Agent sandboxing in depth

Threat model

Sandboxing assumes the code is hostile. Whatever the model writes can be shaped by prompt injection in a web page, a repository file, an issue comment or a tool result, so the generated code has the intent of whoever last controlled the context. Firecracker's design document states the same stance for guest code: "all vCPU threads are considered to be running malicious code as soon as they have been started." The sandbox exists to make that assumption survivable.

Architecture in words

The agent loop (model calls, planning, tool routing) runs in a trusted control process. Code execution, shell commands and local tool servers run in a separate, short-lived execution environment with its own filesystem, no inherited credentials and a network path that passes through an egress proxy. Results come back as data. gVisor describes its aim as "defense against the exploitation of kernel bugs by untrusted userspace code", achieved by having its Sentry implement system calls rather than passing them to the host. Firecracker places a hypervisor boundary between guest and host and drops privileges through its jailer before guest code runs.

Escape and bypass routes

• Permitted exits: most real escapes use a door left open, not a kernel bug. The OpenAI and Hugging Face breach 2026 began with an evaluation sandbox that could reach an internal package registry, from which agents found routes to the internet and then to cloud credentials.
• Mounted secrets and environment variables: a sandbox that receives a production token in its environment hands that token to any code that runs.
• Metadata endpoints: 169.254.169.254 exposes instance credentials unless blocked. The MCP security best practices list link-local 169.254.0.0/16 among ranges clients should block.
• Persistence outside the sandbox: writes to a mounted workspace, a shared cache or a configuration file that a host process later reads and executes.
• Runtime vulnerabilities: shared-kernel containers are one bug from the host (ATT&CK T1611 Escape to Host). A second, independent boundary such as a user space kernel or microVM makes this materially harder.
• Environment detection: code that probes for the sandbox and behaves differently inside it (ATLAS AML.T0097 Virtualization/Sandbox Evasion) undermines evaluation sandboxes in particular.

Controls that make a sandbox real

• Isolation tier by trust: OS process sandbox for local single-user agents; user space kernel or microVM for multi-tenant, internet-facing or evaluation workloads.
• Default-deny egress: neither gVisor nor Firecracker filters the network for you. gVisor's security model says network controls "should be applied at the container level", and Firecracker's design says guest egress "should be filtered at the host-level". See the Agent Egress Control and Network Isolation Guide.
• No standing credentials inside: broker short-lived, task-scoped tokens from outside. See Secrets in Prompts vs Brokered Credentials.
• Ephemeral lifecycle: fresh environment per task, destroyed afterwards, with CPU, memory, wall clock and process count limits. gVisor leaves resource exhaustion to host cgroups.
• Read-only base, scratch writes only: nothing written inside should be executed later by a host process without review.

Tool allowlisting in depth

Threat model

Allowlisting assumes the model will try to use whatever it is given, sometimes because it was told to by an attacker and sometimes by plain error. The defence is to give it less. OWASP's LLM06 mitigations start with "Minimize extensions", "Minimize extension functionality" and "Avoid open-ended extensions", and its examples include a plugin trialled in development and left available to the agent, which is a tool sprawl problem that only an inventory and allowlist catch.

Architecture in words

Each agent has a manifest: the tool servers it may connect to, the tools it may see from each, and for each tool any argument constraints and approval requirements. The MCP client, an MCP gateway or the agent framework enforces the manifest by filtering tool lists before they reach the model and rejecting calls to anything not on it. The MCP tools specification allows servers to return "only the tools the caller's granted scopes permit", so a second allowlist can be enforced server-side through authorisation, which is stronger than client-side filtering alone because the model never sees the definition. The specification also says clients aggregating several servers SHOULD disambiguate names, "such as prefixing tool names with a server identifier".

Bypass routes

• Open-ended tools: allowing run_shell, execute_python, http_fetch or run_sql allows everything those can reach. OWASP's example is "an extension to run one specific shell command" that fails to prevent other commands.
• Argument abuse: send_email is allowed, so the attacker changes the recipient. The allowlist approved the verb, not the object.
• Tool chaining: read_file plus http_post, each harmless alone, form an exfiltration path together.
• Definition drift: an allowlisted tool name whose description or behaviour changes after approval, covered in Static Tool Allowlists vs Dynamic Tool Discovery for AI Agents.
• Client-only enforcement: a filter in the agent framework that a misconfigured or alternative client simply does not apply.

Controls that make an allowlist real

• Purpose-built tools: replace run_sql with get_invoice(invoice_id) where the business case allows.
• Argument constraints: enum lists, maxLength, path roots and recipient domains in the inputSchema, plus server-side business rules the schema cannot express.
• Server-side authorisation: OWASP's "Complete mediation" mitigation, authorisation in downstream systems rather than in the model. ATLAS AML.M0028 Enforce Access Controls for AI Agent Tools covers the same idea.
• Approval for high-impact verbs: human confirmation for destructive, financial or external-send actions (ATLAS AML.M0029 Human In-the-Loop for AI Agent Actions). See the Human-in-the-Loop for AI Agents Guide.
• Do not trust annotations: the MCP specification says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers", so a readOnlyHint is not a policy input for third-party servers.

Residual risk of allowed tools

The hardest question in this comparison is what remains when both controls are in place. An allowed, sandboxed tool still acts with whatever identity and data reach it has. The table shows where that residual risk lives and which layer has to carry it.

The pattern is consistent: residual risk sits in identity and authorisation. That is why the AI Agent Authorisation Guide and the credential brokering pattern belong in every containment design. See the AI Agent Authorisation Guide.

Operational cost and decision criteria

Cost of sandboxing: image builds and patching, cold start latency per task, compatibility gaps (gVisor notes that not every system call is implemented), KVM requirements for microVMs, egress policy that must be kept current, and engineers who can debug all of it. Cost of allowlisting: a tool inventory, a review step for each new tool, per-agent manifests and re-approval when tools change. The allowlist cost scales with the number of tools and agents; the sandbox cost scales with execution volume and the number of distinct runtime images.

For small organisations the order is usually allowlist, credential scoping, then managed sandboxing for the few agents that execute code. Large platforms with many teams tend to standardise one sandbox tier per trust level and enforce allowlists centrally through a gateway. See the MCP Gateway and MCP Server Governance Guide.

Layered design

1. Inventory and classify tools: list every tool and server, mark each as narrow or open-ended, read-only or write, internal or external-send.
2. Build per-agent manifests: start each agent with the smallest tool set that completes its task. Enforce at the client or gateway, and server-side through scopes where the server supports it.
3. Scope credentials per tool: one workload identity per tool server, short-lived tokens, delegated user context for user-facing actions.
4. Isolate every execution path: any tool that runs code, binaries or parsers runs in an ephemeral sandbox matched to the trust tier, with no inherited secrets.
5. Close the exits: default-deny egress, metadata endpoint blocked, no route to internal registries or management planes unless explicitly required.
6. Add approvals for high-impact verbs: destructive, financial and external-send actions require confirmation or a policy engine decision. See Prompt Guardrails vs Policy Engines for AI Agent Actions.
7. Test both layers: attempt calls outside the manifest, hostile arguments to allowed tools, and egress and metadata access from inside the sandbox. Run new policies in log-only mode first, then enforce.
8. Plan rollback: keep the previous manifest and sandbox image versioned so a policy that breaks a workflow can be reverted in minutes, and keep a kill switch for each agent. See the AI Agent Kill Switch and Containment Guide.

Worked scenario: a data analysis agent

A finance team wants an agent that reads uploaded spreadsheets, runs Python to analyse them and emails a summary to the requester. The first design allowlists three tools: read_upload, run_python and send_email. The allowlist looks tight, but run_python is open-ended: injected instructions hidden in a spreadsheet cell can make the generated code read environment variables, call the cloud metadata endpoint or post data anywhere the host can reach. The allowlist is satisfied throughout.

The layered redesign keeps the same three tools but changes what sits under them. run_python executes in a per-task microVM with no network, a read-only copy of the upload and no credentials. send_email is constrained to the requester's own address taken from the authenticated session, not from model output, and attachments are size-limited. read_upload is scoped to the current user's uploads by the storage service, not by a path the model supplies. The result: a successful injection can produce a wrong analysis, which a person reviews, but cannot exfiltrate data or reach credentials. Neither control alone achieved that.

Detection and measurement

• Sandbox telemetry: blocked egress attempts, metadata endpoint access attempts, unexpected process trees and resource limit hits per task. gVisor and Firecracker both leave network policy to the host, so log at the egress proxy.
• Allowlist telemetry: denied tool calls, calls to tools not in the manifest, tool list changes on connected servers, and approval decisions. The MCP specification says clients SHOULD log tool usage for audit purposes.
• Correlation: join tool call logs with sandbox and egress logs on a task identifier so an investigator can see the whole chain.

Metrics that show the design is working:

• Percentage of agents with an enforced per-agent tool manifest (target 100 per cent in production).
• Percentage of code-executing tools running in an isolated, ephemeral environment.
• Number of open-ended tools in production, trending down as purpose-built tools replace them.
• Percentage of tool credentials that are short-lived and scoped to one tool server.
• Blocked egress and denied tool calls per 1,000 tasks, investigated rather than tuned away.
• Mean time to revoke a tool or quarantine an agent after an alert.

Common failure patterns

• Allowlisting a shell and calling it contained: an allowlist entry for an open-ended tool contains nothing. Pair it with a sandbox or replace it.
• Sandbox with open egress and inherited secrets: isolation that still reaches the internet, internal registries and a mounted token is an inconvenience, not a boundary, as the OpenAI and Hugging Face breach 2026 showed.
• Approving the tool, ignoring the credential: a well-reviewed tool server running under a shared administrative service account turns every injection into an administrative action.
• Client-side filtering only: enforcing the manifest in one framework while another client connects to the same server with no filter.
• Evaluation sandboxes treated as low risk: test and benchmark environments often get the weakest controls while running the most capable agents with the fewest restrictions.
• No re-review after change: an allowlist approved once and never revisited as tools, images and agent goals change.

Framework mapping

Practitioner checklist

• Classify every agent tool as narrow or open-ended, and list the open-ended ones by name.
• Enforce a per-agent tool manifest at the client or gateway, and server-side through scopes where available.
• Run every code, shell and parser path in an ephemeral sandbox with a second boundary for untrusted or multi-tenant input.
• Default-deny egress from sandboxes, block metadata endpoints and remove routes to internal registries.
• Remove standing secrets from sandbox environments; broker short-lived, tool-scoped tokens.
• Constrain arguments for high-impact tools and require approval for destructive, financial and external-send actions.
• Correlate tool, sandbox and egress logs on one task identifier.
• Test escape routes and out-of-manifest calls before each major release, in log-only mode first.
• Re-review manifests and sandbox tiers when tools, images or agent goals change.

Standards and references

• OWASP: LLM06:2025 Excessive Agency
• Model Context Protocol: Tools specification
• Model Context Protocol: Security Best Practices
• gVisor: Security Model
• Firecracker: Design
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE: ATLAS

Related NHI Mgmt Group resources: AI Agent Sandboxing and Code Execution Guide · AI Agent Tool and Plugin Security Guide · Know Your Agent (KYA) Guide · Human-in-the-Loop for AI Agents Guide · Agent Egress Control and Network Isolation Guide