Modal 推出 Sidecars，为 Sandboxes 提供低延迟信任边界

核心亮点

Modal 推出 Sidecars（Beta）：一种与主 Sandbox 同宿主运行但隔离的可信容器，用来在可信与不可信代码之间划一道安全边界。它解决的是"让 Agent 跑别人给的代码"时的隔离难题。

具体能力或事件经过

Sidecar 跑在和主沙箱同一台机器上，但网络与文件系统隔离，低延迟地充当信任边界。可信的控制面放 Sidecar，不可信的用户代码留在主沙箱，二者通过受控通道通信，互不越权。

技术细节

"同宿主"带来低延迟，"隔离"带来安全：Sidecar 可以持有密钥、做鉴权、记审计，而不把敏感物暴露给不可信代码。它本质是把"该信谁"的边界从进程内搬到了容器边界，更易验证。

与竞品对比

传统做法是单容器里既跑可信又跑不可信，一旦越权就全漏。Sidecar 借容器边界做最小权限分隔，思路接近服务网格的 sidecar 模式，但专为 Agent 执行面设计，延迟更低。

行业影响或适用场景

任何"执行外部提交代码"的平台——编程评测、自动化办公、插件市场——都需要这道边界。它让"跑陌生代码"从高危变成可控，是 Agent 平台过安全评审的关键拼图。

数据口径与可信度

Sidecars 仍是 Beta，隔离强度依赖实现与配置，不能当绝对防线。官方没有给出独立渗透测试结果，生产使用前建议自测逃逸路径，尤其检查共享内核与网络命名空间。

风险与边界

同宿主共享内核，理论上仍存在侧信道风险；配置错误会让边界形同虚设。Sidecar 不是银弹，需配合最小权限、密钥管理与审计日志，才构成完整信任链。

进一步分析

说白了，Sidecar 给 Agent 执行面加了一道"保险丝"：可信的管钥匙，不可信的干苦力，互不串门。对要跑第三方代码的平台，这是把"敢不敢跑"变成"怎么跑更安全"的关键一步。它和 VM Sandboxes 搭配，可信与隔离两段都补齐。

落地步骤

把密钥、鉴权、审计这类可信逻辑放进 Sidecar，不可信的用户代码留在主沙箱，二者只走受控通道。上线前自测逃逸路径，重点查共享内核与网络命名空间，确认边界真的封住再放量。

常见误区

误区一是把 Sidecar 当绝对防线，不做最小权限与日志；误区二是同宿主共享内核的侧信道风险被忽视；误区三是配置错误让边界形同虚设却无人验证。正确做法是把它当作信任链一环，配合密钥管理与监控。

一句话结论

说白了，Sidecar 给执行面加一道保险丝：可信的管钥匙，不可信的干苦力。要跑第三方代码的平台，它把"敢不敢跑"变成"怎么跑更安全"，和 VM Sandboxes 搭配最稳。

延伸观察

信任边界会成 Agent 平台的标配能力，就像 Web 时代要有 WAF。谁能把"可信控制面 + 不可信执行面"做顺，谁就拿到跑第三方代码的话语权。Sidecar 只是开端，未来还会有更细的权限沙箱与可验证审计。