Perplexity 安全团队 9 月 28 日公布了一份红队报告：他们花了一个月攻击自家沙箱平台 SPACE，这个平台承载着 Perplexity Computer 里所有智能体任务的运行。测试方法很直接，给 9 个模型在虚拟机里的 root 权限，部分运行里连 SPACE 的源代码也一并交给模型，然后让它们完成两件事之一：逃到宿主机上，或者访问一个被网络策略封锁的网址。
参测模型包括 Anthropic 的 Opus 5、OpenAI 的 GPT-5.6 Sol 和 GPT-5.6 Cyber、月之暗面的 Kimi K3、谷歌的 Gemini 3.1 Pro 等。Perplexity CEO Aravind Srinivas 在 X 上转发时，把结果概括成两句：虚拟机守住了，网络层还要补。
虚拟机没破，网络漏了
逃逸虚拟机这一项，108 次运行没有一次成功。按报道转述的测试设计，运行按”能否看到源码""能否连外部包仓库”两个变量组合配置，每种组合重复多次。
网络策略这一项的结果分成两截。完全断网的配置下，54 次运行没有模型拿到目标地址；允许连包仓库装依赖的配置下，54 次里有 11 次成功，涉及 4 个模型。
它们用到的手法有两类：
- 伪造 DNS 应答。模型在虚拟机里有 root，可以伪造发往网关的 DNS 响应，让网关误以为目标地址是允许访问的域名；
- 借共享 IP 过路。pypi.org 挂在 Fastly 的 CDN 上，同一批 IP 背后还有成千上万个其他网站。网络策略按 IP 放行 pypi，等于连同一 IP 上的其他站点一起放行了。
最绕的一条来自 GPT-5.6 Cyber。它先让 Taboola 的图片抓取服务去请求一个网页截图服务，截图服务再去打开被封锁的目标页，模型拿回截图后用 OCR 把页面上的 flag 读了出来。整条链路里，沙箱自身没有一次直接连到目标地址。
8 家服务商中招
报告的另一半更让同行坐不住。Perplexity 用同样的方法测了另外 10 家沙箱服务商，8 家存在同样的共享 IP 问题，报道点名的包括 E2B、Vercel 和 Modal。Perplexity 称已加固自家的网络控制，复测时上述绕过都失效了。
需要说明的是，这些都属于网络策略被绕过，没有任何模型拿到宿主机权限。Perplexity 把这份研究定位为和英伟达及 100 多家行业伙伴共建智能体隔离基础设施的一部分，参与各方的具体分工，公告里没有展开。
串起来看：DNS 这条缝
把时间往前拨几天，这份报告里的手法并不陌生。
9 月 25 日，OpenAI 在自家的不对齐报告栏目里披露，一个内部研究模型在搜索类训练任务里，发现沙箱代理挡住了 HTTP 和 HTTPS，DNS 解析却没有过滤，于是把问题编码进 DNS 查询发给外部聊天机器人，再从解析结果里读回答案。OpenAI 事后把研究环境的 DNS 收窄到白名单，并暂停了最强几款模型的训练、评估和带工具推理。
再往前是 7 月，OpenAI 的模型在一次网络安全评测里逃出环境，进入了 Hugging Face 的生产设施。
三件事放在一起，模型找的都是同一类地方：出站流量管住了，DNS、CDN、第三方抓取服务这些”顺路”的通道没管住。区别在于，OpenAI 那两次是训练中意外发生，Perplexity 这次是主动布置的攻防。Perplexity 的测试里，参与的都是公开可用的模型，其中包括开源的 Kimi K3。用这些模型搭智能体的团队，不能只看模型厂商的安全承诺，沙箱这一层也要自己查一遍：网络策略是按域名还是按 IP 放行，DNS 响应是否可以被虚拟机内部改写。
报告目前是第一部分。11 次成功分别出自哪几个模型、各占几次，二手报道的口径并不一致，以 Perplexity 后续公开的完整数据为准。
参考来源：Perplexity 官方博客、AlphaSignal、CocoLoop、Aravind Srinivas 在 X 上的说明；运行次数与成功次数按报道转述的测试设计核对，OpenAI 的 DNS 事件以其不对齐报告为准。