渐进式授权实装 — 分级授权决策树、复用 P2 风控网关、授权决策写审计轨迹

日期: 2026-09-03 阶段: Phase 3 - AML 调查 Copilot 标签: #progressive-authorization #least-privilege #audit-trail

核心问题

Day 78 选定的 4 个 UX 模式里，渐进式授权（Progressive Authorization）是横跨 Control + Consent 两轴的那个——也是最难做对的一个。Fuselab(2025-08) 的定义是 "starts the agent with limited autonomy and expands it as the user builds trust"，并补了关键一句 "earns permission through demonstrated reliability rather than demanding it at launch"。Day 80 的置信度信号已经把"低置信 → 强制人审、禁批量批准绕过"这条挂钩到了授权上。今天把它落成一套可执行的分级授权机制。

回答三件事：(1) 授权该按什么分级——风险分档 × Agent 信任度两个维度怎么组合成一棵决策树，"低风险自动通过 / 高风险强制人审"的边界怎么定（不拍脑袋，锚定 CTR $10,000 与类型学阈值）；(2) 为什么这套授权门不该新写一个权限系统，而要复用 P2 的风控网关语义（toolRegistry.ts 的 schema 校验 + budget.ts 的硬上限）——一个 AML Copilot 不该有两套"什么能做什么不能做"的判据；(3) 授权决策本身为什么必须落进审计轨迹——在金融合规里，"系统替人放行了什么、人批准了什么"本身是监管审查对象。

主线案例锚定：MindStudio《Progressive Autonomy》四级自治框架（2026）、AWS Well-Architected Generative AI Lens 的最小权限/权限边界最佳实践（GENSEC05-BP01，2025-12 更新）、以及 AML 交易监控里"低风险告警自动结案、高价值/跨境告警自动升级"的行业实践。

核心反直觉先抛出来：渐进式授权的"渐进"不是放松，而是按可量化的可靠性证据收紧再松绑——默认零权限（deny-by-default），权限靠"完成 N 个实例且错误率达标"挣来，而不是上线时索要。 一个常见误判是把"渐进式"理解成"先给宽权限、出问题再收"，恰好反了。

关键内容

A. 分级授权决策树：风险分档 × 信任度的二维组合

授权决策不是一维的"该不该人审"，而是两个正交维度的组合：

• 风险分档（action risk tier）：这次让 Agent 做的事有多大后果。借 MindStudio(2026) 的三档——低（读取/起草内部内容/记日志）/ 中（外部通信/状态修改 API）/ 高（不可逆操作/金融交易/敏感数据）。映射到 AML Copilot：起草 SAR 段落、内部高亮证据 = 低风险（产出可被人推翻、无外部副作用）；类型学判定结论 = 中风险（影响是否升级）；触发"提交 SAR 给 FIU"或"对外发起任何动作" = 高风险（不可逆 + 监管后果）。
• Agent 信任度（trust level）：这个 Agent/该类任务历史上多可靠。Day 78 的 user_trust_level 三档（LOW/MEDIUM/HIGH），由历史 override 率 / 误升级率度量。

两维组合成决策树（Agent 收到一个待执行动作，决定 AUTO / ASYNC_REVIEW / SYNC_APPROVE 三种处置）：

authorize(action, trustLevel):
  riskTier = classifyRisk(action)              # 静态：按动作类型；动态因子见下

  # —— 合规域硬约束（与信任度无关，监管恒定）——
  if action.irreversible or action.crossesRegulatoryBoundary:
      return SYNC_APPROVE                       # 提交 SAR / 对外动作：永远同步人审
  if confidence(action) == LOW:                 # 串 Day 80：低置信无条件人审
      return SYNC_APPROVE

  # —— 风险 × 信任 矩阵 ——
  switch (riskTier, trustLevel):
    (LOW,  *)            -> AUTO                 # 低风险：任何信任度都自动通过
    (MED,  LOW)          -> SYNC_APPROVE         # 中风险 + 新 Agent：先同步人审
    (MED,  MEDIUM|HIGH)  -> ASYNC_REVIEW         # 中风险 + 已建立信任：自动执行、异步抽审
    (HIGH, *)            -> SYNC_APPROVE         # 高风险：恒同步人审（即便 HIGH 信任）
  → 三档处置语义见下表

三档处置对应 MindStudio 的风险分类语义（low=auto-execute / medium=log and alert / high=require human approval）：

为什么风险维度优先于信任维度——决策树里 (HIGH, *) -> SYNC_APPROVE，即便最高信任的 Agent，高风险动作仍强制同步人审。这对应行业 AML 实践："High-risk alerts involving sanctions matches or large cross-border transactions may trigger auto-escalation to senior compliance teams"（Shuftipro 2026）——信任度只能松绑中风险动作，永远松绑不了高风险动作。这是把"信任换权限"这条原则用风险天花板封了顶：再可靠的 Agent 也不许自动提交 SAR。

动态分档因子（让 classifyRisk 不只看动作类型，还看金额）锚定 CTR 门槛：

反直觉洞察①（"渐进"是 deny-by-default 的收紧，不是"先宽后收"）：直觉把"渐进式授权"读成"先给 Agent 较宽的权限，出事再收窄"——这正好把方向搞反了，而且在合规域是危险的。MindStudio(2026) Level 0 是 "draft only：human reviews and approves everything"，Level 1 才 "acts on low-stakes tasks automatically"——起点是几乎零自治，权限是一级一级挣上来的。AWS GENSEC05-BP01(2025-12) 同口径："roles attached to agents... should be developed with least privilege access principles"、"start with no permitted actions by default and incrementally enable capabilities based on role and risk"。Zscaler/BeyondTrust(2026) 把这叫 "narrower, shorter, more inspectable permissions that expire with the task"。默认拒绝 + 按证据松绑，而非默认允许 + 出事收紧——后者意味着"出事"已经发生了（在 AML 里 = 一份错误 SAR 已提交给 FIU，不可逆）。

B. 复用 P2 风控网关：一套判据，不写第二个权限系统

最大的工程诱惑是为渐进式授权新写一个权限引擎。但 AML Copilot 已经有了"什么能做、什么不能做"的判据来源——P2 建的两个装置：

• toolRegistry.ts（MCP 工具注册表，P2 作品③）：每个工具声明 inputSchema，调用前 validate() 校验入参，失败抛 McpCallError(INVALID_PARAMS)。这是调用面的策略执行点（PEP）——动作要落地必须过工具，过工具必须过 schema 校验。
• budget.ts（预算硬上限）：assertCostOk() / assertCanToolCall() / assertCanStep() 是资源面的策略执行点——步数/工具调用数/成本超限即拒。

渐进式授权要做的，不是另起炉灶，而是在工具调用前插一道授权决策，作为 schema 校验之外的第二道闸。两道闸语义不同、互补：

Agent 想调用工具 submit_sar(args)
        │
   ┌────▼─────────────────────────────┐
   │ 闸 1：schema 校验 (toolRegistry)  │  ← "参数合法吗？"（语法/类型）
   │   validate(spec.inputSchema,args) │
   └────┬─────────────────────────────┘ 失败 → INVALID_PARAMS
        │ 通过
   ┌────▼─────────────────────────────┐
   │ 闸 2：授权决策 (本日新增)         │  ← "这个动作此刻准做吗？"（风险/信任/置信）
   │   authorize(action, trustLevel)   │
   └────┬─────────────────────────────┘
   AUTO │ ASYNC_REVIEW │ SYNC_APPROVE
        │              │         │
        ▼              ▼         ▼
     执行          执行+排异步审  阻塞→等人批准→执行 or 退回
        │              │              │
        └──────────────┴──────────────┘
                       ▼
              ★ 三路都写审计轨迹（C 节）

为什么是"两道闸"而不是"把授权塞进 schema 校验"：schema 校验回答的是语法问题（参数类型/范围对不对，与上下文无关、纯函数、可缓存——这正是 MCP stateless 设计的好处）；授权决策回答的是语义+上下文问题（这个动作在当前风险/信任/置信状态下准不准做，依赖运行时状态）。把两者混在一起会污染 schema 校验的无状态性。职责分离：toolRegistry 管"调用形状合法"，授权层管"调用时机合规"。

复用 budget.ts 的点：授权层的 SYNC_APPROVE 动作在等待人工批准期间，不计入 assertCanStep() 的步数预算（人审是带外动作，不烧 Agent 预算）；但一旦批准执行，工具调用照常走 assertCanToolCall()。授权与预算是正交的两层闸，叠加而非替代。

反直觉洞察②（schema 校验通过 ≠ 该动作被授权——合法的参数可以是未授权的动作）：容易误以为"既然 toolRegistry 已经 schema 校验了入参，授权就有保障了"。但 schema 校验只证明 submit_sar({caseId:"C-007", narrative:"..."}) 的参数形状合法——它完全不管"此刻该不该提交这份 SAR"。一个被 prompt 注入诱导的 Agent 可以构造出完全合法 schema、但语义上灾难性的调用（参数齐全、类型正确，但这份 SAR 内容是幻觉、或这个 case 根本不该升级）。这正是 Day 79 "冻结计划防控制流劫持、但防不了内容投毒"在授权层的延续：schema 校验防语法层攻击，授权决策（尤其 SYNC_APPROVE 高风险动作）防语义层误动作。两道闸缺一不可，第二道才是合规的那道。

C. 授权决策写审计轨迹：放行本身是监管审查对象

金融合规里有一条容易被工程师忽略的原则："系统自动放行了什么"和"人批准了什么"，本身都是审计对象——不是只有"做了什么"要留痕，"凭什么准许去做"也要留痕。SR 11-7 模型风险管理的三道防线、DORA 的运营韧性可问责性，都要求授权链可回溯。

所以决策树的三条出口（AUTO/ASYNC_REVIEW/SYNC_APPROVE）全部写审计轨迹，而不是只记 SYNC_APPROVE 的人工批准。审计条目结构：

AuthDecisionRecord {
  caseId, action, timestamp(逻辑序号),    # 何案、何动作、何时
  riskTier, trustLevel, confidence,        # 决策的三个输入
  decision: AUTO | ASYNC_REVIEW | SYNC_APPROVE,
  rationale: "(HIGH risk + irreversible) → forced sync approval",  # 为什么这么判（可读）
  // SYNC_APPROVE 专属：
  approver?: string, approvedAt?, approverEdits?,  # 谁批的、改了什么（人改了什么本身是审计对象，呼应 Day 78 反直觉）
  // AUTO 专属：
  autoReason: "low-risk draft, no external side effect"
}

为什么 AUTO 也要留痕——直觉是"自动通过的低风险动作没什么可记的"。错。监管事后审查问的不是"你拦了什么"，而是"你为什么没拦这个？" 若一份后来被发现有问题的 SAR 段落当初走了 AUTO，监管要看到"当时系统凭什么判它低风险、自动放行"的完整理由链。没有 AUTO 的留痕，就无法证明自动放行是合规判断而非系统疏漏。 这与 Day 75 的"不可篡改审计轨迹"是同一条链——授权决策记录是审计轨迹的一类条目。

审计轨迹的另一个作用：为信任度量提供数据源。Day 78 说信任度由"历史 override 率/误升级率"度量——这些率正是从 AuthDecisionRecord 聚合出来的（SYNC_APPROVE 里人工 reject 的比例 = override 率；ASYNC_REVIEW 抽审中被推翻的比例 = 误自动率）。授权留痕 → 算信任度 → 调下次授权松紧，构成 Fuselab "earns permission through demonstrated reliability" 的闭环。信任不是声明的，是从审计数据里算出来的。

设计要点/决策表

对本项目的落地

• 新建 src/aml/authorization.ts：导出 classifyRisk(action, case) → 'LOW'|'MED'|'HIGH'（A 节静态分类 + 动态因子，金额阈值引 typology.ts 的 CTR_THRESHOLD_CENTS、跨境标记从 case 字段读）、authorize(action, trustLevel, confidence) → AuthDecision（A 节决策树，置信度档引 Day 80 confidence.ts 的 Band）、toAuditRecord(decision, action) → AuthDecisionRecord（C 节结构）。决策树里"高风险/不可逆恒 SYNC_APPROVE"与"低置信恒 SYNC_APPROVE"为硬编码合规约束，注释标注监管依据。
• 复用 P2 风控网关，不新建权限引擎：授权层作为 src/agent/mcp/toolRegistry.ts 调用前的第二道闸——在 call() / handle('tools/call') 通过 schema 校验后、进 handler 前，插入 authorize() 判定；SYNC_APPROVE 抛一个"待人审"中断（非错误，是暂停态），由 UI 接管。预算面复用 src/agent/orchestrator/budget.ts：人审等待期不烧步数预算，批准后工具调用照走 assertCanToolCall()。
• 授权决策写审计轨迹：AuthDecisionRecord 作为 Day 75 不可篡改审计轨迹（src/aml/auditTrail.ts，仓库已有）的一类条目类型——三路出口全部 append，与"已人工修改 SAR 段落"等现有审计条目并列同一 trail，保证授权链与修改链在同一可回溯流里。
• UI 落到 AmlSarPanel 的 HITL 区：SYNC_APPROVE 动作在"人工复核 (HITL)"区呈现为"待批准"卡片（动作 + rationale + 涉及证据），批准/退回写回 approver/approverEdits；串接 Day 80——LOW 置信段已置顶的"待重点复核"清单，其对应动作天然走 SYNC_APPROVE，两者在同一队列。
• 诚实标注（不谎称已实现）：W1-W2 落 authorize() 决策逻辑 + AuthDecisionRecord 结构 + 三路留痕 + UI 待批准卡片；但 (a) 真实"信任度量"（从审计聚合 override/误自动率）为 P3 上线后运营埋点，首发 trustLevel 固定为 LOW（最保守：中风险也先同步人审），不按真实历史计算；(b) 接真实 LLM 工具调用面的授权拦截为 P3 后续，当前原型动作是确定性规则引擎产出（无外部副作用），授权层先以"形状正确、逻辑可测"落地，注释标注其在 LLM 接入后的拦截意图。authorization.ts 头注写明：默认 deny-by-default、trustLevel=LOW 首发、信任度量与 LLM 拦截为后续。

参考资料

1. MindStudio — What Is Progressive Autonomy for AI Agents? How to Safely Expand Agent Permissions：四级自治框架（L0 draft only / L1 supervised execution / L2 monitored autonomy / L3 full autonomy within guardrails）；风险三档（low=auto-execute / medium=log and alert / high=require human approval）；扩权标准"100–500 instances... error rates below a defined threshold and low false-escalation rates"；human review "binary where possible, asynchronous by default" (2026)
2. AWS Well-Architected Generative AI Lens — GENSEC05-BP01 Implement least privilege access and permissions boundaries for agentic workflows：agent 角色须按最小权限开发；权限边界限制 agentic workflow 越界；"start with no permitted actions by default and incrementally enable capabilities based on role and risk"（2025-12 更新；InfoQ 2025-12 报道 Lens 扩展 Responsible AI/agentic 章节）
3. Medium (R. Saghafi) — Least Privilege for AI Agents：agent 是 composite/ephemeral/session-bound，传统 zero-trust 假设的稳定 principal 不成立；"narrower, shorter, more inspectable permissions that expire with the task" (2026-03)；Zscaler/BeyondTrust 同口径 zero-trust for agents (2026)
4. Shuftipro — Transaction Monitoring in AML: Ultimate Guide for 2026：低风险告警可季度审/自动结案；"High-risk alerts involving sanctions matches or large cross-border transactions may trigger auto-escalation to senior compliance teams"；2026 监管从"控制存在"转向"控制有效性" (2026)
5. 本仓库 src/agent/mcp/toolRegistry.ts（schema 校验 PEP）、src/agent/orchestrator/budget.ts（资源 PEP）、src/aml/typology.ts（CTR_THRESHOLD_CENTS/SCORE_PRIMARY/ASSESS_THRESHOLD）、src/aml/confidence.ts（Day 80 Band）、src/aml/auditTrail.ts（Day 75 不可篡改轨迹）、src/components/aml/AmlSarPanel.tsx（HITL 区） (2026-06)

SOTA 检查 (2026-06-11)

• "deny-by-default + 按可靠性证据渐进松绑"在 2026-06 是 agent 安全的稳固共识：MindStudio 四级框架(2026)、AWS GENSEC05-BP01(2025-12)、Zscaler/BeyondTrust/Cisco zero-trust-for-agents(2026) 三方一致——agent 默认零权限、最小权限、时限权限、按风险与角色增量开放。本日 WebSearch 未见推翻此框架的主流新方法。
• "securing permission-hungry agents"已从 Tech Radar 主题(Vol 34, 2026-04，Day 78 引)落到具体最佳实践：AWS Generative AI Lens 把它写成可审计的 BP（GENSEC05-BP01/GENREL03-BP02 timeout/GENCOST05-BP01 stopping conditions），说明 13 个月里"权限治理"从口号变成了 well-architected 条目——这是给渐进式授权的最新工程化背书。
• Fine-Grained Authorization (FGA) 是 2026 升温方向：WorkOS(2026) 等把 agent 权限做成 FGA（建模 agent/user/resource/permission 的层级关系、实时评估）——比本项目的二维决策树更细。本项目 v1 用"风险×信任"二维矩阵足够（动作集小、确定性规则），但 P3 接真实多工具 LLM 后若动作集膨胀，应评估是否引 FGA 引擎（如 OpenFGA/Cedar）替代硬编码矩阵，回填本笔记。
• AML 行业侧"按风险分级处置告警"是成熟实践、非新发现：低风险自动结案/季度审、高价值跨境自动升级在 2026 是 table-stakes；但 2026 监管口径明确转向"demonstrable effectiveness"（Wolters Kluwer 2025-2026），意味着授权决策的留痕与可证性（C 节）比以往更被审查——"自动放行也须可证"不是过度设计，是 2026 监管预期。
• 过时警示："先给 agent 宽权限、出事再收"的早期部署直觉在合规域是危险的过时认知——AML 里"出事" = 不可逆的错误 SAR 已提交，deny-by-default 是唯一安全起点（反直觉①）。
• 待跟踪：实装（2026-09）时复核 (a) 是否引 FGA 引擎替代二维矩阵；(b) MindStudio "100–500 instances 扩权" 的具体数字在 AML 高 stakes 场景应取上界还是更高（监管容错低）；(c) AWS Generative AI Lens 是否在 2026 H2 新增针对"授权决策留痕"的专门 BP。