Back to blog
sandboxcode interpreterescapeAI agents

AI Agent Code Sandbox: Escape, Network and Tests

Published on 2026-11-047 min read
In short: A code interpreter lets an agent write and run code, so the sandbox becomes the last barrier between a prompt injection and your systems. The four points to check are network access (DNS included), the credentials reachable from the sandbox, the file system and the container boundary. A recent public case shows that a "sandbox" mode advertised as having no network access can still let DNS requests through.

Why is the sandbox of an agent that runs code critical?

Because the code that runs may come from text a third party wrote. An agent analyzing a CSV file, a web page or an email can receive a hidden instruction telling it to run a script. Triedman, Jha and Shmatikov showed that adversarial content placed in untrusted inputs can lead multi-agent systems to execute arbitrary code, with success rates of 58 to 90 percent depending on the orchestrator in their GPT-4o trials. The sandbox then decides severity: code running in an empty enclosure reaches nothing, code that has a network and a cloud token reaches a lot.

A code interpreter is a special case of what OWASP calls Excessive Agency (LLM06): a very powerful function handed to a model that can be manipulated. So you test it as a high-privilege tool.

Which public incidents illustrate the risks?

Two verifiable facts serve as reference points, one on the agent side, one on the container side.

AWS Bedrock AgentCore Code Interpreter (BeyondTrust, 2026). Researchers at BeyondTrust Phantom Labs showed that the "Sandbox" mode of AgentCore's Code Interpreter, presented as having no external network access, let DNS queries out. By encoding data into DNS queries to a name server they controlled, they achieved data exfiltration and an interactive reverse shell. According to their repository, the mode also allowed HTTPS to S3 endpoints, and the impact depended on the IAM role assigned to the interpreter. BeyondTrust says it reported the issue to AWS on September 1, 2025; publication dates from March 16, 2026. The press (The Hacker News, CSO Online) reports that the behavior received no CVE identifier, was rated CVSS 7.5, and that AWS's update consisted of documenting that Sandbox mode allows DNS resolution while recommending VPC mode. That position may have changed since: check the service’s current state before relying on this finding. For your own deployment, the main lesson is that "isolated" in a product page does not exempt you from testing.

runc CVE-2024-21626 (2024). This flaw in the runc container runtime allowed a container breakout through leaked file descriptors and a booby-trapped working directory. It affects runc versions from 1.0.0-rc93 up to and including 1.1.11, with a CVSS score of 8.6; version 1.1.12 fixes it. It is a reminder that an agent's sandbox often rests on a container, and a container is only as safe as its engine and configuration.

Keep in mind that a sandbox failure rarely stands alone. The usual chain has three links: an injection that reaches the agent, code the agent agrees to run, and a sandbox that lets something out. Breaking any one link reduces the risk, which is why tests cover each of them separately and then together.

Which escape and abuse paths should you know?

PathWhat it enablesControl to test
Outbound network (HTTP, DNS, other protocols)Exfiltrate data, reach a command serverDeny-by-default network policy, filtered DNS
Environment credentialsCall cloud APIs with the interpreter's roleRole with no rights, no plaintext secret variables
Cloud metadata serviceRetrieve temporary tokensAccess blocked from the sandbox
Shared file systemRead other sessions' or customers' filesPer-session volume, wiped at the end
Container boundaryEscape to the hostUpdated engine, confinement profiles, unprivileged user
ResourcesDenial of service, miningCPU, memory, time, process limits
Package installationMalicious third-party code or package hallucinationInternal repository or allowlist
Execution outputsBooby-trapped content rendered in the interfaceOutput treated as untrusted

How do you test a code interpreter sandbox?

You test by asking the agent to run reconnaissance programs and observing what it can reach. Tests run on a development or staging environment, with test credentials, and with the system owner's written consent.

  1. Map the environment. User, environment variables (without recording real secrets), mount points, available binaries, kernel version. Note what is exposed.
  2. Test the network. DNS resolution of a test domain you control, outbound HTTP request, connection to an internal address, access to the metadata service. DNS deserves a separate test: a "closed" network that lets DNS queries through allows slow exfiltration. Check the logs on your test domain's side.
  3. Test the credentials. Can the code call a cloud API? With which role? Listing storage objects is already a finding. Do not read or download real data: confirm access, count, stop.
  4. Test isolation between sessions. Write a marker file in one session, look for it from another session or another test account.
  5. Test resource limits. Is an infinite loop or a massive memory allocation stopped? After how long?
  6. Test the full chain. From an indirect injection (a booby-trapped file or page), does the agent write and run a script on its own initiative? That is the realistic scenario.

Each finding comes with the command run, the output obtained and the environment version.

What containment should you put in place?

Effective containment combines several layers, because none is enough alone:

  • Deny-by-default network, DNS included, with an outbound allowlist limited to what the task requires. A product's "no network" mode is verified by a test, never on the strength of its description.
  • Minimal identity role: the interpreter has no rights, or only read rights on a specific dataset.
  • Ephemeral session: a fresh environment per session, destroyed after use, with no shared volume.
  • Stronger isolation: unprivileged container, syscall filtering profile, or lightweight virtual machine for high-stakes cases; keep the container engine up to date.
  • Resource limits: CPU, memory, time, process count, output size.
  • Human approval before any execution that touches anything other than data the user deposited themselves.
  • Logging of executed code and attempted connections.

Report every result with the environment version and the date, because sandbox behavior changes when a provider updates its service. A test that passed in spring may not describe the product you run in autumn, so plan a retest after each significant platform change.

When should you bring in an external test?

When the agent runs code on customer data or holds cloud credentials, the test deserves an independent view. The Agent Red Team Express (€1,900, 5 days, start within 48 hours after the quote and authorization are signed) covers one agent with its interpreter: injection chain, network, credentials, isolation between sessions. For a platform with several agents and several execution environments, the Custom Red Team is quoted individually. We test on development or staging by default; production is targeted only at the client's written request. First step: a free 30-minute discovery call.

Further reading

Does your product ship an AI agent? CleanIssue tests what a stranger can make it do with the Agent Red Team Express (5 days, €1,900), or a custom red team for several agents and MCP servers. First step: a free 30-minute discovery call.

Know what your agent can do before an attacker does.

A free 30-minute discovery call: you describe your agent, I tell you what I would test and what it costs. Five case studies are published.

Book a call