AI Security

外观

AI 应用与智能体系统安全 · A5.5 Agent Runtime、Sandbox 与 Workspace更新 2026-09-06约 14 分钟证据：中等 来源：多来源厂商公开材料

Agent 沙箱市场地图、AgentENV 案例与安全成熟度模型 ​

摘要 ​

Agent 沙箱市场存在隔离原语（namespace/seccomp、gVisor 用户态内核、Firecracker/Kata microVM、WASM、TEE）与产品化封装（E2B、Modal、Daytona 等）两层解耦的结构，产品的安全边界几乎完全由它选用的底层隔离原语决定。本文综合公开厂商材料按四层（隔离原语、MicroVM/托管服务、自托管运行时、编码 Agent 内置沙箱、浏览器沙箱、机密计算）比较市场格局，并给出 L1–L5 安全成熟度对照：市场在 L1/L2（隔离原语选型）已经相当成熟，真正的风险集中在 L4（编排面鉴权）和 L5（信任边界审计），这两层目前既缺乏行业标准也缺乏第三方评测基准。

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

案例：AgentENV 的鉴权缺失声明 ​

AgentENV（AENV）是一个面向 Kimi K3 Agent 强化学习训练的分布式沙箱平台，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 等，安全和多租户隔离优先）目标不同的产品定位，评价其安全性时不能直接套用生产沙箱的标准。

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

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

底层隔离原语 ​

原语代表项目隔离机制安全证据等级
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 路径转换缺陷绕过文件系统限制）

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 层未披露充分独立验证

Firecracker 1.16.2 的运行时边界修复 ​

Firecracker 1.16.2（2026-09-03）是维护版本，不是新的沙箱逃逸公告。与 Agent 沙箱直接相关的变更包括：修复 bare pause/resume 后 vsock 永久抑制 host-to-guest 接收；修复快照恢复时 virtio-mem 已拔除内存仍可能保持 VMM 可写或未映射，以及部分 plug/unplug 失败后块状态与 KVM memory slot 不一致；修复 aarch64 jailer 复制 CPU cache 与 MIDR_EL1 信息文件后设置所有权时的 TOCTOU；限制内存热插拔 MiB→byte 转换，避免超大值静默回绕；并修复可由 SIGPIPE 触发的 logger 死锁与 vsock busy-spin。

该版本把快照格式升级，1.16.2 快照不能由 1.16.0/1.16.1 加载，旧版快照也不能由 1.16.2 加载。升级验证必须同时覆盖冷启动、pause/resume、snapshot restore、vsock 双向连接、内存热插拔失败恢复和回滚方案，不能只确认 VMM 进程启动。上述问题主要影响可用性、恢复一致性和宿主管理面的状态正确性；官方发布说明没有把它们定性为新的 guest-to-host 逃逸，因此不能据此提高隔离强度或现实利用结论。

云托管 Agent 沙箱服务 ​

产品开源状态隔离技术冷启动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 历史，非硬件级隔离
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/分布式文件系统持久化强（但方向为负面）：官方明确声明当前无鉴权

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

自托管开源沙箱运行时 ​

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

  • 多后端封装：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 命令"这件事的信任在下降，越来越多轻量级、单机可用的沙箱包装器涌现，而不是都依赖云托管。

编码 Agent 内置沙箱 ​

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

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

浏览器与 Web Agent 沙箱 ​

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

机密计算与可信执行环境 ​

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 作为默认选项。

安全成熟度对照 ​

复用并适配 pentest-agent-countermeasure/notes/security-agent-countermeasure-research.md 中的成熟度分级方法到沙箱场景：

等级含义典型措施本次调研中的对应产品/项目
L1 基础隔离有一层隔离原语namespace、cgroup、Docker 默认配置多数自建轻量沙箱（碎片化生态）
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 都在此层出过高危漏洞）。这两层目前既缺乏行业标准，也缺乏第三方评测基准。

局限与待验证问题 ​

  • 本文的产品对比表大量依赖厂商博客与第三方评测站点（Northflank、Blaxel、AgentMarketCap 等），尚未找到公开方法论、可复现的独立评测覆盖全部主流产品；已知相关论文《AI Code Sandboxes: A Comparative Security Study》只评测了五个沙箱产品，未在可抓取内容中明确点名并给出总排名。
  • 未披露表示公开资料中未找到足够技术细节，不代表产品一定没有实现该能力或该风险一定不存在；不构成独立安全审计结论。
  • 需要跟踪 AgentENV 后续版本是否补齐鉴权层，以及其他同类"训练场景优先"的开源沙箱项目是否存在同样问题。
  • 需要跟踪 TEE（SEV-SNP/TDX）路线在 Agent 沙箱产品中的商业化落地节奏，目前仍以研究性方案为主。

参考链接 ​