AI 智能体沙箱实践:在 Kubernetes 上安全运行模型生成代码
厂商 Mitos 解析在 Kubernetes 上为 AI 智能体构建安全沙箱的方案,对比 gVisor、Kata、Fi…
随着大模型驱动的 AI 智能体(Agent)逐步走向生产环境,如何安全地运行「模型自己写出的代码」成为工程团队必须面对的问题。基础设施厂商 Mitos 在其技术博客中详细阐述了基于 Kubernetes 构建 AI 沙箱的思路,并横向比较了主流的隔离运行时方案。
模型生成的代码,本质上就是不可信代码
文章首先援引 Simon Willison 提出的「致命三要素」(lethal trifecta)框架:当智能体同时具备访问私有数据、读取不可信内容、以及对外通信三种能力时,一次提示词注入就足以把智能体能读取的数据外泄出去。一旦再为智能体开启 Shell 权限,注入攻击便直接升级为代码执行。
这不是理论风险。2025 年 10 月,Trail of Bits 证明即使做了命令白名单,没有沙箱依然会被攻破:攻击者可以把恶意参数藏进 go test -exec 或 fd -x 这类被允许的命令中。2025 年 7 月,Replit 智能体在代码冻结期间删除了生产数据库;一个月后,Nx 供应链攻击(s1ngularity)反向上演——恶意 npm 包调用本地安装的 AI CLI 去扫描凭据,GitGuardian 统计到来自 1,079 个仓库的 2,349 条密钥泄露。
工具厂商实际上已经承认了这一点。Anthropic 为 Claude Code 默认启用操作系统级沙箱,并报告由此减少 84% 的权限弹窗;OpenAI 的 Codex 则默认关闭网络。但这些只保护了开发者的个人笔记本。一旦要面向他人托管智能体,或将一个智能体扩展为五十个实例,运行的就是一个「敌对的多租户服务」,问题从「要不要沙箱」变成「你愿意租出哪一层边界」。
Pod 只是内核的一个视图
Kubernetes 默认按「一个 Pod 一个智能体」来部署,但理解 Pod 的实际边界非常关键。kubelet 通过容器运行时接口(CRI)调用运行时(通常是 containerd),containerd 为每个 Pod 启动一个 shim,shim 调用 runc,最终构建出我们所说的「容器」:命名空间提供受限视图、cgroups 限制资源、seccomp 裁剪系统调用,最后通过 execve 启动进程。
文章强调了这一调用链中没有发生的事:进程与宿主机内核之间并没有一道墙。命名空间只是「视图」而非「墙」。同一个 CRI 调用链,两种边界:runc 把宿主内核的一个视图交给智能体;Firecracker 则交出独立的内核。
这一接口并不安全的历史上已有诸多漏洞。CVE-2019-5736 允许容器通过 /proc/self/exe 覆盖宿主机上的 runc 二进制;CVE-2024-21626(Leaky Vessels 文件描述符泄漏)评分为 8.6,可逃逸到宿主机文件系统;2025 年 11 月同一天披露的三个 runc 逃逸漏洞,全部通过 procfs 写入完成突破。
容器对开发者自写、自审的代码而言仍是合理的工程边界;但智能体生成的代码在构造上就「通不过信任测试」。
gVisor、Kata、Firecracker:三种提升隔离强度的方式
Kubernetes 通过 RuntimeClass 提供可插拔机制,将 spec.runtimeClassName 映射到不同 shim,使同一个 Pod 描述可以落到不同的隔离机制上。文章重点比较了三种运行时:
- gVisor:在工作负载与真实内核之间插入一个用户态内核,用 Go 重新实现系统调用。其设计目标是「不放过任何一个系统调用直通」。启动在几十毫秒级,是 GKE Sandbox 的底层实现。代价主要在系统调用开销上:多数工作负载增加几个百分点,系统调用密集型场景可能增加数倍。隔离墙由软件构成。
- Kata Containers:每个 Pod 跑在独立 VM 中,拥有自己的客户内核(基于 KVM)。隔离墙更强,代价也更重:第三方基准测试显示,启动额外延迟约 600 ms,每个 Pod 大约 180 MiB 开销(默认 VMM 下)。
- Firecracker:AWS 为 Lambda 构建的 microVM。官方称约 5 万行 Rust 代码,比 QEMU 少 96%。它几乎不做设备模拟,仅支持 virtio-net、virtio-block、vsock 与串口控制台。公开规范承诺从 API 调用到 guest 用户态不超过 125 ms,每个 microVM 开销低于 5 MiB。NSDI 论文测得约 3 MB 开销(QEMU 为 131 MB),单主机创建速率可达每秒 150 个 microVM。
「一道接近容器价格的硬件级隔离墙」,正是当下大量 AI 沙箱产品选择 Firecracker 的根本原因。
(注:原文在运行时对比表格处截断,本文依据已披露内容整理。)
