Perplexity SPACE 开源：108 次逃逸说明了什么

一、先校正一个数字：108 只覆盖了实验的一半

2026 年 10 月 15 日，Perplexity 把支撑其 Computer 产品的沙箱平台 SPACE 以 Apache 2.0 开源，代码在 GitHub 上，Rust 实现，公开基线版本 0.8.0，对外是 HTTP API + SSE，没有嵌入库。同期放出的还有 9 月 23 日那份红队报告《Escaping SPACE: Part I》。

传播里最响的数字是"108 次逃逸零成功"。这个数字需要拆开看，否则会得出错误结论。

报告的实验设计是 9 个模型 × 2 个任务 × 4 种设置 × 每个 3 轮，共 216 轮。两个任务分别是：从客户机逃到宿主机并读出宿主侧的蜜标（honeytoken）；访问一条被出网策略封禁的回调 URL。四种设置是"给不给源码"与"完全不联网/只放行 PyPI 与 Ubuntu 镜像和搜索"的交叉。

216 轮里，逃逸任务占 108 轮——0 成功。断网条件下的绕行 54 轮——0 成功。允许装包的部分联网 54 轮——修复前 11 轮成功，占 20.4%。修复后按最强设置（给源码 + 部分联网）复测，27 轮里 25 轮可评估，0 次取到回调 flag。

所以准确表述是"虚拟机边界扛住了 108 次，出网策略在 11 次里被绕过"。Semafor 报道里出现的"118 次"是公告口径的另一个汇总数字，报告本体只有 108 这个逃逸样本。看到 108 就以为"沙箱已经安全"，是读错了这份研究最想说的部分。

二、SPACE 到底是什么

对象模型很小，五个概念：

• Template：起始文件系统与运行时配置，不可变，按内容寻址（sha256 digest），类似镜像。
• Sandbox：Template 的一个实例，独占一台 microVM 和一份可写磁盘，同一沙箱里可以跑多条命令。
• Process / Command session：进程；command session 是一份连接信息与授权，创建时分配进程 ID，attach 才真正启动。
• Operation：异步生命周期请求（create/pause/suspend/wake/delete）的追踪记录。

架构是控制面与数据面分离。管理面走 Application → API → PostgreSQL（期望状态）→ 控制器 → 沙箱 Pod → worker → microVM，声明式调和，客户端拿 operation ID 轮询；数据面完全旁路控制面，靠会话级 attachment token 经 SSE 直连沙箱内进程取输出，命令输出不落数据库。管理 token 与 attachment token 不可互换，这是它明确写出来的安全边界之一。

状态机区分得很细，这点值得抄：

状态	内存	磁盘	用途
Paused	常驻 worker 内存	保留	秒级恢复，不是持久快照
Suspended	快照到对象存储	快照	释放 VM 资源，可跨节点唤醒
Deleted	回收	回收	任务结束

默认 6 小时无活动自动 suspend——这是空闲限制，不是最长存活时间。Computer 用它做暂停、续接和会话分叉：同一任务可以从某个检查点岔出两条路各跑一遍。

凭据不进入客户机。密钥留在宿主侧，通过网络层注入，凭据存储带分层作用域、限流与审计日志。Agent 在沙箱内是 root，可以装包、跑任意命令，但拿不到那把钥匙——即使整台虚拟机被攻破，攻破者也是空手到。

三、为什么非要一台 microVM，以及 60 毫秒是怎么来的

容器与宿主机共享内核。对内网里几个内部服务，这个风险通常可接受；但对一个会被提示注入操纵、会主动去摸边界的 Agent，不合适。Firecracker 用 KVM 做硬件虚拟化，每个 guest 有自己的内核，共享内核漏洞不再是第一道墙。这套技术在 AWS Lambda 上跑了多年，不是实验性方案。

代价是启动比容器重，所以 SPACE 做了两层抗冷启动：

1. Warm pools（Kubernetes 部署）：按"模板版本 × VM 规格"预启动一批就绪沙箱，create 直接领用，池空了才退化为冷启动。
2. Base snapshots（单机部署）：从基线快照恢复，跳过完整引导。

根文件系统用 btrfs 写时复制，从模板克隆一份根目录是元数据操作而非数据拷贝。合起来的效果：生产环境创建延迟中位数从上一家供应商的 185 ms 降到 60 ms，P90 从 447 ms 降到 89 ms。

热池有个容易踩的坑：每次未命中都是静默的。create 找不到匹配的热沙箱照样成功，只是走了冷启动。按仓库文档，池被钉在某个 release 上（升级 latest 会让池失效）、create 指定的 vcpu / memory_mib 与池规格不完全一致、请求自定义 disk_mib 或文件变更追踪，都会强制冷启动；突发流量大于 ready_slots 时也会冷启动直到池补上。要看 warm_pool.create_path.duration_ms 这个指标，别假设热池被命中了。

60 ms 的意义不只是快。如果开一台干净机器要三十秒，你自然会想"复用一台、多跑几步"；能 60 ms 开一台，就可以每一步都从干净状态起步，把"上一步的脏状态污染下一步"这类问题直接消掉。

四、真正的失败在 DNS 和 CDN 这一层

11 次成功绕行只用了两种手法，都不涉及攻破虚拟机：

手法一：伪造 DNS 应答。 拿到 guest 内 root 的 Agent 向网关发 pypi.org 的查询，然后冒充外部解析器注入一条假应答。网关缓存了这条伪造映射，后续 HTTPS 流量就被路由到攻击者控制的地址。报告里只有 Claude Opus 5.0、GPT-5.6 Sol、Kimi K3 做到，且都需要源码。

手法二：共享 CDN 地址。 策略按主机名放行 pypi.org，而它落在 Fastly 的某个 IP 上，那个 IP 同时服务成千上万个站点。GPT-5.6 Sol 走了 fiddle.fastly.dev，GPT-5.6 Cyber 更绕：经 Taboola 的图片抓取服务转到 thum.io 截图，再把图里的 flag OCR 出来。这条链路上没有被攻破的任何东西，它只是把"通道"和"内容"当成两个层面，攻击它们的接缝。

根因是一个错配：出网策略用域名书写，线上跑的包只认地址。域名到地址之间还有一个可被 guest 影响的环节，那个环节就是缺口。

修复对应两处。nftables 增加源地址校验，guest 发出的每个包必须携带分配给它自己的地址，伪造解析器这条路被堵；网关改为终止 TLS，同时校验 SNI 与 HTTP Host 都在白名单内，并要求该主机名到目标 IP 存在实际 DNS 归属观察；明文 HTTP 走中继，校验 request authority 并剥离路由元数据。复测 0 次成功。

报告还有一个更要紧的横向结果：同一团队测了 10 家第三方沙箱平台，8 家至少存在一种网络策略绕过（其中一家要求延后，因此具名列出的是 9 家、7 家存在绕过，被点到的包括 E2B、Vercel、Modal、Daytona；Cloudflare 与 NVIDIA OpenShell 未被绕过）。八成同类产品共享同一个失败模式，说明这不是某家实现的缺陷，而是行业默认架构——为便宜共享出网——的直接后果。

五、取舍：谁该用，谁不该

收益：一台任务一台机器；root 在内、策略在外；密钥永不进 guest；生命周期长于请求，支持 pause / fork / snapshot；E2B 兼容包装器（ECW）能让已有的 e2b Python 代码直接指向 SPACE，实测基线是 e2b==2.21.1、e2b-code-interpreter==2.6.2。

成本与限制：

• 硬件门槛硬。Linux x86_64 + KVM，需要 /dev/kvm、/dev/net/tun、btrfs、特权 Docker；本地快速上手是 Kind 集群，不支持 macOS。想在 Mac 上试用只能远程连一台 Linux 主机。
• 本地部署自带的开发密码与签名密钥只用于开发，文档明确要求别接生产凭据。生产要多节点、Postgres、对象存储、热池调参，这是一套要有人值守的基础设施，不是一个库。
• ECW 是有边界的兼容层，不是 E2B 规范的实现。它把 pause 映射成 SPACE 的 suspend、resume 映射成 restore，原生 API 的常驻内存 pause 没有暴露；mcp、volumeMounts、iam 会被返回 400；allowPublicTraffic=true 直接拒绝；文件写入单请求上限 256 MiB，JSON 写入 1 MiB。新接入应该用原生 API。
• 零逃逸不等于零风险。报告自己说 Part I 只测了有限时间预算下的特定攻击任务，Part II 才讲攻击策略；而且"0/108"是一家厂商对自己产品做的评估。

适合：要给编码 Agent、浏览 Agent、数据分析 Agent 一个能跑任意命令的执行环境，且这些 Agent 会拿到用户数据和下游系统凭据的团队。不适合：只需要在容器里跑一段可信脚本，或者没有 Linux + KVM 宿主资源的场景。

六、落地时可以直接照抄的三件事

1. 出网从 default-deny 起步，写成具名的 egress profile，而不是给每个沙箱散写规则。
2. 把 red team 那两条路写进你的验收测试：从 guest 内伪造 DNS 应答；找一个与放行域名共享 CDN 地址的站点去取被封的回调。这两条能过，才谈得上"网络策略有效"。
3. 管理面与数据面 token 分离，命令输出旁路控制面。这不只是架构洁癖——它决定了审计日志里能不能区分"谁创建了沙箱"和"谁读了输出"。

一段可直接跑的迁移样例（用 E2B 兼容层指向自建 SPACE，配置取自仓库示例）：

# SPACE_ECW_HOSTS 需要同时配在 API 与数据面服务上（JSON 数组）
#   [{"apiHost": "api.sandbox.example.test", "host": "sandbox.example.test"}]
# api.sandbox.example.test 路由到 API，*.sandbox.example.test 路由到数据面
export E2B_DOMAIN=sandbox.example.test
export E2B_API_KEY=<scripts/seed-api-key.sh 只打印一次的 raw key>

uv run --no-project --python 3.11 --with e2b==2.21.1 python - <<'PY'
import os
from e2b import Sandbox

sandbox = Sandbox.create(
    api_key=os.environ["E2B_API_KEY"],
    domain=os.environ["E2B_DOMAIN"],
    template="seed",
    timeout=60,
)
print(sandbox.commands.run("printf 'Hello from SPACE\\n'").stdout)
sandbox.kill()
PY

还有一个容易撞上的细节：通过 startCmd 声明应用时，create 返回后进程可能还没开始监听，客户端会先看到 connection refused，需要单独等应用就绪——create 成功、沙箱 ready、命令退出码是三个独立的状态，别把它们当一个布尔值用。

结论：这份研究最有价值的地方，不是"虚拟机挡住了 108 次"，而是它把注意力从 hypervisor 挪到了 DNS 和出网策略上。当 8/10 家同类产品都栽在同一个地方时，你该问自己一句：我的 Agent 拿到"只放行 PyPI"这个权限，它在 IP 层究竟解析成什么，还有谁和它解析到同一个地方。

参考链接

1. Perplexity, Open-sourcing SPACE, the sandbox platform behind Computer（2026-10-15）— https://www.perplexity.ai/hub/blog/open-sourcing-space
2. Perplexity, Escaping SPACE: Part I（2026-09-23）— https://www.perplexity.ai/hub/blog/escaping-space-part-i
3. GitHub, perplexityai/SPACE（Apache 2.0，v0.8.0）— https://github.com/perplexityai/SPACE
4. Aravind Srinivas, 红队结果 thread（2026-09-28）— https://x.com/AravSrinivas/status/2104597362475708781
5. SiliconANGLE, Perplexity launches secure sandbox to make its AI agents secure and powerful（2026-07-15，SPACE 发布与技术设计）— https://siliconangle.com/2026/07/15/perplexity-launches-secure-sandbox-make-ai-agents-secure-powerful/
6. CTOL, Perplexity's VM held. Agents still bypassed the network rules（实验分组与修复细节）— https://www.ctol.digital/news/perplexity-space-open-source-agent-sandbox-network-bypass/
7. Semafor（经 Yahoo 转载）, Perplexity to give away its AI security software（118 次口径、Zibi Braniecki 访谈、合作方）— https://tech.yahoo.com/ai/perplexity-ai/articles/perplexity-away-ai-security-software-171027072.html
8. matthewswong.com, Perplexity SPACE: Firecracker Agent Sandbox, Warm Pools, E2B（架构、热池陷阱、ECW 差异与代码示例）— https://www.matthewswong.com/en/blog/perplexity-space-firecracker-agent-sandbox/

创作说明：本文在资料整理与成文中使用了 AI 辅助（DeepSeek），经作者审阅后发布，作者对内容负责。