核心要点
风险重排的信号：OWASP 2026 版（2026-08-06 发布）中 Prompt Injection 保持第 1，Excessive Agency 从 2025 版第 8 位升至第 3 位——直接反映 Agentic AI 部署爆发后「权限过度授予」成为最高频被利用的风险（poolId P-401）。
首次实证化：2026 版首次纳入 6,639 起真实安全事件数据，清单从专家共识升级为实证风险排序，可直接指导企业安全投资优先级（poolId P-402）。
Hidden Context Exposure（第 7 位）：原 System Prompt Leakage 扩展更名，覆盖 RAG 检索文档、工具调用结果、Agent 间通信等所有隐藏上下文的意外暴露——检索进上下文的文档既是能力来源也是攻击面。
设计原则：最小权限（工具白名单 + 参数级约束）、策略前置检查（工具调用前执行策略判定，如 asago/OPA 式策略即代码）、上下文隔离（隐藏内容标注与脱敏）、人在回路的高危操作确认、全链路审计。
边界意识：Top 10 是风险排序框架而非修复清单；Prompt Injection 仍居首位意味着「权限收紧」不能替代输入侧防御，两者必须叠加。
简要回答
Excessive Agency 升到第 3，是因为 2026 年 Agent 部署爆发：LLM 一旦拥有工具调用、代码执行、API 访问能力，「给了过多权限」就从理论风险变成最高频的实际事故类型，OWASP 首次用 6,639 起真实事件验证了这一点。我的设计思路是四层：一是权限层，工具白名单加参数级最小权限，读写分离、高危操作需人工确认；二是策略层，每次工具调用前跑一次策略即代码检查（OPA/asago 式），把治理规则变成可执行拦截；三是上下文层，针对 Hidden Context Exposure 做隐藏上下文标注与脱敏，RAG 文档进入上下文前先做敏感信息过滤；四是审计层，全链路记录工具调用与决策依据，保证事后可取证。同时要强调：权限收紧不能替代 Prompt Injection 的输入侧防御，两层必须叠加。
标准回答
一、为什么 Excessive Agency 升得这么快
2025 版的 Top 10 主要反映「对话式 LLM」时代的风险结构：输入侧攻击（Prompt Injection）和输出侧泄露是主角。2026 版发布时（2026-08-06），产业重心已转向 Agentic 部署——模型直接持有工具、代码执行和 API 凭据。此时风险结构发生变化：攻击者不需要精巧的越狱，只要诱导 Agent 用已有权限做越权操作即可。Excessive Agency 从第 8 升至第 3，正是这一转变的量化体现。更关键的是 2026 版首次纳入 6,639 起真实事件数据（poolId P-402），使这个排序不再是专家直觉，而是实证结论。
二、Agentic 安全设计的四层架构
权限层（最小权限）：为每个 Agent 建立工具白名单，权限按「工具 × 参数 × 频率」三维度收紧；读写操作分离，删除、支付、对外发送等高危操作默认需要人工确认或二次授权。凭据按任务下发、短时效，不给 Agent 长期持有广域凭据。
策略层（策略即代码）：在工具调用执行前插入策略检查点，用 YAML/OPA 类规则表达「什么场景下什么操作被允许」，例如 Red Hat asago 的思路——把治理要求编译为调用前自动执行的策略判定（poolId P-424）。策略层的好处是规则可审计、可版本化，不依赖模型自觉。
上下文层（防 Hidden Context Exposure）：OWASP 2026 把 System Prompt Leakage 扩展为 Hidden Context Exposure（第 7 位），覆盖 RAG 检索文档、工具返回结果、Agent 间通信的意外暴露（poolId P-401）。对策：进入上下文的每段内容标注来源与敏感度，RAG 文档入库前做敏感信息过滤，输出前做隐藏内容泄露检测。
审计层（可取证）：全链路记录工具调用、参数、模型决策依据与策略判定结果，保证事后能重建攻击路径。没有审计层的防御无法验证是否被绕过。
三、诚实的边界
Top 10 是风险排序框架，不是修复清单；Prompt Injection 仍居第 1，意味着所有「权限收紧」措施都建立在输入可能被污染的前提下——输入侧防御（内容过滤、指令与数据隔离）与权限侧防御必须叠加，不能互相替代。另外，2026 版的实证数据主要来自已报告事件，存在幸存者偏差，未披露事件的分布可能与公开数据不同。
常见误区
⚠️ 常见踩坑
误区一：「Excessive Agency 就是权限管理问题，收紧 token 就行。」 错。它覆盖权限、功能与自主性三个维度：工具数量过多、单个工具权限过宽、以及缺少人工确认的自主执行链都属于 Excessive Agency，仅收紧凭据只解决其中一层。误区二：「系统提示不告诉用户就算防住了 Hidden Context Exposure。」 错。2026 版已把范围扩展到 RAG 检索文档、工具调用结果与 Agent 间通信——任何进入上下文的隐藏内容都是暴露面。误区三：「有了 Top 10 清单就能照单修复。」 Top 10 是风险排序与投资优先级框架，每项的落地形态随业务差异极大，且清单基于已报告事件，存在幸存者偏差。误区四：「权限收紧后可以放松 Prompt Injection 防御。」 恰恰相反，权限越大越要防注入，两者是叠加关系。
追问
追问 1：如果 Agent 必须持有高权限工具（如数据库写操作），你会如何降低 Excessive Agency 风险？
核心思路是**「权限可持有但不可滥用」，具体分四层收口。第一是参数级约束**：不限制「能否调用」，而是限定可操作的表、行范围与字段，把广域写权限拆成窄域白名单。第二是速率与频次限制：单位时间内的写操作上限可拦截大部分被诱导的批量破坏。第三是留痕与异步复核：所有写操作记录完整上下文（触发指令、模型推理、参数），高危操作进入异步复核队列。第四是影子模式放量：新 Agent 先以只读/影子模式运行，观察调用分布无异常后再逐步放开写权限，避免一步到位授予生产权限。
追问 2：策略前置检查（policy-as-code）会不会成为延迟瓶颈？如何权衡？
延迟本身通常不是瓶颈：OPA 类本地策略引擎单次判定在毫秒级，相对 LLM 推理耗时可忽略；真正的成本在策略维护与误拦截率。权衡方式有三：一是风险分级——低风险操作走轻量规则快速放行，仅高危操作走完整策略链加人工确认；二是规则回归测试——把历史调用日志作为策略变更的回归集，防止新规则误伤正常业务；三是用审计数据持续校准——定期复盘拦截记录，把误拦截高的规则降级为告警、把绕过高发的规则升级为硬拦截，让策略精度随部署时间提升而非退化。
追问 3：Hidden Context Exposure 与间接 Prompt Injection 是什么关系？
二者共享同一个攻击面——进入上下文的不可信内容，但攻击目标不同。间接 Prompt Injection 关注外部内容如何操纵模型行为：检索文档里埋入指令，诱导 Agent 执行越权动作；Hidden Context Exposure 关注内部内容如何泄露给用户：系统提示、RAG 内部文档、工具调用结果被复述或诱导输出。同一份检索文档既可能是投毒载体，也可能本身含敏感信息，因此防御手段高度重叠：来源标注、信任分级、入库前过滤对两者都有效；但检测目标必须分开配置——注入检测看「是否试图改变指令流」，暴露检测看「输出是否包含隐藏上下文特征」，混为一谈会漏检。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习