2026-11-09 18:59:49 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

乌镇讨论智能体互信之后：代理身份和授权边界怎么落地

谈思实验室

2026年11月8日 17:42
上海

去阅读

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

从论坛共识，走到一次实际业务调用

11月4日，2026年世界互联网大会乌镇峰会在浙江乌镇举行智能体互信互联互操作全球合作创新论坛。中国国家互联网信息办公室与全球移动通信系统协会主办的这场论坛，讨论了智能体注册解析、身份可信、协议互通与安全治理，并发布合作倡议、全球合作行动和智能体发展自律公约等成果。值得关注的变化，是议题已经从模型怎样回答问题，延伸到不同主体怎样一起执行任务。

2026年乌镇峰会相关论坛的《智能体发展自律公约》发布现场。

同日发布的《智能互联网创新发展合作倡议》，把互信框架覆盖的范围放到了智能体发现、协商、执行的全生命周期，并强调可验证与可追溯。11月6日人民日报关于自律公约的报道，则提到分层次、可验证的身份标识，以及身份验证、权限授予和控制。这些方向指向一个具体难题：能够找到另一个智能体，并不意味着它可以带着用户的全部权限进入业务系统。

以企业采购为例，一名员工让采购助手查询三家供应商的报价、整理比较结果。助手可能调用文档服务、询价工具和财务接口，但查询报价、发出订单、提交付款是三种后果不同的动作。以下采用这一说明性场景，结合MCP与OAuth原始技术资料讨论授权设计；它不是对论坛已采用某项协议的报道，也不是某家企业已上线系统的案例。

身份要同时说明使用者与执行者

如果采购助手直接使用员工密码，后台只看见员工登录，便很难分辨一次操作由本人完成，还是由助手规划后执行。美国国家标准与技术研究院在8月27日的一篇身份安全博客中指出，共享凭据会制造责任追踪缺口，智能体应有自己的标识、凭据和权限，并与运营它的用户或系统关联。该文属于技术讨论，不是一套已经生效的智能体认证法规。

这种区分可以沿用已有授权机制。OAuth令牌交换标准RFC 8693区分委托与身份冒用：在委托语义下，执行方仍保留区别于用户的身份，明确表示自己代表用户行动。标准还定义了JWT中的act声明，用于表达当前执行者。它提供了一种表达办法，是否签发这样的令牌、如何建立信任，仍取决于部署策略；不是给任意令牌添加一个字段就自动完成可信委托。

因此，企业需要先定义采购助手对应哪个应用、由哪个团队运营、关联哪个用户或业务角色，以及哪些系统认可它的凭据。助手之间转交任务时，也应保留这一关联，而不是统一换成共享管理员账号。身份目录证明服务是谁，业务授权决定它此刻能做什么，二者应在调用入口汇合。即便模型准确理解了采购需求，也不能由模型自行宣布获得付款资格。

《智能体发展自律公约》发起单位名单图

每经过一个服务，都应重新收紧权限

MCP的2025年11月25日版授权规范，为基于HTTP传输的受保护服务规定了OAuth授权流程。客户端请求令牌时需要标明目标资源，服务端则要验证令牌确实签发给自己；调用下游接口时，应使用为下游签发的独立令牌，不能直接透传收到的客户端令牌。这里讨论的是该版本的授权机制，并不意味着所有本地工具或所有智能体交互都必然使用相同流程。

回到采购场景，文档服务的读取权限不能自然延伸为财务系统的付款权限。RFC 9700的OAuth安全最佳实践要求把令牌权限限制在具体用途所需的最小范围，并由资源服务逐次检查目标资源与动作。落到实现上，可以把报价查询约束到指定项目及供应商，把订单草稿与正式提交分开，再对付款设置金额、收款方和审批条件。后面这些业务条件需要系统自己定义，不能指望一个笼统的读写范围替代。

Auth0发布的MCP授权架构示例：用户、智能体、授权服务、MCP服务与内部及第三方接口分层交互

权限检查也要放在工具实际执行的位置。即便助手被外部文档诱导，试图把报价表发到陌生地址，通信工具仍应根据收件范围与数据策略拒绝请求。MCP安全文档特别提醒代理服务防范混淆代理问题，不能因为用户曾批准某个中间服务，就省略对新客户端的独立同意和校验。连接器已经连通，只说明通信路径存在，不能代表新的调用方也获得同等授权。

把确认弹窗加到每一步同样不是充分条件。NIST的上述博客提醒，过多人工审批可能造成同意疲劳。较合理的设计，是让可重复、影响有限的查询在预先授权内运行，在收款方变化、金额增加或数据流向外部等关键边界重新决策。确认界面应展示真实业务后果，授权结果仍需由服务端执行，不能只留下一句用户已经点击允许。

取消任务之后，旧权限什么时候失效

如果员工取消采购任务，或者助手的凭据泄露，系统必须能够阻止后续操作。OAuth令牌撤销标准RFC 7009规定了撤销机制，也明确指出实际系统可能存在传播延迟，应尽量缩小这一窗口。与同一授权关联的其他令牌是否一并撤销，还涉及令牌类型、服务器能力与撤销策略。界面显示取消成功，不能直接当成所有节点已经停止接受旧凭据的证据。

对企业实现而言，撤销应同时覆盖任务调度、刷新令牌、现有访问令牌以及后台执行队列。短时令牌能够缩小泄露后的可用时间，但不是即时终止开关；任务已经排队时，执行前还要检查授权是否仍然有效。验收可以在撤销后重放旧调用，并在不同节点、不同缓存状态下测量拒绝生效时间，而不只检查撤销接口返回了成功。这里是工程验证建议。

撤销还不能自动消除已完成操作的后果。订单已经提交，需要业务系统走取消或补偿流程；敏感报价已经交付外部，也不能仅靠令牌过期将数据收回。因此，授权设计应提前区分可重试、可撤销和需要补偿的动作，并让用户知道任务停在什么位置。否则，安全系统停止的是下一次请求，业务人员误以为整项交易从未发生，责任仍会出现断层。

审计要还原决定，不能只留下模型的回答

一次采购任务的记录至少应能关联发起人、执行助手、目标工具、业务对象、采用的授权策略以及执行结果。只保存聊天记录，通常看不到后台为何放行；只保存接口访问日志，又可能无法还原它对应哪项用户委托。可以用任务标识和关联标识把这些证据串起来，同时对审批快照、权限变化和异常重试保留必要记录。这些是面向调查与复核的设计建议，保存范围与期限仍须根据业务需要确定。

日志本身也不能成为新的凭据仓库。应记录令牌的安全标识或必要元信息，而不是把完整访问令牌写入日志；敏感业务参数也应按需脱敏。MCP安全文档还明确要求，实施授权的服务器验证所有入站请求，不能把会话当作身份认证。任务关联标识帮助查找证据，却不能替代令牌验证和权限判断，否则知道一个会话编号的人就可能跨过原本的边界。

乌镇论坛提出的互信，最终需要在这些细节里获得实际含义：身份能够被核验，用户与代理能够被区分，权限沿服务链受到约束，撤销能够到达执行点，出错之后还能还原决策过程。企业不必等待一种包办全部问题的智能体通行证，才开始补齐已有身份系统和接口治理的缺口。真正值得验收的，是助手接入更多工具之后，业务边界是否仍然清楚、有效，并且能够被证明。

end