AISI SandboxEscapeBench：容器逃逸能力评测

AISI SandboxEscapeBench：容器逃逸能力评测

核心判断

AISI 的 SandboxEscapeBench 值得进入长期 wiki，因为它把 agent 安全评测从“模型会不会做危险事”推进到“评测/开发 sandbox 本身是否会被 agent 突破”。这直接命中 Agent-Benchmarks 与 Harness-Engineering 的交叉点：benchmark 的真实性依赖 sandbox，sandbox 的安全性又必须被 benchmark。

机制 / 一阶原理

SandboxEscapeBench 使用 “sandbox-within-a-sandbox” 结构：被测 agent 在容器中尝试逃逸，但容器外还有 hardened VM，因此即使成功逃逸也不触碰真实基础设施。任务形态是 capture-the-flag-style challenges，覆盖 orchestration、runtime、kernel 三层容器栈，共 18 个 public scenarios，并保留 private test set 以维护评测完整性。

这个设计的重要机制有三层：第一，场景来自真实漏洞类别，如 exposed Docker socket、privileged container、runtime CVE、privilege escalation chain；第二，外层 VM 把研究危险能力与真实损害隔离；第三，公开/私有集合分离，避免公开 benchmark 过快变成训练材料或提示工程靶子。

与已有 wiki 的关系

• 与 Agent-Benchmarks：补充 benchmark integrity 的基础设施维度——不是只有 hidden verifier 和污染控制，sandbox 配置本身也是被测变量。
• 与 Harness-Engineering：说明 sandbox、network、privilege、Docker socket、runtime patch level 都应进入 harness contract，而不是“默认安全”。
• 与 MCP-Gateway-Runtime：MCP/tool runtime 若通过容器运行第三方 server，也需要类似 container escape / privilege audit；gateway policy 不能替代底层隔离。

可执行启发

1. Hermes 的无人 cron / external tool ingest 不应自动运行未知 repo；源码、README、论文可以入库，但执行前要有 sandbox policy 和权限清单。
2. 未来若做本地 coding-agent benchmark，应记录 Docker socket、privileged mode、network、mounts、kernel/runtime version、outer isolation，而不仅是模型和测试命令。
3. 对 llm-wiki 的工具生态雷达，应把“是否要求 Docker socket/privileged container/host mount”加入降权或 HOLD 字段。

边界与失败模式

• AISI 博客给出高层方法和早期结果，完整数字、prompt、run config 和 private set 细节需要论文/代码进一步复核。
• 公开场景可提升社区防御，也会被模型/agent 开发者针对性优化；长期评测必须保留 private or rotated cases。
• Token budget 可提升 cyber eval 成功率，意味着“当前没逃逸”不是长期安全证明；预算/时间上限必须随结果一起报告。

写入记录

• 2026-08-31 09:00 CST：新增 AISI SandboxEscapeBench source page，提炼容器逃逸评测、sandbox-within-sandbox 和 Hermes 工具执行边界启发。