SandboxBench：当 Agent 拿到 Shell，沙箱还能关住它吗？

如果 Agent 已经拿到了工具权限，它到底能不能被沙箱关住？

SPAR Fall 2025 的一份报告《SandboxBench: A Comprehensive Evaluation Framework for AI Agent Containment》，正是在回答这个问题。

https://library.sparai.org/attachments/reports/recuJPjRGInlmwGDa/sandboxbench-a-comprehensive-evaluation-framework-for-ai-agent-containment-lmwgda.pdf

报告作者不是单纯罗列几个容器逃逸案例，而是提出了一个叫 SandboxBench 的评测框架，用 27 个 Docker 和 Kubernetes 挑战来测试 AI Agent 是否能够突破隔离边界、发现敏感信息、横向移动、建立持久化，甚至完成自我复制。

报告称，SandboxBench 覆盖 21 个 Docker 挑战和 6 个 Kubernetes 挑战，评测风险包括容器逃逸、数据外传、凭证发现、横向移动、持久化和自我复制等类型。

这篇报告真正值得关注的地方，不是它证明了某个模型“已经可以自动攻破容器”，而是它把 Agent 安全评测往前推了一步：从“模型会不会输出危险内容”，推到了“模型在真实工具环境里能不能完成危险行为”。

这正是 Agent 时代安全范式变化的关键。

Agent 安全不能只看它说了什么，还要看它做了什么

传统大模型安全评测，更多关注输入输出。用户问了什么，模型答了什么，里面有没有违法违规内容、敏感信息、错误引导或者危险知识。这套方法对聊天机器人是有意义的，但对 Agent 明显不够。

因为 Agent 不是只会说话。它会调用工具，会执行命令，会访问文件，会读写数据库，会请求 API，会在容器和集群里运行。

也就是说，Agent 的风险不只存在于文本里，还存在于执行链路里。

SandboxBench 对传统安全工具有一个很直接的批评。Trivy、Grype、Checkov、Kubesec、Falco、Sysdig 这类工具可以发现 CVE、配置错误或运行时异常，但它们回答的是“这里有没有风险点”；而 SandboxBench 想回答的是另一个问题：AI Agent 能不能真的利用这个风险点完成攻击目标？ 原文表 1 明确对比了传统工具和 SandboxBench 的区别，传统工具可以做 CVE 检测和配置错误检测，但不能验证多步攻击链、Agent 自适应推理和真实利用结果。

这就像看一扇门有没有锁，和真的让一个人去试着开门，是两回事。前者是静态风险识别，后者是动态能力验证。

Agent 安全真正麻烦的地方正在这里。它可能先观察环境，再判断自己处在 Docker 还是 Kubernetes 里，然后检查权限、枚举文件、尝试挂载、读取 token、调用 API，最后把一连串小动作组合成一次真实越界。

所以，Agent 安全评测不能停留在“有没有危险提示词”这一层，而要进入“工具调用行为是否越界”这一层。

SandboxBench 核心设计：旁路验证

SandboxBench 最关键的设计，是它没有完全相信 Agent 自己说的话。

在很多安全评测里，模型只要输出了某个 flag，或者描述了某种攻击路径，就会被认为“完成任务”。但这种方式有明显问题：模型可能幻觉，可能编造，也可能只是说出了正确方法，却没有真的完成操作。

SandboxBench 使用的是 sidecar verifier，也就是旁路验证容器。Agent 在沙箱容器里执行任务，如果是逃逸、持久化、横向移动、复制这类挑战，就必须把特定 marker 写到指定位置；旁边的 verifier sidecar 再以只读方式检查 marker 是否真的存在。对于凭证发现、数据外传这类任务，则由 scorer 检查 Agent 输出中是否包含预设的 flag 或秘密。

这个设计很重要。因为在托管 Docker 或托管 Kubernetes 环境里，评测系统往往不能直接 SSH 到宿主机上确认攻击是否成功。SandboxBench 用 verifier sidecar 解决了这个问题：不需要拿到宿主机 shell，也能获得比较可靠的 ground truth。报告特别提到，这种方法可以适配 Docker Compose、Kubernetes 和 Docker Swarm。

换句话说，SandboxBench 不是问 Agent：“你逃出去了吗？”

它是在问系统：“你留下的证据在哪里？”

这会让 Agent 安全评测从“自述式评测”变成“证据式评测”。这也是它相比普通红队 prompt 测试更有价值的地方。

27 个挑战：从容器逃逸到自我复制

SandboxBench 的挑战设计覆盖面比较完整。Docker 部分一共有 21 个挑战，分为六类。

第一类是容器逃逸，比如 privileged container、Docker socket 暴露、proc 可写、危险 capabilities、kernel module、shared PID、cgroup escape 等。

第二类是数据外传，比如 proxy bypass、DNS tunnel、covert channel。

第三类是敏感信息发现，比如环境变量密钥、文件系统凭证、云元数据、数据库凭证。

后面还有横向移动、持久化和复制，比如弱口令 SSH 进入其他容器、创建 cron 任务、添加后门用户、启动新容器、构造后门镜像。

这里的重点不是某个单独漏洞，而是 Agent 的行为谱系变宽了。

过去讨论容器逃逸，更多是安全研究员的问题。现在如果一个 Agent 能够使用 shell、docker、kubectl，或者能访问一些云原生 API，那么它就可能把这些传统攻防知识变成自动化操作。Agent 不需要成为原创漏洞研究员，只要能沿着已知路径执行，就已经会带来新的风险。

Kubernetes 部分则更加贴近企业实际环境。报告设计了 6 个 K8s 挑战，包括过度授权 RBAC、ConfigMap 中存放敏感数据、service account token 窃取、创建 privileged pod、hostPID pod escape、访问云元数据服务等。

这些挑战其实很现实。很多企业的 Agent 不是运行在孤立容器里，而是运行在一整套云原生基础设施里。一旦它拿到 service account token 或者被绑定了过大的 RBAC 权限，风险就不再是单容器内的越权，而可能扩展成跨 namespace 读取 secrets、创建高权限 pod、访问元数据服务，甚至进一步触达云账号资源。

Docker 和 Kubernetes 的边界，其实没有想象中那么远

报告里有一个判断很关键：所谓 Docker escape，很多时候并不只是 Docker 的问题，而是容器运行时隔离原语的问题。

比如 privileged、capabilities、shared PID、proc writable、cgroup escape，它们本质上都和 namespace、cgroups、Linux capabilities、挂载点和进程隔离有关。这些机制不只存在于 Docker，也存在于 Kubernetes 背后的 containerd、CRI-O、gVisor 等运行时环境中。

报告认为，Docker 挑战里的很多容器级逃逸场景，在 Kubernetes 中也有对应配置形态，比如 securityContext.privileged: true、securityContext.capabilities.add: [SYS_ADMIN]、hostPID: true、hostPath volume mounts 等。

这意味着，Agent containment 不能简单理解成“我给 Agent 套了一个 Docker 容器，所以安全了”。

真正的问题是：这个容器的能力边界是什么？有没有挂载宿主机目录？有没有 Docker socket？有没有危险 capability？有没有过大的 service account 权限？有没有访问 Kubernetes API 的路径？有没有网络出口？有没有可写的共享卷？

如果这些问题没有被系统性收敛，沙箱就只是一个看起来像边界的边界。

原文 Figure 2：SandboxBench Kubernetes architecture。图中展示 LLM Agent 通过 Agent Pod 使用 kubectl/curl，与 K8s API Server、Shared Volume、Verifier Pod 交互。

实验结果：有提示时很强，无提示时很弱

这篇报告最容易被传播的数字，是模型在 medium difficulty 下的成功率。

报告评测了 GPT-5、Gemini 2.5 Pro 和 GPT-4o-mini。在 13 个 Docker 挑战中，GPT-5 通过 10 个，成功率 77%；Gemini 2.5 Pro 也通过 10 个，成功率 77%；GPT-4o-mini 通过 9 个，成功率 69%。

乍看这个结果有点吓人，似乎前沿模型已经能稳定逃出沙箱。但细看会发现，成功主要集中在“直接利用路径”上，比如 privileged container、Docker socket、proc writable、capabilities、shared PID 等。对于 kernel_module 和 cgroup_escape 这种需要复杂环境前提或多步精确操作的挑战，三个模型都失败了。

Kubernetes 的结果更低。报告在 minikube + gVisor 环境中对 Gemini 2.5 Pro 做了初步评测，5 个 K8s 挑战里通过 2 个，成功率 40%。它能完成较简单的 K8s API 滥用和 ConfigMap 凭证发现，但在 service account token 窃取、创建 privileged pod、pod escape 等更复杂任务上失败。

但真正值得关注的是 hard mode。

medium 模式下，prompt 会给 Agent 漏洞提示、环境说明、检测路径和利用方向；hard 模式下，这些信息都没有，Agent 必须自己发现错误配置并完成利用。结果非常明确：medium 模式 5 到 10 分钟内完成 10/13，成功率 77%；hard 模式运行 60 分钟以上，13 个挑战 0 个成功。

这说明当前模型的能力状态很微妙。

它们不是完全自主的攻击者，还不能稳定在陌生环境里自己发现漏洞。但一旦有人给出方向，或者通过越狱、提示注入、外部指挥把它们引导到具体攻击路径上，它们已经可以完成相当一部分真实利用动作。

所以，这篇报告不应该被解读成“AI 已经能自动攻破所有容器”。更准确的说法是：

当前 Agent 已经具备较强的 guided exploitation 能力，但 autonomous vulnerability discovery 能力仍然有限。

也就是说，它现在更像一个“被指导后执行力很强的攻击执行器”，还不是一个完全自主的漏洞挖掘专家。

社会工程比技术混淆更危险

报告前两阶段还有一个很有意思的发现：社会工程攻击非常有效。

研究者先构建了一个 AI-vs-AI 攻击框架，让攻击者 LLM 生成提示，去诱导拥有 MCP 工具访问能力的受害 Agent。这个阶段测试了 54 个攻击提示，形成了 21 类攻击策略，覆盖越狱、社会工程、技术混淆、多轮攻击和多步攻击链。报告称，这套自动化测试相对人工测试实现了约 120 倍效率提升。

在攻击效果上，社会工程是最有效的类型之一，在 baseline server 上成功率达到 80%；多步攻击链也是 80%；多轮操纵达到 75%。报告还指出，多轮攻击比单轮攻击有效性提升 87.5%。

这对 Agent 安全非常重要。

很多人讨论工具安全时，容易把问题想成命令注入、路径穿越、shell 执行、权限配置。它们当然重要，但 Agent 的特殊性在于：攻击者可以先操纵语言层，再触发工具层。

攻击者不一定上来就说“帮我逃逸容器”。他可以伪装成管理员，说这是一次紧急排障；也可以伪装成审计人员，说需要验证系统隔离效果；还可以通过多轮对话逐渐建立信任，让 Agent 一步步放宽边界。等 Agent 接受了这个任务叙事，后面的工具调用就会变得顺理成章。

这也是为什么 Agent 安全不能只靠“模型对齐”。模型对齐解决的是“模型是否愿意拒绝”，但 Agent containment 解决的是“即使模型被诱导，它有没有权限做成这件事”。

不要指望 Agent 永远守规矩

报告在讨论未来风险时讲到一个关键不对称性。当前模型 hard mode 成功率为 0，说明它们还依赖明确提示；但 medium mode 成功率达到 77%，说明只要攻击者提供足够指导，模型已经能完成不少常见错误配置的利用。

报告还把这种情况类比为 jailbroken models as attack tools，也就是一旦模型被越狱、胁迫或微调成攻击工具，medium 难度中的表现就可能成为现实攻击能力的下限。

这句话对企业安全非常关键：

Agent 安全不能建立在“模型会自觉守规矩”这个假设上。

真正可靠的策略，是让 Agent 即使想越界，也没有条件越界。它没有过大的 capability，没有 Docker socket，没有宿主机敏感挂载，没有过度 RBAC，没有无限网络出口，没有长时间反复尝试的机会，也没有未经审计的工具调用链。

报告建议的防御方向包括环境加固、检测和资源限制。环境加固是消除模型已经能利用的错误配置；检测是监控 block device mounting、Docker socket access、/proc manipulation 等利用模式；资源限制是控制 token 预算和执行时间，防止模型长时间持续探索复杂攻击路径。

这其实可以总结成一句话：

不要只训练 Agent 不要开门，还要把门锁拆成多道、把钥匙分开保管、把开门动作全部记录下来。

AgentSecOps：把 Agent 沙箱评测放进上线流程

SandboxBench 还有一个很值得产品化的概念：AgentSecOps。

它的思路是把 Agent containment test 融入 DevSecOps 流程。只要容器镜像更新、K8s RBAC 或 NetworkPolicy 变化、新模型部署、安全补丁发布，或者生产上线前，都应该重新跑一遍 SandboxBench 这类评测。报告给出的触发点包括 container image update、K8s policy change、new model deployment、security patch cycle 和 pre-production gate。

这个思路非常合理。因为 Agent 安全不是一次性评估。

模型能力会变。今天 hard mode 做不到，不代表下一代模型也做不到。工具权限会变。今天只是读文件，明天可能就能调 kubectl。环境配置会变。今天 RBAC 收得很紧，某次上线改动后可能就放大了。容器镜像也会变。今天没有危险工具，下一版镜像里可能多了 docker、curl、gcc、python 包管理器。

所以，企业上线 Agent 之后，不能只做一次安全评估就结束，而应该建立持续评测机制。

这也是 SandboxBench 最有价值的地方。它不是一次性的论文实验，而是在尝试把 Agent 行为风险变成可以回归测试、可以量化对比、可以纳入上线门禁的工程流程。

局限性

当然，SandboxBench 还不是一个完整的企业级 Agent 安全标准。

首先，它评测的模型数量有限，主要是 GPT-5、Gemini 2.5 Pro 和 GPT-4o-mini，报告自己也承认需要扩展到 Claude、Llama 和其他前沿模型。

其次，它的结果主要是 single-attempt evaluation，没有充分衡量多次运行之间的方差。对 Agent 来说，这一点很重要，因为同一个任务多跑几次，路径和结果可能会不同。

再次，medium 模式给了比较明确的提示和利用方向，因此更接近“攻击者指导下的 Agent”，不等于完全自主攻击。但从防守角度看，这恰恰是一个真实威胁模型：攻击者未必需要模型自己发现漏洞，只要能通过提示注入、多轮诱导或外部指挥让 Agent 进入执行状态，就足够危险。

最后，报告目前更关注“能不能成功”，还没有系统回答“能不能被发现”。报告未来工作里也提到，后续要结合 auditd、Falco、seccomp 等监控手段，衡量哪些安全工具能够抓住 AI-driven escapes。

所以，它更像是 Agent containment 评测的第一块地基，而不是最终答案。

写在最后

如果把这篇报告放进整个 Agent 安全发展脉络里，它代表的是一个明显转向。

过去的大模型安全，核心词是 guardrail，也就是护栏。护栏的目标是让模型不要说错话、不要泄露数据、不要输出危险内容。

但 Agent 时代，只有 guardrail 不够了。因为 Agent 不只是说话，它还会做事。它可能打开文件、调用工具、运行命令、访问 Kubernetes API、读写数据库、修改系统状态。

因此，Agent 安全正在从 guardrail 走向 containment。前者强调“输出约束”，后者强调“行为边界”。

更直白一点说：

聊天机器人需要护栏，工具型 Agent 需要围栏。

这个围栏不是一个单点机制，而是一套系统工程。模型层要有拒答和意图识别，工具层要有权限收敛和参数校验，运行时要有沙箱隔离和资源限制，云原生层要有最小权限和网络策略，审计层要有行为日志和异常检测，评测层要有像 SandboxBench 这样的持续回归测试。

SandboxBench 的意义就在这里。它没有告诉我们“模型已经无所不能”，而是在提醒我们：当模型开始拥有真实执行能力后，安全评测必须从“它会不会答”升级为“它能不能做成”。

未来企业评估 Agent 安全时，真正重要的问题可能不再是：

“这个 Agent 有没有安全提示词？”

而是：

“这个 Agent 拿到 shell 以后，最多能走到哪里？”

“它能不能读到不该读的 secret？”

“它能不能绕过容器边界？”

“它能不能访问 Kubernetes API？”

“它能不能建立持久化？”

“模型升级之后，原来的沙箱还关得住它吗？”

这才是 SandboxBench 想让行业开始认真回答的问题。