ModalAnnouncement
Modal introduces Sidecars, isolated containers that run alongside a main Sandbox on the same host, establishing a trust boundary between trusted and untrusted code. Sidecars enable communication across trust boundaries at least 3x faster than using separate Sandboxes, reducing latency for operation-heavy agent workloads. The feature addresses the security risk of running an agent’s harness and tool calls together, which creates the “lethal trifecta” of private data, untrusted content, and external communication. Existing solutions either move the harness to a remote service (adding network latency) or rely on egress controls that lack flexibility. Sidecars allow trusted services such as credential injection, proxy traffic, and harness logic to run locally alongside the Sandbox, with independent network policies and dynamic creation via the Modal SDK.
Modal’s Sandboxes execute untrusted code from users and agents. Running an agent’s harness alongside its tool calls creates a security risk (the ‘lethal trifecta’ of private data, untrusted content, and external communication). Existing solutions either move the harness to a remote service (adding latency) or use egress controls (lacking flexibility). Sidecars provide a new isolation primitive to address this.
Sidecars are isolated containers that run alongside a Modal Sandbox on the same host, separated by gVisor or VM isolation. They communicate via an internal bridge network over TCP/UDP, with at least 3x lower latency than separate Sandboxes. Sidecars can be created dynamically via the Modal SDK, have independent outbound network policies, and share CPU/memory resources with the Sandbox. They can be used for credential injection, proxy traffic, harness logic, or monitoring.
Sidecars enable at least 3x faster communication across trust boundaries compared to separate Sandboxes, reducing latency for operation-heavy agent loops.
Sidecars solve the “lethal trifecta” by allowing trusted code (harness, credentials, proxies) to run in an isolated container alongside the untrusted Sandbox, without requiring remote network calls.
Sidecars are dynamically created via the Modal SDK and can be terminated and replaced during a Sandbox’s lifetime; each Sidecar has its own outbound network policy independent of the main Sandbox.
Sidecars run on the same host as the main Sandbox and communicate via an internal bridge network over TCP/UDP, avoiding remote network round trips. Internal benchmarking shows communication is at least 3x faster than between separate Sandboxes in the same region.
No. Sidecars are created dynamically through the Modal SDK, and code running inside the Sandbox cannot create or modify them. This ensures the trust boundary is maintained.
Sidecars share CPU and memory resources with the main Sandbox, making them more cost-efficient than running processes across multiple Sandboxes. A single Sandbox can run up to 250 Sidecars.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
A five-step workflow for turning agent output into versioned artifacts: scope a repo per agent, branch instead of copying, run in an isolated sandbox, gate changes with push-triggered evals, then deploy or roll back.
A five-step how-to for deciding when an AMD Instinct GPU should stay dedicated and when SR-IOV virtual functions, VMs, or sidecar isolation can safely share it.
Agentic development turns AI assistance into delegated work: a harness runs the agents, skills supply domain knowledge, a sandbox bounds execution, and evals verify the result.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.
