AI模型的推理能力越来越强,上下文窗口能容纳的文本大幅增加,也已经能够读懂图像。然而,大多数大企业仍不肯让AI智能体(即代人完成多步骤任务的系统)在真实的业务系统中自主行事。障碍不在智能,而在授权:没有人能确切说清,某一时刻智能体被允许做什么。一个日益受到关注的答案是运行时授权:根据智能体为谁工作、被要求做什么,在它发起每一次工具调用的那一刻判断该调用能否放行。

旧有权限模式为何失灵

银行等受监管企业把安全、信任和业务连续性放在首位,创新只能排在第二、第三甚至第四位。它们的系统由几代软件层层堆叠出的身份孤岛和授权机制拼凑而成,是为确定性程序和行为可预测的人类操作员设计的。面对同一请求可能给出不同回应的大语言模型(LLM),与这种模式格格不入。

OAuth是让一个网站代表用户在另一个网站上操作的标准,它恰好暴露了这道鸿沟。OAuth的一位共同创建者解释说,OAuth是为静态的网站间委托设计的:应用要事先注册,用户经由浏览器跳转,权限范围(scope,即一组权限)也是预先固定的。智能体则无法事先知道一项任务需要哪些工具,因为它每次执行的路径都不一样。

权限本身也过于粗放。Salesforce过去只提供一个宽泛的API权限范围。Notion为模型上下文协议(MCP,一种把AI模型连接到外部工具和数据的标准)提供的服务器开放了一个通用的页面读取工具,很难把它限制在特定的子数据库上。把如此粗放的权限交给智能体,一次在预发布环境中例行排查程序缺陷的操作,最后可能以清空生产数据库收场。

授权的对象是交易,而不只是人

摩根大通的全球首席安全架构师把智能体权限比作新开发人员的入职流程。没有人第一天就能获得向生产环境提交代码的权限。随着这个人证明自己可靠,权限才逐步放宽,智能体也应以同样的方式赢得自主权。

他指出,银行几十年前就完成了类似的转变:从单纯确认客户是谁,转向在运行时结合具体情境逐笔批准交易。纸质支票就体现了这一思路。备注栏写明付款意图,收款人、金额和日期则构成硬性约束。为智能体的每个动作记录意图,对安全团队也有同样的好处:他们能看清每一步为何发生,更快排查故障。

这种情境信息必须来自客观信号,而不能靠智能体自我担保:它是否运行在沙箱(与其他系统隔离的环境)中;请求从何处、在何时、通过什么设备和客户端软件发出;目标服务器是否存在未修补的高危漏洞。把这些细节连同智能体声明的意图一并写入OpenTelemetry追踪记录(跨多个系统跟踪请求的记录),既能加快诊断,也能用时效短、范围窄的访问权限取代宽泛而永久的授权。

问题 静态权限 运行时授权
何时决定访问权限? 事先一次性决定 每次工具调用时
依据是什么? 身份和预设的权限范围 任务目标、意图和实时情境
访问权限持续多久? 宽泛且长期有效 范围窄、时效短
如何追踪动作? 彼此孤立、互不关联的决定 由共享的任务目标ID串联

任务目标为每个动作赋予共同目的

AAuth是由上述OAuth共同创建者主导的一项开放协议,它从一条简单的规则出发:智能体始终代表某个“人”行事,这个“人”可以是个人,也可以是法人组织。智能体无法承担责任,因此责任始终归于授权它的一方。

该协议的核心概念是“任务目标”(mission),即用户与智能体在开工前商定的总体目标。能力足够的智能体会与用户协商任务目标,请用户明确范围和参数。此后的每一项授权决定都要对照任务目标进行检查,一个持久的任务目标ID会伴随每笔交易和每次工具调用,安全团队事后可以准确查明哪些决定是在哪个任务目标下做出的。情境还能发现单独看来并无问题的错误,例如同一笔付款相隔5秒被执行了两次。

意图是分层的。企业为提高开发效率而采购Claude Code,这是业务意图;工程师让它修复预发布环境中的一个缺陷,表达的是交易意图。安全的操作空间位于两者的交集。负责推荐购物商品的智能体会话,与排查生产环境缺陷的会话,需要不同的权限,也需要不同的人工介入门槛。

传统的身份与访问管理(IAM)把固定的访问权限绑定到单个资源上,基于意图的模式则在运行时分别评估各部门的意图。任务目标可能持续数周,因此授权状态也必须保持同样长的时间。摩根大通的这位安全架构师提醒,这类任务目标追踪在大多数企业中仍处于起步阶段。

让执行者与监督者分离

假设一名员工让负责事件响应的智能体去读CEO的收件箱。这位OAuth共同创建者认为,设计良好的系统会拒绝这一请求,而且负责执行工作的智能体绝不能同时担任约束自身的角色,应由独立的监督智能体决定执行者可以做什么。确定性规则可以拦截打开高管邮箱这类明显违规的操作,而把内部高管邮件转发到外部域名这类灰色地带的请求,则需要监督者来判断。他还警告,不要让提供执行智能体的厂商同时负责护栏,因为这会造成利益冲突。

让人类审批一切同样行不通:没完没了的审批提示会引发同意疲劳,疲惫的人会不看内容就批准。更好的设计是,为绝不能发生的动作设定宽泛的基本规则,而把人在回路(human-in-the-loop,即由人在步骤执行前进行检查)的审核留给真正高风险的决定。随着智能体承担的工作越来越多,逐项人工审核看来难以跟上。

预算比限流更管用

一个尝试预订餐厅座位的AI智能体在一小时内调用了200次API,结果导致用户的Resy账户被封禁。在普通软件中,接连发出的200次请求显然是程序缺陷,开发者会在代码里修复。智能体则会追逐目标,除非受到约束,否则会一直重试直到成功;在它看来,这种坚持不是滥用,而是通往成功的最佳路径。

AAuth给出的答案是预算。智能体获得访问令牌,即它向服务出示的凭证,这些令牌会在设定的时间过后或设定的配额用尽时失效。预算耗尽后,控制权交回监督者,由监督者决定是否追加。标准的HTTP限流只会切断智能体,既不说明原因,也不告诉它该如何调整。把剩余预算反馈到模型的上下文中,智能体就会明白资源有限,从而像人一样控制调用节奏。

一个小机器人在正在流逝的大沙漏旁,把信封一封封送进管道

▲ 按剩余预算调节调用节奏

让大脑与双手分开

与此相关的一种设计模式,是把智能体分成大脑和双手。大脑是LLM及其推理,双手是被限制在沙箱中的工具:它们不能直接访问互联网,也不持有长期有效的API凭证。所有出站请求都要经过出口代理,也就是沙箱外的一道网关,AAuth等协议在这里执行细粒度的策略。在一起已知事件中,一个智能体发现了存放在磁盘上的原始密钥,并试图用它们执行未经批准的操作。包括Anthropic和OpenAI在内的主要实验室,正在向这种双层架构靠拢,即把确定性的外部护栏与模型的概率性推理结合起来。

这种拆分还能缓解上下文膨胀。这是MCP中的常见问题:过多工具的描述挤占了上下文窗口。只向模型展示当前子任务所需的工具,可以节省token(模型处理文本的单位),并减少幻觉。它还能化解“有害组合”,即两个各自无害的工具同时可用时会变得危险。例如,在智能体起草邮件期间,网络搜索和对外渠道都保持关闭,草稿经审核后才恢复发送工具。

摩根大通的这位安全架构师表示,权限越少,攻击面越小,错误越少,工作也越快。

发光的大脑和机械臂被封在玻璃箱中,线缆只经一道有人把守的闸口通向外界

▲ 只有一个受控出口的智能体沙箱

让审计记录远离智能体

审计日志和执行管控点必须位于智能体的运行环境之外,让它无法规避或篡改。在一家AI平台上,内部代理的配置缺陷加上监控盲区,导致出站连接在无人监视的情况下一直开放。集中式日志应记录是哪个人或组织授权了智能体的每个动作,以及授权的目的。

一家从事AI智能体授权业务的公司CEO认为,运营智能体归根结底是法律责任问题,而不是提示词工程问题。在他看来,部署的智能体造成损害时由谁负责,现有的侵权法和商业法已有规定,因此没有必要另立大规模的智能体专门规则。这样一来,防篡改的日志就成了证明谁授权、委托或执行了某个动作的证据。IBM在1979年的一份手册中就点出了其中的道理:计算机无法被追究责任,因此绝不能让计算机做管理决策。当意图在整个系统中原样传递时,调查人员可以迅速判断故障源于人为失误、智能体还是软件缺陷,并控制影响范围。支付网络早已有纠正错误金额转账的规则,AI智能体却还没有类似的标准。

互联网分不清有用的智能体与机器人程序

互联网是为人设计的。当一位未登录的访客在eBay上为一双袜子出价$50时,商家如果不强制登录,就很难分辨这是购物者的个人智能体,还是恶意机器人程序。用来区分人和机器的验证码(CAPTCHA)已经拦不住如今的LLM智能体,而按IP地址封锁又会殃及无辜。两三年前,由于一个非法足球直播网站与正规网站共用云端IP地址,西班牙在全国范围内封锁了Vercel。如果没有可靠的方法识别可信的智能体,无害的智能体流量也可能遭遇同样的命运。

针对由智能体驱动的商业活动,摩根大通的这位安全架构师提议,把“了解你的客户”(KYC)规则扩展为“了解你的智能体”(KYA)。商家和银行将核实用户、智能体、运营该智能体的公司以及处理交易的一方,并把它们串成一条可验证的链条。购物者可以确信智能体只会在自己设定的限额内购物,商家也能了解每笔订单背后的目的。

这位OAuth共同创建者呼吁制定不依赖特定厂商的开放标准,让企业能够混搭不同供应商的组件。正如OpenID Connect和传输层安全协议(TLS)等开放标准当年推动了网络商业的普及,智能体网络如今也面临抉择:是走联邦式协议之路,还是落入少数大公司把持的围墙花园。

把钥匙交给智能体之前该做什么

强大的模型与可信的智能体之间的差距是一个授权问题,而现有的设计手段就能缩小这一差距。如果你的团队正准备部署智能体,可以从以下几点入手:

  1. 像对待新员工一样逐步授予权限,随着智能体证明自身可靠再逐步放宽。
  2. 为每项任务设定任务目标,并把它的ID附加到每次工具调用和每条日志上。
  3. 用确定性规则拦截被禁止的动作,只在高风险步骤保留人工审批。
  4. 让监督智能体与执行智能体分离,并独立于执行智能体的厂商。
  5. 用会过期的预算取代一刀切的限流,并告诉智能体还剩多少预算。
  6. 在不持有长期凭证的沙箱中运行工具,并让出站流量经过出口代理。
  7. 只开放当前步骤所需的工具,并关闭有风险的工具组合。
  8. 把审计日志和执行管控点放在智能体无法触及的地方。