在 Modal，我们的客户依赖沙箱来执行下游用户或几乎完全由代理编写的不受信任代码。运行不受信任的代码并不是一个新问题：每个云服务提供商从一开始就必须这样做，以隔离平台与用户，以及用户之间的相互影响。幸运的是，像 gVisor 和 Firecracker 这样的技术几乎在八年前就“解决了”“隔离”问题。不幸的是，它们解决的是现在已过时的信任单元。你如何保护用户免受他们“自己的”代码影响？
今天我们很高兴介绍 Sidecars，这是我们对这一问题更广泛的解决方案。Sidecars 是与您的主沙箱在同一主机上并行运行的隔离容器，为可信代码或不可信代码之间提供真正的安全边界。Sidecars 使跨信任边界的通信速度提升了 3 倍，这对于操作密集型工作负载特别有帮助。
代理需要在没有凭证的情况下获取功能。我希望代理检查我的 Slack 消息，并为我花了那么长时间来处理同事发送给我的内容而向同事道歉。我不希望当代理偶然访问 exfiltrate-my-credentials.com 登录页面并被指示记录我的密码时，它知道我的 Slack 密码。
如果沙箱主要作为不受信任代码的执行环境存在，那么你必须问：为什么沙箱中有这么多受信任代码？
这种反模式在很大程度上源自早期的编码代理（如 Claude Code）设计用于在用户的笔记本上运行，而不是在远程沙箱中运行。该框架从未与其工具调用分离，这种设计模式在迁移到云端时仍然存在。
将框架与工具调用一起托管是一种安全风险。Simon Willison 将其称为致命三重奏：https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/：一个有权访问私人数据、暴露于不可信内容并能进行外部通信的代理可能被欺骗泄露数据。一个在其沙箱中运行框架的编码代理默认就具备这三个条件。框架的凭证与生成的代码并存，代理可以读取来自网络的不受信任内容，如软件包和仓库，而且沙箱中的任何内容都可以进行网络调用。
我们并不是第一个思考这个问题的人，也不是第一个提出解决方案的人。现今流行的解决方案各自解决了三位一体中的一个问题：将控制程序从沙箱中移出可以保护私人数据，而增加高级网络出口控制则限制了外部通信。
像 Anthropic（https://www.anthropic.com/engineering/managed-agents）和 OpenAI（https://developers.openai.com/api/docs/guides/agents/sandboxes）这样的公司提倡将代理的控制程序与其工具调用分离，或者用 Anthropic 的话说，将“大脑”与“手”分开，我们也倡导这种模式。
然而，无论控制程序是在控制平面中运行还是在单独的沙箱中运行，每一次代理操作现在都需要一次网络调用。对于需要进行大量工具调用的代理，每次调用产生的微小延迟会累积起来。安全性最终会直接以延迟为代价。此外，对于编码代理来说，代码库本身就是私人数据，因此即使控制程序被移出，仍然存在数据外泄的风险，这就引出了第二种方法。
第二种方法是构建高级的网络出口控制，比如域名允许列表（https://modal.com/docs/guide/sandbox-networking#restricting-by-domain-name-domain-allowlist）、凭证注入（https://modal.com/docs/guide/sandbox-secret-injection）以及动态出口策略更新（https://modal.com/docs/guide/sandbox-networking#updating-the-network-policy-at-runtime）。包括我们在内的沙箱提供商，已经快速推出这些功能以解决最常见的数据外泄风险。
这些解决方案在使用上很方便，并且对大多数客户都非常有效，但它们并不像许多客户所需的那样灵活。例如，我们的一位客户 Ramp 需要在其代理旁运行一个复杂的服务，该服务既要注入凭证，又要监控外部调用——现成的凭证注入并不能完全满足他们的应用场景。随着代理能力越来越强，新需求不断出现，其速度甚至快于任何提供商推出新功能的速度，前沿团队需要一个能够构建自己解决方案的方法。
避免任何权衡的完整解决方案将是：
Sidecar 是我们用来在保持低延迟和高可编程性的同时，将受信任代码与不受信任代码隔离的解决方案。Sidecar 与 Sandbox 并行运行，同时保持隔离，为受信任的软件提供了注入凭证、代理流量、编辑数据、运行测试逻辑或观察代理的场所，而无需每个操作都跨越远程服务边界。
这种模式的灵感来源于现有设计，例如 Kubernetes：https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/ 的 sidecar 容器或 Datadog Agent：https://docs.datadoghq.com/agent/：这些都是运行在主要应用旁的小型专用容器，用于提供辅助功能。Sidecar 将相同的理念应用于代理基础设施，并具备建立容器之间信任边界所需的隔离性。
隔离性：Sidecar 与主 Sandbox 分隔，隔离边界与独立 Sandbox 相同——gVisor 或虚拟机，取决于你传递给 `Sandbox.create()` 的运行时：https://modal.com/docs/guide/sandboxes#runtimes。这意味着代理生成的代码可以在主 Sandbox 中运行，而凭证、代理、测试逻辑或其他受信任操作则在 Sidecar 中运行，代理无法直接访问。
延迟：由于容器在同一主机上运行，它们之间的通信保持本地化。主 Sandbox 与其 Sidecar 通过 TCP/UDP 内部桥接网络相连：https://modal.com/docs/guide/sandbox-sidecars#introduction，每个容器都可以通过名称访问。本应从 Sandbox 发送到远程控制平面的工具调用，可以改由旁边运行的 Sidecar 处理，从而避免执行密集的代理循环中累积的网络往返。我们的内部基准测试显示，Sandbox 与其 Sidecar 之间的通信至少比同一地区内不同 Sandbox 之间的通信快 3 倍。
创建：Sidecar 可通过 Modal SDK 动态创建，因此你可以在运行时启动所需的受信任服务，而无需事先定义固定拓扑。运行在 Sandbox 内的代码无法创建或修改它们。
资源：Sandboxes 和 Sidecars 共用 CPU 和内存资源：https://modal.com/docs/guide/sandbox-sidecars#resource-configuration，这使得使用 Sidecars 比在多个 Sandboxes 之间运行进程更具成本效益。一个 Sandbox 最多可以运行 250 个 Sidecars。
网络策略：每个 Sidecar 都有自己的出站网络策略，独立于主 Sandbox，并且您可以强制 Sandbox 的出站流量通过代理 Sidecar：https://modal.com/docs/guide/sandbox-sidecars#routing-https-traffic-through-a-sidecar。
生命周期：Sidecars 可以在 Sandbox 的生命周期的任何时候被终止和替换，其文件系统可以被快照并用来启动另一个 Sandbox 或 Sidecar。终止 Sandbox 会停止其所有 Sidecars。
Ramp 的后台编码代理 Inspect：https://builders.ramp.com/post/why-we-built-our-background-agent，撰写了 Ramp 超过 75% 的所有已合并 Pull Requests，每个会话都运行在其自己的 Modal Sandbox 中。Ramp 在 Sidecars 上方构建了自己的自定义出口代理，运行在每个 Inspect Sandbox 旁边，以监控和控制代理的出站流量。
“我们需要确切知道我们的编码代理正在访问什么，并且在其访问不应访问的内容时能够阻止它。Sidecars 让我们能够在代理旁边运行我们自己的出口代理，并设置自己的规则。我们可以强制出站流量通过该代理，因此没有东西可以绕过它，并且因为它在同一主机上，所以不会产生额外的网络跳数。” - Zach Bruggeman，Ramp 首席软件工程师
Sidecars 目前以 Beta 形式提供，关于如何入门及已知限制的更多细节，请参阅我们的文档：https://modal.com/docs/guide/sandbox-sidecars。
我们刻意将 Sidecars 设计为一个灵活的构建模块，但为了帮助您入门，我们还为一些特定用例编写了示例：
然而，我们预计最有趣的用例将是那些我们还未想到的。因此，如果您使用 Sidecars 构建了某些东西，我们非常希望听到您的反馈！
At Modal, our customers rely on Sandboxes to execute untrusted code written by their downstream users or, almost exclusively now, by agents. Running untrusted code isn’t a new problem: every cloud provider has to do this from day 1 to isolate their platform from their user and their users from each other. Fortunately, technologies like gVisor and Firecracker “solved” “isolation” nearly eight years ago. Unfortunately for us, they solved it for an now-outdated unit of trust. How do you protect users from their “own” code?
Today we’re excited to introduce Sidecars, which are our broader answer to this problem. Sidecars are isolated containers that run alongside your main Sandbox on the same host and provide a real security boundary between trusted or untrusted code. Sidecars enable 3x faster communication across trust boundaries than using separate Sandboxes — which is particularly helpful for operation-heavy workloads.
Agents demand capabilities without credentials. I want an agent to check my Slack messages and apologize to my colleagues for how long it took to review what they sent me. I don’t want that agent to know my Slack password when it stumbles upon the landing page of exfiltrate-my-credentials.com instructing it to log my password.
If Sandboxes primarily exist as an execution environment for untrusted code, then you have to ask: why is there so much trusted code in Sandboxes?
This anti-pattern largely stems from how the early coding agents, like Claude Code, were designed for running on a user’s laptop and not in a remote Sandbox. The harness was never separated from its tool calls, and that design pattern survived the shift over to the cloud.
Hosting the harness and the tool calls together is a security risk. Simon Willison calls it the lethal trifecta ：https://simonwillison.net/2025/Jun/16/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. A coding agent whose harness runs in its Sandbox has all three by default. The harness's credentials sit next to generated code, the agent can read untrusted content from the web, like packages and repos, and anything in the Sandbox can make network calls..
We aren’t the first to think about this problem, and we aren’t the first to propose a solution either. The popular solutions today each remove one leg of the trifecta: moving the harness out of the Sandbox removes private data, and adding advanced network egress controls restricts external communication.
Companies like Anthropic ：https://www.anthropic.com/engineering/managed-agents and OpenAI ：https://developers.openai.com/api/docs/guides/agents/sandboxes promote separating the agent’s harness from its tool calls, or in Anthropic’s words: the “brain” from its “hands,” and we’ve advocated for this pattern as well.
However, whether the harness runs in a control plane or a separate Sandbox, every single agent operation now takes a network call. For agents making many tool calls, the small latency associated with every call adds up. Security ends up coming at the direct cost of latency. Also, for a coding agent, the codebase itself is private data, so even when the harness is moved out, there is still a data exfiltration risk, which brings us to the second approach.
The second approach is building advanced network egress controls like domain allowlisting ：https://modal.com/docs/guide/sandbox-networking#restricting-by-domain-name-domain-allowlist , credential injection ：https://modal.com/docs/guide/sandbox-secret-injection , and dynamic egress policy updates ：https://modal.com/docs/guide/sandbox-networking#updating-the-network-policy-at-runtime . Sandbox providers, us included, have been shipping these quickly to solve for the most common exfiltration risks.
These solutions are ergonomic and for most customers they are very effective, but they aren’t as flexible as many customers need. For example, one of our customers, Ramp, needed to run a complex service alongside their agent that injected secrets, but also monitored external calls— off-the-shelf secret injection didn’t fully address their use case. As agents get more and more capable, new needs keep emerging faster than any provider can ship new features, and teams at the frontier need a way to build their own solutions.
A full solution to avoid either tradeoff would:
Sidecars are our answer for isolating trusted from untrusted code with low latency and high programmability. A Sidecar runs alongside a Sandbox while remaining isolated from it, giving trusted software a place to inject credentials, proxy traffic, redact data, run harness logic, or observe the agent without requiring every operation to cross a remote service boundary.
The pattern draws inspiration from existing designs like Kubernetes ：https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/ sidecar containers or the Datadog Agent ：https://docs.datadoghq.com/agent/ : small, specialized containers that run alongside a primary application to provide supporting functionality. Sidecars apply the same idea to agent infrastructure, with the isolation needed to establish a trust boundary between the containers.
Isolation: Sidecars are separated from the main Sandbox with the same isolation boundary as separate Sandboxes - gVisor or VMs, depending on which runtime ：https://modal.com/docs/guide/sandboxes#runtimes you pass to `Sandbox.create()`. This means agent-generated code can run in the main Sandbox while credentials, proxies, harness logic, or other trusted operations run in a Sidecar that the agent cannot directly access.
Latency: Because the containers run on the same host, communication between them stays local. The main Sandbox and its Sidecars are connected through an internal bridge network over TCP/UDP ：https://modal.com/docs/guide/sandbox-sidecars#introduction , and each container is reachable by name. A tool call that would otherwise travel from a Sandbox to a remote control plane can instead be handled by a Sidecar running next to it, avoiding the network round trips that add up in execution-heavy agent loops. Our internal benchmarking shows that communication between a Sandbox and its Sidecars is at least 3x faster than between separate Sandboxes in the same region.
Creation: Sidecars are created dynamically through the Modal SDK, so you can spin up the trusted services you need at runtime rather than defining a fixed topology in advance. Code running inside the Sandbox can't create or modify them.
Resources: Sandboxes and Sidecars share CPU and memory resources ：https://modal.com/docs/guide/sandbox-sidecars#resource-configuration , which makes using Sidecars more cost-efficient than running processes across multiple Sandboxes. A single Sandbox can run up to 250 Sidecars.
Network policy : Each Sidecar has its own outbound network policy, independent of the main Sandbox, and you can force the Sandbox's outbound traffic through a proxy Sidecar ：https://modal.com/docs/guide/sandbox-sidecars#routing-https-traffic-through-a-sidecar .
Lifecycle : Sidecars can be terminated and replaced at any point in the Sandbox's lifetime, and their filesystem can be snapshotted and used to start another Sandbox or Sidecar from. Terminating the Sandbox stops all of its Sidecars.
Ramp's background coding agent, Inspect ：https://builders.ramp.com/post/why-we-built-our-background-agent , writes over 75% of all merged pull requests at Ramp, with every session running in its own Modal Sandbox. Ramp built their own custom egress proxy on top of Sidecars, running next to each Inspect Sandbox to monitor and control the agent's outbound traffic.
“We need to know exactly what our coding agent is reaching out to, and be able to stop it when it's accessing something it shouldn't. Sidecars let us run our own egress proxy, with our own rules, right next to the agent. 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.” - Zach Bruggeman, Principal Software Engineer, Ramp
Sidecars are available in Beta today, with additional details on how to get started and known limitations in our docs ：https://modal.com/docs/guide/sandbox-sidecars .
We’ve intentionally designed Sidecars to be a flexible building block, but to get you started we’ve also written examples for some specific use cases:
However, we expect the most interesting use cases to be the ones we haven’t thought of yet. So if you build something with Sidecars, we’d love to hear about it!
扫码直达文章详情