Skip to main content
AI & Agents

Agent Sandboxing

Agent sandboxing is isolating the environment an AI agent executes in — file system, network access, credentials and compute — so that a wrong or manipulated agent cannot reach anything outside its granted boundary. It assumes the model will eventually make a bad decision or be compromised, and contains the blast radius in infrastructure rather than in the prompt.

The premise is that an agent is untrusted code with a convincing interface. Prompt injection means any content the agent reads can contain instructions aimed at it, and prompt-level restrictions are preferences the model may ignore. Sandboxing moves the boundary somewhere text cannot reach: the operating system, the network and the identity layer.

A sandbox is built in layers. Code the agent generates runs in an ephemeral container or microVM — Firecracker-class isolation is the standard for multi-tenant code execution — with resource limits and no route to production networks. Outbound traffic passes an egress allowlist. Credentials are scoped per tool, short-lived, and read-only wherever possible. Tenants are separated by namespace, so one customer's agent can never address another customer's data.

The design discipline is deny by default and assume breach. Enumerate what the agent can reach rather than what it is told to avoid, then audit that list: every reachable system is a system a manipulated agent can operate. Destructive operations require an approval token the model cannot mint for itself, issued by a human or a separate policy service. The test of a sandbox is simple — a fully compromised agent should be an incident report, not a data breach.

Network policy is the layer most often got wrong. An agent that can fetch arbitrary URLs can be steered into calling internal services — the classic server-side request forgery pattern — and cloud metadata endpoints are a standing invitation to credential theft. Egress allowlists, blocked link-local address ranges and no route from the sandbox into internal networks close the bulk of the exposure, and DNS-based exfiltration deserves an explicit check rather than an assumption that the firewall covers it.

These decisions belong in the architecture review before the first tool is wired up. Retrofitting isolation onto a running agent means untangling credentials, network paths and assumptions baked into every integration, which is why teams defer it until an incident forces the issue. Defining the trust boundary first and then granting the agent the minimum inside it is faster to build, not slower — permissions are added deliberately instead of discovered during incident response.

Codazz builds this in production — AI Agent Development.

FAQ

Agent Sandboxing
FAQ.

Common questions about agent sandboxing.

Ask Us Anything

Guardrails constrain what an agent is allowed to do — limits, approvals, validation — enforced in the tool layer. Sandboxing constrains where an agent can reach, enforced in the environment: network, file system, credentials. They overlap deliberately; a system needs both, because a guardrail bug inside a tight sandbox is a contained event, while a guardrail bug with production network access is not.

Whenever an agent executes generated code, holds credentials with write access, or can reach systems beyond its own workspace — which is most production agents. A read-only research agent over public content can run with light isolation; an agent that runs code or touches production data needs the full treatment: ephemeral execution, egress allowlists, scoped short-lived credentials and tenant separation.

Slightly, and it is worth it. Starting an isolated execution environment adds latency measured in milliseconds to seconds depending on the technology, and an egress allowlist occasionally blocks a legitimate call until it is reviewed. Against that sits the alternative: an agent with production network access and standing credentials is one successful injection away from an incident whose cleanup dwarfs every millisecond ever saved.