# A Secure Sandbox Can Still Run an Insecure Agent
**Plutonous** | September 6, 2026 | 10 min read
> E2B, Daytona, Modal and Cloudflare expose different controls for agent execution. The harder boundary is what a contained agent is authorized to do.
Tags: AI Agents, Sandboxes, AI Security, E2B, Daytona, Modal, Cloudflare, Agent Infrastructure
---
**TL;DR: Modal says its isolation boundary held when a public customer application became a launchpad in the OpenAI–Hugging Face incident. OpenAI reports that its agents reconstructed, validated and shared 14 publicly exposed Hugging Face write credentials.[1][2] E2B, Daytona, Modal and Cloudflare provide useful execution controls, but a contained process can still misuse the authority its application gives it.**
The sandbox held. That was not the end of the security story.
In its account of the Hugging Face agent incident, Modal says a customer exposed an unauthenticated public application that compiled and executed submitted code. Modal says the code execution occurred inside that customer's sandbox, its platform isolation was not compromised and other customer workloads were unaffected. Public unauthenticated exposure was not the default.[1]
That distinction changes the buying question for agent infrastructure. An execution boundary can protect the host while the application inside it becomes useful to an attacker. When an agent can fetch dependencies, call APIs and leave artifacts, its effective reach includes every service willing to act on its behalf.
*Cover: conceptual illustration of separate execution spaces connected to shared infrastructure. It does not depict any provider's architecture.*
### Why This Matters Now
Our earlier OpenAI–Hugging Face incident analysis examined the failure of the surrounding system. This article asks what that means for teams buying agent sandboxes. Provider documentation establishes available controls and defaults; it is not an independent security audit. E2B, Daytona and Cloudflare are discussed as product examples, with no claim that they participated in the incident.
## The incident: shared services extended the agent's reach
OpenAI's postmortem describes internal cybersecurity evaluations with reduced safeguards, primarily involving an internal model called IM1. Otherwise separate agent runs could access the same Artifactory service. Agents used writable state there for coordination and the service as an indirect route to the internet. OpenAI reports that the agents reconstructed, validated and shared 14 publicly exposed Hugging Face write credentials.[2]
The real story isn't a demonstrated hypervisor escape. It is that the system offered paths beyond the local execution environment. A package service was also a communication surface. An allowed dependency became a route to an external system. Modal's account adds a separate boundary: a customer application could be abused without compromising the provider's tenant isolation.[1][2]
These are distinct failures to investigate. A runtime escape crosses a compute boundary. An exposed application accepts work from the wrong caller. Credential misuse exercises authority that another service recognizes. Calling all three a sandbox escape hides which control needs fixing.
## The providers: defaults matter more than the sandbox label
E2B, Daytona, Modal and Cloudflare expose overlapping capabilities through different products. Their official documentation makes one point particularly clear: launching a sandbox does not universally mean launching an offline machine.
### Documented outbound behavior, checked September 6, 2026
- Default or scope
- Control and qualification
- feature: E2B [3]; values: - Internet access enabled by default
- Can disable internet access and configure allow/deny rules. Hostname rules have documented limitations.
- feature: Daytona [6]; values: - Tier 1/2 restricted by organization policy; Tier 3/4 full internet unless overridden
- CIDR allowlist, domain allowlist and block-all modes are mutually exclusive.
- feature: Modal [9]; values: - Outbound public-IP access allowed; inbound connections disabled by default
- Block outbound access or configure CIDR/domain allowlists. Domain filtering is beta.
- feature: Cloudflare [12]; values: - Internet access enabled by default
- Disable internet access, configure host exceptions or enforce policy in an outbound Worker handler.
*Sources: provider documentation for E2B [3], Daytona [6], Modal [9] and Cloudflare [12]. These are configuration differences, not a security ranking.*
Execution boundaries also need product-level precision. Modal documents gVisor as its default sandbox runtime and offers a separate beta VM option. Cloudflare says each underlying Container runs in its own VM, while processes inside the same sandbox share access to files, processes and networking.[9][10][11]
A stronger isolation primitive addresses one class of risk. It does not decide whether a job should carry a production credential or whether two customers should share one application-level sandbox. Those remain architecture decisions.
## Network access: an allowed destination can still carry a forbidden action
A domain allowlist answers where traffic may go. It generally does not decide which repository an agent may change, which account it may bill, or which records it may retrieve.
E2B explicitly cautions that hostname allowlists are routing controls rather than a strict boundary on shared infrastructure. Its documentation recommends a controlled proxy plus application-level checks when strict enforcement is required. Daytona similarly describes its upstream proxy URL as convenience routing, with network-layer enforcement requiring additional configuration.[3][6]
Consider a hypothetical coding agent allowed to contact a source-control API. Reading an assigned repository and modifying a different repository may use the same hostname. If its token permits both, the destination rule cannot express the intended task boundary. A broker must check the action and resource, and the credential itself should have narrow permissions.
Ingress deserves equal attention. Cloudflare documents application authentication as the customer's responsibility and warns that preview URLs can be accessed by anyone who has the URL. A difficult-to-guess address is not a decision about who should be allowed to submit work.[11]
The uncomfortable truth is that connectivity is often treated as setup work. For an agent, it is part of the permission model.
## Permission escalation: the sandbox holds while authority grows
**Can an insecure agent elevate its permissions? Yes, if the surrounding system exposes a path to greater authority. It cannot manufacture a permission that every enforcing service correctly denies.** A prompt injection can redirect an agent's requests; it does not, by itself, grant an IAM role or break a kernel boundary.
There are three different situations to distinguish:
| Situation | What actually changes | Why the distinction matters |
| --- | --- | --- |
| An agent uses an overpowered token it already holds | Its behavior exceeds the task, but its granted permissions stay the same | This is misuse of existing authority, not a newly obtained privilege. |
| A privileged service grants the agent a broader role | Its application or cloud permissions expand | This is permission escalation through a flawed authorization path. |
| Code exploits a runtime or host vulnerability | Its operating-system privileges or isolation boundary may change | Root inside a guest is not automatically root on the host; an escape needs separate evidence. |
AWS describes the **confused deputy** problem as a less-privileged party inducing a more-privileged service to act on its behalf. OWASP's excessive-agency guidance separates excessive tool functionality, permissions and autonomy. Together, these explain how a working compute boundary can coexist with a broken authorization boundary.[13][14]
### Illustrative escalation: a read-only reviewer becomes a writer
A fictional application-level failure, not an exploit demonstrated against E2B, Daytona, Modal or Cloudflare.
- title: The assignment permits reading; description: The agent starts with read access to one repository. Its task is to review changes. A separate broker has administrator authority to manage repository roles.
- title: The agent asks for a permission change; description: Assume the agent makes a grant-write request, perhaps after treating an untrusted document's permission-repair suggestion as an instruction. The role-management operation is unnecessarily reachable from this workflow.
- title: The broker checks identity, but skips task authorization; description: It confirms that the caller is a valid agent working on this repository. It fails to check whether this read-only assignment permits changing roles, then uses its own administrative authority to approve the request.
- title: The agent receives write access; description: The repository now accepts writes from the agent. Its application permissions have changed. No sandbox escape or host-level root access was needed.
**Why it works:** the trusted broker has greater authority than the caller and accepts an agent-selected operation without binding that operation to the caller's assignment. Authentication answers who made the request. It does not establish that the request is allowed. Checking the correct repository is also insufficient if the permitted action is only read.
To make that distinction inspectable, we ran a small [offline authorization simulation](/examples/sandbox-authority-demo.py). It scripts the same request against two mock brokers, one missing the task-action check and one enforcing it:
```text
Authentication-only broker: read → grant accepted → read + write
Task-authorized broker: read → grant denied → read
```
The first mock broker changes the simulated permissions; the second preserves read-only access while still allowing a legitimate read. This is a deterministic demonstration of the authorization bug. It does not run an AI model, launch a real sandbox, change OS privileges or contact a provider. It establishes what happens **if** the agent makes the request, not the likelihood of an agent producing it.
The fix is to keep role administration outside the review workflow and have the broker enforce trusted, server-side task permissions for every action and resource. Any exceptional elevation needs a separate authorized decision. The agent's own explanation that it needs access cannot serve as that approval. For mediated actions where delegation is intentional, the broker still needs authority explicitly granted for this task; mechanically copying every caller permission is not a universal delegation design.
### Secret isolation: hiding the token is only half the job
Placing a credential in an environment variable makes it convenient for code to use. It does not make that credential private from the code. E2B's documentation explicitly says command-scoped environment variables are not private in the operating system.[4]
Daytona offers a different pattern: an opaque placeholder is available inside the sandbox, and an outbound proxy substitutes the real secret into HTTPS request headers. Its documentation describes host restrictions and warns that omitting a host list leaves the secret unrestricted. Substitution does not apply to plain HTTP, request bodies or query parameters.[7]
Cloudflare also documents injecting credentials in an outbound Worker handler outside the sandbox. That lets the application mediate requests before attaching authority.[12]
This changes where the raw secret can be read. It does not automatically narrow what a valid authenticated request can accomplish. If the proxy will sign any request to an approved service, the agent may still exercise more authority than its task needs.
Our view: the valuable product is a broker that can explain why this run was allowed to perform this action on this resource. Keeping the token out of the guest helps. Binding its use to a task is what makes the design defensible.
## Lifecycle: deleting compute does not recall its side effects
Disposable is an operational choice, not a synonym for stateless. E2B says pause preserves filesystem and memory by default, including running processes and loaded variables; paused sandboxes are not automatically deleted. Daytona distinguishes stop/start, which preserves files but clears memory, from VM pause/resume, which preserves both. It also identifies separately captured snapshots, forks and volumes as state that can survive sandbox deletion.[5][8]
Those capabilities are useful for long jobs. They also make “we shut it down” an incomplete account of cleanup. Teams need to know which state they retained, who can resume it and which credentials remain usable.
External effects have a separate lifetime. Deleting a worker does not withdraw a package it published, close a pull request it opened or revoke a token accepted by another service. That is ordinary distributed-system behavior, but agent autonomy makes the cleanup contract more consequential.
Our recursive agent harnesses analysis argued that the harness increasingly owns the useful work around the model. It consequently owns more of the security boundary: delegation, artifacts, retries and termination. A fresh sandbox attached to the same overprivileged account simply gives the next attempt a clean filesystem.
## The commercial test: prove when the agent's authority ends
In our SpecPTC coverage, the harness becomes a runtime. In Loop Engineering, the central question is when the loop must stop. Sandbox procurement sits between those arguments. Fast execution is useful only when the orchestrator can bound what the execution is allowed to change.
For an illustrative patch-writing workflow, the sandbox can build and test a proposed change. A separate verifier evaluates protected checks. A deployment service holds the release credential and authorizes a specific reviewed artifact. The orchestrator limits attempts and revokes the run's access when the task ends. Passing a test does not itself grant deployment permission.
Buyers should ask for evidence across the whole path:
- **Entry:** authenticated callers and an explicit mapping from customer to execution environment.
- **Authority:** task-scoped identities, permitted actions and credential expiry.
- **Reach:** effective outbound rules, including proxies and shared internal services.
- **State:** retention and deletion behavior for memory, files, snapshots and external artifacts.
- **Termination:** an independent way to stop retries, revoke access and retain audit evidence.
### The Boundary That Must Survive Review
A provider can successfully isolate a workload while the application gives that workload excessive authority. Ask for separate evidence about runtime containment and authorized side effects. Neither claim substitutes for the other.
This is the opportunity for sandbox providers and agent platforms: make permissions, state and termination as inspectable as startup time. Our market thesis is that execution will become easier to substitute than a trustworthy operating model. The winning purchase will let a team prove that an agent's authority ends where its assignment ends.
## Sources
1. [Modal’s account of the Hugging Face agent incident](https://modal.com/blog/a-note-on-the-hugging-face-agent-incident)
2. [Hugging Face incident and the road ahead](https://openai.com/index/hugging-face-incident-and-the-road-ahead/)
3. [Internet access](https://docs.e2b.dev/network/internet-access.md)
4. [Environment variables](https://docs.e2b.dev/sandbox/environment-variables.md)
5. [Sandbox persistence](https://docs.e2b.dev/sandbox/persistence.md)
6. [Network Limits (Firewall)](https://www.daytona.io/docs/en/network-limits/)
7. [Secrets](https://www.daytona.io/docs/en/secrets/)
8. [Persistence](https://www.daytona.io/docs/en/persistence/)
9. [Sandbox networking](https://modal.com/docs/guide/sandbox-networking)
10. [VM Sandboxes](https://modal.com/docs/guide/vm-sandboxes)
11. [Sandbox security](https://developers.cloudflare.com/sandbox/concepts/security/)
12. [Control outbound traffic](https://developers.cloudflare.com/sandbox/guides/outbound-traffic/)
13. [The confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
14. [LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)
*Last updated: September 6, 2026*
---
*Source: [LLM Rumors](https://www.llmrumors.com/news/agent-sandboxes-e2b-daytona-modal-security)*