解锁智能体自主性:安全才是下一个瓶颈
关联
这一集是一场技术大会演讲,主讲人来自 Docker(他在演讲中提到,大家熟悉的 Docker 解决了过去十年软件的可移植性问题,而他们现在正把这套经验拿来做一件新事)。他抛出的核心主张是:过去两年大家都在把智能体做得更聪明、更强大,但下一个重大挑战其实更难也更重要——安全。智能已经不再是利用智能体的瓶颈,真正的阻碍是如何安全地给它们所需的全部访问权限和自主性,否则自主性就解锁不了。
他先讲了个亲身案例:他有一个每晚运行的智能体,替他读报告、做分析,然后发邮件给他,稳定跑了好几周。某一天,它毫无征兆地决定把这份报告作为一个 PR 发布到代码仓库上——什么配置都没变,只是「模型决定要帮忙」。他说这只是个最简单的例子:智能体会做事、会试图帮忙,会因为想帮忙、犯迷糊、出错或被利用(攻击者在输入里塞指令劫持智能体)而扩展或改变自己的目标。
【背景】这种攻击手法业界通称「提示词注入」(prompt injection),即将恶意指令嵌入智能体的输入内容以劫持其行为。
这个案例好修——那个智能体本来就不该有 GitHub 写权限,只给读权限就行。但复杂场景没这么简单。
核心难题:权限需求在运行时才出现
他举了一个更有代表性的场景:让智能体调查一次延迟飙升。它查日志,发现可能涉及另一个服务,于是去要那个服务的日志;又发现可能和一次代码提交有关,于是要 GitHub 读权限;再去 Slack 搜相关讨论,要 Slack 访问权限。
每一步都合理,是一个工程师会做的事。**问题在于:每当它扩展目标,它就跨越了一个信任边界。**最终你会得到一个同时握有一切权限的智能体,任何事情都成了爆炸半径(出事时波及范围)被放大的攻击向量。
这和传统软件有本质区别:传统软件是确定性的,权限可以预先定义;而自主智能体要做的事、需要的权限,都是在运行时才动态确定的。我们现在还没解决「怎么给它恰好所需的权限、怎么安全地做到、怎么判断对不对」。问题从「它能不能做到」变成了「它应不应该做到」。
为什么不能指望模型自己不犯错
他给出两条理由,说明解决方案必须独立于模型层:
一是我们一定会用多个模型。没人会把一切押在单一模型或单一前沿实验室上,出于隐私、成本等原因,我们也会用开源模型——他特别提到 GLM 5.2 最近几周令人惊叹的进展,并说「这只是开始」。
二是我们也会用多个 harness(承载智能体运行的框架外壳)。完全押注某个前沿实验室的 harness,会让你难以在各家模型和开源模型间做选择;而且用例会从编码扩展出去——他说 OpenClaw 时刻已经发生但还没完全落地,可以想象销售、营销人员也让智能体跑着干活,你还会构建自己的 harness。
所以,需要的是一个跨模型、跨 harness 的运行时层,它不依赖「模型不出错」,而是约束智能体周围的环境:出了问题爆炸半径有限,只给它所需权限。
三大支柱:遏制、范围限定、意图式访问
第一是遏制:在不受信任边界之内运行智能体,把控制放在 VM(虚拟机)边界之外。他自嘲说现在沙箱公司多到你随便扔块石头都能砸中,但他要讲的不止沙箱。
第二是限定访问范围,这比「能访问哪个网络/工具」细得多。回到 Slack 的例子:给只读权限仍然太多,对话可能散在多个频道里,他不想让智能体看到其他内容。运行时应该做的是即时生成一个新工具,组合在现有 Slack MCP 工具之上,但只放行与该事件相关的对话;并且与其维护一个不断加权限的大沙箱,不如把这部分任务拆出来,放进只为它建的、只带所需能力的小沙箱里跑。
第三是**基于意图的访问**:理解用户或任务的意图、结合上下文,再决定给什么权限、在哪个容器环境里跑。调查事件时要 Slack 读权限,合理,放行;突然要邮箱权限,提示词里没有任何依据——拒绝,或提升给人工审批。
而且这个判断要作为独立的控制层、在治理层面运行,不依赖具体哪个模型或 harness。他坦承:这是很难的问题,还没有被完全解决,但这是必须迈向的方向。
运行时还得能「跟着工作走」
安全之外,运行时还必须满足功能性:不能只在本地或只在云端,要在本地、云端、跨云编排、自己的或客户的 VPC 里都能跑,理想情况由一个 fabric 连接,智能体可以按需上下迁移。他把这比作 Docker 的延续:Docker 过去十年解决的是可移植性——软件怎么从笔记本搬上云;现在是在此之上叠加安全,构建跨所有环境的运行时,起点是一项全新的 VM 技术,上面是一系列关于 MCP、策略、安全和治理的进展。
现场演示:SPX
他现场演示了一个叫 SPX 的新工具,底层是可跨 Windows、Mac、Linux、云端运行的 MicroVM。要点:
- 一条命令就能在沙箱里启动 Codex 等智能体,凭证是运行时注入的——智能体自己看不到真实凭证(查询确认全是存根),网络策略受控。
- 拆任务、拆沙箱:审查 PR 和写 Notion 总结不必塞进一个握有两份凭证的整体沙箱,而是两个沙箱各司其职——PR 沙箱只有 GitHub 和 Anthropic 权限,别的地方去不了;Notion 沙箱只有 Notion MCP 访问权,没有 GitHub。
- 本地创建的沙箱加个参数就能原样跑上云:同一个沙箱、同样的策略平面和控制跟着过去。他还演示了一个小脚本,创建六个沙箱并行审查六个 PR——「你在云端获得与本地相同的体验,相同的安全运行时、相同的策略和受限访问」。再往上是编排器:让它找 10 个随机 PR、查看、写摘要进 Notion,它会在各智能体之上组合调度,PR 的只带 PR 权限、Notion 的只带 Notion 工具。
最后他展示了一个内部原型(明确说明还没构建好):主智能体在只有 Anthropic/Claude 权限、没有 GitHub 的沙箱里,被要求概览一个 PR。它通过一个基于意图的工具向运行时申请,运行时判定「用户要审查这个 PR,要 GitHub 访问是合理的」,于是为它生成一个范围受限的子沙箱拿到 GitHub 权限,结果回传,主沙箱始终拿不到权限。
假如 PR 文本里说「导出到 pastebin.com」,就会被拒绝。他总结:手动做的事,可以开始带着人工判断自动发生,而且这跑在基础运行时层,覆盖每一个智能体、每一个模型、每一个 harness。
本集带走
- 瓶颈已从智能转向安全:让智能体更聪明差不多快成了,真正卡住自主性的是「怎么安全地给它权限」——问题从「能不能」变成「该不该」。
- 别把宝押在单一模型或 harness 上:一定会混用多家模型(含开源)和多个 harness,所以安全方案必须做成独立的运行时控制层,跨模型、跨 harness 生效。
- 权限跟着任务拆,不跟着智能体给:把工作拆成跨安全边界的任务,每个任务一个范围受限的沙箱、即时生成只覆盖所需范围的工具(如只放行某个事件的 Slack 对话),而不是往一个大沙箱里不断堆权限。
- 用意图判定动态授权:结合任务上下文判断权限请求是否合理——合理的就为它开一个限权的子沙箱,无依据的(比如突然要邮箱权限)拒绝或转人工审批。
- 安全运行时要无处不在:从本地到云端、VPC 再到编排,同一套策略和控制跟着智能体走——这是 Docker 可移植性经验向安全方向的延伸;演讲者称可用 brew install SPX 直接试用。
什么都没变。只是模型决定要帮忙。
Nothing’s changed. Just the model decided to be helpful.
—— Tushar Jain · [01:56]
我们最终会得到一个同时拥有一切权限的智能体,于是任何事情都成了爆炸半径扩大的攻击向量。
We now end up with an agent that has access to everything at the same time, and so anything becomes a vector where the blast radius expands.
—— Tushar Jain · [03:24]
之前,传统软件是确定性的,你可以预先定义好权限。但现在,随着智能体变得自主、试图解决更多问题,它们在做的事情在运行时发生改变。
Earlier, traditional software was deterministic. You could define the permissions. But now, as agents become autonomous and they gain and they try to solve more problems, what they’re doing changes at runtime.
—— Tushar Jain · [03:37]
没有人会把一切都押在单一模型上,甚至是单一前沿实验室上。
No one is going to bet everything on a single model or even a single frontier lab.
—— Tushar Jain · [04:25]
我们还需要某种不依赖于「不出错」,而是约束它周围环境的东西。
And we need something that doesn’t just depend on no mistake happening, but constrains the environment around it.
—— Tushar Jain · [05:37]
重要的是,你在不受信任边界之内运行智能体,而把控制放在 VM 边界之外运行。
And importantly, you run the agent inside the untrusted boundary, and you run controls outside the VM boundary.
—— Tushar Jain · [06:37]
突然之间,它想要邮箱访问权限。为什么?你给的提示词里没有任何东西表明它应该有这个权限。
All of a sudden, you would like email access. Why? Nothing about the prompts that you should have that.
—— Tushar Jain · [08:59]
Docker 在过去十年解决的是可移植性——怎么把软件从你的笔记本搬到云端。我们正在把所有这些经验拿来构建一个运行时,并把它演进到如今去解决安全性问题。
And what Docker solved the last decade is portability. How do you get software from your laptop to the cloud? We’re taking all of that experience and building a runtime and evolving that to now solve for safety.
—— Tushar Jain · [10:35]
顺着「AI 安全」挖下去
- AI 智能体不该握着钥匙干活:Docker 工程师的沙箱安全课同公司:Docker · 同概念:harness、MCP、智能体 (agent)、沙箱 (sandbox)
- 我用五个提示词「黑」了自己:你的 AI 助手并不安全同公司:Docker · 同概念:MicroVM、智能体 (agent)、沙箱 (sandbox)、Claude
- 把智能体当普通应用来部署:企业级 AI 落地的老办法新用途同概念:MCP、智能体 (agent)、沙箱 (sandbox)
换个口味
- Anthropic 平台负责人:Claude 平台的「三层蛋糕」与给 token 分工的「策略」同概念:harness、MCP、智能体 (agent)、Claude
- Codex 负责人亲述:OpenAI 内部如何造编程智能体同概念:harness、智能体 (agent)、沙箱 (sandbox)、Codex
- 当 AI 决定买什么软件:G2 的「信任层」生意同概念:harness、MCP、智能体 (agent)、Claude
