文章总结： 该研究对五款主流AI代码沙箱进行系统性安全测评，从主机攻击面、信息泄露、纵深防御、CVE历史、补丁节奏和Fuzzing投入六个维度分析三类引擎。关键发现包括：不同引擎在架构维度存在明显分层；下游产品补丁延迟可达471天；microVM与持续公开Fuzzer的组合尚属空缺。研究提出威胁模型限定矩阵，为运营者提供可操作的安全选型框架。 综合评分： 87 文章分类： 漏洞分析,安全工具,云安全,安全运营,技术标准

【论文速读】| AI代码沙箱：安全性比较研究

原创

知识分享者 知识分享者

安全极客

2026年6月16日 17:53 北京

在小说阅读器读本章

去阅读

基本信息

原文标题：AI Code Sandboxes: A Comparative Security Study — Part 1 of 2 — Engine-Level Properties (Attack Surface, Leakage, Stackability, CVE History, Patch Cadence, Fuzzing)

原文作者：George Andronchik、Pavel Lokhmakov

作者单位：fellows.tech、orbitalab.dev

关键词：AI 代码沙箱、安全隔离、microVM、gVisor、runc、攻击面、信息泄露、CVE、Fuzzing、补丁节奏

原文链接：https://arxiv.org/abs/2606.08433

开源代码：暂无

论文要点

论文简介：这是一篇专门针对 AI 代码沙箱进行系统化引擎级安全测评的研究。随着 AI 智能体被赋予越来越强的代码执行能力，”如何把不可信代码安全地关进沙箱”已经从一个未来命题，变成了眼下就要回答的现实问题。论文从主机攻击面、信息泄露、纵深防御可堆叠性、公开 CVE 历史、补丁下发节奏以及上游 Fuzzing 投入这六个维度出发，对覆盖 microVM、用户态内核与 OCI 容器三大引擎类别的五款主流 AI 沙箱产品（arrakis、e2b、microsandbox、gvisor、daytona）进行了交叉测量。

论文最终得出三条高层结论：第一，三类引擎在所有架构维度上都能干净地分开，但同一类内部的产品之间却没法这样分；第二，产品的版本绑定策略才是真正决定运营者体验的主导变量，上游修复几乎都是当天发布，但下游产品的延迟从零天到 471 天、再到完全不透明甚至无穷大；第三，整个测评中”microVM × 持续公开 Fuzzer”这个最强组合是空缺的，没有任何一款产品同时占据这两个优势。

研究目的：这项研究试图回答一个看似简单但实则棘手的问题：当我们让大语言模型生成的代码在真实生产环境中跑起来时，它真的被关在了一个安全的笼子里吗？过去关于容器与虚拟化安全的讨论多停留在单一维度，要么只看 CVE 数量，要么只看架构隔离强度，缺乏一套能把架构属性、历史信号与运营动作糅合在一起的综合判断方法。作者希望通过六轴交叉读数，给运营者提供一个真正”可操作”的判断框架，让他们能够根据自己的威胁模型挑选合适的沙箱产品，而不是被单一指标误导。

研究贡献：论文的核心贡献体现在四个层面。

首先，作者构建了一套覆盖六个引擎级维度、五种测试体裁（测量、探针、组合测试、桌面研究、元分析）、跨越三类引擎与五款产品的统一测评方法论，并且明确禁止把各维度得分加总为一个综合分。

其次，作者通过具体可重复的探针发现了多个具有重大现实意义的安全问题，包括 arrakis 默认镜像中 /dev/kvm 设备节点对客户机用户态可见、e2b 编排器默认绑定的 Firecracker 版本已停留 399 天未升级、daytona 运行器硬编码 Privileged: true 等运营级隐患。

第三，论文揭示了 2026 年 Firecracker 与 Cloud Hypervisor 同期出现 Escape 级 CVE 的”基线漂移”现象，这从根本上改写了过去”主流 microVM 没有公开宿主逃逸记录”的认知。

最后，作者把单一威胁模型拆解为逃逸抵抗、侦察抵抗、加固兼容性、补丁下发四个运营子问题，形成了一个不做综合排名但能横向比较的”威胁模型限定矩阵”。

图1：三类引擎与五款被测产品全景

背景与方法论

论文的研究框架建立在三条交叉的学术脉络之上。第一条是 2026 年发表的 Agentic AI 安全综述，它把”沙箱与能力限制”列为智能体安全的四大防御家族之一，并指出对沙箱与仿真环境保真度的测量仍是一个公开挑战。第二条是关于危险能力的紧迫性研究，包括 Google DeepMind 团队的预测——专家预估的能力阈值跨越窗口在 2025 至 2029 年间——以及英国 AI 安全研究所对推理时计算与多步骤攻击能力呈对数线性关系的测量。这些研究共同把”沙箱遏制”从未来话题拉到了当下任务。第三条是 Marin 等人 2021 年提出的四类执行环境分类法，论文沿用其类别结构并补充了 Cloud Hypervisor 和 libkrun 这两款新型 microVM。

在方法论层面，作者刻意把单一 Linux 宿主（Hetzner 裸金属、固定内核版本）作为统一测试床，把所有 SDK 版本固定，并以”创建沙箱时不传任何参数”作为默认状态。这样的安排让”产品给你什么”成为基础事实，而任何偏离默认值的发现都被记为产品级而非引擎级问题。每个维度只产出五种判定之一：pass、fail、partial、inconclusive、skipped，并明确禁止把不同维度的判定混合或求和。威胁模型也被严格限定为 AISI T0.H2.N2——单租户运营者在自有基础设施上运行不可信代码，多租户隔离、微架构侧信道、控制面攻击都被排除在外。

图2：五款产品在六大维度上的相对位置

主机攻击面与信息泄露

主机攻击面这个维度衡量的是引擎在主机内核面前暴露了多少系统调用与设备入口。作者用一个四层模型把问题刻画清楚：客户机用户态在第四层，要想真正逃逸到第一层的宿主内核，必须穿过第二层的运行时与中介。所有 1.1 探针测量的就是这条通路的宽度。具体到数据上，三款 microVM 在轻负载下分别只暴露 5、13、22 条不同的系统调用，gVisor 升到 33 条，而 daytona 在重负载下达到 62 条且总调用量高达 90 万次以上。当然，作者也提醒读者：strace 总数对 microVM 不可比，因为客户机系统调用是在客户内核里完成的，根本不会浮到宿主层面。

在 14 个内核 LPE 与容器逃逸”原语”组成的可达性目录里，gvisor 以 5/14 排在最前面，e2b 以 7/14 紧随其后，microsandbox 与 daytona 持平于 11/14，而 arrakis 以 12/14 反而垫底。arrakis 之所以排名靠后，是因为论文的探针发现客户机用户态可以直接打开 /dev/kvm，并成功调用 KVM_GET_API_VERSION 等只读 ioctl，这意味着客户机进程理论上可以调用 KVM_CREATE_VM 创建一个嵌套虚拟机，整个 KVM ABI 的内核 LPE 攻击面被向用户态打开。这是整篇论文最具体也最具操作性的一个发现。

图3：1.1 维度采用的四层主机攻击面模型

信息泄露维度通过 28 个探针在 5 款产品上跑出 140 个子检查项，结果在三类引擎之间形成了非常清晰的分层。e2b 与 microsandbox 实现了零泄露，arrakis 因为 Cloud Hypervisor 默认开启 cpu=host 透传导致 CPU 型号字符串被原样暴露，gvisor 在 /proc/meminfo 和 /sys/class/dmi 上有两个 Sentry 实现缺口，而 daytona 一次性暴露了多达 10 项主机标识，包括 CPU 品牌、内存总量、内核版本、IRQ 表、BIOS 产品名、CPU 微码版本以及四项磁盘硬件标识符。值得注意的是，论文特别强调这三种泄露的”性质”完全不同：microVM 的泄露是 VMM 配置选项的问题，可以通过修改默认参数解决；gvisor 的泄露是 Sentry 没有为这两个文件实现虚拟化；而 daytona 的 10 处泄露则不是缺口而是共享内核架构本身的”结构签名”——一个运行在容器里的工作负载，必然能看到宿主内核的指纹。

纵深防御可堆叠性

纵深防御可堆叠性这个维度专门考察运营者还能在产品默认配置之上叠加多少层 Linux 加固。论文挑选了七层：seccomp、AppArmor、SELinux、用户命名空间、能力丢弃、no_new_privs 以及 pids.max。每个单元格采用两段式判定：applied 表示引擎默认就启用了这一层，stack-redeploy 表示运营者通过 systemd 包装或守护进程配置即可叠加，not-exposed 表示必须修改产品源代码才能开启。作者特别指出，纯粹比较”已应用层数”在跨类比较时是没有意义的——gvisor 的 Sentry 本身就是由 seccomp、能力丢弃、用户命名空间组成的，那是它的主隔离机制，而 microVM 上的七层只是 hypervisor 之上的额外加固。

真正具有跨类可比性的指标是 not-exposed 单元格数，因为它衡量的是”产品到底封死了运营者多少加固空间”。e2b、microsandbox 和 arrakis 这三款 microVM 的 not-exposed 都是 0，意味着运营者可以自由堆叠所有七层。gvisor 有 1 个 not-exposed（AppArmor 字段被 runsc 在 specutils.go 里默默丢弃），daytona 则一次性贡献了 5 个 not-exposed 单元格——其中四个直接源于运行器源码 apps/runner/pkg/docker/container_configs.go 第 134 行硬编码的 Privileged: true，这一行配置同时禁用了 Docker 默认 seccomp、禁用 AppArmor、让用户命名空间不再兼容，并把 no-new-privileges 钉死为 false；第五个 pids-max 则是因为运行器的 CreateSandboxDTO 没有暴露 PidsLimit 字段，连原生的 Docker per-container 限额都用不上。论文给出了两条非常具体的修补路径——增加 DTO 字段或在守护进程默认配置里加 default-pids-limit——并测算了对应的补丁面积，是整篇论文里少见的”建设性建议”。

公开 CVE 历史与补丁节奏

公开 CVE 历史这一维度的统计窗口覆盖 2024 年 5 月至 2026 年 5 月共 24 个月。五款引擎在这段时间里共贡献了 11 个 CVE，而它们共同依赖的 Linux 内核同期累计约 3500 条记录，两者相差两个半数量级。runc 以 4 条 Escape 级 CVE 居于榜首，包括 2025 年 11 月 5 日同时披露的 procfs 与挂载竞争三连击（CVE-2025-52565、CVE-2025-52881、CVE-2025-31133），延续了 runc 历史上一贯的 procfs / mount-race 模式。Firecracker 的两条 CVE 都是 Escape 级（虚拟 PCI 越界写、jailer 符号链接写），Cloud Hypervisor 的 CVE-2026-45782（virtio-block 异步 I/O 释放后使用，CVSS v4 8.9）是该引擎首次出现的逃逸类记录，gvisor 的 3 条 CVE 则全部是信息泄露与内部逃逸，没有任何越过主机边界的记录。这与 Sentry 在系统调用进入宿主之前就拦截大部分调用的架构特性高度一致。

特别值得一提的是，libkrun 在统计窗口内的 CVE 数量为零，但论文明确把它从排名中剔除。作者用一段非常清晰的话表达了这一点：零并不等于安全，它可能意味着没有 bug、也可能意味着没人找过、还可能意味着 bug 被悄悄修了没有分配 CVE。结合 1.6 维度发现 libkrun 没有任何上游 Fuzzer，作者倾向于认为”没人找过”是最可能的解释——这就是论文中反复强调的”libkrun 单元格在结构上不可测量”问题。

补丁节奏这一维度被论文拆成上游与下游两部分。上游的所有协调披露 CVE 几乎都是当天发布修复版本，P50 与 P95 都是 0 天，gvisor 因为采用”先静默修复再走 CVE”的特殊模式，反而呈现 -165 天到 -458 天的”负延迟”。下游的图景则完全相反，跨度从 0 天一直延伸到 471 天，再到完全不透明甚至无穷大，比上游宽了整整四个数量级。arrakis 把 Cloud Hypervisor 钉在 v44.0 已经 471 天没动过，期间上游发布了 12 个版本，其中两个版本包含同期披露的关键 CVE 修复，而 arrakis 都没有跟进；e2b 自托管编排器的 Firecracker 版本绑定也已经停留了 399 天，让 CVE-2026-5747 至少 44 天没有打补丁。daytona 反而靠 Docker-CE 29.x 捆绑的 runc 1.3.5 一路保持 current 状态，是五款产品里在补丁下发这个维度上最干净的——前提是运营者使用 daytona 推荐的 docker compose 部署路径，而不是从 Ubuntu 仓库手工安装 runc。

图5：五款产品在下游补丁延迟谱系中的位置

Fuzzing 投入与跨维度交叉读数

Fuzzing 投入这一维度是论文里最具前瞻性的一项，它试图回答”还有多少未发现的漏洞潜伏在引擎里”。作者把整个调查范围分为三个等级。第一档”持续公开 Fuzzer 加仪表盘”只有 gvisor 和 Linux 内核两家入选，gvisor 在 syzkaller.appspot.com/gvisor 上长期保持公开的模糊测试操作，并且在源码树里维护了 secfuzz 库专门针对 seccomp-bpf。第二档”内嵌测试目标但缺少持续上游执行”有 Cloud Hypervisor 与 runc 两家——前者在 fuzz/ 目录里维护了 18 个 cargo-fuzz 目标但 CI 只做编译门控、不实际运行，后者通过 OSS-Fuzz 间接覆盖。第三档则是”完全没有上游 Fuzzer”，Firecracker 与 libkrun 同列其中。论文特别澄清，Firecracker 仓库里那 32 行的 docs/fuzzing.md 描述的 –features fuzzing 只是一个面向外部模糊测试的确定性构建钩子，并不是 Fuzzer 本身，AWS 内部很可能跑着内部 Fuzzer，但那不在上游公开测量范围内。

作者还指出了一个非常有意思的现象：CVE-2026-45782 这条 Cloud Hypervisor 的逃逸级漏洞其实就发生在 fuzz harness 已经覆盖的 block 目标里，但因为 CI 只运行 cargo fuzz build 与 cargo fuzz check 而不跑 cargo fuzz run，语料库并没有真正得到执行，最终是 DemiMarie 的人工审计发现了这个 UAF。这成为整篇论文里”编译门控 ≠ 持续执行”这一论断最有力的实证。

图6：可堆叠性 (1.3) 与补丁下发 (1.5) 是两个独立的运营杠杆

论文的第三章用五个交叉读数把六个维度之间的隐藏关联拎了出来。第一条交叉读数说，攻击面小并不必然意味着逃逸类 CVE 少——Firecracker 拥有全集里最紧的 seccomp 限制（只允许 55 个系统调用），但它在 2026 年依然出现了两条 Escape 级 CVE，因为漏洞就藏在 VMM 自己仍然要走的内核路径里。第二条交叉读数提醒读者，gvisor 的”先静默修复”披露模式从结构上隐藏了 Fuzzer 在 CVE 提交记录里的归因——脱离 1.5 的披露模型语境去读 1.6 的 0/3 归因率，就会误以为 syzkaller 不起作用。第三条交叉读数则把 1.3 与 1.5 划为两个独立的运营杠杆：daytona 拿到了最好的补丁节奏却给运营者最差的加固空间，arrakis 拥有强加固却拿不到上游修复。

图7：libkrun 在 1.4 × 1.6 两轴上同时返回”无信号”

威胁模型矩阵与运营者决策建议

为了避免误导运营者，作者拒绝给出一个综合排名，转而把单一威胁模型拆成四个互不相干的子问题：A 逃逸抵抗（由 1.1、1.4、1.6 共同决定）、B 侦察抵抗（由 1.2 决定）、C 加固兼容性（由 1.3 决定）、D 补丁下发（由 1.5 决定）。每个单元格只标注”qualifies、qualifies with caveats、does not qualify”三种状态，绝不做加权求和。读完这张矩阵之后会发现，没有任何一款产品在四列上同时拿到 qualifies——gvisor 在 A 与 D 上拿到 qualifies、在 B 与 C 上拿到带注脚的 qualifies，是最接近”全列通过”的产品；microsandbox 形式上在 B/C/D 上都干净，但 A 列的”残余漏洞深度不可测量”才是决定性约束；arrakis 与 e2b 都因为绑定策略在 D 列上落败；daytona 则只在 D 列上独占鳌头，其余三列全部 does not qualify。

针对每款产品，论文都附了一段”运营画像”。arrakis 是引擎层投入很到位、却被产品默认值部分抵消的典型——per-thread seccomp 与 18 个 cargo-fuzz 目标都很出色，但活跃的 /dev/kvm ioctl 暴露与 471 天的版本冻结同时拉低了 A 与 D 两列。e2b 拥有最紧的 seccomp 上限与第二好的原语可达性得分，但 2026 年连续两条 Escape 级 CVE 加上没有任何上游 Fuzzer，加上 399 天的编排器版本冻结，使它本质上和 arrakis 一样依赖 AWS 内部不可观测的 QA 能力。microsandbox 是数据最少的产品，它在 1.2 与 1.5 上都很干净，但 1.4 与 1.6 同时返回空信号，让残余漏洞深度真的”无从评估”。gvisor 是唯一在五个维度上都能站住的产品，代价是 Sentry 的内核 API 表面是有边界的，依赖 io_uring 或 userfaultfd 的应用会直接撞上 ENOSYS。daytona 则是公开主机内核给沙箱里”AI 写的代码”看的唯一一款产品，它在 4 条 Escape 级 CVE 与 10 项主机标识泄露的背景下，仅靠 Docker-CE 把 runc 自动升级到 1.3.5 这一点维持着”补丁是新的”的底线。

结论与展望

这篇论文用六个维度的交叉读数，把”AI 沙箱够不够安全”这个看似简单的问题拆解成了一组真正能落地决策的子问题。作者得到的结论与其说是”哪款产品最好”，不如说是”哪款产品适合你的运营场景”。当一个维度是引擎类决定的架构属性时（1.1、1.2、1.4、1.6），引擎类层级是主导信号；但当涉及到补丁下发与加固兼容性时，产品级选择会把同一引擎类内部的产品撕开一条很大的差距。作者最希望强调的一个发现是：整个测试集里，”microVM × 持续公开 Fuzzer”这一最强组合根本没有产品占据，这迫使运营者在”残余 bug 最浅”（gvisor）与”隔离类最强”（microVM 集合）之间做一次显式取舍。

论文的后续工作分为两条线：一条是把现有六个引擎级维度扩展到对真实部署的”主动探测”,把 1.3 里推断出来的 stack-effort 单元格升级为实测；另一条是开展所谓”二级测评”，覆盖默认配置审计、沙箱内部枚举、镜像供应链、网络出口控制、密钥处理、SDK API 表面以及组合攻击场景等七个产品级维度。同时，arrakis 嵌套 KVM 暴露与 Cloud Hypervisor Fuzz 执行提案被列为最具影响力的两条具体改进建议，前者将被报送给 arrakis 维护者进入负责任披露流程，后者则建议上游 Cloud Hypervisor 团队从 GitHub Actions 定时任务、ClusterFuzzLite 集成到 OSS-Fuzz 申请三档路径中择一推进。这篇论文用一种克制而严谨的方式提醒所有运营者：AI 沙箱的安全不是一个等级，而是一组互不相干的运营杠杆，谁也别想用一个分数说服自己。

-End-

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全极客 知识分享者 知识分享者《【论文速读】| AI代码沙箱：安全性比较研究》