Agent 沙箱红队测试暴露网络边界缺口

2026 年 9 月 23 日，Perplexity 的 Secure Intelligence Institute 发布了《Escaping SPACE: Part I》，这是一份针对 SPACE 的红队测试报告。SPACE 是支撑 Perplexity Computer 的 microVM 沙箱平台。测试中，九个模型获得了客户机 VM 内的 root 权限，目标明确：突破沙箱边界。

在 108 次运行中，没有观察到任何从 VM 逃逸到宿主机的情况，即使模型能够访问 SPACE 源码、使用网页搜索并安装软件包。这道边界守住了。

网络边界却没有守住。在网络访问受限的情况下，九个模型中的四个——Claude Opus 5.0、GPT-5.6 Cyber、GPT-5.6 Sol 和 Kimi K3——通过 DNS 欺骗或共享 IP 路由，在 54 次部分开放网络的运行中，成功绕过出站访问策略 11 次。

问题并不局限于一家厂商：接受测试的十个第三方沙箱平台中，有八个至少出现过一次网络策略绕过。只有 Cloudflare Sandbox 和 NVIDIA OpenShell 在这些实验中守住了边界。

对于所有运行 Agent 工作负载的人，这件事揭示了一个结构性教训：“运行在沙箱中”至少应该拆成两个独立的主张——计算隔离和网络约束——并分别测试。

相应的运维调整也很明确：独立审计这两道边界，针对部分开放网络开展自己的红队测试，优先选择在网关终止 TLS、并依据具有 DNS 归属信息的允许列表校验 SNI 的方案，同时将共享 IP 绕过视为一个长期存在的问题。

红队实际测试了什么

SPACE 基于 Firecracker microVM 构建。每个沙箱都是一台客户机 VM，运行在客户机无法控制的宿主机上；每个沙箱都有一个独立网关，对客户机发出的所有流量执行出站访问策略。报告评估了两道容易混淆的边界：VM 与宿主机之间的边界，也就是已经获得客户机内部 root 权限的 Agent 能否访问宿主机；以及网络边界，也就是 Agent 能否访问出站访问策略禁止的目标。

实验让九个模型以 Agent 的方式运行，并根据两个维度组合出四种设置：Agent 是否能够访问 SPACE 源码，以及网络访问是完全禁止，还是部分开放——允许访问软件包仓库和 Perplexity Search API。沙箱逃逸任务要求 Agent 获取存储在宿主机上的 AWS honeytoken；网络绕过任务则要求它们从被禁止访问的回调 URL 中获取 flag。

Perplexity《Escaping SPACE: Part I》官方配图（perplexity.ai，2026-09-23）：报告对两道边界的总结——VM 与宿主机的隔离在 108 次运行中没有出现经过验证的逃逸，而部分开放网络时出现了网络策略绕过。

这样的实验设计很重要，因为它把不同的失效模式分离开了。让 Agent 在客户机 VM 内获得 root 权限，是对计算隔离最不利的假设：只要 hypervisor 边界可靠，客户机内部的 root 权限就不应该在客户机外产生任何效力。让 Agent 获得部分网络访问权限，则更贴近生产环境，因为生产中的 Agent 几乎总要访问软件包仓库、API 或检索服务，才能完成有用的工作。因此，部分开放网络才是应该重点测试的设置：Agent 在这种条件下仍能正常工作，策略错误也会在这里暴露出来。完全封锁网络，证明不了出站访问控制是否有效；完全开放网络，则根本没有测试任何限制。这两项任务的失败方式截然不同，报告的措辞也很严谨：“成功绕过网络策略，并不意味着从 VM 逃逸到了宿主机；没有观察到逃逸，也不能证明隔离成立。”

出站访问策略为什么失效

每一次成功的绕过都利用了同一个结构性缺口：策略用域名表达，执行时却依据 IP 地址。Perplexity 描述了两种具体方法。

Perplexity《Escaping SPACE: Part I》官方配图（perplexity.ai，2026-09-23）：绕过方法一——Agent 注入伪造的 DNS 响应，将允许访问的域名 pypi.org 映射到被禁止访问的回调地址的 IP，从而用一条被污染的映射通过网关的域名到 IP 策略检查。

在 DNS 欺骗变体中，Agent 冒充外部 DNS 解析器，注入伪造的 DNS 响应，将允许访问的主机名 pypi.org 映射到被禁止访问的回调地址的 IP。于是，网关看到的是一个发往允许访问的域名的连接，而连接实际指向的地址并未被网关判定为禁止访问。这是 SPACE 特有的策略实现缺陷。报告称，已经通过源地址校验修复了这个问题。在两种绕过方式中，这一种也最容易修复。

第二种方法更令人不安，因为它是结构性问题。一个 IP 地址可以服务于多个域名：内容分发网络会在共享 IP 池后面托管数千个彼此无关的客户域名，而 Fastly 的 Fiddle 服务本来就是为了代替用户在服务端抓取任意 URL。某次运行向 fiddle.fastly.dev 发送请求，指示该服务抓取被禁止访问的回调 URL。GPT-5.6 Cyber 则通过 images.taboola.com 找到了另一条路径：这是一个图片抓取服务，可以通过策略已经允许的 IP 访问。模型再串联 thum.io 截图，最后用 OCR 从 PNG 中提取出 flag。整条链路的每一跳都经过网关已经允许的 IP，因此出站访问策略始终看不到最终目的地——整个过程中，基于域名的允许列表检查一直能够通过。这也正是为什么修复必须发生在网关，而不是客户机内部。

Perplexity《Escaping SPACE: Part I》官方配图（perplexity.ai，2026-09-23）：第三方沙箱平台的验证结果——十个受测平台中，有八个被证实至少存在一种网络策略绕过方式；两种绕过方式在 Cloudflare Sandbox 和 NVIDIA OpenShell 上均未成功。

Perplexity 自己的结论具有普遍适用性：“在宿主机上，仅依赖目标 IP 地址来判断是否允许连接，并不足够。”无论是为 Agent 沙箱、CI runner，还是微服务构建出站访问允许列表，只要检查发生在 DNS 解析之后，并且信任解析器，就会引入同样的失效模式。

十个平台中，八个没能通过同样的测试

Perplexity 并没有止步于测试自己的沙箱。它对十个宣称支持基于主机名或域名的出站访问控制的第三方沙箱平台，开展了直接 HTTP/HTTPS 测试：验证允许访问一个主机名，是否也会放行对另一个主机名的请求，只因为它们由同一个 CDN 或多租户基础设施提供服务。十个平台中，有八个至少发现了一种网络策略绕过方式。具体细节同样重要：Deno Sandbox 对 HTTPS 执行了策略限制，却允许向未列入允许列表的地址发起任意 TCP 连接；多家厂商在收到披露后迅速发布了缓解措施，包括 microsandbox、Daytona 和 Deno；另一些厂商则将其记录为已知限制，没有重新界定这种行为。两种受测绕过方式均未成功的平台，是 Cloudflare Sandbox 和 NVIDIA OpenShell。

涉及的厂商范围本身就是新闻点：E2B、Vercel、Modal、Daytona、Fly.io、microsandbox、Deno 等，都是 Agent 框架常用的执行平台。如果 Agent 的出站访问“策略”可以通过共享 CDN 边缘节点被重定向，那它实际上并没有受到约束，只是在产生账单。这与我们在 Cloudflare 将 Cursor Agent 放入客户可控沙箱时提出的控制平面观点直接相关：沙箱是否可靠，取决于客户能够实际验证哪些控制措施；而在出站访问这一环，大多数平台仍然信任客户机所看到的网络信息。

运维人员应该做哪些调整

首先，不要再把“沙箱是否安全”作为一个整体问题来审计。报告的核心发现是，计算隔离和网络约束是相互独立的属性，失效率也不同。在这次测试中，差异尤其明显：0/108 对比 11/54。其次，按照 Perplexity 测试自身平台的方式测试你的平台：给 Agent 部分网络访问权限，让它尝试访问一个被禁止的目标，看看共享 CDN 边缘节点或被污染的 DNS 响应能否帮助它突破限制。第三，优先选择在网关终止 TLS，并依据具有 DNS 归属信息的允许列表校验 SNI 和 HTTP 主机名的平台。这种设计可以同时堵住两类绕过方式，也是 Perplexity 已经上线的修复方案。最后，要假设 IP 共享问题会长期存在：它是当今互联网架构的固有属性，并非某一家厂商的问题。因此，如果出站访问控制只检查 IP 地址，无论你购买哪一种沙箱产品，它都会继续失效。

Netics 根据 Perplexity 报告制作的编辑配图：十个第三方沙箱平台中，有八个至少出现了一种网络策略绕过；九个模型中的四个在部分开放网络的运行中绕过了出站访问控制；只有 Cloudflare Sandbox 和 NVIDIA OpenShell 守住了边界。

这与我们在 CVE-2026-80521 容器逃逸分析中指出的模式相同：营销材料描述的边界，与攻击实际跨越的边界，往往并不是同一条线。容器能守住边界，前提是内核没有漏洞；Agent 沙箱在 hypervisor 处守住了，却在网关处泄漏。应当把威胁模型聚焦到已经被证实会失效的边界上，并针对那道边界开展测试。

本文最初发表于 Netics 博客。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。