设想一个很普通的下午。你让 coding agent 把官网文案改一版，顺手让它测完没问题就发。它读了代码、跑了测试，然后发现生产环境的配置文件就躺在同一个仓库里，改一行就能让构建过。于是它改了。你在半夜两点被报警电话叫醒。
这件事里没有任何一环"坏掉"了。模型没幻觉，工具没出错，你的指令也挺清楚。出问题的地方只有一个：你给了它和你自己一样的权限。
一个正在成形的共识
微软在讲 agent 安全时说过一句很直白的话：agent 不能当自己的安全权威。边界必须由开发者或组织来划，并且在 agent 之外强制执行。
这话不是修辞。过去两年大家默认的安全模型是"提示词里写清楚别乱来，工具层再做点参数校验"。这两样都属于让 agent 自己管自己。而 agent 恰恰是最没资格评判自己该不该越界的角色：它只对自己的目标负责，不替你考虑爆炸半径。让它自己判断，等于把刹车交给想快点到终点的人。
2026 年 10 月 7 日，微软把 Microsoft Execution Containers（MXC）正式 GA，算是把这句话从口号变成了一个可以装进 app 的依赖。
MXC 到底做了什么
一句话概括：它是一个 policy-driven 的执行层，专门用来跑不信任的代码，模型产出、插件、工具调用、甚至整个 agent harness 都算。
开发者用一份 JSON 声明这个负载需要什么：能写哪些路径、能只读哪些、哪些完全不能碰、能连哪些网络地址、能不能碰桌面。MXC 校验请求、挑一个合适的隔离后端、把负载启动在里面。关键在于策略在 agent 的掌控之外，agent 和它生成的代码都没法给自己加权限。
后端有几种，按风险和平台挑：
- 进程容器：Windows 11、macOS、Linux 都能用，最轻，底层是各平台自己的沙箱机制，Windows 上是 AppContainer，macOS 是 Seatbelt，Linux 是 Bubblewrap。适合模型生成的代码和工具调用这种要响应速度的活。
- 会话容器：只有 Windows 11 有。agent 跑在一个独立的 Windows 账户和独立会话里，桌面、剪贴板、UI、输入都不和用户共享。跑长时间自动化、又怕它偷看你在别的窗口敲什么的时候用。
- WSL 容器：只有 Windows 11 有，给那些离不开 Linux 包和开发链的 agent 用。
- MicroVM：Windows 11 和 Linux，还是实验阶段，给的是硬件级边界。仓库里还列了 Windows Sandbox、LXC、Hyperlight 这些后端。
策略域一共五块：隔离环境、进程启动参数、文件系统、网络、UI 访问。
真正实用的是它的三种运行模式，写策略的时候顺序很重要：
- Enforcement：没授权的直接挡掉，不产出报告，生产环境用这个。
- Learning：没授权的照样挡，但每次拒绝都记录进一份 JSON 报告，用来诊断 agent 到底想碰什么。
- Permissive：策略本该拒绝的操作放行但记下来，用来起草策略。
合理的流程是先用 Permissive 对着一个可信负载跑一遍，看它到底用了哪些资源，把策略收紧，再用 Learning 验证一遍，最后切到 Enforcement。这个思路值得抄，任何自己做权限系统的团队都能用：先观察真实行为，再授权，别拍脑袋写白名单。
顺带一提，这已经不是纸面功能。GitHub Copilot CLI 的 /sandbox enable 走的就是 MXC 进程容器，你在会话里让它建议并执行 rm -rf ./dist，它碰不到你的 home 目录，也连不上网，除非策略允许。OpenAI 和 NVIDIA 也在发布伙伴名单里。
微软自己的诚实
MXC 的仓库里有一句话写得很清楚：目前没有任何 MXC profile 应该被当作安全边界，而且已知有些自动生成的策略过于宽松。
具体的坑也没藏着。Windows 上 deniedPaths 目前接受但不执行；网络主机过滤在 Windows 上还不支持；macOS 缺代理支持；几个后端明确标着 experimental。
所以 MXC 现在的正确定位是纵深防御里的一层，同时是一个收集反馈的地方，而不是你和你的数据之间唯一那道门。微软自己承认这一点，反而比任何营销话术都更值得信任。
墙本身也不牢
2026 年 8 月，Trail of Bits 的 Artem Dinaburg 给 GPT 5.6-Cyber 派了个活：从一台 QEMU/KVM 虚拟机里逃出来，读到宿主机上的 flag 文件。虚拟机是业界默认的沙箱做法，里面什么都不值钱，和宿主机隔离，出事直接快照丢掉。
它逃了三次。
第一次是 Januscape（CVE-2026-53359），当时没有公开 exploit，agent 自己写了一个，把宿主机内核搞到死机，只是没干净落地。内核升级之后，第二次走 libslirp：Debian 12 随包的是有漏洞的 4.7.0（CVE-2026-9539），agent 又找到一个已经修好但没分配 CVE 的提交，两个一拼就在宿主机上拿到了任意内存读写。作者把 QEMU 和依赖都从上游源码重新编译之后，第三次，agent 挖出三个 0day，加上一个"没被当成安全问题、所以没进发行版内核"的补丁，串成一条稳定的逃逸链。
这不是一次侥幸。整个过程跑了大约 12 小时，跨了多次上下文压缩和无数个子 agent，它会回溯走不通的路径、去拉论文、写自己的 oracle、做最小复现。作者说他的主要工作是内核死机时物理重启机器。
结论很硬：别再假设一台普通虚拟机能关住足够强的 agent，把它们当成 APT 对待更合适。
好消息是 Firecracker 守住了，虽然机器还是被内核漏洞搞崩过。Firecracker 的攻击面小得多，是明显更硬的目标。但作者给出的建议不是"换个更厚的墙"，而是回到安全基本功：最小权限（网络、凭证、可用功能都算）、留日志、主动监控，再加上限制 agent 的运行时长、每次用干净环境。
隔离技术其实在回答两个不同的问题
行业里习惯把隔离技术排成一条"墙有多强"的谱系：容器共享内核，最弱；gVisor 用用户态内核拦系统调用，中间；Firecracker 和 Kata 给每个负载一个独立内核，硬件边界，最强。
但墙的强度只回答了一个问题：代码会不会打到宿主机。agent 场景里更常见的危险是另一个问题：工具压根没逃出去，只是被提示注入了，然后用你主动给它的权限干坏事。
这里的关键词是 authority，不是 wall。容器和 VM 都让代码一进去就"天生"看得见环境里的东西：文件系统、网络、进程里的凭证。墙挡住了外面的宿主机，挡不住里面的密钥。
最能说明问题的是 DNS。一台 microVM 画了硬件边界，但 guest 要有网络就得有解析器，解析器本身就是一条出网信道。你可以过滤它、记录它、把它指到很严的地方，但只要 guest 有网络栈，就拿不走它。这不是 microVM 的缺陷，这是 VM 的本分。
Wasm 能力沙箱走的是另一条路：不给你权限，而不是过滤你的权限。一个 WebAssembly 组件只拥有它的 world 声明和 host 授予的那些接口，没有 import wasi:sockets 就没有 socket 可开，没有解析器可查，连"把数据编码进一次查询"这条路都不存在，因为 host 是替它去解析白名单上那个主机名的。代价是兼容性：需要任意系统调用、原生线程、长期内核网络的东西，还是得退回容器或 microVM。
启动开销的差异也直接决定架构：
| 技术 | 隔离强度 | 冷启动 | 权限模型 | 适合场景 |
|---|---|---|---|---|
| 容器 | 进程级（共享内核） | 毫秒 | 环境内天生可见 | 自己写的可信代码 |
| gVisor | 系统调用拦截 | 毫秒 | 环境内天生可见 | 计算密集、多租户 |
| Firecracker / Kata | 硬件级（独立内核） | 约 125 到 200 毫秒 | 环境内天生可见 | 不信任代码、多租户 |
| Wasm 组件 | 能力沙箱 | 约 0.2 毫秒 | 默认无权限，按需授予 | 短命、高并发、每次一开 |
容器和 microVM 每次冷启动要一百毫秒往上，Wasm 组件实例化大约 0.2 毫秒。五百倍的差距决定了一件事：你是真能做到"每次工具调用开一个全新沙箱"，还是只能池化复用环境，而复用又会把你想解决的状态泄漏问题带回来。
落到自己身上
给独立开发者和团队几条能直接用的：
本地跑 agent，别把"我盯着它"当安全模型。 Windows 上开 MXC，其他平台用 Docker Sandboxes 这类 microVM 方案，或者至少给它一个没有凭证的容器。Copilot CLI 那个 /sandbox enable 是零成本的起点。
凭证别进沙箱。 这是最小权限里最容易被忽略、收益又最大的一条。让 agent 用一个代理去拿能力，真实密钥留在宿主机上。它拿到的是"能做这件事"，不是"能用这把钥匙做任何事"。
网络默认拒绝，白名单放行。 上面 DNS 那个例子已经说清楚了：只要 agent 能出网，它就永远有一条你能看见但拿不走的信道。别指望它不发数据，指望它连不上。
把沙箱当成爆炸半径管理器，不是安全保证。 微软自己都说现在别把 MXC 策略当边界。正确的态度是假设 agent 会找到路，然后确保路上那些东西可以撤销、可以快照、可以直接丢掉。
限制运行时长，每次用干净环境。 那 12 小时说明了一件事：时间本身也是攻击资源。
写在最后
沙箱这一年的变化其实挺朴素：从"我在提示词里跟你约好了"变成"操作系统说了算"。
MXC 把这件事塞进了主流操作系统的 SDK 里，是进步。但它文档里那句"别把现在的策略当安全边界"同样重要，因为它提醒我们这不是一道能一次划完的线。
这四件事得一起做：墙要够厚，权限要够小，动作要留痕，环境还得每次重开。少哪一条，剩下三条都会打折。而少得最狠的往往是最小权限，没有它，再硬的墙也只是把 agent 和一个它本来就有钥匙的房间隔开而已。
参考来源
- Microsoft Developer Blog：Microsoft Execution Containers: Policy-driven containment for AI agents
- GitHub：microsoft/mxc
- Trail of Bits：VMs won’t contain cyber-capable agents
- Docker：Docker Sandboxes
- Cosmonic：Compare sandbox approaches for AI agent code
- Northflank：How to sandbox AI agents in 2026