agent 风控网关 v1 — 把支付风控三段式搬到 MCP 调用链

日期: 2026-08-06 阶段: Phase 2 - AI-native 参考架构 标签: #risk-gateway #zero-trust #least-privilege #pep-pdp #payment-risk

核心问题

Day 52 测出了基线 ASR——我们的 MCP server 在工具投毒下会被劫持。Day 51 的 OAuth 只管「谁能调」，不管「这次调用本身是否恶意」。今天建第一道运行时防线：agent 风控网关。回答三个问题：

1. 为什么 prompt 层护栏不够，必须在协议外建确定性网关？ 零信任 + 最小权限怎么落到 MCP 调用链上（PEP/PDP 模型）。
2. 网关怎么设计？ 我有 10 年支付风控经验——这里有个精确类比：MCP 工具调用 ≈ 一笔支付交易，支付风控的「事前授权 / 事中拦截 / 事后审计」三段式可以原样搬过来（对照 docs/arch/day56 三层风控）。
3. 怎么挂进 Day 50/51 的 MCP 调用链？ 拦截流水线放在哪、判定逻辑怎么写。

本篇是网关 v1——确定性策略层 + 三段式骨架。ML 异常检测、自适应策略留到后续迭代。

关键内容

A. 为什么 prompt 护栏不够：零信任 + PEP/PDP 确定性网关

先说一个 Anthropic 框架里的关键区分（Varonis, Zero Trust for AI Agents, 2026；Zentera/Zscaler 同口径）：

• prompt 层护栏（guardrail）：「告诉 agent 别做某些事」的指令。它能被足够精巧的 prompt 绕过——护栏可以被「讲道理」绕过。
• 网络/基础设施层围栏（enclave）：「agent 物理上够不到」的边界，无论收到什么指令都越不过——围栏无法被推理绕过。

反直觉洞察①：任何写在 prompt / 工具描述里的安全约束，本质上都是「建议」而非「强制」。 Day 52 已证明：工具描述能注入指令、强模型反而更听话。所以「在系统提示里写『绝不未经复核提交 SAR』」这种护栏，在 P2 注入面前是纸糊的。真正的强制必须放在模型推理之外的确定性层——agent 决定要调 submit_sar 之后、真正执行之前，有一个不参与推理、只执行规则的拦截点说「不行」。这就是为什么网关必须是确定性代码，不能是又一个 LLM judge（judge 自己也会被污染）。

落地架构借经典 PEP/PDP 模型（arXiv 2603.20953, Deterministic Pre-Action Authorization, 2026）：

• PEP（Policy Enforcement Point，策略执行点）：拦截在途的工具调用，是「闸门」。挂在 Day 50 的 handleRpc 与真正执行 hybridSearch/draftSar 之间。
• PDP（Policy Decision Point，策略决策点）：评估「这次调用是否合规」，做二元 allow/deny——基于显式策略，不是概率性模型输出。判据：被调的工具 + 传入的参数 + 预设授权规则。

这与 Anthropic 零信任六支柱对齐（Varonis, 2026）：Agent Identity（Day 51 OAuth）、Access Control 按任务 scope、Observability/Auditing、Behavioral Monitoring、Input/Output Controls、Integrity & Recovery。网关 v1 落其中的 Access Control + Input/Output Controls + Auditing 三支柱。

B. 支付风控三段式 → agent 风控网关（核心类比）

这是本篇的金融×AI 交叉点。把一次 MCP 工具调用当成一笔支付交易，支付风控的三段式（对照 docs/arch/day56-risk-control-architecture.md 实时/准实时/离线三层）原样映射：

三段式拦截流水线（伪代码）：

// agent 风控网关拦截流水线（挂在 MCP handleRpc 与工具执行之间）
function riskGateway(call: ToolCall, ctx: CallContext): GateDecision {
  // ── 事前授权（PDP，确定性二元判定）──
  if (!ctx.scopes.includes(scopeFor(call.tool)))         // Day 51 OAuth scope
    return deny('scope_violation', call)                  // → 403 + 审计
  if (call.tool not in ALLOWED_TOOLS)                     // 危险工具白名单
    return deny('tool_not_allowlisted', call)
  if (rateExceeded(ctx.agentId, call.tool))               // 调用频率限额
    return deny('rate_limit', call)

  // ── 事中拦截（参数级规则 + 高危转 HITL）──
  for (const rule of PARAM_RULES[call.tool] ?? []) {      // 参数边界校验
    if (!rule.check(call.args))                           // 如金额∈合理区间
      return deny(rule.id, call)                          // 防 P3 参数篡改
  }
  if (HIGH_RISK_TOOLS.has(call.tool))                     // draft/submit SAR
    return requireHitl(call)                              // → 强制人工复核闸

  // ── 放行 ──（事后审计在 wrapper 里无条件执行）
  return allow(call)
}
// 包裹层：无论 allow/deny/hitl，都 writeAudit(call, decision) → useTraceStore

这套设计精确打击 Day 52 的三范式：

• P1 越权读案件 → 事前授权的 scope 校验 + 事中的「越权访问检测」拦截；
• P2 绕过 HITL 自动提交 → submit_sar/draft_sar_batch 进 HIGH_RISK_TOOLS，强制转 HITL，agent 无论被怎么诱导都没法自己提交；
• P3 金额参数篡改 → 事中 PARAM_RULES 的金额合理性校验（复用 evalChecks 的 amount_money_format + 区间约束）直接拒。

反直觉洞察②：风控网关最该拦的不是「明显的攻击」，是「合法工具的非常规组合」。 支付风控的老经验：单笔交易都合规、组合起来是欺诈（化整为零 structuring——这恰是我们 AML 要抓的 typology！）。agent 同理：get_note（合法）+ export（合法）单看都没问题，但「检索敏感案件后立刻导出」这个序列才是数据外泄。所以网关 v1 的确定性单点规则只是地基，真正的价值在「调用序列/组合」的风控——这正好是我 10 年风控经验的迁移点，也是 v2 要做的（事后审计层先把序列记下来，为序列规则铺路）。

C. 挂进 MCP 调用链：拦截点与降级

网关挂载点必须在「PDP 决策」和「副作用执行」之间，且不可绕过（不能是工具内部的 if 判断——那又回到可被推理绕过的护栏）。

tools/call → handleRpc → [OAuth verifyToken (Day51)]
                              │ token ok
                              ▼
                       ★ riskGateway(call) ★   ← PEP，唯一闸门
                          ┌────┴────┐
                       allow      deny/hitl
                          │          │
                   执行工具纯函数   deny→403+审计
                   (hybridSearch)  hitl→挂起等人工
                          │
                   writeAudit → useTraceStore（事后审计，无条件）

降级纪律（呼应 P1「无 key 诚实降级」）：网关是确定性代码，无需 LLM、无需后端即可运行——这是它相对 prompt 护栏的又一优势。静态仓库里它完全可跑、可测、可演示。HITL 闸在静态阶段表现为「标记为待人工复核状态 + 阻止 agent 自行推进」，真实工单系统对接留到接后端时。

设计要点/决策表

对本项目的落地

• 新建 src/agent/mcp/riskGateway.ts：导出 riskGateway(call, ctx): GateDecision（实现 B 节三段流水线，二元 allow/deny + requireHitl），以及策略常量 ALLOWED_TOOLS/HIGH_RISK_TOOLS/PARAM_RULES。挂进 src/agent/mcp/server.ts 的 handleRpc，在 verifyToken（Day 51）之后、工具执行之前调用，作为不可绕过的 PEP。
• PARAM_RULES 复用 P1 风控逻辑：金额合理性校验直接复用 src/aml/evalChecks.ts 的 amount_money_format 和 CTR 门槛 exceedsCtrSingleCash/CTR_THRESHOLD_CENTS（src/aml/typology.ts），把「确定性单值守卫」从 eval 层复用到运行时拦截层——同一套规则两处用。
• 审计接 trace：网关 wrapper 无条件 writeAudit(call, decision) 写入 src/agent/trace/useTraceStore.ts，与 MCP 调用同 trace；deny/hitl 事件额外打标，为事后离线序列分析（v2）留数据。
• HITL 闸：高危工具（draft_sar_batch/未来的 submit_sar）命中 requireHitl，置「待人工复核」状态、阻断 agent 自行推进——对应 P1 已有的 HITL 复核模型（src/aml/types.ts 的 ReviewAction）。
• 验证闭环：用 Day 52 的 measureBaselineAsr 在「挂网关前 vs 挂网关后」各跑一次，断言 ASR 显著下降——把「防御有效」做成可量化的回归测试（呼应 P1「先有基线再谈改进」）。
• 诚实标注：riskGateway.ts 头注写明「v1 为确定性单点规则 + 三段骨架；序列/组合风控、ML 异常检测、真实工单系统对接为后续迭代；网关本身无需 LLM/后端，静态仓库可跑可测」。

参考资料

1. Varonis — Zero Trust for AI Agents: How to Enforce Anthropic's Framework：Anthropic 零信任六支柱（Agent Identity/Access Control 按任务 scope/Observability/Behavioral Monitoring/Input-Output Controls/Integrity & Recovery）、pre-execution/in-flight/post-hoc 三层时序 (2026)
2. arXiv:2603.20953 — Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents：调用执行前确定性策略评估、PEP/PDP 模型、二元 allow/deny、基础设施层 hard stop 而非 prompt 内约束 (2026)
3. Zscaler — Zero Trust for AI Agents: Least Privilege for Prompts & Plugins / Zentera — Zero Trust Architecture for Agentic AI in 2026：enclave（网络层强制，不可被推理绕过）vs guardrail（prompt 指令，可被绕过）、AI Gateway 在请求路径内联强制 (2026)
4. 本仓库 docs/arch/day56-risk-control-architecture.md（实时/准实时/离线三层风控，本篇三段式骨架来源）、docs/arch/day57-rule-engine-design.md（规则引擎）(2026-05)
5. 本仓库 src/aml/evalChecks.ts（amount_money_format/exceedsCtrSingleCash 复用为运行时规则）、src/aml/typology.ts（CTR_THRESHOLD_CENTS）、src/agent/mcp/server.ts（被保护的 MCP 调用链）、src/agent/trace/useTraceStore.ts（审计）、src/aml/types.ts（HITL ReviewAction）(2026-06)

SOTA 检查 (2026-06-11)

• 「prompt 护栏不可靠、需协议外确定性网关」是 2026 agent 安全共识：Anthropic 零信任框架、OWASP Agentic Top 10 2026（2025-12-10，ASI01 Agent Behavior Hijacking 列为最危）、ThoughtWorks Radar Vol 34（2026-04，「权限饥渴 agent 用零信任」）三方一致。本篇方向与 SOTA 对齐。
• PEP/PDP 确定性预授权是上升中的范式（arXiv 2603.20953, 2026）；但「确定性规则 vs ML 自适应」之争未定——纯规则覆盖率有限（反洞察②的序列攻击），v2 须评估引入轻量异常检测，但裁判层仍应确定性（防污染）。
• NIST CAISI（2026-02-17 启动，Q4 2026 出 profile）将定 tool invocation governance / runtime constraints 标准——本篇网关设计须在 Q4 标准发布后对标回填，确保 scope/审计/HITL 闸符合 COSAiS 对齐的 runtime monitoring 要求。
• 支付风控三段式迁移到 agent 是本项目差异化点：未见公开资料系统性把「事前/事中/事后 + 化整为零序列风控」从支付迁到 MCP 网关——这正是 10 年金融背景的可展示交叉创新，但须诚实标注 v1 仅落单点规则、序列风控未实现。
• 过时认知警示：「靠系统提示约束 agent 行为」「升级更强模型即更安全」均已被 Day 52 的 MCPTox 证伪；安全必须是确定性的协议外强制。