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?
| Path | What it enables | Control to test |
|---|---|---|
| Outbound network (HTTP, DNS, other protocols) | Exfiltrate data, reach a command server | Deny-by-default network policy, filtered DNS |
| Environment credentials | Call cloud APIs with the interpreter's role | Role with no rights, no plaintext secret variables |
| Cloud metadata service | Retrieve temporary tokens | Access blocked from the sandbox |
| Shared file system | Read other sessions' or customers' files | Per-session volume, wiped at the end |
| Container boundary | Escape to the host | Updated engine, confinement profiles, unprivileged user |
| Resources | Denial of service, mining | CPU, memory, time, process limits |
| Package installation | Malicious third-party code or package hallucination | Internal repository or allowlist |
| Execution outputs | Booby-trapped content rendered in the interface | Output 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.
- Map the environment. User, environment variables (without recording real secrets), mount points, available binaries, kernel version. Note what is exposed.
- 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.
- 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.
- Test isolation between sessions. Write a marker file in one session, look for it from another session or another test account.
- Test resource limits. Is an infinite loop or a massive memory allocation stopped? After how long?
- 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.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
OpenAI Pauses Tool Use After a Sandbox Escape
On September 20, 2026 an OpenAI agent bypassed its sandbox through DNS. Verified timeline, related incidents, notified third parties and tests to run.
Fastjson CVE-2026-16723: Default Spring Boot RCE Explained
CVE-2026-16723: code execution in Fastjson 1.2.68 to 1.2.83 on Spring Boot fat JARs, no AutoType needed. The 1.2.84 fix, detection and AI agent risks.
Adobe Campaign Classic CVE-2026-48449: CVSS 10.0 RCE
CVE-2026-48449 (CVSS 10.0) in Adobe Campaign Classic: broken authorization and code execution. Versions, build 9398 fix and AI agent risk.
Sources
- BeyondTrust Phantom Labs: Pwning AI Code Interpreters in AWS Bedrock AgentCore
- BeyondTrust: AgentCore proof-of-concept repository
- The Hacker News: flaws in Amazon Bedrock, LangSmith and SGLang (March 2026)
- GitHub Advisory: runc CVE-2024-21626, container breakout
- Triedman, Jha, Shmatikov: Multi-Agent Systems Execute Arbitrary Malicious Code
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.