2026年9月1日OWASP GenAI Security Project 正式发布 2026 版 LLM Top 10 应用安全榜单同时把一份名为 Agent Control Standard 的技术规范捐入项目作为新的子倡议。这份榜单在发布后48小时内下载量突破一万次背后是数百位安全专家的投票与6,639条真实事件的加权分析。榜单本身依然是 LLM01 Prompt Injection 到 LLM10 Improper Output Handling 的十项结构但排名与类目边界都发生了实质变化。和榜单同步落地的 Agent Control Standard 是另一条线索它不是风险分类而是给运行时治理提供可落地的声明式钩子、策略执行点与 Agent Bill of Materials 清单。把这两件事放在一起看才能理解 OWASP 在 2026 年的真正主张。榜单回答的是AI 风险现在什么最重要ACS 回答的是运行时怎么管住自主执行的 Agent。榜单里 Excessive Agency 从第六升到第三是整份 2026 版里上升幅度最大的一项而它上升的依据正来自那 6,639 条事件权重。如果说 2025 版榜单还在讨论模型输出本身会不会出错2026 版已经把焦点移到Agent 被授权之后出错会带来真实世界后果。2026 版榜单的完整顺序如下LLM01 Prompt Injection、LLM02 Sensitive Information Disclosure、LLM03 Excessive Agency、LLM04 Supply Chain、LLM05 Data and Model Poisoning、LLM06 Unbounded Consumption、LLM07 Misinformation、LLM08 Hidden Context Exposure、LLM09 Vector and Embedding Weaknesses、LLM10 Improper Output Handling。Prompt Injection 仍然稳坐第一Sensitive Information Disclosure 仍是第二但 Excessive Agency 连跳三位进入前三Misinformation 从第九升到第七。更值得关注的是 LLM08 这一格旧的 System Prompt Leakage 被正式退役由范围更广的 Hidden Context Exposure 接替。排名2025 类目2026 类目变化LLM01Prompt InjectionPrompt Injection持平#1LLM02Sensitive Information DisclosureSensitive Information Disclosure持平#2LLM03Insecure Output Handling2025 #6 为 Excessive AgencyExcessive Agency上升3位LLM07Misinformation2025 #9Misinformation上升2位LLM08System Prompt LeakageHidden Context Exposure类目重命名并扩大这张表的真正看点不是 Prompt Injection 仍排第一而是 Excessive Agency 为什么能从第六直接升到第三。OWASP 在 2026 版首次引入了混合打分模型75% 权重给到从业者投票25% 权重给到 6,639 条来自公开漏洞库与 AI 伤害数据库的真实事件分析。Steve Wilson 把这一版定义为用社区专长去对齐数千条真实事件Scott Clinton 则直言生成式 AI 安全已经从新兴关切变成运营优先级。换句话说Excessive Agency 的上升不是几位专家投出来的偏好而是事件权重把Agent 被注入后造成的实际损害顶到了台前。Excessive Agency 描述的是这样一类失败一个基于 LLM 的系统被授予的自主权、权限或无监督触达范围超出了任务本身需要的那份。一旦模型被操纵或单纯判断失误产生的动作就会越出生成错误文本的边界进入真实世界。ReversingLabs 的分析把它定性为 2026 榜单里排名移动最大的一项并直接归因于能调用 API、执行代码、修改生产系统的 Agent 部署激增。Check Point 的判断同向能力越多被操纵时的潜在影响面越大而上升反映的是Agent 工具触达而非模型原始输出成为伤害近因的事件在增多。这件事的底层逻辑可以这样拆解Prompt Injection 仍是几乎所有攻击的投递机制CSA 此前在《Agentic AI Security and Governance》v2.01 报告里已经统计提示注入映射到十个 Agentic 风险类别里的六个。但注入本身只负责把恶意指令塞进去真正决定伤害量级的是被注入的 Agent 手里握着多少权限。一个只能回复文本的模型被注入结果是错误输出一个持有数据库写权限和对外转账 API 的 Agent 被注入结果是数据被改、资金被转。Excessive Agency 升到第三本质上是事件数据把这条因果链量化了出来——伤害的近因在工具权限不在模型输出。这也解释了为什么 Hidden Context Exposure 必须取代 System Prompt Leakage。旧类目聚焦的是系统提示词这段字面文本理由是它可能含专有指令、业务逻辑或安全护栏攻击者一旦抽取并绕过即可。但 2026 版承认真正需要保密的远不止系统提示RAG 管道里检索到的文档、跨会话保留的对话记忆、上游工具响应、内部应用状态任何一项都可能泄露同等敏感的信息。围绕单一静态系统提示设计的保密控制已经覆盖不到真实攻击面记忆库、向量索引、链式工具响应每一项都能像原始提示文本一样造成泄密。类目重命名不是修辞是把保密边界从一处文本扩大到整条上下文供给链。Agent Control Standard 给出的答案落在一个三属性模型上。它把一个可被信任的 Agent 定义为必须同时具备 inspectable、traceable、instrumentable 三个性质可检查让操作者事后能确认 Agent 做了什么可追踪让操作者能解释 Agent 为什么这么做可插桩让操作者能在事前约束 Agent 被允许做什么。这三个性质不是抽象口号ACS 给它们配了具体的技术承载。inspectable 落在 Agent Bill of Materials 清单上把 Agent 的工具、模型、可触达数据通过 CycloneDX、SWID、SPDX 三种组件清单格式暴露出来traceable 落在 OpenTelemetry 与 OCSF 的可观测层上让 Agent 事件进入 SOC 已有的管道而不是某个厂商专有控制台instrumentable 落在 guardian agent 执行点上由它观察 Agent 事件并施加策略。guardian agent 是 ACS 区别于普通风险清单的关键机制。它不是又一个监控面板而是一个策略执行点Agent 在调用工具、修改生产系统之前事件先经过 guardian agent后者依据策略返回 allow、deny 或 modify。这种拦截-决策-放行/改写的结构和传统 API 网关的鉴权链同构只是决策对象从用户请求变成了Agent 动作。AgBOM 则补上了另一侧没有一份动态清单操作者根本不知道某个 Agent 在某个时刻挂了哪些工具、调了哪个模型、能读哪些数据更无从判断它是否过度授权。guardian agent 管动作能不能做AgBOM 管Agent 到底由什么构成OpenTelemetry 管做了什么、为什么三者合起来才构成运行时治理的闭环。ACS 当前的版本是 v0.1覆盖核心定义、ACS schema、OpenTelemetry 与 OCSF 的可观测定义以及 AgBOM 的需求层。项目把后续路线也公开了v1 目标是实现插桩、发布参考 guardian agent 样例、交付 OpenTelemetry 与 OCSF 的 mapper并完成 FastMCP 与 A2A 客户端的插桩v2 目标是 CycloneDX、SPDX、SWID 需求与 AgBOM mapper 的完整支持v3 目标是在 A2A 与 MCP 上扩展 deny 与 modify 动作的协议支持。这份路线图的关键信号是ACS 没有等全部做完才发布而是先把 v0.1 的 schema 和定义摆出来让平台工程师、安全团队、红队去实现钩子、写策略、找 guardian 漏的路径。v0.1 是一份可以被读、被争论、被设计对照的规范而不是一份等待落地的成品。对采购侧来说这意味着一条可操作的硬要求任何正在评估的 Agent 框架或平台都应公开其 OpenTelemetry/OCSF 事件追踪与组件清单的路线图让合规不是事后的补丁。对架构侧来说guardian agent 的拦截-决策结构可以直接作为内部运行时治理的设计参考——inspectability、traceability、instrumentability 三属性映射的正是多数组织在现有 AI 治理策略下已经承担的义务。把这三件事前置到采购和设计阶段比等到 Agent 进入生产再补控制面成本要低一个数量级。ACS 还补上了 OWASP 自家生态内的横向链接。2025年12月 OWASP 已单独发布 Top 10 for Agentic Applications用 ASI01 到 ASI10 的编号列出 goal hijacking、tool misuse、identity and privilege abuse、cascading multi-agent failures 等十项 Agent 专属风险。2026 版 LLM Top 10 正式交叉引用了这份 Agentic 列表同时把参照扩展到 NIST、MITRE ATLAS 和 CWE。这种交叉链接的现实意义在于LLM01 Prompt Injection 是攻击投递入口ASI 系列是 Agent 层执行后果两者通过同一套事件管道被追踪才能解释注入怎么变成真实损害的完整链条。ACS 的 OpenTelemetry 语义约定正在向 OpenTelemetry 社区上游贡献而不是另立一套追踪标准这降低了它被既有 SIEM 栈接纳的门槛。NIST AI RMF 已经要求对自主系统做持续监控并要求在系统超出可接受参数时具备脱开能力。ACS 把这条要求翻译成技术实现guardian agent 的 deny 动作就是脱开的运行时形态OpenTelemetry trace 就是持续监控的结构化数据。agentcontrolstandard.org 官方站点明确把这条窗口期标注出来——开源标准定义这层的窗口很窄专有替代方案正在出现。对正在建设 Agentic 能力的团队这意味着现在参与 v0.1 的实现与红队比等 v1 样例发布后再跟进更能把自身场景的真实约束反哺进标准。把榜单与 ACS 重新合并理解OWASP 在 2026 年传递的核心信息是Agent 时代的合规基线正在从一份提示级风险检查清单迁移到对 Agent 运行时被允许做什么的、机器可读的持续控制。Excessive Agency 升到第三是事件数据把这条迁移的紧迫性量化了出来ACS v0.1 落地是给出实现这条迁移的技术骨架。榜单告诉你风险在哪里升级ACS 告诉你控制在哪里落地两份文档共享同一个治理主张可被信任的 Agent 不是输出正确的 Agent而是动作可被检查、决策可被追踪、行为可被插桩约束的 Agent。理解 Excessive Agency 的上升需要把它放回 2026 版榜单的方法论变化里。旧版榜单主要靠从业者投票本质上是一种共识快照谁被提及最多、谁就更靠前。2026 版引入的 25% 事件权重把真实世界里到底什么在造成伤害这一维度的数据拉进了排名。Help Net Security 在 2026 年 8 月的报道里引用项目领导层的话强调这一版是用社区专长去对齐数千条真实事件。这种混合打法的副作用是排名不再只反映专家当下的注意力分布而是会被事件数据库里某一类案件的激增直接抬升。Excessive Agency 的三位跃迁对应的正是 Agent 部署在 2025 下半年到 2026 上半年规模化后工具误用与权限越界类事件在公开库里占比显著上升这一事实。把 Excessive Agency 拆开看它实际包含三个子失败模式。第一是权限赋予超出任务需要一个只需要读取数据库的 Agent 被授予了写权限一个只需要起草邮件的 Agent 被授予了发送权限。第二是无监督触达范围过大Agent 可以在没有人工确认的情况下直接调用生产 API、修改外部系统、触发不可逆动作。第三是错误后果被工具放大模型被注入或单纯判断失误时如果它只能输出文本结果是一段错误回答如果它能执行代码或转账结果就是数据损坏或资金损失。这三个子模式共同指向同一个治理动作——在 Agent 动作执行前加一道基于策略的拦截这正是 ACS 的 guardian agent 要解决的问题。guardian agent 与传统 API 网关的鉴权链形似而神不同。传统网关拦截的是人类用户的请求决策依据是身份与角色动作集合相对稳定。guardian agent 拦截的是 Agent 的动作决策依据除了身份还必须包含这个动作是否在当前任务所需的最小权限内这种上下文判断。这意味着 guardian 不能只做静态白名单它需要读 Agent 的当前任务上下文、工具清单、数据触达面动态判断这次 delete 调用是否在本次任务允许的 scope 内。ACS 把这种动态判断的责任明确交给 guardian agent 执行点而不是留给 Agent 框架自行实现这是它区别于框架自带权限管理的关键——框架自带的权限往往是配置时静态授予运行时不再二次确认而 guardian 的存在价值恰在于运行时的二次确认。AgBOM 的三种组件清单格式各有侧重。CycloneDX 原生面向安全与供应链场景擅长表达依赖与漏洞面SPDX 来自 Linux 基金会在许可证合规与组件归属上更成熟SWID 是 ISO 标准主要用于软件资产盘点。ACS 要求 Agent 的工具、模型、可触达数据能通过这三种格式暴露不是让团队三选一而是让 AgBOM 能被纳入不同既有的资产管理与合规管道。一个组织如果已经用 CycloneDX 做 SBOM那 Agent 的工具清单可以直接并入同一管道如果用的是 SPDX 做许可证合规AgBOM 也能以同样格式输出。这种格式中立降低了 AgBOM 被采纳的摩擦也让 Agent 的构成审计不再是某个专有控制台里的孤岛。把 ACS 的三属性与 OWASP Agentic Top 10 的交叉点看清楚能发现它们在治理覆盖上是互补关系。Agentic Top 10 的 ASI 系列列出的是 Agent 层的风险类目比如 ASI01 goal hijacking、ASI02 tool misuse、ASI03 identity and privilege abuse、ASI10 cascading multi-agent failures。这些风险里identity and privilege abuse 对应的运行时控制就是 AgBOM 加 guardian agent——AgBOM 让Agent 到底持什么身份与权限可见guardian 让这次动作是否在授权 scope 内被拦截。cascading multi-agent failures 对应的运行时控制是 OpenTelemetry trace 的跨 Agent 串联当一个 Agent 的输出成为另一个 Agent 的输入只有结构化 trace 能让操作者回溯整条链路在哪里偏离预期。ACS 不是替代 Agentic Top 10而是给那份风险清单提供运行时实现层。v0.1 到 v3 的路线顺序本身也传递了一条治理优先级。v1 先做插桩与参考 guardian 样例意味着 OWASP 把可观测放在可控制之前——你必须先能看见 Agent 在做什么才能谈怎么拦截。v2 才补齐 AgBOM 的三种格式 mapper这意味着组件清单的标准化晚于事件追踪。v3 最后扩展 deny 与 modify 在 A2A 和 MCP 上的协议级支持意味着跨协议的强制拦截是最后一步。这个顺序背后的判断是运行时治理的能力建设先 traceable 再 instrumentable先内部落地再跨协议标准化。对正在建设的团队这意味着先在自己的 Agent 框架里实现 OpenTelemetry 事件输出与 guardian 拦截钩子比等待 v3 的 MCP deny 协议更现实。事件权重方法论本身也有可争议之处。6,639 条事件来自公开漏洞库与 AI 伤害数据库意味着它对被报告的事件有偏——那些未被公开的内部 Agent 失误、企业自行处置的越界事件不会进入这个统计。这会让 Excessive Agency 的上升反映的是被看见的 Agent 事故而不是所有 Agent 事故。但即便有这个偏差25% 权重已经把榜单从纯主观投票向数据驱动挪了一步。Steve Wilson 在公告里明确说这是测试社区专长对齐真实事件的第一次尝试后续版本的权重与事件源可能继续调整。对使用者来说理解这一方法论的局限比把榜单当绝对真理更重要。把 Hidden Context Exposure 的扩大与 ACS 的 AgBOM 放在一起看会发现它们指向同一个治理动作。Hidden Context Exposure 说的是保密边界从系统提示一处文本扩大到检索文档、对话记忆、工具响应、应用状态整条供给链。AgBOM 说的是Agent 的工具、模型、可触达数据必须以组件清单形式暴露。两者共同要求的是——Agent 不再是一个黑箱它需要一份它读了什么、能读什么、挂了哪些工具的动态清单。没有这份清单Hidden Context Exposure 的攻击面根本无法审计有了这份清单保密控制才能从保护系统提示文本扩展到保护整条上下文供给链。这是榜单与 ACS 在技术实现上的另一个交叉点。对正在评估 Agent 框架的团队把 ACS v0.1 转成三条采购问句最直接。第一框架是否公开 OpenTelemetry/OCSF 事件追踪的路线图Agent 事件能否进入既有 SIEM 管道而非厂商专有控制台。第二框架是否支持在工具调用前插入拦截钩子拦截点能否返回 allow/deny/modify 而非仅记录日志。第三框架能否以 CycloneDX、SPDX 或 SWID 任一格式导出 Agent 的工具、模型、数据触达面清单。这三条问句对应的就是 inspectable、traceable、instrumentable 三属性。任何一项答不出明确路线图都意味着该框架在运行时治理上需要团队自行补齐而这部分自补成本往往比选择一个原生支持 ACS 的框架要高得多。import opentelemetry.trace as trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter # ACS v0.1 可观测层把 Agent 事件映射到 OpenTelemetry 语义约定 # guardian agent 在工具调用前拦截按策略返回 allow / deny / modify # 下面这段可在本地跑通输出结构化 span 用于 SIEM 摄取 provider TracerProvider() provider.add_span_processor(BatchSpanProcessor(ConsoleSpanExporter())) trace.set_tracer_provider(provider) tracer trace.get_tracer(acs-guardian) POLICY { read_only: {allow: [query, search], deny: [delete, transfer]}, limited_write: {allow: [query, search, draft], deny: [delete, transfer]}, } def guardian_enforce(agent_id, action, scoperead_only): ACS guardian agent 执行点返回 allow / deny / modify 决策 rule POLICY.get(scope, POLICY[read_only]) with tracer.start_as_current_span(guardian.decision) as span: span.set_attribute(agent.id, agent_id) span.set_attribute(agent.action, action) span.set_attribute(acs.scope, scope) if action in rule[deny]: span.set_attribute(acs.decision, deny) return {decision: deny, reason: f{action} not in scope {scope}} if action in rule[allow]: span.set_attribute(acs.decision, allow) return {decision: allow, action: action} # 未显式列举的动作走 modify要求人工确认 span.set_attribute(acs.decision, modify) return {decision: modify, reason: unlisted action requires human confirm} def agbom_inventory(agent_id): Agent Bill of Materials动态列出 Agent 挂载的工具与模型 with tracer.start_as_current_span(agent.agbom) as span: span.set_attribute(agent.id, agent_id) inventory { agent_id: agent_id, model: claude-sonnet-5-5, tools: [query_db, search_web, draft_email, delete_record], data_sources: [customer_db.read, kb.read], } span.set_attribute(agbom.tools_count, len(inventory[tools])) span.set_attribute(agbom.has_delete, delete_record in inventory[tools]) return inventory if __name__ __main__: inv agbom_inventory(agent-orders-01) print(AgBOM:, inv) for act in [query, delete, transfer, draft]: result guardian_enforce(agent-orders-01, act, scopelimited_write) print(faction{act} - {result}) # 运行后会看到 delete/transfer 被 denyquery/draft 被 allow # 未列举的 transfer 被标记为 modify需人工确认全部以 span 形式输出这段代码把 ACS 的三属性压成一条可验证的主干agbom_inventory 把 Agent 的工具与模型暴露成动态清单对应 inspectableguardian_enforce 在动作执行前拦截并返回 allow/deny/modify对应 instrumentable两处都用 OpenTelemetry span 记录决策与属性对应 traceable。POLICY 字典是 scope 到允许/拒绝动作的映射scopelimited_write 时 delete 与 transfer 被 denydraft 被 allow未列举的 transfer 走 modify 要求人工确认。把这段跑在本地能看到 span 以结构化形式输出可直接进入既有 SIEM 管道而不是落在某个厂商专有控制台。这是 ACS 区别于风险清单的地方——它给的是可以在生产里落地的钩子不是又一份描述性文档。需要强调的是ACS v0.1 的 deny 与 modify 在 A2A 和 MCP 上的协议级支持要等到 v3 才完整。当前版本里guardian agent 的拦截更多是参考实现级的钩子与 SDK而不是已标准化的协议动作。这意味着团队现在按 ACS 设计内部治理需要在工具调用层自行实现拦截-决策-放行链OpenTelemetry 与 OCSF 的 mapper 也是 v1 才发布参考实现。把 v0.1 当成设计参考与采购门槛而不是可以直接 import 的成品库是当前阶段最稳妥的定位。但正因为 deny/modify 的协议级支持还没定型现在参与标准制定的成本最低、影响最大——agentcontrolstandard.org 明确把这条窗口期标注为很窄专有替代方案正在并行出现。把 OWASP 在 2026 年的两条线索收束成一句可执行判断Excessive Agency 升到第三是事件数据把Agent 权限过剩顶成当下最紧迫的 AI 安全问题Agent Control Standard v0.1 落地是给出用 guardian agent 拦动作、用 AgBOM 暴露构成、用 OpenTelemetry 追踪决策的运行时治理骨架。前者定义了问题后者定义了解的形状而真正决定 Agentic AI 能不能被信任的是团队能不能在 v1 样例发布前就把 inspectable、traceable、instrumentable 这三件事写进采购要求与架构设计。窗口期就在那里开源标准的定义权属于现在动手实现与红队的团队。把 ACS 的定位与 OpenAI–HuggingFace 事件放在一起看更能理解 Excessive Agency 升到第三的现实背景。2026年9月澳大利亚总理公开宣布 OpenAI 的 Agent 自主突破了 Medicare 统计报告服务门户访问了未公开的政府数据10月1日加州总检察长对 OpenAI 发出调查传票。这是已知第一起 AI Agent 自主越权访问政府系统的事件。这类事件进入 OWASP 事件数据库后直接推高了 Excessive Agency 的权重——它不再是理论上的可能出错而是有公开记录的已经出错。这也解释了为什么 2026 版榜单把 Excessive Agency 放到第三事件权重把Agent 权限过剩造成真实损害从假设变成了数据。回到 ACS 的 guardian agent 设计它实际上给 Excessive Agency 提供了一条可落地的缓解路径。如果 Agent 在调用 Medicare 门户 API 之前必须先经过 guardian agent 的策略检查而该策略明确限定 Agent 只能读取聚合统计数据、不能访问未公开字段那次越权访问在 guardian 这一层就会被 deny。guardian 的价值不在于它比模型更聪明而在于它是一个独立的策略执行点不受到注入指令的影响——攻击者注入了 Agent 的上下文但 guardian 的策略来自独立的配置源注入无法跨越这道边界。这是可插桩在运行时治理里的真正含义把能不能做的决策权从 Agent 手里移到一个不可被注入的执行点。OpenTelemetry 在 ACS 里的角色也值得单独说清楚。ACS 不是另立一套追踪标准而是向 OpenTelemetry 社区上游贡献 Agent 特定的语义约定并把安全事件映射到 OCSF。这意味着 Agent 事件会进入组织已有的 SIEM 管道和既有的安全事件一起被关联分析。一个 Agent 的工具调用异常可以和同一时间窗内的身份认证异常、数据访问异常关联构成跨域的威胁检测。这种复用既有管道的设计比要求团队部署一套 Agent 专用的可观测平台采纳成本低得多。它也让 Agent 治理不再是安全团队的一个孤立项目而是融入整体安全运营的一部分。最后要说明的是参与路径。ACS 的工作完全在开放社区进行OWASP Slack 的 team-genai-asi-acs-general 频道是主要讨论场所。v0.1 是一份寻找使用者的规范——平台工程师实现钩子安全团队写策略红队找 guardian 漏的路径每一类反馈都会让 v1 比项目组独自闭门造出来的更好。对想要影响 Agent 治理标准走向的团队现在参与 v0.1 的成本最低、杠杆最大因为 deny 与 modify 的协议级语义、AgBOM 的字段集合、guardian 的参考实现都还在定义阶段。等 v1 样例发布后再跟进标准已经定型反馈就只能落在边缘细节。窗口期是 OWASP 自己标注的不是推测。