AI Agent Sandboxing: Bounding What Agents Can Reach

Tool permissions decide what an agent may do through the doors you built for it. Sandboxing decides whether there are other doors. A runtime that can open arbitrary network connections, read the host's files, or execute code with the host's privileges gives a steered or malfunctioning agent paths around the permission model, and injected content will find them. This guide sets out isolation for agent runtimes, complementing how to design tool permissions for AI agents and the AI agent security architecture whitepaper.

What is the threat sandboxing addresses?

Path around permissions	Example
Direct network access	The agent posts data to an external endpoint named in an injected instruction
Local secrets	A credential file on the host is read and used
Filesystem	Shared mounts expose documents outside the role's scope
Code execution	Generated code runs with the host's identity and access
Cloud metadata	Instance credentials obtained from a metadata endpoint
Resource exhaustion	A loop consumes compute or budget until stopped

Each is closed at the environment level, where a prompt cannot reopen it.

What are the isolation layers?

Layer	Control
Compute	An isolated environment per agent role (container, micro-VM, or dedicated virtual desktop for computer-use agents), no persistent state between tasks unless required
Network	Egress denied by default; allowlist limited to the gateway and approved destinations; no direct access to systems of record
Secrets	None in the environment; credentials brokered at call time by the tool layer, per secrets management for AI agents
Filesystem	Read-only base; scratch space per task; no sensitive mounts
Identity	The environment holds the agent's workload identity only; no host or cloud instance credentials reachable
Resources	CPU, memory, execution time, step and token budgets per task
Observability	Environment-level logging of network attempts, file access, and resource use

How does sandboxing differ by agent type?

• Tool-calling agents over APIs: the standard layers; the main risk is egress and secrets.
• Code-executing agents: strongest compute isolation; ephemeral environments per execution; no network unless the task requires an allowlisted destination; outputs scanned before use.
• Computer-use and browser agents: dedicated virtual desktops or browser profiles with application and URL allowlists, downloads controlled, session recording; see computer-use agent security.
• Document-processing agents: isolation from the document source's wider store; scanning of inputs; output redaction.

Why is the gateway the only door?

With egress limited to the gateway, every action an agent takes passes through identity, permission, gate, and logging controls. A sandbox that allows direct calls to systems "for performance" reopens every path the permission model closed. Performance is solved with pooled connections at the gateway, not with holes in the sandbox. The gateway is described in how to build an MCP gateway.

What limits stop runaway behavior?

Per task: step budget, token budget, execution time, and cost ceiling, enforced by the runtime and the gateway with alerts before hard stops. Per environment: CPU and memory caps. A budget breach ends the task with an escalation, never a retry loop. Budget design is discussed in the AI agent unit economics whitepaper.

How is containment tested?

Automated escape tests run inside the agent's environment in CI and after infrastructure changes:

1. Outbound connection to a non-allowlisted host is blocked.
2. Secret and credential paths are unreadable.
3. Sensitive filesystem paths and mounts are absent.
4. Metadata endpoints are unreachable.
5. Resource caps trigger.
6. A generated script cannot escalate privileges.

Results are recorded with the environment version. A red-team exercise periodically attempts the same through injected content end to end; scope is described in AI penetration testing scope.

How does sandboxing fit with evaluation and operations?

Sandboxes are also where end-state evaluation runs: a copy of the systems the agent touches, isolated the same way, lets the harness verify what an agent would have changed without touching production. The same environment images serve shadow mode and production, so a containment property tested in evaluation holds at runtime. Operationally, environment versions are recorded on every trace, escape-test results are attached to each version, and the runbook names the environment as the first thing to check when an agent's behavior changes after an infrastructure update. The evaluation design is in how to build an agent evaluation harness.

What are the common mistakes?

1. Agents on shared hosts with the host's network and files.
2. Egress "temporarily" open to a system of record.
3. Secrets mounted for convenience.
4. Code execution on the same host as the orchestrator.
5. No budgets, so loops run until someone notices.
6. Sandbox never tested.

How does FISTA Solutions help?

FISTA Solutions runs every AI agent it delivers in isolated environments with gateway-only egress, brokered credentials, and budgets, builds the escape-test suite as part of its AI enablement platform work, and aligns isolation with your infrastructure and security teams through forward deployed engineers. FISTA has delivered 150+ projects for 50+ companies across 12+ countries with 99.9% uptime.

To assess how contained your agents are, message FISTA on WhatsApp, or read AI agent kill switch design for the control that stops an agent the sandbox could not.