What should be sandboxed: code, the browser, or the whole AI agent?

Scope

Use this decision for agents that execute generated code, browse untrusted sites, manipulate files, call tools, or install dependencies. The goal is to contain resources and effects. Content policy and prompt-injection detection remain additional layers.

Why it happens

Teams ask which component to sandbox as though code and browser were alternatives. An agent may read an untrusted webpage, write a script, execute it, open a file, call a network tool, and persist a memory in one task. The attack path crosses component names.

A sandbox also fails when it is isolated computationally but receives production credentials, writable shared volumes, unrestricted egress, or a long-lived home directory. The boundary is defined by resources and channels, not the virtualization logo.

Diagnosis

For each task class, list untrusted inputs and intended effects. Then enumerate resources: CPU/GPU, memory, processes, kernel, devices, filesystem, clipboard, browser profile, network destinations, metadata services, credentials, tools, artifact stores, and persistent memory.

Run escape-consequence questions:

• If code gains the sandbox user, what can it read or change?
• If the browser is compromised, which credentials and local services are reachable?
• Can a tool bypass egress or file restrictions?
• Does the task share state with another tenant or run?
• What remains after timeout, crash, or teardown?

Solution

Create task-specific profiles. A documentation formatter may use a locked-down container with no network and a disposable volume. Untrusted package execution may require a stronger kernel boundary or microVM, allowlisted egress through a proxy, no ambient credentials, and immutable base images. Browser automation needs an isolated profile, download quarantine, navigation policy, and separation from host secrets.

Keep the policy engine, credential broker, and audit sink outside the worker sandbox. Give the worker capability handles only for approved resources and duration. Apply CPU, memory, process, storage, network, and wall-clock budgets. Destroy the environment after the task and verify cleanup.

Test with known malicious files, websites, dependency behavior, network scans, fork bombs, resource exhaustion, and teardown failures in a dedicated environment.

Artifact

Complete a sandbox profile per task tier:

Dimension	Required decision
Untrusted inputs	Prompt, page, code, package, file, tool result, or memory
Isolation	Process, container, userspace kernel, microVM, VM, or remote service
Files	Read-only base, writable paths, mounts, downloads, size, and persistence
Network	Deny by default, allowlist, DNS/proxy, metadata endpoints, and bandwidth
Credentials/tools	None by default; brokered, task-bound handles and operations
Compute	CPU/GPU, memory, process, device, and wall-clock limits
Cross-tenant	Namespace, caches, images, artifacts, and cleanup proof
Observability	Metadata, security events, content-capture policy, and tamper resistance
Teardown	Kill, revoke, wipe, verify, and quarantine on failure
Escape consequence	Reachable assets, detection, containment, and response owner

Common mistakes

• Treating a browser sandbox as containment for shell and tool calls.
• Mounting host credentials or broad sockets into a disposable worker.
• Allowing unrestricted egress because the filesystem is isolated.
• Reusing writable state across tenants or tasks.
• Declaring teardown complete without verifying processes, volumes, tokens, and external jobs.