文章总结： 文章提出多Agent授权第一性原则：授权校验应发生在模型上下文之外，而非依赖提示词防御。通过网关侧令牌交换（RFC8693）与策略引擎结合，实现任务级短时效最小权限令牌，可有效抵御提示注入。Oxo实验显示20万伪造令牌零通过。落地建议：拆分共享凭证、网关引入令牌交换、高风险操作审批、Agent间双向认证。 综合评分： 85 文章分类： 安全建设,解决方案,应用安全,云安全,威胁情报

多Agent授权的第一性原则：把模型当成已被注入的组件

cwbird cwbird

bird网络安全

2026年9月11日 10:16 浙江

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

OWASP 在 2025 年 12 月发布的《智能体应用十大安全风险》里，身份滥用和过度授权排在前列。榜单发布九个月后，国内厂商的动作集中在运行时防护：阿里云 2026 年 3 月上线 AI 安全护栏 2.0，主打 Agent 全链路拦截；腾讯推出 Agent 安全中心管数字员工。这些产品解决的是「Agent 做了不该做的事怎么拦」，但有一个更靠前的问题没有被充分讨论：多个 Agent 协作时，授权决策放在哪里。

安全厂商 Oxo Security 9 月 8 日发布的一组实验数据给出了一个可量化的答案：在多 Agent 环境里投入 20 万个伪造令牌做注入测试，全部被拒绝，零个通过。前提条件只有一条，授权校验发生在模型上下文之外。

为什么提示词防御撑不住

业界对提示注入的防御思路经历了三个阶段。最早靠系统提示词里写禁令，比如「你只能访问订单表，不能访问用户表」。GitHub 精品推荐公众号 1 月底的文章引用实验结论：在单一大模型架构下，试图通过纯文本技巧对抗注入，失败只是时间问题。注入攻击的本质是数据被当成指令执行，只要防御指令和恶意数据在同一个上下文窗口里竞争模型的注意力，就没有确定性可言。

第二阶段是输入过滤和输出审核，用另一个模型或分类器扫描请求。这类方案降低了攻击成功率，但引入了新的不确定层：过滤模型自身也可能被绕过，而且每个 Agent 的每次工具调用都要过一遍审核，延迟成本在多 Agent 编排里会放大。

Oxo Security 那篇里有个说法值得记住：你在提示词里写「这个 Agent 只做这一件事」，一旦模型被注入，这句限制降级为建议。建议对攻击者无效。

授权离开模型上下文，具体指什么

多 Agent 系统常见的凭证管理有三种错误形态。三者没有内置隔离：所有 Agent 共享同一个服务账号，任何一个被攻陷就等于全部沦陷。一部分产品做了 Agent 级凭证，但权限粒度停在 Agent 维度，没有细化到单次任务。还有的把授权令牌直接塞进上下文，等于把钥匙和锁放在同一个房间。

正确的位置是网关侧或执行侧。流程上拆成四段：

1. 每个 Agent 启动时向授权服务注册机器身份，拿到长期身份凭证
2. Agent 发起工具调用时，请求先到授权网关，网关解析这次调用需要的具体权限
3. 网关用策略引擎判定后，签发一个只覆盖本次操作、短时效的任务令牌
4. 工具侧只认任务令牌，Agent 的身份凭证碰不到资源

这样模型被注入后能做什么？它能发起越权请求，但网关会拒签。它能尝试伪造令牌，但工具侧校验签名。20 万个伪造令牌零通过的实验背景就在这里：校验逻辑在模型外，攻击者控制的输入进不了判定环节。

RFC 8693 和策略引擎的组合

技术上不需要发明新协议。安全新视线公众号 3 月的文章提到，已有厂商用 RFC 8693 令牌交换机制配合 Open Policy Agent 实现细粒度动态授权。RFC 8693 是 OAuth 2.0 Token Exchange 标准，核心能力是拿一个已有的 subject_token 换出一个权限收缩的新令牌，换出的令牌通过 scope 和 audience 参数限定范围。

落到 Agent 场景的调用序列：

POST /oauth2/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<agent 的身份凭证> resource=https://crm.internal/api scope=「orders:read」

网关收到 Agent 的请求后，用上面这个交换拿到一个只能读订单接口的令牌，再转发给 CRM。OPA 侧的策略文件写的是「谁在什么条件下能换什么范围的令牌」，策略用 Rego 语言描述，可以按 Agent 身份、任务类型、资源敏感级三个维度收敛。Palo Alto 的 Prisma AIRS 把这套逻辑包装成 Agent 全生命周期防护产品，提示注入拦截和工具调用管控在同一个链路上。

这个组合的收益是可审计。每次令牌交换都有记录，谁在什么时间换了什么权限的令牌，事后追溯不需要回放模型对话。传统 SOC 的日志分析流程在这里直接复用。

上下文变化时，授权要跟着变

NIST NCCoE 今年 2 月启动了 AI Agent 身份管理与授权的标准化研究，立项书里点出一个容易被忽略的问题：智能体的上下文是动态的。一个客服 Agent 在会话开始时只有查询权限，用户要求退货后它需要改单权限，转人工时这个权限又要收回。

静态的 RBAC 处理不了这种变化。授权模型必须跟着任务生命周期走：任务开始时签发，任务结束或超时后吊销。Session 级别的令牌有效期建议压到分钟级，宁可让 Agent 多做几次交换，也不要给它一个能活几小时的宽权限令牌。Oxo Security 给出的八项安全要求里，短时效和最小范围这两条是所有后续设计的基础。

落地顺序建议

给正在搭建 Agent 平台的团队一个可执行的路径。

第一步，盘点现有 Agent 的凭证形态。共享服务账号的要先拆，这是成本最低收益最大的一步。盘点结果按「全局凭证、Agent 级凭证、任务级凭证」三类标记，全局凭证数量目标压到零。

第二步，在网关层引入令牌交换。不用一步到位上 OPA，先在 API 网关（ Kong、APISIX 都支持 OAuth 插件）做 audience 限定的令牌签发，把「Agent 拿到的令牌只能访问声明的资源」这件事做实。

第三步，把高风险工具调用接进审批流。OWASP 十大风险里过度授权的应对措施就是工具降权加审批：删库、转账、发邮件这类操作，策略引擎判定后不直接签发令牌，转人工确认。这一步会损失自动化效率，生产环境值得。

第四步，Agent 间通信补上双向认证。子 Agent 被攻陷后冒充父 Agent 发起请求，是 Oxo Security 列的四类对手之一。每个 Agent 用独立的机器身份做 mTLS，别信内网。

这四步做完，模型层的提示注入防御（输入过滤、输出审核）依然要保留，但它的角色从主防线降级为纵深防御的一层。架构上的确定性来自授权链路，模型层面的对抗留给概率性手段。20 万伪造令牌零通过的实验说明，这条边界划清楚之后，注入攻击的天花板就被压到了「发起无效请求」的水平。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：bird网络安全 cwbird cwbird《多Agent授权的第一性原则：把模型当成已被注入的组件》