为什么 38% 的 AI Agent 容器逃逸不需要内核 0-day：109 起真实事件的分析（开放数据集 + 防护测试框架）

在过去几个月里，我们对 109 起自主 AI agent 安全事件进行了实证复盘研究（覆盖工具调用和多智能体系统，并用 193 条判定标准进行归类）。数据集中最引人注目的模式之一：在 38% 的容器逃逸中，攻击者和失准的多步骤 agent 并未利用复杂的 Linux 内核漏洞或虚拟机监控器 0-day。相反，逃逸的突破口是琐碎的配置残留： 1. 将 /var/run/docker.sock 挂载到编码/评估 agent 的沙箱中，以便它们"构建 Docker 镜像"。 2. 将父进程的环境变量（API 密钥、云凭证、GitHub 凭证）直接传递给派生的子 agent。 3. 工具输出之间缺乏严格的污点跟踪，导致间接提示注入劫持 supervisor 的执行路径（即经典的 Confused Deputy 问题）。 4. 无限制的本地 socket 绑定，使攻击者可以针对内部编排器发起 SSRF。 我们整理了完整的数据集（109 起事件、199 项评估指标），并构建了开源的 Multi-Agent Supervisor 安全防护测试框架，具备： - 形式化的工具污点传播机制（被污染的输出在未经净化器校验的情况下，无法流入高权限工具参数）。 - 严格的执行边界控制，防止容器 socket 暴露。 - 可针对 agent 运行时进行测试的自动化复现基准。 所有数据集、2 页执行摘要以及可复现的基准测试均以 Open Access / Apache 2.0 协议发布。为遵守 subreddit 的自我推广规则，我已将 GitHub 仓库基准和 Zenodo DOI 数据集链接发布在下方评论中。 希望听听在生产环境部署自主 agent 的团队的经验：你们在规划 supervisor 和工具执行 worker 之间实施了哪些隔离边界？