AI 智能体不该握着钥匙干活:Docker 工程师的沙箱安全课
关联
半年前,大多数人还坐在电脑前,对 AI 智能体的每个请求点是、是、是。现在,智能体开始独立跑几小时的长任务。
Jim Clark 是 Docker 的工程师,他用一场简短的演讲回答了一个关键问题:不盯着智能体的时候,怎么保证它不闯祸?
为什么现在必须操心 AI 安全?
Jim 的判断标准很简单:一个设计好的任务,应该不需要他给多少监督,智能体就能自己啃下来。
但放手越多,担心就越多——智能体拿着你的工具和权限,到底会干出什么?
他把问题拆成三层:智能体的工作框架(harness)、干活的沙箱,以及连接外部工具的 MCP。
工作框架其实很笨:收进上下文,吐出工具调用,一个循环而已。真正危险的是它手里的资源和工具。
【背景】MCP(Model Context Protocol)是一种开放协议,让 AI 智能体连接外部工具和数据源,比如 Notion、GitHub 的接口。
新闻编辑室的比喻:把危险能力拆开
Jim 用报纸编辑室做比喻。
记者跑出去到处搜集信息,但不能直接发文;核查员核对事实,但不需要上网;撰稿人拿到的是核查过的材料,才有发布权限。
三个角色分开,谁也不掌握全部权力。
对应到智能体:研究员沙箱可以随便上网,但没有写入公司系统的工具;事实核查员能查内部数据库,但完全断网;发布环节才拿到 Notion 或发布工具的接口。
整个流程合起来能力很强,但任何单个沙箱里,都不会同时出现读任意内容和能对外操作这两种危险组合。
沙箱大小,应该由任务意图决定
Jim 讲了他自己搭建编程智能体的做法。任务可能跑一小时,但真正需要提交代码、用签名密钥的时间可能只有两分钟。
那为什么密钥要在沙箱里待满一小时?
他的原则:沙箱按任务意图建模。这一步不做提交,就不该有提交签名密钥;这一步不需要网络,就该彻底断网。
能力随需给,用完就收回。
【背景】沙箱指隔离的运行环境,限制程序能访问的文件、网络和工具。
所有 MCP 流量走一个网关
Docker Sandbox 产品的核心设计,是在每个沙箱里放一个网关端点(类似 mcpgateway.docker.internal 的内部地址)。所有工具调用、所有资源获取,都从这个单一关口进出。
好处有两个。第一,网关成了控制点:哪个沙箱能用哪些工具、资源和提示,由沙箱配置说了算。
第二,各种工作框架都变得 MCP 无关——不用在 Codex 里配一遍、Claude Code 里再配一遍,框架本身成了沙箱的一个可替换参数。
这就是他演讲标题的答案:沙箱里应该放多少[[泄露的凭证|凭据]]?
「正确答案永远是零。」
凭据不进沙箱,智能体犯错的爆炸半径就被压到最小。真正需要授权时,走另一条路。
零凭据怎么授权?复用公司的现有体系
Docker、Anthropic 和 Okta 正在合作推动一个叫 XAA(Cross-App Application)的方案。
思路是:公司早就有了单点登录和身份管理,Notion、GitHub、Slack 这些服务早就接好了——但智能体至今够不着它们。
做法是沙箱和网关定义智能体的身份,也就是它代表谁在干活。
拿这个身份去和公司已有的身份提供商交换声明,换回一个授权许可(新版 MCP 规范里的新概念)。
没有疯狂的同意弹窗,公司就能集中管理智能体对所有内部服务的访问——把已有投资直接复用。
渐进式披露,顺便省上下文
一个完整工作流可能用 50 个 MCP,但每个沙箱不需要装着全部 50 个。Jim 借用了渐进式披露的说法:工具和资源按需逐步给进去。
这还有个附带好处:上下文体积更小。
编排器的职责也随之清晰——接到任务,先问需要什么能力,再决定放进哪个沙箱、配哪些工具、给什么网络规则。
Jim 说,这一切本质上是把智能体容器化,也解释了他为什么在 Docker 做这件事。现场可以通过 brew install SBX 装到这个工具。
本集带走
- 沙箱里应该放多少凭据?答案永远是零,凭据由网关按需授权。
- 把危险能力拆开:能读任意内容的能力和能对外操作的能力,永远不要出现在同一个沙箱里。
- 沙箱大小由任务意图决定:这一步用不到的权限,就不该出现在沙箱里。
- 所有 MCP 流量走单一网关,形成控制点,还让各种工作框架可以随意替换。
- Docker、Anthropic、Okta 合作推进 XAA,复用公司已有的单点登录体系给智能体授权,无需重复配置。
所以在每个单独的时间点,我们都不会出现既能读取疯狂未过滤的上下文、又能用我们的工具做事情的危险组合。
So at each individual point, we don’t have a dangerous combination of both being able to read in crazy unfiltered context and do things with our tools.
—— Jim Clark · [08:26]
如果你的智能体知道你想做什么的意图,那就用那个意图来建模你赋予它的能力。
If your agents know the intent of what you’re trying to do, then use that intent to model the capabilities that you give to that.
—— Jim Clark · [09:58]
而且如果里面绝对没有任何凭证,一个智能体做出错误行为的爆炸半径就缩小了。
And the blast radius of an agent doing something incorrect if there are absolutely no credentials in there is reduced.
—— Jim Clark · [12:12]
给你的智能体解决问题的空间,但让单个沙箱表达任务的意图。
Give your agents room to solve problems, but let individual sandboxes represent the intent of the task.
—— Jim Clark · [14:56]
我们习惯于考虑建模能力、为任务构建合适的沙箱、把任务放进去,而现在我们开始看到,这个个体循环更安全,因为它拥有的访问权限比整个工作流实际拥有的要少。
We get used to thinking about modeling capabilities, building the right sandbox for the task, putting the task in, and now we’re starting to see that this individual loop is safer because it has less access than the entire workflow effectively has.
—— Jim Clark · [15:54]
顺着「智能体」挖下去
- 解锁智能体自主性:安全才是下一个瓶颈同公司:Docker · 同概念:MCP、智能体 (agent)、智能体 harness (harness)、沙箱 (sandbox)
- Anthropic 构建生产级智能体的教训:harness 须为模型能力演进而生同公司:Anthropic · 同概念:凭据 (credentials)、智能体 (agent)、智能体 harness (harness)、沙箱 (sandbox)
- AI 原生组织如何运行在 Skills 之上同公司:Anthropic · 同概念:MCP、智能体 harness (harness)、沙箱 (sandbox)、渐进式披露 (progressive disclosure)
换个口味
- Anthropic 的 Thariq 谈 Claude Code:提示词、CloudMods 与给前沿踩刹车同公司:Anthropic · 同概念:智能体 (agent)、智能体 harness (harness)、沙箱 (sandbox)
- 我用五个提示词「黑」了自己:你的 AI 助手并不安全同公司:Docker、SBX · 同概念:智能体 (agent)、沙箱 (sandbox)
- AI失控了别慌,先盯紧漏洞数量爆炸同概念:凭据 (credentials)、智能体 (agent)、沙箱 (sandbox)
