Coding Agent 沙箱化:从信任假设到边界工程的范式转移
2026 年下半年,Coding Agent 的安全治理正在经历一次根本性的范式转移:从"Agent 是不是可信的"转向"即使 Agent 是不可信的,Agent 能造成的损害有多大"。这个转移直接体现在行业里多家头部厂商发布的工程实践上 —— 其中一篇公开博客把这种思路概括为"把 AI Agent 当作不可信代码来执行",给出了五个具体的边界设计:Compute、Host、Network、Resources、Lifecycle。这五个边界一起定义了 Coding Agent 在生产环境里能做什么、不能做什么、能影响什么、不能影响什么。
这条工程新基线的本质是把 Coding Agent 看作一段不可信的输入数据,而不是一个可信的工具。这是过去几年 Agent 工程化里最重要的安全转向之一 —— 因为传统的 IDE 编程模式下,程序员写代码 → 编译器运行 → 程序员调试,中间每一步的输出都是"信任"的;而在 Coding Agent 模式下,Agent 写代码 → 沙箱执行 → 人工监督,中间每一步的输出都必须"假设 Agent 可能出问题"。这种信任假设的转移,对企业 IT 的沙箱设计提出了明确的新基线。
从共享内核到 microVM:沙箱光谱的工程选择
Coding Agent 的沙箱化不是一个二元决策,它有一个完整的光谱,从 Level 0 的"完全不隔离"到 Level 5 的 WebAssembly 隔离。每个 Level 在隔离强度、性能开销、运维成本上有不同取舍。
Level 1 的容器隔离(Docker / LXC)是最常见的起点,但它的根本局限是"共享内核" —— 同一台物理机上所有容器跑同一个 Linux 内核,任何一个未修补的内核 CVE 都会同时攻破所有容器。容器隔离适合可信代码在单租户内部环境,但不适合多租户的 Coding Agent 场景,后者会因为某个用户上传的代码而影响其他所有用户。
Level 4 的 microVM 隔离(Firecracker)是 Coding Agent 在多租户场景下的当前事实标准。AWS 用 Firecracker 跑 Lambda,每天处理几十万亿次调用。每个 microVM 有自己独立的 Linux 内核、只暴露四个虚拟 IO 设备(virtio-block、virtio-net、serial、keyboard)。攻击面从 QEMU 的几百个虚拟设备压缩到四个,内存开销每个 VM 不到 5 MiB,冷启动不到 125 毫秒。这种隔离强度足以承担生产环境的多租户 Coding Agent 负载。
Level 3 的 gVisor 是介于容器和 microVM 之间的中间方案。它把 Linux syscall 表面在用户空间重新实现(Sentry 进程),guest syscall 在到达 host kernel 之前被截获并转换。这种设计的攻击突破需要先打破 Sentry、再击破 seccomp 防护,有两层独立防线。性能开销在 I/O 重负载下 10% 到 30%,但启动毫秒级。gVisor 适合"没有嵌套虚拟化能力的多租户 Kubernetes 部署"。
五边界框架:从单点防御到系统级隔离
把"当作不可信代码来执行"这个原则落到工程上,需要明确的边界设计。一份公开博客给出了五个边界的具体定义:Compute 边界用 microVM 提供独立的执行环境、内存和文件系统;Host 边界通过 Firecracker 的 jailer 把 host 进程降权到非 root UID/GID,加上 per-VM 的 chroot;Network 边界通过 host 防火墙限制 outbound 到私有和基础设施地址,inbound 通过 Edge API 鉴权;Resources 边界用 cgroups 绑定 guest 内存和 vCPU 计数;Lifecycle 边界确保 sandbox 销毁时所有进程、内存、临时文件、可写 rootfs 修改全部丢弃。
这五个边界覆盖了一个 sandbox 需要解决的所有维度。Compute 和 Lifecycle 解决"Agent 能运行什么",Network 解决"Agent 能访问什么",Resources 解决"Agent 能消耗多少",Host 解决"Agent 能不能跳出边界影响其他工作负载"。任何一个维度缺失,整个 sandbox 的安全假设就会被打破。
这份工程实践里有一个值得展开的细节:Workspace 例外机制。默认情况下 sandbox 销毁时所有数据都被丢弃,但有一个明确的设计允许特定路径(`/workspace`)在 sandbox 销毁后存活,作为跨 Session 共享的持久化卷。这种"默认无状态 + 显式持久化"的设计,让 Agent 可以跨会话保留工作成果,但又不会泄露 sandbox 内部其他任何状态。这种设计哲学和传统云沙箱完全不同 —— 传统云沙箱倾向于让 sandbox 内部看起来"像一个完整机器",而 Coding Agent sandbox 倾向于"最小化持久状态"。
沙箱的隐性逃逸向量
沙箱化实施里有几个常被忽略的逃逸向量,即使沙箱本身设计正确,这些向量也可能让 Agent 突破隔离。第一是 Docker socket mount:把 `/var/run/docker.sock` 挂载进容器会授予完整的 Docker API 访问权限,这等于 host root。这种配置在开发环境里很常见,但被误传到生产环境时会造成灾难性后果,任何在容器里运行的代码都可以用它创建特权容器、读取主机文件系统。
第二是符号链接遍历。一些早期的沙箱使用简单的路径前缀检查(如 `if path.startswith("/workspace")`),但符号链接可以让 `path.realpath()` 解析到沙箱外的目标文件。一个广泛部署的 MCP 实现就因此出过事:攻击者创建一个从 `/workspace/escape` 指向 `/etc/passwd` 的符号链接,就能绕过前缀检查读任意 host 文件。正确的做法是用 `os.path.realpath()` 做真实路径解析后再做检查。
第三是配置文件投毒。一个 Agent 被 prompt injection 诱导写入 `~/.gitconfig` 或 IDE 的 hook 脚本,就能在用户下次打开编辑器时执行任意代码。这种攻击跨越了 sandbox 的文件系统边界,因为它利用的是 sandbox 和用户主目录之间的缝隙。防御办法是对 sandbox 外的所有路径使用只读文件系统挂载,而不是只阻止写特定文件名。
第四是允许运行的 escape。在一些权限模型(如 Deno 的 permission 模型)里,允许 sandbox 启动子进程会绕过能力限制。子进程继承 OS 层访问,不受 sandbox 的能力 flag 控制。如果 Agent 的工具调用模式需要执行任意二进制,无论外围 sandbox 怎么设计,本质上等同于 Level 0 的不安全环境。
从工程基线到企业落地的决策框架
把这些工程实践和隐性逃逸向量综合起来,可以给企业 Coding Agent 沙箱化划出五条决策基线。第一条基线是 Coding Agent 必须运行在 Level 2 及以上的隔离环境。Level 0 和 Level 1 容器隔离在任何生产环境都不能用 —— 它们要么没有隔离,要么只有内核共享的弱隔离。Coding Agent 生成的代码对 syscall 和文件系统访问模式不可预测,不能预先刻画,只能用强隔离来对抗。
第二条基线是多租户场景必须使用 microVM。Level 3 gVisor 在没有嵌套虚拟化的环境里是次优选择,但只要硬件支持 KVM,Level 4 Firecracker microVM 应该是默认选择。每个租户的 Agent 跑在独立的 microVM 里,内核边界、内存边界、文件系统边界全部独立。
第三条基线是网络边界必须有 host 防火墙强制。Agent 默认不应该能访问公网,所有 outbound 应该限制到私有和基础设施地址。Inbound 不应该直接暴露给 sandbox,而是通过 Edge API 鉴权后转发。这种边界设计让 Agent 即使被攻陷也不能直接外联到外部网络。
第四条基线是配置文件和持久化路径必须做白名单。Agent 能写的路径必须严格白名单,默认只有 Workspace。配置文件、IDE 设置、shell 配置这类持久化目标必须只读挂载。这条基线防止 Agent 通过配置文件投毒持续影响用户环境。
第五条基线是 sandbox 必须有清晰的销毁语义。每次 sandbox 销毁都意味着所有进程、内存、临时文件、可写 rootfs 修改全部销毁,不能"重启 sandbox 复用部分状态"。Workspace 例外必须显式声明,而且只能在一个 App 内共享,不能跨 App 共享。这种严格的销毁语义是沙箱化能持续起作用的工程基础。
从工程新基线到企业 Agent 治理
把这五条工程新基线放回企业 IT 治理的语境,可以看出 Coding Agent 沙箱化不是技术选型问题,而是治理姿态问题。企业 IT 必须接受"Coding Agent 是不可信代码"这个前提,然后用工程手段让这个不可信代码的影响范围变得可控。这种姿态决定了企业 AI 治理的投资方向 —— 不是"选择更聪明的模型",而是"为不聪明的 Agent 也能跑在安全的边界里"。
这种投资方向在 2026 年下半年变得越来越重要,因为越来越多的内部工具被 Coding Agent 改造,这些工具的工作流直接触碰生产系统。如果 Coding Agent 在生产系统里越界,代价不仅是 bug,可能是数据损坏或安全事件。把沙箱化做到 microVM + 五边界 + 严格销毁语义,是企业 IT 把 Coding Agent 从"个人效率工具"推进到"企业生产基础设施"必须接受的工程基础。
把这份认知落到企业 IT 的采购和工程预算里,就是把 Coding Agent 平台的成本评估从"模型 API 价格"扩展到"沙箱基础设施成本"。后者的预算应该按"租户数 × microVM 小时数 × 单价"来算,这个开销在长期内会显著超过模型 API 本身。但这个开销不是浪费,而是让 Coding Agent 在企业里"被允许使用"的入场券。
