AI Agent Sandboxing: Safely Running Untrusted Code in Production

An AI agent that can execute code is not merely a chatbot with extra buttons. It is an untrusted workload that can interpret hostile input, make mistakes at machine speed, and combine individually harmless tools into a dangerous sequence.

The correct response is not a longer system prompt. Prompts influence behavior; sandboxes enforce boundaries. A production design must assume the model will eventually generate a destructive command, import a poisoned package, follow instructions hidden in a repository, or attempt a network call nobody expected.

This guide builds a defense-in-depth sandbox for agent-generated code without making useful automation impossible.

Define the Threat Model First

List what the agent processes and what it can reach. Inputs may include user prompts, uploaded archives, Git repositories, web pages, package metadata, test fixtures, and tool output. Any of these can contain prompt injection or executable payloads.

Protect at least five asset classes:

• host files and neighboring workloads
• cloud credentials, signing keys, and API tokens
• internal services and metadata endpoints
• customer data and source code
• compute budget and service availability

Then define the maximum acceptable blast radius. For a code-review agent, losing one disposable workspace may be acceptable. Reading another tenant’s workspace, reaching production, or extracting a secret is not.

Use Ephemeral Isolation Per Run

Create a fresh environment for every job and destroy it after completion. Never reuse a writable workspace between unrelated users. Copy in only the required repository snapshot and collect explicit outputs such as a patch, test report, or build artifact.

Containers are a useful packaging layer, but a default container is not a complete hostile-code boundary. Harden it with a non-root user, a read-only root filesystem, dropped Linux capabilities, no-new-privileges, a restrictive seccomp profile, and explicit CPU, memory, process, and disk quotas.

For higher-risk public workloads, use stronger isolation such as a microVM or sandboxed container runtime. The added startup cost is usually cheaper than treating the host kernel as part of every user’s trust boundary.

Make the Filesystem Disposable and Narrow

Mount only the files needed for the task. Keep the base image read-only and provide a small writable workspace with a strict size limit. Do not mount the host Docker socket, SSH agent, home directory, package-manager credentials, or deployment configuration.

Treat path traversal and symlinks as hostile. Resolve paths before access and reject destinations outside the workspace root. Inspect uploaded archives before extraction: entries containing absolute paths, .. segments, device files, or oversized decompressed content should fail closed.

At the end of the run, export only allowlisted artifacts. A generated file should not become trusted merely because the agent labels it a report.

Deny Network Access by Default

Most code tasks do not need arbitrary outbound internet access. Begin with no network and open narrowly scoped routes only when required.

If dependency installation is necessary, route it through a controlled proxy or internal package mirror. Allow specific registries, cap download size, log requests, and pin versions or lockfiles. Block cloud metadata services, private address ranges, localhost services, and DNS rebinding paths.

Separate fetching from execution where possible. One constrained worker can download and scan dependencies; a second networkless worker can run them. This prevents a test script from quietly sending source code to an external endpoint.

Keep Secrets Outside the Sandbox

Do not inject a broad environment file into a code-execution worker. If the task truly needs a credential, use a short-lived, narrowly scoped token delivered only at the moment of use. Prefer a broker that performs the privileged operation on the agent’s behalf after policy checks.

For example, the sandbox can request “read issue 123” from a broker. The broker verifies tenant, repository, operation, and approval state, then returns only that issue. The sandbox never receives a reusable GitHub token.

Redact secrets from prompts, logs, traces, exceptions, and generated artifacts. Rotate credentials after suspected exposure; deleting a log is not revocation.

Enforce Resource Limits

Untrusted code can exhaust a system without exploiting a vulnerability. Apply hard ceilings for wall-clock time, CPU, memory, process count, open files, output bytes, and disk usage. Kill the entire process group when the job ends so grandchildren cannot survive.

Set separate budgets for model calls and tool loops. An agent caught in a retry cycle can create a costly denial of service even when the sandboxed code behaves normally.

Return structured failure reasons such as timeout, memory limit, blocked network, or policy denial. This helps the agent recover safely instead of repeatedly trying variants of a forbidden action.

Put Privileged Actions Behind a Broker

The execution worker should not deploy, merge, send email, modify billing, or write to production. Represent these as typed requests to a separate policy-enforcing service.

Each request should include the actor, tenant, intended resource, operation, parameters, provenance, and risk class. The broker validates schemas, applies allowlists, checks rate limits, and requires human approval for consequential changes.

This architecture turns an open-ended shell into a constrained capability system. The model may decide what it wants to do, but infrastructure decides what it is allowed to do.

Observe Every Boundary

Record the immutable job ID, input digest, image version, policy version, commands, exit codes, resource usage, network attempts, broker requests, approvals, and exported artifacts. Keep logs outside the sandbox so code cannot rewrite its own history.

Alert on repeated policy denials, metadata endpoint probes, unexpected binary downloads, fork bursts, large encoded outputs, and attempts to access neighboring workspaces. These signals are useful even when the boundary holds.

Avoid logging complete sensitive prompts by default. Security telemetry must not become a second data leak.

Test the Sandbox Like an Attacker

Build a regression suite with malicious archives, symlink escapes, fork bombs, oversized output, dependency install scripts, prompt-injected READMEs, DNS tricks, metadata probes, secret searches, and delayed child processes.

Test both prevention and cleanup. A passing test means the action was blocked, the worker terminated, no secret appeared in output, no persistent process remained, and the next tenant received a clean environment.

Patch the runtime and base images continuously. Pin images by digest, generate a software bill of materials, scan dependencies, and roll out changes with canaries. Isolation is a maintained system, not a launch checklist.

A Practical Production Flow

Use this sequence for every execution:

1. Authenticate the user and classify the requested capability.
2. Normalize and scan inputs before they enter the worker.
3. Create a fresh sandbox from a pinned image.
4. Mount a minimal workspace and apply resource limits.
5. Start with network denied and no ambient credentials.
6. Run commands under a non-root identity with a hard deadline.
7. Route privileged operations through a policy broker.
8. Export only validated, allowlisted artifacts.
9. Preserve external audit events and destroy the environment.

AI agent sandboxing works when no single control must be perfect. The model can be manipulated, a dependency can be hostile, and a command can be wrong while the system still contains the damage. That is the standard production agents need: not guaranteed obedience, but enforced limits.