如果你正在本机跑 Claude Code、Codex 这类编码 Agent，并且动过"让它放开手脚干活"的念头，今天这篇值得看完。
今年上半年，Agent 沙箱这条线相当热闹：Kubernetes 社区推出了 AgentSandbox，给"怎么在集群里跑 AI Agent"立了个 SIG 级项目。知乎B站有人专门出视频，讲怎么给不可信代码套上笼子，标题很直白：别让 Agent 删了你的库。哔哩哔哩开源沙箱里最火的 E2B，源码也被人逐仓库拆开研究。知乎
国内云厂商也下场了：腾讯云开源的沙箱引擎 Cube Sandbox，基于 RustVMM + KVM，号称 60 毫秒内创建硬件级隔离沙箱，单实例内存开销不到 5MB。哔哩哔哩Docker 自己的答案，是 Docker Sandboxes——把 Agent 塞进独立的 microVM 里干活。这个产品 2 月底发布，官方定位是"第四级别的沙箱解决方案"，为AI智能体提供基于专用轻量级微虚拟机 MicroVM 的解决方案。知乎至今还在 Beta，变化不小，实测者手里的 sbx CLI 已经迭代到 v0.38.0，速度不慢。
它产品页上的卖点很直白：“YOLO mode, safely”——不用逐条确认，放开跑，因为安全。知乎知乎上一个实测系列（共 5 篇）今天刚完结，把 sbx 的隔离边界摸了个底朝天。此前聊过工作区的两种接法，今天说里面最敏感的部分：钥匙怎么管。
社区其实早就动起来了。有人为了"电脑数据的绝对安全"，已经用 Docker 给 Agent 搭好了全功能离线沙箱，让生成的代码和命令都在沙箱里运行，连依赖清单都替你列好。知乎
为什么是 microVM：先看容器挡不住的
先说清楚，Docker Sandboxes 不是容器。每个 Agent 被放进独立 microVM，拥有自己的 Linux 内核、文件系统、网络和 Docker Engine——docker ps 看不到它，得用 sbx 自己的命令。知乎
为什么多此一举？容器是共享内核的隔离：逃逸打穿的就是宿主机那颗内核本身，内核一漏，直通宿主。microVM 方案在内核前面又隔了一层 Hypervisor，想碰宿主机，得先打穿 guest 内核，再打穿 VMM 和虚拟化接口，攻击面被压窄到 guest 这一侧。官方把隔离设计分成五层：Hypervisor、网络、Docker Engine、workspace、凭证。知乎
把眼下主流的 Agent 沙箱方案摆在一起，Docker Sandboxes 的位置更清楚——从共享内核的容器到独立内核的 microVM，隔离级别和启动成本一起变：
钥匙，是 Agent 身上最值钱的东西
聊 Docker 怎么处理之前，先看威胁清单。Agent 干的活是装依赖、跑测试、起服务，一轮任务可能执行几十条命令，而 LLM 生成的代码没法提前预测：它可能 rm -rf，可能扫内网，可能把环境变量里的密钥发出去。知乎凭证就是价值密度最高的那类资产：模型 API Key 能直接刷账单，GitHub token 能替你推代码，SSH 私钥就是你服务器的门钥匙。
Docker Sandboxes 把钥匙的交法分成三条路径，三种完全不同的信任模型。
路径一：sbx secret——钥匙从不进虚拟机。 用 sbx secret 存好官方支持的 provider 的 Key 之后，microVM 里 Agent 进程看到的是固定占位符 proxy-managed。注意，不是"真 Key 打了个码"，是一个字面意思就叫"由代理管理"的哨兵值。真 Key 留在宿主机，Agent 发起的模型请求经宿主机侧的代理，由代理拿真 Key 签好再转发，Agent 进程从头到尾看不到明文。GitHub token 同样待遇，显示的是 redacted 占位符。想复制 API 密钥也没用——原始密钥根本没有进入虚拟机。知乎想核对现状，看 `SBX_CRED_
路径二：SSH 转发——能用，摸不到。 Agent 要走 SSH 免密操作 Git 时，sbx 不是把私钥拷进沙箱，而是转发宿主机的 SSH_AUTH_SOCK。在 VM 里跑 ssh-add -l，列出的指纹和路径是真的——能看到宿主机 ~/.ssh 下的真实路径——但 VM 里 ~/.ssh 目录本身读不到，私钥文件的字节从没进过 microVM。知乎签名请求经这条 socket 发回宿主机，由真正持有私钥的进程完成。一句话：Agent 能拿这把钥匙开门，但拿不走钥匙。
路径三：sandbox-persistent.sh——唯一的明文例外。 如果你的 token 不在官方 provider 名单里，比如某个内部系统的自定义变量，官方给的路径是写进 /etc/sandbox-persistent.sh。注意，这条路径不走代理：值一旦写进去就是明文，直接躺在 VM 文件系统里，Agent 进程能直接读。知乎还有个隐蔽的坑：sbx exec 不经过 shell，这个文件不会被 source，环境变量读不到；包一层 bash -c 才读得到。这个特性很容易让人误判成"没注入"——实际它已经明文落盘了。记住：sbx secret 和 sandbox-persistent.sh 是两种信任模型，别把后者当前者的替代品。
清理盲区：删了沙箱，不等于删了钥匙
sbx rm 之后，VM 内部状态清空，但宿主机侧的配置原地不动：sbx secret 存的凭证、注册过的 MCP Server、共享 Skills store，都不会跟着某个 sandbox 一起消失。知乎这些是宿主机侧持久化的状态，跟单个沙箱的生命周期是两回事。清凭证要单独 sbx secret rm，清 MCP 注册要单独 sbx mcp rm。
三条路径一张表：
路径 | 真值在哪 | Agent 能看到明文吗 | 适用场景 |
|---|---|---|---|
sbx secret | 宿主机侧代理 | 否，只见 proxy-managed 占位符 | 模型 API Key、GitHub token |
SSH agent 转发 | 宿主机 ssh-agent | 否，能签名读不到私钥文件 | Git SSH 免密 |
/etc/sandbox-persistent.sh | VM 文件系统内 | 是，明文可读 | 名单外的自定义 token，能不用就不用 |
给三种情况各一条建议：
只用官方 provider 的，放心走 sbx secret，凭证隔离这层是目前这个产品里设计最干净的。
需要 Git SSH 的，用 agent 转发，别把私钥文件拷进沙箱——转发是"能用摸不到"，拷贝是连钥匙带锁一起给。
必须用自定义 token 的，把给这个 VM 的权限范围收到最小，并且记住：删沙箱的时候，钥匙还留在宿主机上。
边界先说清楚
以上结论来自知乎实测系列的一手数据（sbx v0.38.0、macOS 环境），边界也要说清：sbx 本体闭源，发布仓库里没有源码，官方文档只枚举了 Claude、Codex、Copilot、Cursor、Droid 五个 Agent 的挂载表，非官方 Agent 能不能接入还没人测完；产品还在 Beta，行为可能随版本变，用之前建议拿自己的版本复核一遍。知乎
另外两个"官方主动开放的边界"顺带提醒：共享 Skills store，Claude 默认读写挂载，多个沙箱共用一份可被互相改写的技能；宿主机侧的 MCP Gateway，本地 stdio 类型的 MCP Server 实际跑在你的开发机上，不在 microVM 里，权限和你本人一致。知乎这两处不是隔离被攻破，是设计上就开着的通道——留了例外，隔离就只覆盖剩下的部分。
为什么是今年，沙箱集体冒出来
最后补个背景。今年筑墙的不只 Docker：Claude Code 宣布 8 月 14 日起，Pro、Max、Team 的新会话默认启用 Auto Mode，工具调用不再逐条弹窗。原因很现实——Anthropic 披露的数据里，权限提示的总体批准率高达 97%，审批早就从判断变成了动作。知乎
另一项受控实验更能说明问题：把一条正常权限提示替换成明显危险的命令，1053 名专业测试者只识别出 13.6%，自动分类器拦下了 89%。知乎
当"逐条确认"这道人肉防线被证明靠不住，安全边界就只能往运行时下沉：把它能碰到的文件、网络、凭证收窄到事先划定的范围。Docker Sandboxes 的凭证设计，就是这个趋势的一个切面——钥匙还在你手里，Agent 拿走的只是使用权。
这套"凭证不下发、只发使用权"的思路值不值得跟，你用了 sbx 或者其他 Agent 沙箱的，评论区聊聊踩过的坑。
