R

E02 Agent 权限越界事故剖解

创建 2026-06-19 更新 2026-06-20 0 条双链 Agent 安全与权限 专题 AI 整理

E02 Agent 权限越界事故剖解

概念节点（A02 漂移、A03 子 agent 继承、A04 confirmation 语义）已经把”为什么会越界”讲到了病理层；本节点要做的是验尸——把真实发生过的权限越界事故摊在解剖台上，看那条”意图→授权→动作”的链条到底在哪一刀断的，再从尸体上反推出本该焊在系统里的授权约束。这是一篇事故剖解，不是概念复述：判断主轴是「Agent 的权限越界，绝大多数不是身份被伪造、也不是墙被打穿，而是一个持有合法身份、合法权限的 agent，被诱导去做了授权范围内、却超出用户原始意图的动作——这类’授权内越权’恰恰是身份系统和沙箱都照不到的盲区」。

[!warning] 事实接地声明（读前必看） 本节点剖解的两起事故：**事故甲（Postmark MCP 投毒）**是有公开报道的真实事件，关键事实经 WebSearch 核实，仍有数字标〔待核实〕；事故乙（跨 agent 权限提升 / confused deputy 链）作为结构化代表性失败模式呈现——它综合了 2025 年多份安全研究中反复出现的攻击形态，不指向单一具体公司、不锚定具体日期、不编造损失金额。凡标注”（模式，非具体事件）“处，请当作攻击范式而非新闻事件读。

§0 为什么用”授权内越权”框架，而不是”被黑客攻破”框架

读者脑中的默认事故框架是”系统被攻破”——有人偷了凭证、绕过了认证、提了权。这个框架对传统系统成立，但用在 agent 事故上会把病灶找错位置。

Agent 时代最危险的一类事故，攻击者根本没有伪造身份，也没有突破任何权限边界。agent 用的是它本来就该有的真实身份，调的是它本来就被授予的合法工具，每一次系统调用在访问控制看来都”合规”。出事的是：这个合法动作偏离了用户最初委托的意图。send_email 是合法权限，但”发邮件时静默抄送给攻击者”是意图外的；读文件是合法权限，但”把读到的密钥回传到外部”是意图外的。

这就划出了两个不同的事故类别，对应两套完全不同的防御位置：

事故框架病灶位置防御该建在哪身份系统能挡吗
被攻破（unauthorized access）身份/认证层被绕过认证、凭证保护、MFA能
授权内越权（authorized-but-misaligned）合法权限被诱导用于意图外动作任务级最小授权 + 副作用确认门 + 出站管控不能

本节点剖的两起，都是第二类。这正是 E01 微软方案”失 2”早就点破的洞——身份解决”它是谁”，解决不了”它此刻该不该做这件事”；E02 是把那个洞的现实代价摊开看。

§1 事故甲 · Postmark MCP 投毒：合法工具里藏一行授权外副作用

事故还原（真实事件，关键事实经核实）

2025 年 9 月披露的一起供应链事故，被 Koi Security 称为”全球首例真实世界的恶意 MCP server”：npm 上一个名为 postmark-mcp 的包（提供 send_email 等邮件工具给 agent 调用）是对合法同名 GitHub 项目的仿冒——其发布者复制了合法代码，仅新增一行逻辑：当 agent 调用 send_email 发信时，在收件人之外**静默追加一个隐藏抄送（BCC）**到攻击者控制的地址（phan@giftshop[.]club），把本应只发给合法收件人的邮件副本回传给攻击者。恶意逻辑引入于 v1.0.16（2025-09-17 发布）——此前 15 个版本均无后门；该包披露时约 1,500 次周下载（来源：Koi Security 博客披露，经 The Hacker News / SC Media / Dark Reading / Snyk 等多家 2025-09 报道交叉印证，WebSearch 2026-06-19 核实；受影响的具体组织数〔待核实〕，不在此编造）。

解剖：链条在哪一刀断的

按”意图→授权→动作”三段拆：

  • 意图：用户/上游 agent 的原始意图是”把这封邮件发给收件人 X”。
  • 授权：agent 被授予了 send_email 工具权限。这一步完全合法——任务确实需要发邮件。
  • 动作：实际执行的是”发给 X 并 静默 BCC 给攻击者”。多出来的 BCC 动作，在 send_email 这个粗粒度权限的覆盖范围之内（工具有权决定收件人字段），却完全在用户意图之外。

断点在”授权”与”动作”之间：send_email 这个 scope 表达的是”允许发邮件”（operator 层），而非”允许向 X 且仅向 X 发这一封”（task 层）。这正是 A02 §1 诊断的”OAuth scope 绑定在 operator 层而非 task 层”在事故现场的样子——粗粒度权限给恶意逻辑留出了一整片可以藏副作用的暗房。

为什么身份系统和沙箱都没拦住

  • 身份层无能为力：agent 用的是合法身份，MCP server 提供的是”合法”工具，没有任何身份冒用。Entra Agent ID 式的”发身份证”方案对此一无所知——它能告诉你”是 agent A 发的邮件”，却不会告诉你”这封邮件被多抄送了一份”。
  • 沙箱层无能为力：发邮件本就是这个 agent 被允许的出站行为，沙箱（S02 的爆炸半径遏制）放行 send_email 是设计本意；它不审查邮件头字段里多了一个 BCC。沙箱挡的是”不该出去的流量”，挡不住”该出去的流量里夹带了私货”。

这条事故印证了本专题的核心命门：纵深防御的每一层都各司其职，但没有任何一层负责回答”这个具体动作还在不在用户意图内”——这正是任务级授权与副作用确认门要补的位置。

反推出本该有的授权约束

  1. 工具副作用要声明、要约束：send_email 工具应把”收件人集合”作为受控参数而非工具自由裁量字段——任务级授权应能表达”本次只允许发给 X”，server 擅自增加收件人即越权。对应 R01 的复现对策”send_email 禁止隐式 BCC / 收件人白名单”。
  2. 出站目的地白名单：邮件外发的目的域应受出站白名单约束（对应 R02 的 MCP server 沙箱化 + 出站白名单），攻击者地址不在白名单内即被拦。
  3. MCP 供应链不可信：第三方 MCP server 的代码是信任假设的一部分——Anthropic 共享责任模型把 MCP server 行为的担责放在部署方（来源：Backslash Security 解读 Anthropic 模型，2026-04-29）。引入第三方 MCP 等于把”它会不会私加副作用”纳入了自己的攻击面，这条直接升级到 E03 的协议层剖解。

§2 事故乙 · 跨 Agent 权限提升（模式，非具体事件）：confused deputy 在委托链上的复现

本节为结构化代表性失败模式。它综合了 2025 年安全研究中反复出现的”低权限 agent 诱导高权限 agent 代为执行”形态（A02 §3、A03 均已以概念形式登记），不指向单一公司、不锚定具体日期。读作攻击范式。

模式还原

一个多 agent 编排系统：orchestrator（高权限，持有写入生产数据库 / 调用支付接口等敏感工具）把子任务委托给若干 sub-agent（低权限，只该处理文本整理之类无害任务）。攻击路径：

  1. 攻击者通过被污染的输入（如一份待 sub-agent 整理的文档里嵌入 prompt injection）控制低权限 sub-agent 的行为。
  2. 被劫持的 sub-agent 自己没有敏感工具权限，但它能向高权限 orchestrator 发起请求——它构造一段看似正常的任务回报，诱导 orchestrator”帮忙执行”一个敏感操作。
  3. orchestrator 持有合法的高权限，且信任来自自己子 agent 的请求，于是代为执行了越权动作。攻击者借了一个”糊涂副手（confused deputy）“的手。

解剖：哪条授权原则失效了

这是经典的 confused deputy（混淆代理人） 问题在 agent 委托链上的复现，断点有两处叠加：

  • 权限继承/传递无递减：A03 诊断的”子 agent 裸继承或反向借用父 agent 权限”。委托链上没有强制的 Scope Attenuation（范围递减）——下游本该权限严格小于上游，但系统让一个低权限节点有能力触发高权限节点的动作。
  • 委托链无法在标准层强制收敛：这正是全专题反复点名的制度性空白——RFC 8693（Token Exchange，正式 RFC）明确写道嵌套的 act claim”仅供参考，不得用于访问控制决策”（来源：IETF Datatracker）。也就是说，“这个请求是低权限 sub-agent 转发来的、本不该触发高权限动作”这件事，标准层没有可强制的字段来表达和拦截。orchestrator 在协议上无从区分”用户的合法委托”和”被劫持 sub-agent 的诱导”。

为什么身份系统照样挡不住

每个 agent 都有合法身份，每一跳调用都是”合法主体发起的合法请求”。身份系统能记录”orchestrator 执行了支付”，却无法回答”这个支付指令的意图源头其实是一段注入文本”。意图不可沿委托链传递——这是 A04 与本专题判断主轴共同的命门。

反推出本该有的授权约束

  1. 委托即降权（mandatory attenuation）：任何委托给 sub-agent 的 token 必须严格窄于上游，且上游不应无条件信任下游回传的”请帮我执行”请求——来自低权限节点的高权限动作请求应被默认拒绝或强制人工确认。
  2. 敏感动作绑定意图来源：高副作用操作（支付、生产写入，对应 A04 的 L3–L4 副作用分级）执行前，应能追溯”这个动作的意图最初由谁、在什么授权下发起”，而非只看”谁转发了它”。这要求审计不止记录调用方，还要记录授权来源链（对应 S03 审计即责任界面）。
  3. confirmation gate 设在副作用而非主体上：确认门应按动作的副作用等级触发，而不是按”谁来调用”——因为调用方身份是合法的，骗过身份不难，骗过”这个不可逆操作需要人确认”难得多。这正是 A04”confirmation-gated 自主执行”的现实价值。

§3 判断主轴：两起事故合起来揭示的命门

把甲乙两起叠在一起看，命门浮出水面：

Agent 权限越界的主流形态，不是”非法主体闯入”（认证问题），而是”合法主体被诱导做了意图外的合法动作”（授权-意图对齐问题）。前者身份系统能挡，后者必须靠任务级最小授权 + 副作用确认门 + 出站管控 + 可追溯授权来源的审计——四者缺一，越权就从某个缺口漏出去。

按”症状 → 为什么错 → 正确做法 → 真实反例”四件套收口：

  • 症状：事故复盘时第一反应是”是不是凭证泄露了""是不是被提权了”，于是去加固认证、轮转密钥。
  • 为什么错：这两起事故里没有任何凭证泄露、没有任何越权提权——攻击者用的全是合法身份与合法权限。在认证层加固，等于在没破的那堵墙上反复砌砖，真正的洞（粗粒度权限 + 意图无法约束）原封不动。
  • 正确做法：把防御重心从”它是谁”移到”它此刻这个动作还在不在原始意图内”——任务级 scope 收窄到”只够这一次”、高副作用动作走确认门、出站目的地白名单、审计记录意图来源链。
  • 真实反例：事故甲里，再强的 Entra Agent ID 身份治理也拦不住一行静默 BCC——因为发邮件的身份和权限全都合法，身份层在这类事故面前结构性失明。

§4 PM / 安全产品视角补盲

跳出工程视角，两起事故给安全 PM 三个易被技术团队看走眼的判断：

  1. 事故归类决定了你修错地方：把”授权内越权”误归为”被攻破”，会导致整个修复预算投向认证加固（MFA、密钥轮转），而真正该投的是任务级授权与工具副作用治理。事故分类本身就是一项产品能力——和滴滴风控里”把账号盗用和本人欺诈分开定性”决定了完全不同的处置链路同构。分错类，资源就全打偏。
  2. 第三方 MCP 供应链是被低估的攻击面：事故甲的本质是供应链投毒。PM 引入任何第三方 MCP / 工具 server，都等于把”它会不会私加副作用”写进了自己的信任假设。采购侧应有”工具副作用可声明、可审计、可白名单约束”的准入门槛，而非装上就用。
  3. 逐操作确认已被证伪，确认门要少而重：Anthropic 数据显示 93% 的权限弹窗被无效批准（来源：Backslash Security 解读，2026-04-29）。事故乙的确认门若设成”每次调用都弹”，必然被疲劳点过；正确做法是只在 L3–L4 高副作用、不可逆动作上设少而重的确认门（对应 A04 的副作用分级），把人的注意力留给真正要命的动作。

§5 对手框架回应：接受 + 边界

对手立场 · “这些都是 prompt injection 问题，根治 injection 就不用谈授权了”（部分模型安全研究者立场）。

  • 接受：两起事故的触发器（尤其事故乙）确实是 prompt injection；提升模型对注入的鲁棒性当然有价值，是纵深防御的一层。
  • 边界：但把希望全押在”根治 injection”上是危险的赌注——其一，injection 鲁棒性是概率性属性，没有任何 2026 年的方案敢声称 100% 拦截（语义/意图保留类研究在复杂改写下准确率会显著下降，确定性属性可信、概率性属性不可全信，参见本专题对 arXiv 2604.02767 的引用）；其二，事故甲根本不是 injection——它是供应链投毒，模型再鲁棒也看不见 server 在 wire 上偷加的 BCC。正确姿态是把 injection 防护当”减少触发概率”的一层，把任务级授权 + 副作用门 + 出站管控当”即便被触发也限制爆炸半径”的兜底层——这正是纵深防御不靠任何单层当银弹的本意。

§6 跨域呼应：confused deputy 与法律上的”代理人越权”

事故乙的 confused deputy 结构，与民商法里的**表见代理 / 代理人越权（unauthorized agency）**问题同构。法律上，当一个代理人超出委托人授权范围行事，核心争议是：责任归委托人还是代理人？相对人能否善意信赖代理权表象？ 法律给出的解法是”授权范围必须可外部识别”——代理权的边界要能被第三方查验，越界行为原则上不约束委托人。

映射到 agent 委托链：orchestrator 之所以被”confuse”，正是因为它无法外部识别子 agent 这个请求是否在原始授权范围内——授权范围在系统里不可查验。法律用”授权范围公示 + 越权不约束本人”来遏制糊涂副手，agent 系统的对应物就是可强制、可追溯的授权来源链（S03 审计即责任界面要承载的正是这个”授权范围可外部查验”的能力）。这也呼应 0430 制度专题讨论”agent 作为准法律主体”的前提：你不能给一个连授权边界都无法外部查验的实体安上责任——归因是法律主体性的前提，而归因依赖授权链可追溯（0430 在 staging，降级文本引用）。

§7 PM 决策启示

  • 面试怎么用：被问”举一个 agent 安全事故并分析”，不要只会说”被黑了/被注入了”。亮出分类——“先分清是’认证被绕过’还是’授权内越权’：前者修认证，后者得修任务级授权 + 副作用门。Postmark MCP 静默 BCC 是后者的典型，身份系统根本照不到。“再补一句”很多越界本质是 confused deputy，根在委托链授权无法外部查验，而非凭证泄露”，立刻区分出念过新闻和真分析过的人。
  • 选型/评审怎么用：做 agent 系统的安全评审，按两起事故反推的约束列 checklist——(1) 工具的高副作用参数（收件人、目的地、金额）是否可被任务级授权约束，而非工具自由裁量？(2) 是否有出站目的地白名单？(3) 委托链是否强制 scope 递减，上游是否拒绝下游发起的高权限动作请求？(4) 高副作用动作是否走确认门、审计是否记录意图来源链？(5) 第三方 MCP / 工具是否过了”副作用可声明、可审计”的准入门槛？
  • 事故复盘怎么用：复盘 agent 事故先做一件事——判定它属于哪一类（认证被绕过 / 授权内越权 / 沙箱逃逸）。分类错，整改方向就错。授权内越权占多数，意味着多数整改资源该投向授权治理而非认证加固。

§8 与已有节点的关系

  • 对 A02 授权范围与 Privilege Drift（概念前置）：本节点是其现实验尸——A02 讲”权限为什么会漂移、operator 层 vs task 层为什么脱节”，本节点用 Postmark 事故展示”粗粒度 scope 在事故现场如何成为藏副作用的暗房”。不复述漂移等式，只做事故级 gap 分析。
  • 对 A03 子 Agent 权限继承问题（概念前置）：本节点是其现实验尸——A03 讲”子 agent 继承/confused deputy 为什么是病理”，事故乙展示它真的这么发生了，并反推出”委托即降权 + 上游拒绝下游高权限请求”的约束。
  • 对 A04 Confirmation-gated 自主执行的权限语义（概念前置）：本节点为其提供事故级证据——两起事故都指向”高副作用动作必须走确认门”，且确认门要按副作用分级（L0–L4）触发而非按调用方身份，统一指向 A04 的合成框架，不重定义分级。
  • 对 E01 微软 Agent Identity Perimeter 剖解（同模块对位）：E01 剖”大厂身份方案的得失”，E02 剖”没解或解错的真实事故”，一正一反。E02 用事故甲坐实了 E01”失 2 · 身份 ≠ 授权”的现实代价——身份层对授权内越权结构性失明。
  • 对本专题 S01 授权栈 / S02 沙箱 / S03 审计、R01 白名单 / R02 沙箱化 / R03 审计追踪（同批 staging，降级文本）：本节点反推出的约束（任务级授权、出站白名单、确认门、意图来源链审计）正是 S/R 系列要给出方案的问题面——E02 出题，S/R 给解。
  • 对 E03 MCP 工具授权边界（同批 staging，降级文本）：事故甲的供应链投毒升级到 E03 的协议层剖解——E02 是”事故级”病理，E03 是”协议机制级”病理。

§9 关联节点

核心（必读）

延伸（可选）

跨专题与同级引用（staging，降级文本）：本专题 S01/S02/S03、R01/R02/R03、E03 均在 staging，未入主库，以文本引用而非双链。0435 红队专题”S03 Agent 权限边界与最小权限设计”（“权限是最后防线”、L0–L4 副作用分级源头）同为 staging，相关概念以文本引用。0430 制度专题”agent 准法律主体 / 归因是法律主体性前提”在 staging，降级文本。事故乙作为代表性失败模式呈现，不指向具体公司/日期。

修订日志

  • R0（2026-06-19）：首稿。判断主轴”授权内越权 ≠ 被攻破，身份系统对前者结构性失明”成形；剖事故甲（Postmark MCP 静默 BCC，真实事件，v1.0.16 / 2025-09-17 / ~1500 周下载 / BCC 地址经 WebSearch 多源核实，受影响组织数标〔待核实〕）与事故乙（跨 agent confused deputy 提权，明确标注为代表性失败模式、非具体事件、不编造公司/日期/损失）；每起按”意图→授权→动作”断点 + “身份/沙箱为何挡不住” + 反推授权约束三段剖；对手框架（“根治 injection 即可”）接受+边界，区分确定性/概率性属性；跨域呼应民商法 confused deputy / 代理人越权与 0430 准法律主体前提；与 A02/A03/A04 建立”现实验尸”关系、与 E01 一正一反、为 S/R 系列出题。事实接地：RFC 8693 act claim 不可用于访问控制（IETF）、Anthropic 93% 弹窗无效批准（Backslash 2026-04-29）均沿用专题已核实口径；arXiv 仅复用专题清单（2604.02767），未新编编号。staging 区，0435/0430 及本专题未落盘同级节点降级文本。