R

A04 Confirmation-gated 自主执行的权限语义

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

当 Agent 能自己决定调哪个工具、要不要花这笔钱、该不该 spawn 一个子 Agent，“哪些动作可以自己做、哪些必须先问人”就成了一个权限语义问题——而不是一个 UI 问题。本节点要解决的问题是：确认门（confirmation gate，高风险动作执行前需人类批准）的权限语义到底是什么，以及它为什么必然滑向两个失败极点——确认太多（confirmation fatigue，疲劳点过）与确认太少（越权放行）。 视角/框架名：按动作副作用分级（side-effect grading）来定义确认语义，而不是按工具类型或调用频率。

[!warning] 一句话反共识立场 确认门不是”安全开关”，而是把权限决策外包给人类注意力的设计——而人类注意力是整个 Agent 系统里最稀缺、最不可靠、最容易被对抗者利用的资源。Backslash Security 复述 Anthropic 共享责任模型时给出的数字：开发者在 93% 的权限提示弹窗中未经有效审查即点击批准（来源：Backslash Security 复述 Anthropic Shared Responsibility Model，2026-04-29）。这意味着一个”什么都问”的确认门，在统计意义上≈一个”什么都放行”的确认门——只是多了一层免责的仪式感。

§0 为什么是”副作用分级”框架，而不是”工具类型”或”风险等级”框架

读者脑中默认的确认门模型，大概率是下面两个之一，两个都不够用：

默认框架一：按工具类型分级。 “读类工具不用问，写类工具要问。” 这是 0411 S03 Harness Engineering 全景 §3.5 已有的”按工具类型 × 风险等级 × 用户配置三层叠加”立场的简化版。问题在于：同一个工具的副作用取决于参数而非工具本身。send_email 发给自己是 L1，群发 5000 人是 L4；bash 跑 ls 是 L0，跑 rm -rf 是 L4。OWASP LLM06:2025 把这点形式化为”过度功能”（Excessive Functionality）——文档读取插件同时具备删除能力，按工具类型授权就会把删除能力一并放出（来源：OWASP GenAI LLM06:2025 Excessive Agency，正式发布于 2024-11）。

默认框架二：按风险等级（高/中/低）分级。 听起来对，但”风险”是一个未定义的复合量，不可操作。一个 Agent 在运行时无法回答”这个动作风险高不高”，但它可以回答三个正交的物理问题：可逆吗？后果范围多大？是否持久化/对外可见？ 副作用分级框架就是把模糊的”风险”拆成这三个可判定的维度，再合成一个 L0–L4 的格。这正是 0411 S03 Harness Engineering 全景 §3.5 中”风险等级”那一维一直缺的形式化填实。

为什么是副作用而不是意图？ 因为意图不可验证。SentinelAgent（arXiv 2604.02767，2026-04-03）把委托链属性分成 6 条确定性属性 + 1 条概率性属性，唯一那条概率性的就是 intent preservation（意图保留），在对抗复杂改写攻击时检测准确率降到 13%（来源：arXiv 2604.02767，已 WebFetch 核实）。副作用是确定的（删除就是删除），意图是概率的（“用户真的想删吗”靠猜）。确认门的语义只能锚定在可确定的副作用上，不能锚定在需要猜测的意图上。 这是本框架的地基。

§1 副作用分级：把”风险”拆成三个可判定维度

确认语义的核心，是给每个待执行动作算出一个副作用级别。三个正交维度：

维度问题取值
可逆性执行后能否一键撤销 / 自动回滚？可逆 / 难逆 / 不可逆
爆炸半径后果触及多少对象 / 多少钱 / 多少人？单对象 / 有限集 / 大规模
外溢性是否对外可见、持久化、改变他人状态？内部沙箱 / 持久化 / 对外发送

合成为五级：

级别含义典型动作确认语义
L0纯读、沙箱内、无外溢列目录、查文档、检索永不确认
L1可逆写、内部、单对象写草稿、改本地文件、建临时分支默认不确认（可配批量回看）
L2难逆 / 有限爆炸半径发邮件给自己、提交 PR、小额支付阈值确认（金额/数量超线才问）
L3不可逆 / 大规模 / 对外群发、删生产数据、合并到 main、spawn 高权子 Agent必须确认（展示影响清单）
L4不可逆 + 大规模 + 对外 + 高后果批量退订、清库、大额转账、对外发布必须确认 + 二次验证 / 升级到人

这张表与 0411 S03 Harness Engineering 全景 §3.5 的”按工具类型 × 风险等级 × 用户配置三层叠加”的关系是：它把”风险等级”那一维替换成了可计算的 L0–L4，把 HITL（Human-in-the-loop）断点的触发条件从”工具类型”挪到了”动作副作用”。 这是一次纠偏：触发确认的不该是”你用了写工具”，而是”这次写的副作用落在 L3 以上”。

OpenAI Model Spec（2025-12-18 版）给了一个具体的 L4 处理样板：不可逆操作（如批量退订邮件）在执行前需向用户展示列表并取得确认（来源：OpenAI Model Spec 2025-12-18，已 WebFetch 核实）。注意它的语义不是”问一句 yes/no”，而是”展示影响清单”——确认门的质量取决于它给人看了什么，而不是它有没有弹窗。

§2 判断主轴：90% 的人在确认门上搞错的四个点

[!danger] 致命双失败模式 确认门有一个内在的、无法靠”调参”消除的张力：确认太多 → confirmation fatigue → 人闭眼点同意 → 等价于无门；确认太少 → 越权动作直接放行 → 等价于无门。 两端都收敛到”无门”。设计确认门的全部工艺，是在这条双失败曲线上找那个窄窗口。下面四点是 90% 的人会摔的地方。

错点一：把”问得越多越安全”当真。

  • 症状：给每个写动作都弹确认框，团队自我感觉”我们很严谨”。
  • 为什么会错：人类注意力是会枯竭的资源。Anthropic 数据显示 93% 的权限提示被无效批准（来源：Backslash 复述，2026-04-29）；当弹窗变成背景噪音，第 100 个弹窗里那个真正危险的 L4 动作会和前 99 个 L1 一样被秒批。过度确认不是把安全水平拉高，而是把它拉到地板。
  • 正确做法：L0/L1 永不弹窗，确认预算只花在 L3/L4。把”确认”当成稀缺货币来分配，不是当成保险来铺满。
  • 真实反例：OpenAI Model Spec 自己明确承认”为每一步都要求显式确认通常不现实”（来源：OpenAI Model Spec 2025-12-18）——制定规范的人都不信”全确认”可行。

错点二：把”越权”理解成”用了没授权的工具”，忽略了”授权范围内的滥用”。

  • 症状：确认门只拦”调用未授权工具”，对”授权工具被用在超范围参数上”放行。
  • 为什么会错：OAuth scope 绑定在”允许访问某系统”而非”允许完成此任务”，scope 与任务意图天然脱节（来源：arXiv 2510.26702，El Helou et al.，2025-10-30，已核实）。一个有 send_email 授权的 Agent，群发钓鱼邮件用的也是同一个被授权的工具。确认门若只看”工具是否授权”，就完全看不见这类授权内越权。
  • 正确做法：确认触发条件必须看动作的实际参数算出的副作用级别（§1），而非工具的授权状态。
  • 真实反例：2025-09 被篡改的 Postmark MCP 服务器，在 send_email（完全合法授权的工具）里静默加了 BCC 字段抄送攻击者——工具是授权的，副作用是越权的（来源：多源安全报道，2025-09）。

错点三：把确认门当成防注入的最后防线。

  • 症状：“反正高风险动作要人确认，prompt injection 进来也无所谓。”
  • 为什么会错：注入攻击的目标恰恰是让恶意动作看起来像 L1，从而绕过确认。Agent Session Smuggling（2025-11）、Cross-Agent Privilege Escalation（2025-09）这类攻击都是把高副作用动作伪装/拆解，使其落在确认阈值之下（来源：WorkOS Blog，已核实）。确认门拦的是”被正确分级为 L3/L4 的动作”，对”被错误分级为 L1 的 L4 动作”完全失效。
  • 正确做法：确认门是纵深防御的一层，不是最后防线。它上游必须有任务级权限白名单（防止恶意工具进入可调集合）、副作用计算的确定性校验（防止分级被语义欺骗）。这正是 0435 红队专题 S03（0435 专题 staging，降级文本引用）反复强调的”权限是最后防线”的精确边界——权限边界是最后防线，确认门是这道防线上的一个可被绕过的人因环节。
  • 真实反例：PAuth（arXiv 2603.17170，2026-03-17）和 Open Agent Passport（arXiv 2603.20953，2026-03-21）都把判断点从”问人”前移到”工具调用前的确定性策略检查”——OAP 在 4437 次授权决策测试中，把社会工程攻击成功率从宽松策略的 74.6% 降到严格策略下的 0%（来源：arXiv 2603.20953，已核实）。靠确定性预动作拦截，而不是靠人确认。

错点四：把”最小权限”和”最小自主”混为一谈。

  • 症状：“我们给 Agent 配了最小权限，所以确认门可以宽松点。”
  • 为什么会错：OWASP Agentic AI Top 10（2025-12-09 发布）明确区分了 least privilege（最小权限）≠ least agency（最小自主）（来源：OWASP GenAI Agentic AI Top 10，2025-12-09，已核实）。最小权限说的是”Agent 能访问什么”，最小自主说的是”即使能访问，它在多大程度上可以无需回确认地自主行动”。一个有合法读写权限的 Agent，仍然可以因为”自主度过高”而做出灾难性动作。确认门治理的是 agency 维度，权限白名单治理的是 privilege 维度，两者不可互相替代。
  • 正确做法：把这两个旋钮分开调。权限白名单决定”可调集合”，副作用分级 + 确认门决定”可调集合里哪些能自动执行”。
  • 真实反例：Anthropic 数据本身就是反例——开发者有最小权限意识（配了权限提示），但 93% 无效批准说明 agency 维度完全失守。

§3 时间维度的确认语义：shutdown timer 与多跳委托

确认门不只是空间问题（哪些动作要问），还是时间问题（自主执行能持续多久、委托能传几跳）。

时间盒（shutdown timer）。 OpenAI Model Spec（2025-12-18）规定自主执行范围必须包含 shutdown timer——超时自动停止，需重新确认（来源：OpenAI Model Spec 2025-12-18，已核实）。语义是：自主授权是有有效期的租约，不是永久产权。 一个被批准”自主跑 30 分钟”的 Agent，第 31 分钟必须回来续约。这堵住了”上下文漂移”——CSA 把它列为权限漂移四大根因之一：Agent 在迭代中偏离原始意图（来源：CSA “AI Agent Security Starts with Scope Control”，2026-05-12）。

委托的能力降级（scope attenuation）。 当一个 Agent spawn 子 Agent（呼应 0411 A06 Orchestrator 编排器 的权限层、A07 Multi-Agent Teams），确认语义必须沿委托链递减：子 Agent 的副作用上限不得高于父 Agent。OpenAI Model Spec 明确 sub-agent 和第三方必须在同一 scope 约束下运行（来源：OpenAI Model Spec 2025-12-18）。但这里有个标准层的硬空白——RFC 8693（Token Exchange，正式 RFC）明确说嵌套 act claim”仅供参考，不得用于访问控制决策”，即多跳授权链在标准层面无法强制执行（来源：IETF Datatracker，已核实）。

[!note] PM 必须知道的标准空白 “子 Agent 不能比父 Agent 权限大”这条原则在工程上人人同意，但目前没有被广泛采纳的标准能在协议层强制它。IETF 有衰减令牌、可验证 actor 链等 4 个方向在研，均无正式 RFC。这意味着：如果你的 Agent 系统有多跳委托，确认门的递减语义现在只能靠你自己的 harness 代码保证，不能靠底层协议兜底。这是一个该写进选型评估的风险项。

§4 产品 PM 视角补盲：确认门的三个非工程陷阱

工程 PM 容易把确认门当纯技术问题。三个商业/心理/合规盲点：

  1. 用户心理模型陷阱：确认疲劳是可被 A/B 测出来的转化杀手，也是可被滥用的”暗模式”。 一个产品如果确认弹得太勤，用户要么流失（觉得 Agent 没用、什么都要我批），要么训练成”无脑点同意”（比不弹更危险）。反过来，有的产品故意把危险动作的确认做得”轻飘飘”（默认选中”同意”、按钮颜色诱导），把确认门变成免责工具而非保护工具。确认门的 UX 设计本身就是一个伦理与转化的双重战场。

  2. 商业模式陷阱：自主度是定价杠杆，但越权一次可能赔掉全部利润。 卖”全自动 Agent”听起来比”半自动需确认”高级、能卖更高价。但 2025 年 agentic AI 相关 CVE 同比增长 255%（来源：WorkOS Blog，已核实），一次越权的大额支付或数据泄露赔偿，可能远超提高自主度带来的收入。PM 要算的是”自主度溢价 vs 尾部风险期望损失”，不是”自主度越高越好卖”。

  3. 合规边界陷阱：在受监管场景，“人确认了”≠“人有效监督了”。 EU AI Act 对高风险系统要求有意义的人类监督（human oversight），执行截止日 2026-08-02。如果你的确认门是”93% 被无效批准”那种，监管会认定它不构成有效的人类监督——一个走过场的确认门在合规上等于没有。Rick 的滴滴风控/审核经验在这里直接可迁移：风控审核里”人工复核”如果变成秒过的橡皮图章，监管和审计都不认；确认门是同一个问题的 Agent 版本。

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

对手立场一（确定性派 / OAP、PAuth 作者）：确认门是错的范式，应该用确定性预动作拦截取代人确认。

  • 接受：他们对。OAP 把社会工程攻击成功率打到 0%（来源：arXiv 2603.20953），证明确定性策略检查比人确认可靠得多。能用确定性规则判定的（如”金额 > X 拒绝”），就不该浪费人的注意力。
  • 边界：但确定性拦截只能处理可形式化的策略。“这封措辞微妙的对外邮件该不该发”这类需要价值判断、上下文常识的动作，没有确定性规则能覆盖。确认门的存活空间，恰恰是确定性规则的盲区——L3/L4 里那些”对错取决于人类语境”的动作。确认门不是被确定性拦截取代，而是退守到确定性拦截覆盖不了的窄带。

对手立场二（语义匹配派 / El Helou 等）：让授权服务器对任务做语义检查，按需签发最小 scope，从源头就不给 Agent 越权的能力，确认门就不必要了。

  • 接受：他们对——从源头收窄 scope 比事后确认更治本。语义任务-范围匹配是正确方向。
  • 边界：但他们自己的实验显示，当任务需要多个 scope 时，模型匹配准确率显著下降（来源：arXiv 2510.26702，已核实）。语义匹配本身是个概率性的 LLM 判断——把安全关键决策建在概率模型上，正是 §0 拒绝”按意图分级”的同一个理由。语义匹配可以缩小确认门要看守的范围，但不能在高风险动作上消灭对人类确认的需求。

对手立场三（Rick 未读对手框架——Mark Miller 对象能力模型 / Object Capability Model）： 权限根本不该用”问/不问”的确认门来表达，而该用”引用即权限”（the reference is the permission）——一个组件只能动它持有引用的对象，没有引用就物理上做不到，无所谓确认。WebAssembly + WASI 是其运行时实现：模块默认无文件系统、无网络、无系统调用，每个能力都是宿主显式授予的引用（来源：Cosmonic 博文，2026-05-06，注：商业博文，独立审计有限）。

  • 接受：这是更优雅的范式。能用 capability 物理隔离的，确实不需要确认门——你给不出引用，Agent 就做不了，比”问人”强一个量级。
  • 边界：对象能力模型解决的是”能不能做”（capability），不解决”该不该做这一次”（authorization of this specific invocation）。一个持有 send_email 能力引用的 Agent，capability 模型管不了它这一次是发给客户还是发给攻击者——这恰是 §1 的副作用维度。capability 是空间隔离，确认门是行为级判定，两者是纵深防御的不同层，不是替代关系。 引入这个框架逼问出本专题的盲点：我们一直在讨论”什么时候问人”，但更根本的设计是”很多动作应该从能力上就让 Agent 物理上做不到，根本轮不到问”。

§6 跨域呼应：阿伦特”平庸之恶”与确认的责任稀释

[!note] 跨域调度：汉娜·阿伦特（Hannah Arendt）的”平庸之恶”（banality of evil） 阿伦特在《艾希曼在耶路撒冷》中提出：大规模的恶往往不来自恶魔，而来自放弃判断、机械执行、把责任推给流程的平庸个体。这个框架精确地诊断了确认疲劳的本质——93% 的无效批准，就是责任在确认仪式中被稀释为零的过程。

每一个被秒点的”同意”按钮，都在做两件事：把一个本该由人承担的判断，转化成一个机械动作；同时在审计意义上把责任名义上记在人头上（“是你点的同意”）。这制造了一个危险的责任幻觉：系统看起来有人在负责（每个高风险动作都有人确认了），实际上没有任何人在判断。 这正是阿伦特意义上的”无人统治”（rule by Nobody）——责任被分散到一个谁也不真正承担的流程里。

这个跨域视角改变了一个具体的技术判断：确认门的设计目标不该是”让人点同意”，而该是”让人真正做出判断”。 二者天差地别。前者优化的是流程完整性（每个动作都有确认记录），后者优化的是判断有效性（人真的看懂了影响才批）。OpenAI Model Spec 要求”展示影响清单”而非”问 yes/no”，本质上就是在对抗平庸之恶——逼迫确认者面对具体后果，而不是面对一个抽象的同意按钮。把这条接到 0117社会学的权力与责任分析谱系里：确认门是一种责任的技术化分配机制，而技术化的责任分配最容易滑向”人人有责即人人无责”。（关联 生命政治、安全感知与干预——后者是 Rick 滴滴侧”人工干预阈值如何设置”的同构问题。）

§7 PM 决策启示：面试 / 选型 / 复现三类落地

面试怎么用。 当被问”你怎么设计 Agent 的人机协同安全”，不要答”高风险操作让人确认”——这是 hype 腔，会被反问”什么叫高风险？“。正确答法：“我按副作用分级（可逆性 × 爆炸半径 × 外溢性）算 L0–L4，确认预算只花在 L3/L4，并且我知道这套的命门是 confirmation fatigue——Anthropic 数据是 93% 无效批准，所以确认门不是最后防线，它上游必须有任务级权限白名单和确定性预动作拦截。” 一句话展示你知道这个机制的失败模式和边界。

选型怎么用。 评估 Agent 框架/平台时，在 0411 S03 Harness Engineering 全景 的 HITL 维度上追加三问（也是对 m208 - AI 基础设施与中间件选型 安全选型维度的填实）：(1) 确认触发条件能否按动作参数算出的副作用配置，还是只能按工具类型？(2) 确认时给人看的是”影响清单”还是”yes/no”？(3) 自主执行有没有 shutdown timer，多跳委托有没有能力降级？三个都答不上的框架，在高合规场景扣分。

复现怎么用。 自己搭 Agent 时，最小可运行版本就该把动作做副作用打标（哪怕先手工标），L0/L1 直接执行、L3/L4 强制人确认且展示 diff/清单、L2 设阈值。别一上来追求全自动——参考 Anthropic “Building Effective Agents”（2024-12-19）的”最小足迹 / 偏好可逆动作”原则：能选可逆的就别选不可逆的，把不可逆动作的数量从源头压到最少，比把确认门做得多精致更有效。

§8 与已有节点的关系（升级对照，不复述）

  • 对照 0411 S03 Harness Engineering 全景 §3.5 HITL：做的是深化 + 形式化填实。S03 已有”按工具类型 × 风险等级 × 用户配置三层叠加”的立场，本节点把其中模糊的”风险等级”维替换为可计算的 L0–L4 副作用分级，并补上 S03 未展开的两个失败模式（confirmation fatigue 双失败曲线、责任稀释）。
  • 对照 0411 A06 Orchestrator 编排器 / A07 Multi-Agent Teams：做的是补缺。编排器/多 Agent 节点讲了 spawn 子 Agent 的能力，本节点补上”子 Agent 确认语义如何沿委托链递减”以及”标准层无法强制递减”这个空白。
  • 对照 m208 - AI 基础设施与中间件选型 §2.5.2：做的是纠偏 + 维度补充。m208 的编排框架对比缺安全选型维度，本节点 §7 给出确认门的三问评估框架。
  • 对照 0435 红队专题 S03（0435 专题 staging，降级文本引用，不建双链）：“权限是最后防线”——本节点精确化了这条边界：权限边界是最后防线，确认门是这道防线上一个可被绕过的人因环节，不是防线本身。
  • 对照 m207 - Agent 产品化：场景推演与失败模式：confirmation fatigue 是一类应被纳入失败模式库的人因失败。
  • 不复述：MCP Tool 权限面（见 A08 MCP 与 A2A 协议族）、Agent 抽象层级（见 A02 抽象层级辨析·Harness Framework Agent Skill Orchestrator）、Function Calling 机制基础。

§9 关联节点

核心（必读）

延伸（可选）

修订日志

  • R0.1（2026-06-07）：首稿，staging。建立副作用分级（L0–L4，三维度合成）框架；判断主轴四件套（四个错点：全确认幻觉 / 授权内越权 / 把确认当最后防线 / least privilege≠least agency）；引入对手框架三立场（确定性派 OAP/PAuth、语义匹配派、Mark Miller 对象能力模型）；跨域调度阿伦特”平庸之恶”诊断确认疲劳的责任稀释；时间维度（shutdown timer + 多跳委托递减空白）；与 0411 S03/A06/A07、m208、0435 S03 的升级对照。待核实项：Postmark MCP 篡改具体周期、agentic CVE 255% 增长的口径。