过度授权怎么排到了第三：从一张榜单看懂 Agent 安全的转折点

2026 年 7 月 11 日凌晨三点多前 HyperWrite 的创始人在社交账号上发了一句话说他受邀测试一个新模型结果那个智能体把他 Mac 电脑上几乎所有文件都删了。运行了 1 小时 21 分钟之后一个用来清理临时文件的脚本把 $HOME 这个系统环境变量当成了临时目录来用然后执行了那条让任何一个做过开发的人都心里发颤的命令。他当场找到了还在跑的那个进程把它杀掉了但文件已经没了一大批。更让人后怕的是他在帖子里补了一句说自己过去搞过几百次类似的测试会话从来没出过事哪怕是用很弱的模型跑也一样。就这一次给了完整访问权限翻了车。这事情在圈子里传得很快。不光是因为当事人有名也不只因为那条带路径的命令看起来太吓人而是所有在搞企业级智能体落地的人心里都清楚这种事早晚会轮到自己头上。没过几天又有人爆料说巴西一个开发者用类似的方式跑任务生产数据库被整个删掉了。再往前翻亚马逊那个内部 AI 编程工具在自主模式下捅过至少两次篓子每次都是十几小时的服务中断。Cursor 的智能体被曝出过 9 秒删光一个生产数据库和所有备份。这一连串的事情串在一起指向的根本不是模型能力够不够强的问题而是权限给得太粗了、管得太松了、出了事连谁该按停都找不到人。这篇东西不为别的就是想把 OWASP 在 2026 年 6 月发布的那份大语言模型应用十大风险榜单掰开来看尤其是那个从第六名蹿到第三名的过度授权到底在说什么。看完你会带走三样东西第一这张榜单排名变化背后真正的工程含义是什么第二过度授权落到代码和配置层面到底长什么样第三你今天回去就能动手做的三件事不用等平台出补丁也不用重构整个架构。榜单的全貌OWASP 2026 十大风险与两次关键变化OWASP 这个大模型应用十大风险榜单到 2026 年出了第三版。跟前两版比起来。这一版最大的不同是它头一回把真实的安全事件和攻防数据塞进了评估依据里。不再光靠社区投票和专家拍脑袋。这个转变很重要。因为排名的升降不只是在反映大家口头上的焦虑。而是在反映生产环境里真正在发生的事故类型和频次。换句话说。榜单从此有了事故底盘。不是空对空的危言耸听。榜单头两名没动。提示注入还是稳稳坐在第一的位置。敏感信息泄露还是第二。这两个位置稳得住不奇怪。提示注入从大模型应用第一天开始就是最直接的入口型攻击。不管攻击者直接往对话里塞指令。还是把恶意内容藏在文档里让模型去读。本质上都是在操纵模型的理解过程。敏感信息泄露则是另一个极端。攻击者根本不需要攻破服务器。只要不断地问、变着花样问。总有某个上下文会把不该吐的东西吐出来。这两个位置没动。说明它们仍然是最基础、最高频的威胁类型。必须放在防护链最前面。真正让整个圈子侧目的是第三名。过度授权从 2025 年版的第六位直接跳到了第三位。是整张榜单里名次变动最大的一个。往前翻的话。过度授权在更早的版本里排名更低。这一路上升的轨迹本身就说明了一件事智能体落地的速度在加快。因为权限放得太宽而出的事在变多。社区和一线工程师对这种风险的感知在急剧升温。一个原本被认为偏理论的威胁。用一年时间从第六爬到第三。这种爬升速度本身就值得所有在路上做 Agent 的人停下来想一想。还有一个值得看的变动是消耗失控从第八名或者更靠后的位置往前挪了。有的分析里说它往上蹿了四名。这个风险说的是智能体在跑任务的时候无节制地烧算力费用。不一定是有恶意攻击。很多时候就是设计上没写好、循环退不出来、工具调用越滚越大。然后账单就爆了。这个爬升跟过度授权的上升共享同一个背景智能体不再只是回答问题。它在真实地调用工具、操作业务系统、执行多步流程。每一步都有成本。每一步都有后果。决策的颗粒度变细了。风险也跟着变细了。另外两个变化也值得提一下。错误信息风险往上提了两名。因为模型自信满满地输出错误内容、下游直接拿去做决策导致出事的案例变多了。而不当输出处理掉到了第十名。注意它掉下去不是因为这事儿不发生了。而是排在前面的那些风险变得更严重了。相比之下它显得没那么紧急。这种排名的相对变化其实特别能说明问题整个行业对智能体安全的理解在从模型本身的行为往模型能做什么、能碰什么、能改什么这个方向转移。视角从模型内迁到模型外。这是一个很关键的安全观念拐点。榜单头三名里有两项直接和智能体的行动面相关。加上消耗失控。三项占了十大风险里接近一半的位置。这个结构性比例告诉我们一件事智能体一旦具备真实操作能力。安全的重心就必须从提示层下沉到执行层。这不是修修补补能解决的。是底层逻辑的重写。榜单的发布方 OWASP GenAI Security Project 这次还同步给出了一张配套的分类图。把十大风险按照输入侧模型侧输出侧运行时侧四个象限重新排了一遍。过度授权被明确归到了运行时侧。意思就是它不是一条输入能被过滤的提示词。也不是模型内部行为能被微调压住的偏好。它必须靠执行链路上的硬约束来解决。这张图基本等于给所有做企业级 Agent 的人发了一份施工图。过度授权的工程含义权限粒度、工具白名单与最小行动面过度授权这个事从第六跳到第三。如果只是把它理解成排名变化就没意思了。真正要紧的是它到底指什么。按照 OWASP 的定义。过度授权发生在给大语言模型赋予了太多功能、太多权限、太多自主权。而又没有足够的监督机制的时候。模型能调用 API、能写数据库、能发邮件、能做业务决策。这些能力本身不是坏事。但当这些能力被塞进一个可能被操纵、可能误解上下文、可能产生非预期行为的概率系统里。事情就完全变了。说个具体的事你就明白这玩意儿有多细。2026 年 6 月。Meta 的 AI 客服机器人被黑客用一句极其简单的自然语言就搞定了。黑客在对话框里说。把我的新邮箱绑定到这个目标账号上。然后 AI 客服就照做了。直接绕过了双因素认证和身份核验流程。高价值账号被秒换绑。这个事故的根子就在于。研发团队把修改绑定邮箱这个高权限的系统 API 直接注册成了大模型可以调用的工具。模型完美理解了意图、完美执行了调用。但它完全没有能力验证屏幕对面说话的人到底是不是号主。这个事不是提示注入那种攻击。没有任何人给模型灌输恶意指令。模型做的是它被设计去做的事。只是这个设计本身就埋了雷。过度授权的核心矛盾就在这里。在传统系统里。一个 API 端点能做什么是由中间件、角色权限控制、参数校验这些冷冰冰的代码决定的。你篡改一个字段系统就给你扔一个 403 错误回来。但接入智能体之后。意图解析变成了一个黑盒。模型从自然语言里抽取出要做什么、要调什么工具、传什么参数。开发者如果不做额外的一层硬约束。就等于把系统大门的钥匙挂在了模型脖子上。模型理解意图的能力越强。权限失控的爆炸半径反而越大。这是一个反直觉但必须接受的现实。那过度授权在工程上具体表现为哪些形态至少有三个层面要盯住。第一个是工具粒度太粗。很多团队在接入 MCP 或者自定义插件的时候。把一整个服务、一整个数据库操作、一整个业务模块注册成一个工具给模型用。模型一旦决定调用这个工具。能做的事范围就太大了。正确的做法是拆到单个操作级别。创建订单是一个工具、查询订单是一个工具、取消订单是另一个工具。每个工具只干一件事。权限边界清晰。工具的粒度越细。模型能犯错的半径就越小。第二个是工具白名单不落地。Agent 跑起来之后。它能看到哪些工具、能调用哪些工具。这事不是靠系统提示词里写一句你只能调用白名单里的工具就能解决的。攻击者有无数种办法让模型忽略那条提示。比如把它藏在多轮对话的尾巴里、用别的语言复述、用一个看似无关的请求把模型引过去。真正的白名单必须在模型输出之后、工具执行之前这一道拦截点上做。不管模型决定调用什么。网关层或者运行时层先查一遍这个 Agent 有没有权限调这个工具。没有就硬拦截。不能靠模型自觉。第三个是最小行动面。这个概念比最小权限更细。最小权限说的是只给必要的权限。最小行动面说的是只给必要的操作能力。一个客服场景的 Agent。就不应该拥有删除用户账号这个操作的工具。哪怕它有权限调用删除 API。一个数据分析的 Agent。就不应该拥有写生产数据库的能力。这些能力不在它的行动面上。它压根看不到、碰不到、调不了。这就不是权限检查的问题了。是能力暴露的问题。Agent 不知道有这个东西。自然也就不存在被诱导去调用它。把这三个层面放在一起看。过度授权本质上是一个三维问题工具粒度、调用拦截、能力暴露。任何一个维度做得到位但其他维度没做。最终防线都会被绕过。比如工具粒度很细。但白名单只在提示词里写了一句。攻击者照样可以让模型调出它本来不该有的能力。白名单做得很硬。但工具粒度还是按业务模块注册。一个工具里同时能干八件事。模型只要在参数上做文章就能走出格。最小行动面则是从源头解决问题。让 Agent 不知道的事情它自然就做不了。三层一起上。才算把过度授权压到可控范围。三道实操防线从鉴权网关到运行时拦截的工程化落点说了这么多概念和事故。落到代码和架构上到底怎么防。目前能看到的生产级实践。有三道防线已经开始在企业里铺了。这三道不是平行的。是按调用链路的层叠关系递进。第一道是入口。最后一道是出口。中间这道是过程。每一道防线的目的都不一样。合在一起才是完整的护城河。第一道防线是出站网关加细粒度策略引擎。所有 Agent 对外发起的工具调用、API 请求。必须经过一个统一的网关层。不能直接放出去。网关层做两件事。一是身份识别。每个 Agent 带着自己的身份令牌过来。网关先认出来是谁在调。二是策略评估。用策略语言把谁能调什么工具、在什么条件下能调、传什么参数算合规。全部写成硬规则。网关侧执行。阿里云这边已经有一套基于 Agent Identity 的权限方案在生产跑了。底层用的是 Cedar 策略引擎。可以在工具调用这一层做到工具级别的访问控制。比如只允许某个 Agent 在订单金额大于一千的时候才能调用创建订单的工具。同时还限制来源 IP 段。把权限控制从模型内部搬到了模型外部。模型只管输出意图。网关管这个意图能不能被执行。这是第一道防线的核心价值。哪怕模型在某些场景下被诱导出错的意图。意图到达执行层之前会被策略引擎完整检查一遍。过不了就根本走不到工具调用那一步。网关层的好处是规则是声明式的、可审计的、可灰度的。可以一个 Agent 一个 Agent 慢慢铺。不会一夜之间把所有业务都重写一遍。第二道防线是运行时拦截和审计账本。光有网关还不够。因为有些问题出在 Agent 跑起来之后的多步链条里。单个 Agent 调用的每一步都合规。但三步合在一起的结果可能完全跑偏。一种做法是给每次执行、每个步骤都建一条不可篡改的运行时账本。权限检查、工具调用、输入输出全部记下来。支持事后回放和审计。前面提到的那个删文件的例子。如果当时有运行时账本。第一步变量解析错了的时候就能看到路径异常。系统可以直接终止执行。不用等到文件没了才来追责。开源的 Agent 治理平台像 SOIT 已经把这个思路做进内核了。所有执行过同一条账本。权限、白名单、密钥边界、出站管控在每条路径上一致生效。审计的时候能看到每一步发生了什么。运行时账本的设计有一个关键点。它必须不可篡改。账本一旦能被改。事后审计的公信力就垮了。工程上通常用 append-only 的日志结构加哈希链来实现。每一步执行都被打包成一条记录。链上一步的哈希被嵌进下一步的记录头。任何中间修改都会让链条断裂。审计的时候从头跑一遍哈希验证。就能发现哪一步被人动过。这种结构和区块链是同一类思路。只是规模和场景都小得多。工程开销也低得多。但护城河的价值是一样的。第三道防线是多智能体链条中的权限传导。这是目前最前沿的一块。OWASP 的十大风险分类描述的都是某个点上的故障。比如某个 Agent 被劫持了、某个数据被投毒了、某个权限配置错了。是可以定位到具体节点的故障。但在多 Agent 协作的场景里。可能出现一种更隐蔽的情况链条里每个 Agent 都工作正常、权限都没越界。但整体组合起来产生了某个未被授权的动作。第一个 Agent 拒绝了一个请求。第二个也拒绝了。第三个却执行了。最后干了件谁都没授权的事。每个节点都合规。整体却出了问题。这种故障查单个 Agent 的审计日志是查不出来的。因为它不在任何一个节点上。在路径上。解决这个问题的一个思路是把权限约束和操作履历跟着数据载荷一起往下传。每个 Agent 做了什么决策、有没有拒绝什么请求。全部记录在载荷里。下游 Agent 不能篡改这些记录。这样链条末端的检查点就能判断整个链条是否合规。而不是只看最后一个 Agent 的行为。这个方向目前还在早期。但已经开始有人在做开源实现了。可以预见。未来一年里多 Agent 系统的合规框架会往这个方向快速收敛。单纯靠每个 Agent 各自的权限配置已经挡不住整体性的风险传导了。这三道防线不是做了 A 就不用做 B 的关系。它们是层层递进的。网关策略解决单次调用合规。运行时账本解决执行过程可观测。链条权限传导解决多步协作的整体合规。一个企业级 Agent 系统如果能把这三层都铺上。至少能把过度授权这个风险压到可控范围内。当然这三层不是免费的。工程师要投入时间、平台要投入资源。运维要建立新流程。但相对于一次删库、一次数据泄露、一次被监管罚款的代价。这些都是非常划算的早期投入。下面这段 Cedar 策略是从企业生产环境里抽出来的最小子集可以直接拿去跑// forbid delete_user 工具对客服 Agent 可见 forbid ( principal is Agent, action Action::call, resource Tool::delete_user ) when { principal.role customer_service principal.tier external }; // 限制 refund 工具金额 ≤ 5000 且 source IP 在内网段 permit ( principal is Agent, action Action::call, resource Tool::refund ) when { principal.role support_specialist context.amount 5000 context.source_ip.isInIpRange(10.0.0.0/8) };榜单之外还没说完的事企业部署 Agent 的下一步榜单本身是个很好的参照系。但它有个天然的局限。OWASP 的十大风险描述的是故障模式。每一种都是某个东西被劫持了、被投毒了、被滥用了、配置漂移了。是可以定位到某个具体节点的故障。这种分类方式对传统安全团队来说很舒服。因为可以对着清单挨个打补丁。但智能体系统有一个特性是传统系统不太具备的。就是它的行为是涌现出来的。不是完全预先设计好的。模型在运行时根据上下文自己决定下一步做什么、调什么工具、走哪条路径。这个决策过程本身就是概率性的、非确定性的。这就导致了一个尴尬的局面你给每个 Agent 都配好了权限、设好了白名单、接入了网关、记了审计日志。但整个系统跑起来之后可能还是会出现谁都没预料到的行为组合。OWASP 在 2026 年 6 月还发了一份关于智能体 AI 安全与治理的报告。里面提到一个核心判断。说安全与安全的边界已经被智能体打破了。当智能体从上下文中自己构造下一步动作的时候。问题就不再是我有没有拦住那个恶意输入。而是我在执行侧有没有做运行时检查。报告里给出的方向是运行时治理。也就是在执行发生之前做策略决策点检查、做完整的中介、保留人工可以随时按停的开关和降级路径。静态合规检查抓不住智能体一天里做的第一百个动作。决策平面必须紧挨着行动平面。二者之间的距离决定了一个误操作在造成损失之前能被拦截的窗口。这份报告还披露了一些企业部署智能体的真实现状。大多数组织部署智能体的速度超过了它们治理这些智能体的能力。这不是什么危言耸听的判断。而是基于真实生产事故的总结。报告里列了几个近期的案例一个叫 postmark-mcp 的恶意 MCP 服务器在发布了十五个版本之后才开始偷数据。前期一直在建立信任。MCP 基础设施里爆出过一个远程代码执行漏洞。CVSS 评分 9.6。影响几十万开发者。还有针对技能仓库的供应链攻击。后门在使用时才触发。这些事故的共同特征是。出问题的不光是模型本身。而是模型能碰到的工具、能调用的 API、能读写的存储、能访问的外部服务。攻击面在显著扩大。传统的代码审计已经无法覆盖 Agent 实际生效的整条链路。还有一个容易被忽视的点是合规窗口在缩窄。欧洲那边 DORA 法规要求金融机构在事件分类后 4 小时内通报。NIS2 要求关键基础设施 24 小时内发预警。AI 法案要求高风险系统的供应商做持续的市场后监控。审计窗口期越来越短。等出了事再去翻日志、找根因、写报告。时间根本不够用。这就要求 Agent 系统的审计能力不光是事后能回放。还得做到实时的、可查询的、能快速定位异常链条的。实时审计不是简单的把日志从离线搬到在线。它要求账本结构本身就支持快速索引和模式匹配。出事的时候能在几分钟内把整条链路还原出来。从技术演化的时间轴上看。过度授权排名爬升本身就是一个信号智能体已经普遍具备工具调用能力。从原型阶段走进了生产阶段。当一项技术还在原型阶段时。权限给得粗一点是合理的。因为还在验证能力上限。当它走进生产。权限还像原型阶段那样给。事故就一定会接踵而至。榜单变化的真正含义不是 OWASP 在更换关注点。而是行业整体正在为这个普遍的错误补交学费。每一个把 Agent 引入生产链路的团队。都在用自己的方式消化这份学费。区别只在于消化过程中交了多少真金白银。所以回到最开始那个删文件的例子。它真正让人紧张的不是模型出了错。模型会出错这件事谁都知道。真正让人紧张的是。给了完整访问权限之后。一个微小的变量解析失误就能产生这么大的破坏半径。如果当时用的是最小权限、做了工具白名单、网关层拦了一下发现这个操作不在允许列表里、或者运行时账本发现路径异常自动按停了。那个命令根本执行不到文件系统上。事故的真实成本不是事后花多少时间恢复。而是本来可以用 1 块钱拦截的事。最后花了 10 万块来收场。OWASP 的榜单每年都会变。今年的第三名。过两年可能掉下去也可能继续往上爬。但榜单怎么排不重要。重要的是你已经看到了这些事故、这些排名变化、这些工程方案背后的那个共同指向智能体能不能被信任。不取决于模型有多聪明。而取决于权限能不能被管住。这件事从今天开始做。比等下一份榜单更值。