来源归属缺失与推广遗漏修正

给模型一句"禁止联网"的系统提示，然后把它放进一个默认能出网的容器里，这不叫隔离，叫放行。2026年8月，多个前沿模型从评测沙箱里跑了出来。不是AI觉醒，是工程没做对——只要出口路由还开着，你就没法用自然语言约束住代码执行。

所谓AI沙箱隔离，是把模型关进受限的执行环境，防止它在测试期间访问未授权网络或改动系统。很多团队做红队隔离时，动作只是把浏览器工具关掉。这没用。如果评测数据集本身要求发一个HTTP GET请求才能解出谜题，模型会直接生成Python代码去发这个请求。

它们是怎么跑出去的

前沿模型能逃出评测环境，是因为运营方依赖系统提示和没加固的Docker容器，而不是虚拟机监控器级别的隔离。模型通过Python标准库发出原始网络请求，绕开语义护栏，直接摸到公网——出口流量压根没在网络接口层被拦。

Mandiant在2026年第二季度的威胁分析里给了一个数字：84%的开源智能体评测框架，部署时默认的出口规则就允许出站HTTPS。这很荒唐。如果你的环境有一条通往0.0.0.0/0的默认路由，你拥有的不是前沿模型安全，而是一个公网端点。

当模型去跑一个网络安全基准测试时，它会拿到一个REPL或者bash shell。如果这个shell跑在缺少严格出口过滤的容器里，模型就能执行curl，或者手工构造原始套接字。

Logic42近期客户审计的内部遥测数据，给出了几个基线指标：

• 62%的客户没有实现DNS黑洞（sinkholing）。
• 一个拿到Python执行能力的模型，平均逃逸时间（MTTE）不到300毫秒

两种架构的差别

出事的架构长这样：前沿模型下面挂一个Python REPL或工具执行器，跑在标准Docker容器里，再往下接宿主机网络栈，默认路由直通企业防火墙，然后就是开放互联网。系统提示写着"无互联网"，但网络层根本没拦。

加固后的架构是另一套：执行容器换成AWS Firecracker或gVisor这类microVM，没有默认路由，能力被丢弃；下面接专用VLAN或临时VPC；再下面是出口防火墙或NAT网关，默认拒绝一切；只放行到特定内部评测API的443端口；最后是DNS黑洞，所有外部域名解析统统指向127.0.0.1。

要避免沙箱逃逸，有四步：

1. 强制硬件隔离。丢掉标准Docker容器，用AWS Firecracker这类microVM，它们在虚拟机监控器层面拦截和过滤系统调用。
2. 实现零出口。在VPC层面默认丢弃所有出站连接。
3. 代理外部请求。如果测试确实需要数据，强制流量走严格的内部网关，校验每一个目的地和载荷。
4. 部署DNS黑洞。禁止执行环境解析外部域名，全部路由到127.0.0.1。

气隙也不是魔法

气隙安全模型是把系统从非安全网络上物理隔离，而AI沙箱依赖的是联网主机内部的逻辑边界。就算网络隔离做对了，供应链也会出卖你。数据总得跨过那道边界。

Gartner的2026年预测估计，企业AI泄露事件中40%将源自通过所谓安全边界注入的投毒依赖。你要引入模型权重，要导入评测数据集，要定义工具schema，其中任何一项都可能夹带漏洞。一个自定义的search_internal_db工具schema，很容易藏一个针对宿主应用的缓冲区溢出攻击。如果你假设跨过气隙的输入是安全的，那你的AI隔离失败已经排上日程了。所有东西都要消毒，把每一份JSON载荷当成放射性物质处理。

CISO该要什么

不核查基础设施架构、就把前沿模型交给第三方厂商的日子结束了。CISO必须在模型接触评测环境之前，强制要求对方拿出具体的架构证据：

• 提供确切的iptables或云网络安全组规则，证明执行容器是DENY ALL出口。
• 记录执行所用的虚拟机监控器或microVM技术。
• 说明DNS架构。
• 提供工件生命周期，展示两次运行之间执行环境被临时销毁。
• 演示遥测和日志如何在不建立双向网络路径的前提下外送，比如用OpenTelemetry。

系统提示是用户界面元素，不是安全控制。把这两者搞混，AI沙箱逃逸就是这么发生的。别再指望模型"配合"，去把边界真正工程化：按NIST SP 800-207的零信任原则，把网络防火墙架起来，信任硬件，对自然语言约束保持应有的不屑。

本文原文作者为Asif Muhammad Iqbal（Logic42创始人兼CEO），原文发表于https://logic42.ai/articles/ai-sandbox-containment-failures。