Modal launches Sidecars to split trusted and untrusted code in Sandboxes

Modal has introduced Sidecars, isolated containers that run beside a main Sandbox on the same host and form a security boundary between trusted and untrusted code. According to Modal, communication between a Sandbox and its Sidecars is at least 3x faster than between separate Sandboxes in the same region. The feature is available in Beta.
- Modal's Sidecars are isolated containers that run next to a Sandbox on the same host, forming a trust boundary between trusted and untrusted code.
- According to Modal, communication with Sidecars is at least 3x faster than between separate Sandboxes in the same region.
- A Sandbox can run up to 250 Sidecars, and code inside the Sandbox cannot create or modify them.
- Ramp built a custom egress proxy on Sidecars for its Inspect coding agent.
- Sidecars are available in Beta.
The problem: trusted code inside Sandboxes
Modal says its customers use Sandboxes to run untrusted code written by their downstream users or, almost exclusively now, by agents. Isolation technologies such as gVisor and Firecracker addressed the classic problem of separating a platform from its users nearly eight years ago, according to the company. The harder question today, Modal argues, is how to protect users from their own code.
The company points to a design habit as the cause. Early coding agents like Claude Code were built to run on a user's laptop, so the harness was never separated from its tool calls. That pattern carried over to remote Sandboxes. A harness running inside its Sandbox puts credentials next to generated code, lets the agent read untrusted content such as packages and repos, and allows anything in the Sandbox to make network calls.
Modal links this to what Simon Willison calls the lethal trifecta: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally can be tricked into leaking that data.
Why current fixes fall short
Modal describes two common remedies, each removing one leg of the trifecta. The first moves the harness out of the Sandbox, separating the agent's "brain" from its "hands", a pattern Modal says Anthropic and OpenAI promote. The cost is that every agent operation then needs a network call, and for agents making many tool calls those small delays add up. Modal also notes that for a coding agent the codebase is itself private data, so exfiltration risk remains.
The second remedy is network egress controls such as domain allowlisting, credential injection and dynamic egress policy updates. Modal says these are effective for most customers but not flexible enough for all. Its example is Ramp, which needed to run a complex service next to its agent that injected secrets and also monitored external calls. Off-the-shelf secret injection did not fully cover that case.
Modal lists three requirements for a full solution: fully separate untrusted and trusted code, minimize latency for operation-heavy agents, and stay flexible enough for programs not yet imagined.
How Sidecars work
A Sidecar runs alongside a Sandbox while staying isolated from it. Trusted software can use it to inject credentials, proxy traffic, redact data, run harness logic or observe the agent. The design is inspired by Kubernetes sidecar containers and the Datadog Agent.
- Isolation: Sidecars use the same boundary as separate Sandboxes, gVisor or VMs, depending on the runtime passed to Sandbox.create().
- Latency: Containers on the same host talk over an internal bridge network via TCP/UDP, and each is reachable by name. Modal's internal benchmarks show a p50 of 0.58ms per call for a Sidecar versus 2.6ms for a separate Sandbox over HTTPS. At p99 the figures are 1.4ms and 44ms. For 100 calls, total time is 0.6s versus 1.2s.
- Creation: Sidecars are created dynamically through the Modal SDK. Code inside the Sandbox cannot create or modify them.
- Resources: Sandboxes and Sidecars share CPU and memory, which Modal says is more cost-efficient than spreading processes across Sandboxes. One Sandbox can run up to 250 Sidecars.
- Network policy: Each Sidecar has its own outbound policy, and the Sandbox's outbound traffic can be forced through a proxy Sidecar.
- Lifecycle: Sidecars can be terminated and replaced at any time, and their filesystem can be snapshotted to start another Sandbox or Sidecar. Terminating the Sandbox stops all its Sidecars.
Ramp's custom egress proxy
Ramp's background coding agent, Inspect, writes over 75% of all merged pull requests at Ramp, according to Modal, with each session in its own Modal Sandbox. Ramp built a custom egress proxy on Sidecars, running next to each Inspect Sandbox to monitor and control outbound traffic.
Zach Bruggeman, Principal Software Engineer at Ramp, said: "We can force outbound traffic through the proxy, so nothing bypasses it, and because it's on the same host, that doesn't cost us an extra network hop."
Availability and what it means
Sidecars are available in Beta, with setup details and known limitations in Modal's docs. The company has published examples for separating an agent harness from code execution, running an app and its supporting services in separate containers, and filtering Sandbox HTTPS traffic with a proxy Sidecar.
For teams running agents in Sandboxes, the pitch is that security controls no longer have to mean a remote call for every operation, and that teams can build their own trusted services rather than wait for provider features. The latency figures come from Modal's own benchmarking.
Modal: Sidecars: A low-latency trust boundary for Sandboxes

