SideKernel：面向 macOS 上 AI 编码 Agent 的 microVM 沙箱

macOS开发者缺少好用的本地microVM沙箱，不可信的AI编程智能体因此常直接跑在本机上。

• 场景：作者认为编程智能体是不可信组件，却在开发者终端上自主运行。作者举出的风险包括提示注入、工具误用带来的远程代码执行、数据外泄，以及按幻觉包名安装恶意软件。摘要写少于40%的用户把智能体跑在沙箱里。
• 现有不足：作者称面向本地macOS开发的开源选项又少又难用。隔离原语被分成共享内核、语言运行时和独立内核；作者引用文献称容器隔离弱于microVM，但认为Seatbelt是否更弱取决于威胁模型，该比较超出本文范围。
• 问题与信号：研究问题是哪些可用性障碍阻碍macOS开发者采用这类沙箱。作者用形成性在线调查提取障碍，并声明结果只是非正式信号，不能作统计推广。
• 本文提出：SideKernel。作者在摘要中将其描述为开源、本地、基于microVM、只为终端型AI编程智能体建造的可用安全沙箱。次要贡献是障碍的经验描述，以及对市场上同类沙箱的对比分析。
• 威胁模型：
  • 对手：沙箱内的智能体本身。它因提示注入还是自身幻觉而变敌对，作者认为与威胁模型无关，并把它当作沙箱内的完全特权主体。
  • 南向：沙箱到宿主机的通道，实现上可以是虚拟套接字或SSH一类协议。威胁单向。目标是保护宿主机运行时和未挂载文件系统；已挂载目录不在该目标内。
  • 北向：沙箱到互联网或其他外部主机的通道。威胁双向：既防沙箱内数据外泄，也防沙箱成为对外攻击的跳板，并保护外部实体。
  • 覆盖：作者称控制同时针对两条边界，但并不对等。作者举OpenAI智能体绕过北向控制、逃出沙箱并到达互联网的事件，说明沙箱化强智能体并不简单。

隔离原语与云上microVM

• 三类边界：作者按安全边界所在位置分成共享内核（Linux容器、bubblewrap、Landlock、Seatbelt）、语言运行时（WASM、Chromium site isolation、JVM）和独立内核（完整虚拟机、unikernel、microVM，例子包括Firecracker与Kata）。
• 云上做法：作者称许多云厂商用独立内核隔离不可信代码，并举AWS用Firecracker跑Lambda与Fargate，以及E2B、Vercel Sandbox等托管平台使用microVM。
• 强度判断：作者引用文献称基于容器的隔离弱于microVM隔离，同时写明对Seatbelt等策略型、内核执行的原语，这个判断并不简单，需要单独研究。

共享内核或语言级的智能体沙箱

• 厂商原生沙箱：作者把Claude Code、Codex、Gemini、Grok Build的原生沙箱，以及依赖Seatbelt和Landlock的Nono、Agent Safehouse等，归入当前市场的主体，即OS隔离或语言级隔离。
• 未作逐篇优劣对比：正文是按隔离类型归类，没有对上述每一篇给出相对SideKernel的实验对比。

有microVM但未同时满足纳入条件的系统

• 远程或非开源：E2B、Daytona被作者归为无本地部署的SaaS；表注写Daytona自2026年6月起转入私有仓库。Docker Sandboxes在Table I的开源一栏为未通过。
• 用途不同：Lima、Apple container、OrbStack被作者归为通用虚拟机运行时，而不是专用智能体沙箱；CUA主要做computer use，启动的是完整macOS虚拟机。
• 交互形态：作者称另一些系统主要面向可编程SDK智能体或MCP网关，而不是终端型编程智能体，文中点名的引用包括Microsandbox与Arrakis。后文仍把满足交互式shell的Microsandbox纳入对比。

基线与作者的定位

• 相近名单：作者称就其所知，同时满足开源、本地、面向终端型AI编程智能体、microVM硬件虚拟化、macOS原生这五条的，只有SmolVM、Microsandbox、Shuru和VibeBox。这五条即后文的IR-1至IR-5。作者声明这不是对全部沙箱的穷尽普查。
• 基线方法：对比时故意不过滤开源，以免排除Docker Sandboxes。进入后续打分讨论的是Docker Sandboxes、Microsandbox、SmolVM、Shuru、VibeBox和SideKernel。基准不是公开命名数据集，而是调查障碍导出的23项能力测试。
• 定位：作者把SideKernel放在“只为AI编程智能体建造、且把可用安全当作核心论点”的本地microVM沙箱上，并用纳入标准找出相似系统再打分。

整体是先用调查锁定三条可用性障碍，再做成有倾向的SideKernel：默认全拒绝被有选择地放松，以换可用性；部分选择在Table II里记为风险接受。

障碍如何变成设计目标

• 三条障碍：宿主机与沙箱的文件共享（UB-1）、端口与联网（UB-2）、环境供给（UB-3）。作者称安装、多沙箱管理、可靠性与性能也被提到，但为了实践课期限内可完成，开发与评测只基于这三条。
• 未实现目标：Table II把任意用户秘密外置再注入、北向任意目的地allowlist、沙箱内文件与进程事件日志、对外端点日志标为未实现，并指向未来工作。

架构与凭据边界

• 虚拟化：VMM用Swift写在Apple Virtualization framework上。Guest使用Kata Containers的预编译精简Linux内核，以及首次运行时构建的Ubuntu根文件系统，二者都钉住SHA256。
• guest代理：一个零依赖Rust程序作为PID 1，用VirtioFS挂载宿主机文件系统，做端口探测与转发，经vsock与宿主机通信，并暴露伪终端。每次启动或重启都会拉起新的临时microVM。
• 凭据：沙箱外有小型凭据代理，拦截智能体API请求并注入凭据。作者称凭据因此不留在沙箱内；脚注例外是沙箱内首次认证时读入凭据，随即从沙箱删除并存入macOS Keychain。当前安装方式是Makefile。

三条障碍上的机制

• 文件与剪贴板：运行sidekernel（别名sk）后，当前目录经VirtioFS隐式双向挂载。作者承认这与常见的默认拒绝不一致，但与Claude在宿主机上的用法一致。未挂载路径用guest内命令sk-drop，加上沙箱外的显式批准；Claude带有如何使用该命令的预置说明，拖放也可触发。宿主机剪贴板可粘贴进SideKernel，Claude会话还可粘贴图片。Table II把挂载目录的风险写为：智能体可以读、改或破坏其中任何内容。
• 端口与北向：新打开的端口由Rust代理发现，并自动暴露到宿主机127.0.0.1。Table II把相应风险写为：恶意智能体可向宿主机开放端口、暴露恶意服务。北向NAT kill-switch由guest内命令开关；打开后阻断北向出站，默认只放行Claude官方推理端点，以便继续推理；关闭并恢复流量需要用户显式批准。
• 环境与认证：guest内save把安装和配置写入OverlayFS个性化镜像，跨重启、跨沙箱保留。启动前从宿主机复制Claude的skills、plugins和agents。宿主机Claude若已认证，用户批准Keychain访问后，沙箱内会话共用该认证；沙箱内认证也会回写宿主机。宿主机可直接运行sclaude，作者解释为Secure Claude或SideKernel Claude。首次启动时预装最新版Claude。

对比时怎样算通过

• 纳入：IR-1开源或源码可得、IR-2在用户自己的机器上执行、IR-3提供给CLI编程智能体的交互式shell、IR-4以精简内核做硬件虚拟化、IR-5能在macOS ARM上运行。作者把性能当作隐含而非点名的要求，因此排除完整虚拟机平台。对比过滤只用IR-2至IR-5。
• 判定：每项能力测试的成功标准在该轮评测开始前固定。只有沙箱自身、能从官方文档或界面发现的内置机制才算通过；做不到，或只能绕过沙箱，算不通过。作者举例：在宿主机防火墙上手工封网不算沙箱的内置阻断。
• 记分：二元结果故意不看难易。摩擦笔记分Native、Frictionless（再加1至2个动作）和with friction（3个及以上动作），不改写通过与否。能力分是各项等权相加。作者称它是信号，不是定论性度量，应与摩擦笔记一起读。Fig. 2把对比分析画成回灌到SideKernel开发的回路；IV节又把本次评测写成针对最终原型的总结性比较。

实验设置

• 调查：在线Google调查，先筛掉未使用AI编程智能体者，再分现用、曾用、从未用。招募来自作者的职业网络、Zurich的JFloor，以及Georgia Tech实践课CS-6727论坛和Slack。作者称这是非正式调查，结果当轶事信号，不作统计推广。完整问卷在附录B，自由文本只做汇总。
• 对比对象：按IR-2至IR-5滤出Docker Sandboxes、Microsandbox、SmolVM、Shuru、VibeBox和SideKernel（Fig. 3、Table I）。IR-1未用于过滤。VibeBox在两台macOS Tahoe 26.2（M1与M4）上按README安装后仍无可用沙箱，三张结果表均为破折号。
• 被测智能体：能力测试里实际调用的是Claude Code。作者称Docker Sandboxes预装Claude Code、Codex、Gemini CLI、GitHub Copilot、opencode等，SideKernel目前只支持Claude Code。论文未写被测Claude的模型版本。
• 测试与指标：23项能力测试，UB-1共9项、UB-2共5项、UB-3共9项，定义在附录A。指标是内置机制的通过/不通过，以及不加权通过数。模板目录含仅宿主机的external-file.txt、10GB的big-file.txt，以及挂载目录中的requirements.txt（含numpy）、workspace-file.txt和无执行位的shell.sh。
• 评审：评估者是作者一人。论文未报告重复次数，也未使用LLM评审或数值阈值。摩擦笔记不改变二元结果。
• 机器：作者在VIII-C写SideKernel设计给单台macOS，实际只在M1与M4、且只在Tahoe 26.2上测过。

主结果

Swipe horizontally to read the table

沙箱	UB-1（Table III，共9）	UB-2（Table IV，共5）	UB-3（Table V，共9）	合计（VIII-A，共23）
Docker Sandboxes	6	5	8	19
SideKernel	8	3	8	19
Microsandbox	5	3	4	12
Shuru	5	3	4	12
SmolVM	5	3	4	12

VibeBox未列入，因为论文未给出通过数。

• 作者的解读：作者称在所测可用性障碍内，Docker Sandboxes与SideKernel得分最高；这不是“哪个沙箱更有用”的可推广结论，应与摩擦笔记一起读。
• 目标不同：作者称Docker面向企业部署和多沙箱编排；Shuru是由宿主机上的智能体调用的Claude skill，把工具运行隔离进沙箱；SideKernel尽量复现宿主机体验；Microsandbox与SmolVM以可编程SDK为主，CLI是附属。
• 作者点名的差别：作者称只有SideKernel做到guest内或拖放的外部文件投入、新开端口自动转发、Claude会话双向剪贴板，以及与宿主机同步认证。作者同时称Docker在可观测性、审计、治理、细粒度策略、终端界面、多沙箱管理和凭据上更全，其中一部分超出本研究范围。

用户调查

• 测了什么：80名受访者；其中68人使用AI编程智能体（85%）。智能体为多选。沙箱状态以这68人为分母。
• 结果：macOS用户占60.3%。Claude Code为59/68（86.8%），Codex 26/68（38.2%），Copilot的agent mode 23/68（33.8%），Cursor 13/68（19.1%），Gemini CLI 10/68（14.7%）。当前沙箱用户26/68（38.2%），曾用7/68（10.3%），从未用35/68（51.5%）。摘要写的是少于40%。现用加曾用33人中，从零配置与端口/localhost/联网各8人（24.2%），文件共享难或慢7人（21.2%），多沙箱管理与初次安装各5人（15.2%）（Table IX、Fig. 4）。现用者26人中，9人（34.6%）勾选No significant difficulties。
• 作者的解读：样本偏技术，网络安全角色为23/68（33.8%），作者概括为约三分之一。Claude Code占优，使作者把原型收到Claude Code。从未使用者35人中，21人（60%）从未考虑，9人（25.7%）认为安全收益不值付出。自由文本被作者归纳为：沙箱应近乎不可见、环境供给可复现，以及策略粒度与可观测性重要。

分项通过与例外

• UB-1（Table III）：已打分的五家在T3（host到sandbox的inode通知）均为未通过，作者未另给解释。剪贴板T5、T6仅SideKernel通过。权限位跨南向传递在Microsandbox与SmolVM为未通过，Shuru与Docker为通过。未挂载文件传入在Shuru为未通过，在Docker、Microsandbox、SmolVM为通过但作者记为有摩擦。
• UB-2（Table IV）：运行中端口转发仅Docker与SideKernel通过；其余三家须在启动前指定端口。DNS连接日志仅Docker通过。出站阻断五家均为通过，SideKernel靠in-guest kill-switch；出站allowlist仅SideKernel未通过。作者称其他沙箱有带allowlist的细粒度北向控制，SideKernel没有那种粒度。Docker的allowlist可在其TUI里于运行时改，并列出沙箱联系过的域名。
• UB-3（Table V）：凭据继承仅SideKernel通过；自定义秘密库仅Docker通过。智能体预装仅这两家通过。配置、包安装、git可见性和检查点持久化在Shuru、Microsandbox、SmolVM为部分通过：T3至T6通过，T7与T8未通过。作者称这三家的配置与包持久化可行，但有摩擦；Docker与SideKernel可在运行时做跨重启保留，并记为frictionless。技能、插件和agents从宿主机继承，作者称仅SideKernel提供。

其他消融与分析

• 论文未报告对内核、挂载方式或杀开关取值的消融。
• 现用者工具（n=26，Table IX）：Docker Sandboxes 12/26（46.2%），完整虚拟机9/26（34.6%），Nono.sh 7/26（26.9%）。
• 从未使用者原因（n=35，Table IX）：从未考虑21/35（60.0%），不知道好的选项11/35（31.4%），收益不值付出9/35（25.7%），认为智能体自带沙箱已够7/35（20.0%）。
• 曾用者先前工具（n=7，Table IX）：Docker Sandbox 3/7，完整虚拟机2/7，其余列出的选项各1/7。
• 摩擦分级不改分数：Native、Frictionless（额外1至2个动作）、with friction（3个及以上）（IV-D）。
• Table II未实现项没有对应的能力测试分数：任意秘密外置注入、任意目的地allowlist、沙箱内事件日志、对外端点日志。

作者指出的局限与后续方向

• 评估者偏差：比较分析的开发者同时是评估者。作者写明已用固定成功标准、只按内置能力打二元分、可审计测试和标准化摩擦笔记来降低偏差，并称更好的做法是多名用户，但这在实践课期限内不可行（IX）。
• 问卷与抽样：问卷由开发者设计，封闭题会把受访者锚到预设选项；自由文本和其他选项被作者当作缓解，而不是消除。样本偏向有安全意识的受众。作者称真实采用率大概会低于调查记录的38.2%，原文用significantly lower（IX）。
• 样本与研究地位：N=80，其中33人为现用或曾用沙箱用户。作者称这对形成性、方向性信号可能够用，但偏低；调查是非正式实践课研究，未做Georgia Tech IRB，不是为产生可推广知识而设计（IX）。
• 计分：作者称测试测的是沙箱如何应对调查中的可用性障碍，不是一般意义上的可用性。二元分看不见摩擦，也不按用户实际在意的程度加权，因此结果是近似（IX）。
• 平台、评审与产品状态：作者称SideKernel是macOS上的Linux microVM，不适合测试原生macOS SwiftUI，部分macOS终端命令在沙箱内不可用；与Seatbelt等其他隔离原语的对比被刻意留在范围外（IX）。VIII-C另写：只在M1与M4、Tahoe 26.2上测过，可能仍有未发现的bug；安全来自架构论证，实现未做正式安全评审；尚未公证、为自签名，开箱无可观测性，也没有企业级日志、声明式策略和集中治理。
• 后续方向：作者计划用完整网络代理替换NAT kill-switch，以做细粒度allowlist，并由此做DNS可观测；南向剩余工作是Claude以外的通用凭据库；再支持Codex、Microsoft Copilot等更多智能体（X）。Discussion写作者计划开源SideKernel，以此区别于免费但闭源的Docker Sandboxes；Table I则把SideKernel的IR-1标为通过。

实验覆盖范围

• 用户调查为80人，其中AI编程智能体用户68人，现用或曾用沙箱者33人；渠道为作者职业网络、Zurich的JFloor，以及Georgia Tech CS-6727论坛和Slack（V，附录B）。
• 对比名单是通过IR-2至IR-5的Docker Sandboxes、Microsandbox、SmolVM、Shuru、VibeBox和SideKernel；开源条件未用于过滤（IV-B，VII，Table I）。
• 能力测试为23项，分UB-1、UB-2、UB-3；成功标准在评测前固定，只认官方文档或界面中的内置机制，并附摩擦笔记。作者在IV-E写这些测试广泛但非穷尽。模板目录包含10GB文件和含numpy的requirements.txt（IV-D，IV-E，附录A）。
• VibeBox在两台macOS Tahoe 26.2（M1与M4）上未能得到可运行沙箱，表中为破折号（VII）。SideKernel的运行说明写的是M1、M4与Tahoe 26.2（VIII-C）。
• 论文未报告能力测试的重复次数。论文把Seatbelt与microVM在何种威胁模型下谁更安全留作独立问题，不在本文评测内（I-C，IX）。

SideKernel是面向macOS终端型AI编程智能体的本地microVM沙箱，论点是可用安全。

矛盾在于智能体不可信，却在开发者终端上自主运行。研究问题是哪些可用性障碍妨碍采用。摘要写少于40%的用户把智能体跑在沙箱里；68名智能体用户中，当前使用者为38.2%（Table IX）。

作者用调查锁定文件共享、联网和环境供给，再做成有倾向的设计：当前目录隐式挂载、新端口转到127.0.0.1、凭据经沙箱外代理注入、北向杀开关默认只放行Claude推理端点，并用个性化镜像保留环境。作者的安全论据是架构性的：落到宿主机需要逃出VMM；这不是正式安全评审的结果。

• 从未使用者占51.5%（35/68）。现用加曾用33人中，从零配置与端口/联网各8人（Table IX）。
• SideKernel与Docker Sandboxes各通过19/23项，SmolVM、Microsandbox、Shuru各12/23（VIII-A）。VibeBox无分数。
• 文件共享SideKernel为8/9、Docker为6/9；联网SideKernel为3/5、Docker为5/5（Table III、IV）。
• 剪贴板、认证继承和技能迁入仅SideKernel通过；DNS日志、allowlist和自定义秘密库仅Docker通过（Table III至V）。

作者称SideKernel应对了调查中的许多障碍，并称它是目前唯一同时做到Claude Code双向剪贴板、运行时自动端口转发、Keychain认证衔接和技能自动迁入的本地microVM沙箱。作者称在所测障碍内二者得分最高，但Docker的可观测性、治理和凭据更全。作者认为本地macOS上的终端编程智能体沙箱仍少。作者计划开源，并补网络代理、通用凭据库和更多智能体。