Sandbox model-generated code and computer-use agents

An agent that writes and runs code turns text into execution. The model cannot reliably tell instructions from data, so a web page, document, email or tool result it read can steer what it writes, and the code then runs with whatever the runtime can reach. The OWASP Top 10 for Agentic Applications 2026 lists this as ASI05 Unexpected Code Execution (RCE): generated scripts, shell commands, deserialized objects or template evaluation that lead to host or container compromise, persistence or sandbox escape. Its examples include prompt injection that runs attacker-defined code and unverified package installs that execute during installation.

Auto-GPT showed how quickly this reaches the host. Its own advisories describe two flaws fixed in version 0.4.3. In CVE-2023-37273, the docker-compose.yml in the repository root mounted itself into the container without write protection, so code run through the execute_python_file or execute_python_code commands could overwrite it and gain control of the host the next time Auto-GPT started. In CVE-2023-37274, which affected the setup that runs Auto-GPT on the host and only the generated code in a container, execute_python_code wrote model-supplied code to a file with a model-supplied name it did not sanitize, so a name such as ../../../main.py overwrote Auto-GPT's own code, which then ran on the host at the next start. Positive Security's write-up reached those commands through an indirect prompt injection on a web page the agent browsed.

Nothing inside the interpreter fixes this. Python's documentation says audit hooks "are not suitable for implementing a sandbox" and that malicious code can disable or bypass them; denylists of imports or shell commands fail the same way. The boundary has to be the operating system or a hypervisor, and it has to assume the code is hostile on every run.

Pick the weakest boundary that still contains the code you expect, then add one level if many tenants share the machine or nobody reviews what runs. Whatever you choose, run one disposable environment per job or per session, and never reuse one across users.

The function below builds the docker run command for one job in the agent-code-sandbox project, whose live tests run each flag against real escape attempts. The image is pinned by digest. --network=none leaves only the loopback device. --read-only and a size-limited tmpfs give the code scratch space but no way to change the image. The code runs as nobody with no capabilities, and no-new-privileges stops a setuid binary from raising them again. --pids-limit ends a fork bomb, equal --memory and --memory-swap mean the kernel kills the code at the limit instead of swapping, --cpus caps its share of the machine and --ulimit=fsize caps any file it writes. --log-driver=none keeps its output out of Docker's logs, and --init reaps any processes it leaves.

What is absent matters as much: no --volume or --mount, no --env, no --privileged, no --network=host or --pid=host, no seccomp=unconfined and above all no Docker socket. Docker's own security page says only trusted users should control the daemon, because it runs as root; a container that can reach it can start a privileged container on the host. For a stronger boundary, keep the same flags and add --runtime=runsc once gVisor is installed.

def sandbox_argv(image: str, name: str, limits: Limits = Limits(), docker=("docker",)) -> list:
    """`docker run` for one job: a fresh container with no network and nothing from the host."""
    if not DIGEST_PINNED.fullmatch(image):
        raise ValueError("pin the sandbox image by digest")
    return [
        *docker, "run", "--rm", "-i", "--init", "--name", name,
        "--network=none",
        "--read-only",
        f"--tmpfs=/tmp:rw,nosuid,nodev,noexec,size={limits.tmpfs_bytes}",
        f"--user={USER}",
        "--cap-drop=ALL",
        "--security-opt=no-new-privileges",
        f"--pids-limit={limits.pids}",
        f"--memory={limits.memory}",
        f"--memory-swap={limits.memory}",  # equal to --memory: no swap
        f"--cpus={limits.cpus}",
        f"--ulimit=fsize={limits.file_bytes}",
        "--ulimit=nofile=256:256",
        "--ulimit=core=0",
        "--log-driver=none",  # the code's output must not land in Docker's logs
        image, "python", "-I", "-c", RUNNER,
    ]

A shared folder is the most common way out of a code sandbox. If the host mounts a job folder read-write and then reads the code's output files from it, the code can leave a symbolic link named report.txt that points at /home/agent/.env, and the host follows it and hands the agent's API key back to the model. In the project's live tests the starter does exactly this on Docker Desktop. Auto-GPT's compose file shows the other direction: a writable mount lets the code change something the host will later execute.

Send inputs on stdin as part of the job, write them to the container's tmpfs, and have a small runner inside the container return the exit status, stdout, stderr and any regular files from an output folder as one JSON envelope on stdout. The runner opens files with O_NOFOLLOW and skips links, but the generated code runs as the same user and can forge the envelope, so the host checks it again: valid JSON of the expected shape, file names from a strict pattern, sizes under a limit, base64 that decodes. Nothing the code returns becomes a path on the host until those checks pass.

With network access, generated code can send whatever it finds to an attacker, reach your internal services and cloud metadata endpoint, or download a second stage. Start with no network at all. That also stops pip install, which is a feature: build an image with the packages the tool supports, pin it by digest and update it on a schedule, so a hallucinated or typosquatted package name cannot be installed at run time.

If the code genuinely needs a service, do not give the container a general route out. Attach it to an internal network whose only exit is an egress proxy with an allowlist of host names (ASVS 5.0 V13.2.4), block the link-local metadata address, and prefer having the host call the API on the code's behalf through a narrow tool so the credential never enters the sandbox. Remember that DNS is a channel too: a resolver that answers any name lets code leak data in the names it looks up.

The sandbox should hold nothing worth stealing: no model API key, no cloud credentials, no repository tokens, no SSH keys, no .env file and no environment variables copied from the agent. Docker passes no host environment variables unless you ask for them, so the risk is the flag someone adds later; test for it by planting a canary variable on the host and checking the code cannot print it. If the code must act on a system, give the host a narrow, authorized tool for that action instead of handing the code a token.

Decide in advance what happens when the sandbox cannot start. A tool that falls back to subprocess.run([sys.executable, "-c", code]) "so the agent keeps working on laptops" runs hostile code with the agent's environment, files and network. Raise an error and let the agent tell the user the tool is unavailable.

Generated code loops, allocates and forks by mistake as well as by design, and every run costs you capacity. Set each limit in the runtime, not in the prompt: processes with --pids-limit, memory with equal --memory and --memory-swap, CPU share with --cpus, file size with --ulimit=fsize, and wall-clock time with a deadline on the host. The deadline must kill the container itself: docker run is only a client, so a timeout that kills it leaves the container running. The excerpt below kills the container by name and then removes it in case the client died before the container started.

Cap what goes back to the model as well. Output becomes part of the next prompt, so a script that prints 30 MB turns into an unbounded-consumption problem (LLM06:2026) and a channel for injected instructions. Return the first few kilobytes and say the rest was cut.

try:
    status = proc.wait(timeout=limits.timeout_seconds)
except subprocess.TimeoutExpired:
    # Killing the docker client does not stop the container: kill the container by name.
    subprocess.run([*docker, "kill", name], capture_output=True, timeout=30)
    proc.kill()
    proc.wait()
    # If the client died before the container started, remove the late container too.
    subprocess.run([*docker, "rm", "--force", name], capture_output=True, timeout=30)
    raise Rejected(f"timed out after {limits.timeout_seconds:g} s; container killed")

A sandbox makes computation safe to run; it does not make the result safe to act on. Sending an email, changing a record, deploying code or paying an invoice should happen outside the sandbox, through the same tool gateway and authorization as any other agent action (/domains/ai-emerging/agent-security/tool-authorization/). OWASP's ASI05 guidance says to separate code generation from execution with validation gates and to require human approval for elevated runs, with any allowlist for automatic execution kept under version control.

Show the approver the exact action, arguments and data involved, not the model's summary of them. People approve what an agent recommends more readily than they should, which OWASP lists separately as ASI09 Human-Agent Trust Exploitation; an approval screen that renders the model's explanation instead of the actual diff or payment details invites exactly that.

A computer-use agent reads screenshots and sends clicks and keystrokes, so everything on the screen is input to the model. Anthropic's computer use documentation warns that instructions on web pages or in images might override your instructions, and OpenAI's says to treat screen content as untrusted because text in a page, document or tool result "cannot grant permission or override the user's instructions". Vendors add their own detection: Anthropic runs classifiers over what the tools return, such as screenshots, and when they flag a likely injection they steer the model to check that the instruction really came from the user, and Google offers prompt injection detection for Gemini computer use as an opt-in setting that is off by default. Treat these as a second layer; all three vendors still tell you to isolate the agent.

Their documents converge on the same controls. Run the agent in a dedicated virtual machine, container or browser profile with minimal privileges, start each task from a known clean state, and allowlist the domains it may visit. Keep it away from sensitive data such as account logins: do not leave password managers unlocked or sessions signed in, and hand control to the user when a login is needed, because, as OpenAI's guide puts it, typing sensitive information into a form counts as transmission. Ask a person to confirm anything with real-world consequences: purchases and other financial transactions, sending messages, deleting data, accepting cookies or agreeing to terms. Gemini's API marks such steps with a safety_decision of require_confirmation, and the client must ask the end user and send a safety_acknowledgement before continuing. Finally, set step, time and cost limits, support cancellation, and log screenshots, proposed actions and the actions actually executed.

• On-screen injection: a page, email or image tells the agent to open another site, download a file or paste data. Allowlist domains and confirm any navigation the task did not call for.
• Credential entry: the agent types a password or card number into a form it was steered to. Keep credentials out of its reach and let the user sign in.
• Irreversible clicks: Send, Buy, Delete, Accept. Require confirmation in the client, not a polite instruction in the prompt, and show the person what will happen.

A sandbox that runs ordinary code proves nothing about hostile code. The agent-code-sandbox project's live tests run both against real Docker: legitimate analysis, a busy loop and a buggy script must still work, while a connection to a canary server on the host, a planted host environment variable, a search for the Docker socket and credential files, a link to a host file left in the output folder, a bounded fork bomb, a 1 GiB allocation, four spinning processes, an endless loop and a 32 MB output flood must all fail or be cut. Each network test has a control run with networking on that does reach the canary, so the test can fail.

Run the same cases against your own runtime after every change to the image, the flags, the container runtime or the host, and record the versions with the results. For a computer-use agent, add pages that carry injected instructions and a fake login form, and check that the agent asks before following them.

"Do not access the network" in the system prompt is a request to the model, not a control; prompt injection exists because the model cannot be relied on to follow one instruction over another. Denylists of imports, functions or shell commands are bypassed by aliases, dynamic imports, encodings and chained commands; Positive Security noted that Auto-GPT's shell command allowlist could be bypassed by chaining a disallowed command after an allowed one.

Running generated code in the agent's own process, with exec or an embedded interpreter, gives it the agent's memory, environment, credentials and network. Running it in a container that mounts the project folder, passes the agent's environment or can reach the Docker socket only moves the problem. The boundary must deny those paths by construction, and the tests must prove it.

Each row is generated code or an agent action and the result the boundary must produce. The project on this page runs the first eight against real Docker.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP Top 10 for Agentic Applications for 2026 (ASI05 Unexpected Code Execution). Version 2026, December 2025.
2. OWASP AI Agent Security Cheat Sheet
3. Auto-GPT advisory GHSA-x5gj-2chr-4ch6: Docker escape when running from docker-compose.yml in the git repo (CVE-2023-37273)
4. Auto-GPT advisory GHSA-5h38-mgp9-rj5f: Python code execution sandbox escape in the non-Docker version (CVE-2023-37274)
5. Positive Security: Hacking Auto-GPT and escaping its docker container (third-party research). 29 June 2023.
6. Python documentation: sys.addaudithook (audit hooks are not a sandbox). Python 3.14.
7. Docker docs: docker container run (option reference)
8. Docker docs: Resource constraints (memory, swap and CPU)
9. Docker docs: None network driver
10. Docker docs: Seccomp security profiles for Docker
11. Docker docs: Docker Engine security (daemon attack surface)
12. gVisor: What is gVisor?
13. gVisor: Docker quick start (--runtime=runsc)
14. Firecracker microVMs
15. Wasmtime: Security
16. Pyodide: Python compatibility (WebAssembly constraints). Pyodide 314.0.7.
17. Anthropic: Computer use tool (security considerations)
18. Anthropic: Code execution tool (containers, networking and limits)
19. OpenAI: Computer use guide (Run safely)
20. OpenAI: Code Interpreter guide (containers)
21. Google: Gemini API computer use (safety decisions and best practices)
22. Google: Gemini API code execution (limitations)

Reference information

Tags

Kubernetes and containersAI agents and tools

SDLC phase

DesignDevelopment

Role

DevelopersPlatform engineers and SREs

ASVS 5.0.0 requirements

v5.0.0-15.2.5 · v5.0.0-15.2.2 · v5.0.0-13.2.4

Download this guide as Markdown

Continue exploring