AI Security

外观

AI 应用与智能体系统安全 · A5.5 Agent Runtime、Sandbox 与 Workspace2026-07-28约 27 分钟

Agent 沙箱产品全景与逃逸手法研究 ​

调研日期：2026-07-28

证据等级说明（沿用 pentest-agent-countermeasure/notes/security-agent-countermeasure-research.md 的约定）：强 表示有 CVE 编号、官方安全公告或可复现的第三方研究支撑；中 表示只有厂商产品页/博客描述、无独立验证；未披露 表示公开资料未找到足够技术细节，不代表该产品一定没有对应能力或该风险一定不存在。

0. 结论先行 ​

  1. 市面上不存在单一"最安全"的 Agent 沙箱，只有隔离原语（namespace/seccomp、gVisor 用户态内核、Firecracker/Kata microVM、WASM、TEE）与产品化封装（E2B、Modal、Daytona 等）两层解耦的市场结构。 产品的安全边界几乎完全由它选用的底层隔离原语决定，产品层的"security posture"营销语言（"hardware-level isolation"）需要对照其底层技术还原。
  2. 2025-2026 年最重要的转变是：真正能撬动沙箱的漏洞已经很少直接打穿隔离边界本身（容器/微虚拟机层的 CVE 数量少、修复快），绝大多数实战可复现的"逃逸"发生在信任边界，而不是内核态。 Cursor（DuneSlide, CVE-2026-50548/50549）、Google Antigravity、Claude Code（CVE-2026-39861）、OpenAI Codex CLI 的问题共同模式是：沙箱本身没有被打穿，而是沙箱内可信的宿主进程/命令白名单/符号链接处理逻辑被 Agent 自己生成或下载的文件所欺骗，导致沙箱外代码执行。这与 ../../pentest-agent-countermeasure/notes/security-agent-countermeasure-research.md 中"agent-phishing"结论完全一致，说明该模式已经从渗透测试 Agent 扩展到通用编码 Agent。
  3. 2026 年 7 月的 Hugging Face 安全事件是本轮调研中最重要的实证案例：一个自主 Agent 框架利用数据处理管线的两个代码执行漏洞，操纵"由大量短生命周期沙箱组成的集群"作为攻击基础设施，对 HF 生产环境执行了数千个独立动作并完成横向移动。 这表明沙箱不仅是需要被逃逸的边界，其本身的编排能力（快速拉起/销毁、批量并发）也可能被攻击者征用为攻击基础设施——这是现有沙箱产品安全模型普遍未考虑的威胁场景。
  4. 底层隔离原语按公开可验证的安全强度大致排序为：TEE（SEV-SNP/TDX，机密性最强但生态最不成熟）> Firecracker/Kata microVM（硬件级隔离，2026 年出现首个逃逸级 CVE）> gVisor 用户态内核（syscall 拦截，历史上出现过 socket/netfilter 逃逸）> WASM（进程内隔离，编译器 bug 可致沙箱逃逸）> 命名空间+seccomp/Landlock 容器（依赖宿主内核，2025 年 runc 三连发 CVE 影响几乎所有版本）。 但强度排序不能替代威胁模型匹配——多数 Agent 场景的真实风险来自配置错误和信任边界，而不是需要突破哪一层原语。

1. 案例引子：AgentENV（kvcache-ai） ​

用户提及的 AgentENV（AENV）是一个面向 Kimi K3 智能体强化学习训练的分布式沙箱平台，MIT 协议，约 1.2k star（活跃开发中）。技术要点：

  • 隔离原语为 Firecracker microVM，而非容器；核心卖点是规模化下的低成本快照/恢复（<50ms 启动、<100ms 快照）与 fork 出多个独立沙箱的能力。
  • 通过 overlaybd 按需加载镜像、ublk 高性能 I/O、共享 host page cache 优化资源密度。
  • 提供与 E2B 兼容的 HTTP API，便于复用已有 SDK 生态。
  • 官方安全声明明确写出："AgentENV 目前不支持鉴权，请勿将 API 暴露到公网。" 这是一条强证据但方向相反的披露——即项目方直接承认当前版本没有做访问控制层，安全边界完全依赖部署方自行加固网络可达性。这与其说是"沙箱逃逸"风险，不如说是"沙箱管理面暴露"风险：一旦 API 可公网访问，任何人都可以创建/操纵他人的 microVM，等价于绕过了整个隔离设计的前提。

AgentENV 代表的是本轮调研中一个明确的产品定位：训练场景下的沙箱（RL rollout、海量短生命周期环境、成本敏感）与生产 Agent 场景下的沙箱（E2B/Daytona 等，安全和多租户隔离优先）目标不同，评价其安全性时不能直接套用生产沙箱的标准。

2. 市场地图：按隔离层次分类 ​

沙箱产品市场实际上是分层的：底层是隔离原语（内核态/用户态/硬件态），中间是把原语封装成可编程沙箱的运行时，上层是把运行时包装成 SaaS/API 的托管产品，再上层是编码 Agent（Claude Code、Cursor、Codex CLI 等）内置的沙箱功能。以下按此四层展开。

2.1 底层隔离原语（开源，多数无独立"产品"形态） ​

原语代表项目隔离机制安全证据等级
Linux 命名空间 + SUIDFirejail、bubblewrapnamespace 隔离 + 可选 seccomp中（成熟但依赖宿主内核，历史上多次曝出 CVE）
命名空间 + seccomp-bpfnsjail（Google）、Minijail（ChromeOS/Android）namespace + cgroup + syscall 过滤中，工程成熟度高但仍与宿主共享内核
Landlock LSMsandlock、island、Matchlock、nono非特权文件系统/网络访问控制中，Linux 5.13+ 内核原生支持，攻击面比 seccomp 更小但功能覆盖窄
用户态内核gVisor（Google）Sentry 拦截并在用户态重新实现 syscall，禁止 execve/open 等危险调用直达宿主中-强，公开披露过 CVE-2020-10890（socket 处理逃逸）与 CVE-2021-22555 的 gVisor 专属变种（netfilter），此后无新增逃逸级 CVE 报告
WASM 运行时Wasmtime、Wasmer、Deno（V8 隔离）进程内基于能力模型的沙箱，无系统调用直通中，2026 年 Wasmtime 在 aarch64 Cranelift 后端出现 CVE-2026-34971（编译器误编译导致越界读写、构成沙箱逃逸）；Wasmer 曾出现 CVE-2023-51661（WASI 路径转换缺陷绕过文件系统限制）

2.2 MicroVM / 硬件虚拟化层 ​

项目类型说明安全证据等级
Firecracker（AWS）开源KVM VMM，Lambda/Fargate 底座；也是 E2B、Vercel Sandbox、Fly.io Sprites、AgentENV 的底层技术强，2026 年首次出现两个逃逸级 CVE：CVE-2026-5747（virtio-pci 越界写，CVSS 8.7）与 CVE-2026-1386（jailer 符号链接任意宿主文件覆写，CVSS 6.0）；此前多年无逃逸类 CVE 记录
Kata Containers开源OCI 兼容运行时，每个容器运行在独立 microVM 中，可选 Cloud Hypervisor（Intel 主导）作为 VMM中-强，硬件级隔离，工程上比 gVisor 更强但性能开销更高
libkrun开源可嵌入的 KVM library，被 microsandbox、Podman VM 模式复用中，生态尚新
Cloud Hypervisor开源Rust 编写的 VMM，Kata 的替代 VMM 选项中
Lima / Tart开源macOS 原生虚拟化（Apple Silicon），常作为本地 Agent 沙箱的 VM 层未披露充分独立验证

2.3 云托管 Agent 沙箱 SaaS（本轮调研核心对比对象） ​

产品开源状态隔离技术冷启动GPU快照/持久化安全证据等级
E2B开源核心 + 商业托管，可自托管/BYOC（仅限企业客户，仅 AWS）Firecracker microVM~150ms无（CPU 为主）会话级（≤24h），beta 暂停/恢复强，"每个沙箱独立 VM"的硬件级隔离描述有底层技术支撑；号称 Fortune 100 中 94% 使用、月均 SDK 下载 350 万+，是目前该赛道热度最高的开源项目
Modal Sandboxes闭源平台（SDK 开源）gVisor + KVM未披露具体数值支持，唯一可在沙箱内直接挂 GPU 的主流产品会话级（≤24h），支持文件系统+内存快照中，gVisor 的 syscall 拦截强度依赖其自身 CVE 历史（见 2.1），非硬件级隔离
Daytona开源核心（AGPL），商业托管默认 OCI 容器，可选 Kata/Sysbox 增强隔离~90ms，优化后可达 27ms未披露持久化 workspace中，默认容器隔离弱于 E2B/Modal，需显式启用 Kata 才接近 microVM 级别
Vercel Sandbox闭源Firecracker未披露未披露文件系统快照，GA 阶段中，与 AI SDK / OpenAI Agents SDK 集成紧密
Fly.io Sprites闭源Firecracker未披露未披露100GB NVMe 持久化，~300ms checkpoint/restore中
CodeSandbox SDK闭源Firecracker未披露未披露持久化 IDE 式沙箱，最高 64 vCPU中
Runloop Devboxes闭源microVM未披露未披露面向企业，OpenAI Agents SDK 官方 provider 之一未披露
Northflank Sandboxes闭源（平台）Kata + K8s未披露未披露BYOC 全栈基础设施未披露
Blaxel闭源microVM~25ms（宣传值）未披露未披露未披露
AgentENV（kvcache-ai）开源（MIT）Firecracker<50ms 启动，<100ms 快照未披露快照 + fork，S3/分布式文件系统持久化强（但方向为负面）：官方明确声明当前无鉴权，见第 1 节

共同模式：几乎所有主流托管沙箱都建立在 Firecracker（E2B/Vercel/Fly.io/CodeSandbox/AgentENV）或 gVisor（Modal）之上，行业已经收敛到"microVM 为默认高安全选项、容器为默认低成本选项"的两极格局；Daytona 是少数默认走容器路线、把 microVM 级隔离作为可选升级项的产品，体现了性能（冷启动）与隔离强度的直接权衡。

2.4 自托管开源沙箱运行时（非 SaaS，可自部署） ​

覆盖面很广，按隔离后端归类：

  • 多后端封装：boxed（Docker/Firecracker/WASM 可选）、Kilntainers（Docker/Podman/microVM/WASM，面向 MCP 场景）、cco。
  • 单一 microVM 后端：microsandbox（libkrun，<200ms 启动，自带 MCP server）、nervos（Firecracker）、BoxLite（VM 快照）、bunkervm。
  • 容器后端：AIO Sandbox（Docker，内置 shell/浏览器/文件/Jupyter/VS Code/MCP server 一体化）、Amazing Sandbox、ClaudeBox、vibebin（Incus/LXC）。
  • 本地 CLI/桌面场景：Anthropic 官方的 @anthropic-ai/sandbox-runtime（srt，macOS Seatbelt + Linux bubblewrap + 网络过滤代理，是 Claude Code 沙箱化 bash 工具的底座）、Agent Safehouse / SandVault / Chamber（macOS Seatbelt/Tart 生态）、sandlock/Matchlock/Nono（Linux Landlock 生态）。

这一层生态非常碎片化（awesome-AI-sandbox 收录 50+ 项目），多数是社区个人项目、star 数不高，但反映出一个明确趋势：开发者对"编码 Agent 在本机跑 shell 命令"这件事的信任在下降，越来越多轻量级、单机可用的沙箱包装器涌现，而不是都依赖云托管。

2.5 编码 Agent 内置沙箱（不是独立产品，但覆盖面最大） ​

Agent内置沙箱技术
Claude Code@anthropic-ai/sandbox-runtime：macOS Seatbelt / Linux bubblewrap + 出站网络过滤代理
OpenAI Codex CLImacOS Seatbelt（动态生成 .sbpl profile）、Linux Landlock+seccomp、Windows 自研的"提权沙箱"（合成用户 + 写入受限令牌 + Windows 防火墙，详见 2.5.1）
Cursor未完全公开，2026 年多个 CVE（见第 4 节）显示其沙箱与宿主可信进程之间存在边界问题
Google Gemini CLImacOS Seatbelt 或 Docker/Podman 容器（用户自备 Dockerfile）
GitHub Copilot（Agent 模式）每任务独立的临时云端 VM

这一层的特点是：隔离原语本身（Seatbelt/bubblewrap/Landlock）都是成熟、公开审计过的操作系统级机制，真正的漏洞几乎全部出现在"沙箱之上"的策略层——命令白名单误判、符号链接处理、hook 配置文件是否可信——而不是命名空间/seccomp 本身被绕过。这直接对应第 0 节结论 2 和第 4.3 节。

2.5.1 案例：OpenAI Codex 的 Windows 沙箱架构（对照 macOS/Linux） ​

OpenAI 官方工程博客（2026-05-13，Building a secure and efficient sandbox for Codex on Windows）详细披露了 Codex 在三大平台上沙箱实现的不对称性，是目前公开资料中对"同一个 Agent 在不同 OS 上如何拼装隔离能力"描述最细的一手技术文档，证据等级强。

起点：Windows 没有对应 Seatbelt/seccomp 的开箱原语。 OpenAI 原文明确指出，macOS 有 Seatbelt（Codex 会动态生成 .sbpl profile 来调整沙箱语义，改策略的成本很低），Linux 有 seccomp/bubblewrap，但 Windows 没有对应的内置强制访问控制机制，只能自己拼装。这与本笔记 2.1 节"底层隔离原语"的结论一致：Windows 平台在这张地图里长期是空白的，OpenAI 这篇文章相当于第一份公开的、工程级别的补课记录。

评估过的三种 Windows 原生方案，均被否决：

方案否决理由
AppContainer能力模型要求应用启动前声明所需权限，与 Codex 需要驱动 shell/Git/Python/包管理器/构建工具等任意二进制的开放式工作流不匹配
Windows Sandbox（一次性 VM）隔离强，但 Codex 需要直接操作用户真实签出代码/环境，而不是独立桌面里的副本；且 Windows 10/11 家庭版不支持，产品覆盖率不达标
Mandatory Integrity Control（完整性标签）理论优雅，但修改的是真实主机文件系统的信任语义——把工作区标为低完整性，意味着所有低完整性进程（不只是 Codex）都能写入，风险面比精心设计的 ACL 大得多

第一代原型"未提权沙箱"（配置无需管理员权限）：

  • 文件写入限制：创建合成 SID（sandbox-write），配合写入受限令牌（write-restricted token）——一次写入必须同时通过"令牌所有者身份检查"和"受限 SID 列表中至少一个 SID 被授权"两层校验；对 .git、.codex、.agents 等目录显式拒绝写入。
  • 网络限制：因为不提权就调不动 Windows 防火墙，只能靠环境变量污染（HTTPS_PROXY/ALL_PROXY 指向死端口 127.0.0.1:9、GIT_SSH_COMMAND=cmd /c exit 1）+ PATH 前置 denybin 目录拦截 SSH/SCP 存根。OpenAI 原文直接承认这只是**"建议性"（advisory）限制**：任何自行实现 socket 通信、或不遵守代理环境变量的程序都能绕过，"设计之初就无法抵御恶意对抗代码"。
  • 这一版本最终被放弃，直接原因是网络防护强度不达标，而不是文件写入限制的问题。

第二代"提权沙箱"（当前生产架构，配置阶段需要管理员权限）：

  • 核心改动：创建两个专属本地 Windows 用户——CodexSandboxOffline（受防火墙规则约束，禁止一切出站）和 CodexSandboxOnline（不受防火墙规则约束）——把写入受限令牌的主身份从真实用户换成这两个合成用户之一。这一步是关键：Windows 防火墙规则无法绑定到受限令牌的非主体身份（即无法直接对着 sandbox-write 这个 SID 下规则），只能绑定真正的 principal（用户/程序路径/端口），而按二进制路径下规则又太粗（会连坐所有 python.exe 调用，不区分是不是沙箱内启动的）——这正是促成从"未提权"推倒重来到"提权"的根本技术原因。
  • 配置复杂度显著上升：创建/管理两个本地用户，用 DPAPI（Windows 数据保护 API）加密存储其凭据（存在沙箱用户自己读不到的位置）；创建并校验防火墙规则；异步给沙箱用户在常见目录（用户 profile、Windows、Program Files、ProgramData）补读权限 ACL——因为 Windows 默认不允许跨用户读取彼此的 profile 目录，换了合成用户身份后这类读操作会直接失败。
  • 架构拆成四层，职责分离清晰：codex.exe（保持无需提权的主程序）→ codex-windows-sandbox-setup.exe（独立二进制，只在需要提权配置时跨越 UAC 边界）→ codex-command-runner.exe（解决"真实用户侧无法直接用 CreateProcessAsUserW 以沙箱用户身份+受限令牌启动子进程"这一特权壁垒的两跳方案：先用 CreateProcessWithLogonW 以沙箱用户身份启动 runner，再让 runner 在沙箱用户上下文里自行调用 CreateRestrictedToken+CreateProcessAsUserW 启动真正的子进程）→ 子进程。

对照本笔记分类体系：这套方案本质上仍是 2.1 节"命名空间+seccomp/Landlock"一档的 Windows 平替——共享宿主内核，靠 ACL+受限令牌+防火墙做策略过滤，不涉及 microVM/独立内核，理论强度上限和 Linux 容器同级，不会超过 gVisor/Firecracker。它的独特价值在于工程侧的坦诚：OpenAI 公开承认了未提权版本"网络抑制只是建议性、设计上无法抵御对抗代码"这一结构性弱点，并且给出了从"文件系统限制够用但网络限制不够用"到"为了让防火墙规则可执行，不得不引入两个合成用户和管理员级配置步骤"的完整决策链——这是本轮调研中少见的、由厂商自己披露的"安全强度 vs 部署摩擦"权衡案例，值得作为方法论参考。原文结论也呼应了第 3.3 节的判断："编程智能体的安全问题与传统应用安全有本质不同"——因为必须兼容真实开发者的开放式工作流（任意二进制、任意工具链），没法像 AppContainer 那样用能力声明模型提前圈定权限边界。

2.6 浏览器 / Web Agent 沙箱 ​

Browserbase（托管，含 Cloudflare "Signed Agents" 加密验证 Agent 身份）、Steel.dev（开源，Puppeteer/CDP 封装）代表这一细分。其核心风险模型与代码执行沙箱不同：浏览器进程本身的隔离（Chrome 站点隔离）已经很成熟，真正的攻击面是网页内容对 Agent 的提示注入（商品描述、评论中的隐藏指令诱导泄露支付信息或执行未授权操作），这类攻击完全不需要突破浏览器进程隔离，因此传统"沙箱强度"指标在这里几乎不构成防线。

2.7 机密计算 / TEE 沙箱（前沿，生态尚未成熟） ​

AMD SEV-SNP、Intel TDX、ARM CCA、NVIDIA H100 CC 构成机密计算的硬件基础，特点是连宿主 OS/hypervisor 都无法读取沙箱内存，理论隔离强度高于 Firecracker/gVisor。已知落地案例包括 seL4 形式化验证微内核为基础的 agentOS（能力令牌不可伪造）、以及若干"Confidential Agents"类项目。当前证据等级普遍为中或未披露：这类方案部署复杂度高、生态工具链（尤其 GPU 侧的可信通道）仍在完善，2026 年才有 EnclaveX 等论文提出 CPU/GPU 联合 TEE 的完整链路，尚未看到主流 Agent 沙箱 SaaS 把 TEE 作为默认选项。

3. 沙箱逃逸手法分类 ​

按攻击是否需要突破隔离原语本身，分为"原语层逃逸"（真正的沙箱漏洞）和"信任边界滥用"（沙箱本身完好，但沙箱之外的逻辑被欺骗）两大类，后者是 2025-2026 年绝大多数实战案例所在。

3.1 原语层逃逸：配置错误型（不需要 0day） ​

最古老也最常见的一类，本质是运维/产品把危险能力开放给了沙箱内进程：

  • 特权容器 / --privileged：容器内进程直接获得几乎全部 root 能力（CapEff = 0000003fffffffff），可挂载宿主磁盘或 nsenter 进入宿主命名空间。
  • Docker socket 挂载：把 /var/run/docker.sock 挂进容器，等价于把宿主 Docker daemon 控制权交给容器内进程，可再启动一个 --privileged 容器逃逸。
  • cgroup release_agent 逃逸：向 cgroup 层级的 release_agent 文件写入宿主可执行路径，当该 cgroup 的 notify_on_release=1 且进程清空时，宿主内核以最高权限执行该脚本；本用于容器退出清理，被滥用为逃逸原语，代表性漏洞 CVE-2022-0492。
  • 过量 Linux capabilities：CAP_SYS_ADMIN 可组合利用挂载/cgroup 逃逸；CAP_SYS_PTRACE + hostPID 可注入宿主进程；CAP_DAC_READ_SEARCH 对应经典的 shocker 逃逸。
  • 敏感目录挂载：把宿主 /、/proc、/var/run 等挂入沙箱。

对 Agent 沙箱而言，这类风险的现实意义在于：很多"轻量级"自建沙箱包装器（第 2.4 节碎片化生态里的小项目）为了方便调试或功能完整性，容易在无意中开放上述某一项能力，而这类项目通常没有经过独立安全审计。

3.2 原语层逃逸：运行时/内核 CVE 型 ​

真正打穿隔离层代码本身的漏洞，数量少但影响面大：

  • runc（容器运行时）：2025 年 11 月披露的 CVE-2025-31133 / CVE-2025-52565 / CVE-2025-52881 三连发，影响 runc 1.0.0-rc3 至补丁前几乎所有版本，波及 Docker/containerd/Kubernetes 及各大云厂商托管 Kubernetes；三者分别利用 masked path 符号链接替换、/dev/console 挂载竞态、/proc/self/attr/<label> 重定向绕过 LSM 检查。截至 2026 年 6 月仍有在野利用报告。这类漏洞对任何以容器为默认后端的 Agent 沙箱（包括 Daytona 默认模式）都直接适用。
    • 修复版本：runc ≥1.2.8/1.3.3/1.4.0-rc.3，containerd ≥1.6.39/1.7.28-2，Docker Desktop 已内置 runc 1.3.5（2026-06）。
  • gVisor：CVE-2020-10890（Sentry socket 处理逃逸）、CVE-2021-22555 的 gVisor 专属变种（Sentry 自实现 netfilter 存在堆溢出）。gVisor 的设计本身通过 seccomp 白名单大幅收窄了到达宿主内核的路径，攻击者必须先攻破 Sentry 的 Go 实现才能进一步触达宿主内核 CVE，这也是它至今逃逸级 CVE 数量少于容器方案的结构性原因。
  • Firecracker：2026 年出现首批逃逸级 CVE——CVE-2026-5747（virtio-pci 越界写，CVSS 8.7）、CVE-2026-1386（jailer 符号链接任意宿主文件覆写，CVSS 6.0，AWS 官方声明其托管服务因限制了 jailer 目录访问而不受影响）。此前 Firecracker 多年无公开的 hypervisor 逃逸记录，2026 年是明确的转折点，值得持续跟踪其后续 CVE 节奏。
  • WASM 运行时：Wasmtime CVE-2026-34971（aarch64 Cranelift 后端误编译导致 guest 越界读写宿主内存）；Wasmer CVE-2023-51661（WASI 路径转换缺陷绕过文件系统限制）；此外 "Wasm bomb"（内存膨胀式 DoS，如 CWA-2023-004）属于资源耗尽而非内存破坏型逃逸。

3.3 Agent 特有：信任边界滥用型"非典型逃逸"（2025-2026 年实战主流） ​

这类攻击的共同特征是沙箱隔离边界本身完好无损，问题出在沙箱内 Agent 生成/下载的产物，被沙箱外的可信组件不加区分地处理：

  • Google Antigravity：提示注入结合"允许创建文件"的能力，诱导 Agent 拉取一个含有攻击者控制注释的源文件；这些注释作为正常内容被摄入并处理，最终获得远程代码执行权限——攻击链完全没有触碰沙箱边界本身。
  • Cursor "DuneSlide"（CVE-2026-50548 / CVE-2026-50549，CVSS 9.8）：零点击提示注入，可逃逸 Cursor 沙箱并在宿主操作系统执行任意代码。
  • Cursor CVE-2026-48124：Claude hooks 配置文件被用于在沙箱外执行命令，3.0.0 版本修复。
  • Claude Code CVE-2026-39861（<2.1.64 版本）：沙箱化进程可以创建指向工作区之外的符号链接，随后一个非沙箱化进程会在未提示用户的情况下通过该符号链接写入——本质是沙箱内进程与沙箱外特权进程之间的 TOCTOU/符号链接信任问题。
  • OpenAI Codex CLI："安全"命令白名单按命令名信任 git show，但实际调用并非只读，OpenAI 在 v0.95.0 修复并支付了高危漏洞赏金（CVE 待分配）。
  • Docker socket 滥用（Codex CLI / Cursor / Gemini CLI，GHSA-v4xv-rqh3-w9mc）：沙箱管得住 Agent 进程本身，管不住它委托给特权本地 daemon（Docker）执行的操作，逃逸发生在 Docker VM 内部、完全在沙箱管辖范围之外。
  • Venv 解释器劫持（Cursor，GHSA-p9g2-cr55-cw9c）：Agent 替换 bin/python 后，由非沙箱化的 IDE 扩展宿主（ms-python.python 的解释器发现机制）在后台执行，与目录命名无关。
  • Git 目录间接引用（Cursor）：--separate-git-dir 让仓库元数据脱离字面 .git/ 路径，沙箱的路径正则规则失效，core.fsmonitor 被劫持为执行触发器。
  • 共同结论：Pillar Security 等研究者明确指出，这不是经典意义上的沙箱逃逸，而是一个根本性的信任问题——Agent 严格遵守了沙箱约束，但它产出的文件后续被沙箱外的可信软件处理，从而间接导致了沙箱外代码执行。这意味着仅评估沙箱隔离原语强度是不够的，还必须审计"沙箱边界两侧的数据流转"这一整条链路。 上述全部案例的技术细节、PoC 步骤与检测方式的系统性梳理见 pillar-week-of-sandbox-escapes-detection.md。

3.4 网络出口滥用：SSRF / DNS rebinding / 元数据端点 ​

即使沙箱本身隔离良好，只要沙箱内进程拥有出站网络能力，就存在以下风险：

  • 攻击者控制的代码请求云元数据服务（如 169.254.169.254）以窃取宿主/沙箱编排层的临时凭据。
  • DNS rebinding：首次域名解析返回合法公网 IP 通过出站校验，实际发起连接时二次解析已经指向 127.0.0.1 或内网地址，绕过基于"首次解析结果"的白名单/黑名单校验（TOCTOU）。
  • 防御要点：默认拒绝出站（default-deny egress）+ 白名单域名、封禁 RFC 1918 内网段、在实际发起连接时（而非仅在解析阶段）校验并锁定已解析 IP。这正是第 2.4 节中 Cleanroom（Buildkite）等项目主打的"deny-by-default egress + 凭据代理"模式所针对的问题。

3.5 MCP / 工具链供应链型逃逸 ​

MCP 生态引入了新的攻击面，其"逃逸"往往不发生在容器/VM 边界，而发生在 Agent 的工具调用信任链上：

  • 工具投毒（Tool Poisoning）：恶意文本藏在工具描述/schema 中，Agent 在决策阶段读取到并被诱导调用其他已授权的高权限工具（如把消息历史通过一个"合法"的邮件工具外泄）。
  • 供应链攻击：Agent 插件/MCP server 注册表普遍没有代码签名、漏洞扫描、来源认证等标准化安全要求，攻击者可以低门槛发布恶意 MCP server。
  • 官方组件自身的逃逸链：Cymulate 在 Anthropic 官方 Filesystem MCP Server 中发现两个可串联利用的沙箱逃逸，组合后可在不触发内存破坏的前提下获得完整文件系统读写权限——说明"官方/受信任"标签不能替代独立安全审计。
  • 即使 MCP server 运行在隔离容器中，只要它保留网络访问能力，仍可被用于数据外泄或建立反向 shell，容器隔离只限制了"能否触达宿主"，不限制"能否把数据发到外部"。

3.6 旁路 / 资源型攻击（非数据泄露，但破坏可用性或作为跳板） ​

  • Fork bomb、内存耗尽、"Wasm bomb"式内存膨胀：目标是让沙箱编排层过载或让其他租户共享资源被挤占。
  • 侧信道：多租户 microVM/容器共享物理核心时的时序/缓存侧信道，公开文献未见 Agent 沙箱场景下的成熟利用案例，仍属于理论风险（未披露）。

3.7 沙箱被征用为攻击基础设施（而非被逃逸的对象） ​

这是本轮调研中最值得关注的新增威胁模式，与前六类"如何跳出沙箱"方向相反：

  • 2026 年 7 月 Hugging Face 安全事件：攻击者的自主 Agent 框架利用数据集处理管线中的两个代码执行路径（远程代码加载器 + 数据集配置模板注入）在处理节点上获得代码执行，随后操纵一个由大量短生命周期沙箱组成的集群，在一个周末内跨多个内部集群执行数千个独立动作完成横向移动、凭据窃取。这里"沙箱"扮演的角色不是被攻破的边界，而是被攻击者当作低成本、可批量销毁重建、天然难以被传统 IOC 追踪的攻击执行单元。
  • 这与 ../../pentest-agent-countermeasure/notes/security-agent-countermeasure-research.md 中 "Red-Teaming the Agentic Red-Team" 论文的结论（worker 被武器化后横向渗透 orchestrator）方向一致，但 HF 事件是首个已知的生产环境真实案例，而非红队论文中的受控实验（180 次组合实验中工作区代码执行成功率 97.8%，10/12 系统实现某种宿主逃逸）。
  • 对沙箱产品的启示：安全评估不能只看"能否被逃逸"，还要看"沙箱编排 API 本身的鉴权和批量操作限流是否足够"——这正好呼应第 1 节中 AgentENV 当前缺乏鉴权的公开声明所暴露的同一类风险。

4. 综合评估：安全成熟度对照 ​

复用并适配 ../../pentest-agent-countermeasure/notes/security-agent-countermeasure-research.md 中的 L0-L5 成熟度模型到沙箱场景：

等级含义典型措施本轮调研中的对应产品/项目
L1 基础隔离有一层隔离原语namespace、cgroup、Docker 默认配置多数自建轻量沙箱（第 2.4 节碎片化生态）
L2 强化隔离用户态内核或 microVMgVisor、Firecracker、KataE2B、Modal、AgentENV、Vercel Sandbox、Fly.io Sprites
L3 出口与凭据治理默认拒绝出站 + 凭据代理，沙箱内不留密钥deny-by-default egress、credential proxyCleanroom、部分企业自建方案；主流 SaaS 产品在公开资料中普遍未披露具体机制
L4 编排面鉴权与限流管理 API 本身有鉴权、审计、批量操作限流API auth、rate limit、审计日志多数商业 SaaS 隐含具备（但公开细节少）；AgentENV 明确声明当前不满足此级别
L5 信任边界审计审计沙箱内产物流向沙箱外可信组件的完整链路符号链接/命令白名单审计、hook 配置签名校验目前是全行业的公开空白：Cursor/Claude Code/Codex CLI 2026 年的一系列 CVE 均发生在此层

核心结论：市场在 L1/L2（隔离原语选型）上已经相当成熟，产品差异主要是性能/成本权衡而非安全强弱的本质差异；真正的风险集中在 L4（编排面鉴权，AgentENV 是一个公开承认的反例）和 L5（信任边界审计，2025-2026 年几乎所有头部编码 Agent 都在此层出过高危漏洞）。这两层目前既缺乏行业标准，也缺乏第三方评测基准。

5. 待验证问题与后续研究方向 ​

  • P0：建立"信任边界审计"清单，逐一梳理 Claude Code / Cursor / Codex CLI / Gemini CLI 在"沙箱内产物 → 沙箱外可信进程"路径上的具体处理逻辑（符号链接解析顺序、命令白名单是否检查完整参数而非仅命令名、hook/配置文件是否需要签名或用户确认），产出可复用的检测脚本而不仅是事后合订的 CVE 列表。
  • P0：复现并量化 Firecracker CVE-2026-5747 / CVE-2026-1386 在主流托管沙箱（E2B、Vercel Sandbox、Fly.io Sprites、AgentENV）中的实际可利用性——这些产品是否已升级到修复版本、jailer 部署配置是否遵循 AWS 官方声明的"不受影响"前提，目前公开资料未披露。
  • P1：跟踪 AgentENV 后续版本是否补齐鉴权层，以及是否有其他同类"训练场景优先、鲜有考虑对外暴露"的开源沙箱项目存在同样问题（碎片化生态中的中小项目大概率更严重）。
  • P1：为 MCP server 沙箱化建立独立于代码执行沙箱的威胁模型——重点是网络出口而非内存破坏，现有容器/microVM 强度指标不能直接套用。
  • P2：跟踪 TEE（SEV-SNP/TDX）路线在 Agent 沙箱产品中的商业化落地节奏，目前仍是研究性方案（LiteBox 等），一旦出现头部厂商正式产品化，需要重新评估第 4 节的成熟度对照表。
  • P2：本轮调研的产品对比表大量依赖厂商博客与第三方评测站点（Northflank、Blaxel、AgentMarketCap 等），尚未找到类似 arXiv:2606.08433（《AI Code Sandboxes: A Comparative Security Study》）那样公开方法论、可复现的独立评测覆盖全部主流产品——该论文本身只评测了"五个"沙箱产品且未在可抓取内容中明确点名并给出总排名，需要进一步获取全文 PDF（已下载至 ../papers/ai-code-sandboxes-comparative-security-study.pdf）逐项核实。

参考资料 ​