商业银行开放银行场景下引入 A2A/MCP 智能体调用的安全架构与网关演进设计

版本：v3.7 · 更新日期：2026-10-25 · 状态：技术可行性研判稿（未经密评、PoC 与正式架构评审验证）

摘要：本报告研判商业银行在对公开放银行场景下，通过 A2A 1.0 与 MCP 2026-07-28 向合作方智能体开放调用的技术可行性与路线合理性。结论是有条件可行。L1 只读查询，以及不产生法律、资金或资源占用后果的 L2 业务草拟，可以在“外层金融 API 网关 + 内层智能体协议网关 + 合作方受控 Adapter／银行 SDK”架构下分阶段试点。L3 资金动账及其他有约束力的操作，智能体只能经 A2A/MCP 提交无执行权限的待审批意图；本期 L3 可行范围限于已设计的资金支付路径，执行仍走银行带外确认、企业经办／复核和银行受控的确定性支付接口。锁价成交等非支付类约束性操作须另建确定性成交及审批硬校验路径，完成前不纳入本期可行范围。可行范围还取决于五项前提：接口与数据分级、合作方数据处理角色及外部模型数据流的合规评估、密码应用方案与密评、协议互操作，以及故障恢复与容量验证。上述前提完成前，本报告不构成生产准入或合规结论。

一、 术语、合规分层与业务分级 #

1. 核心术语与规范依据 #

2. 四层合规分类 #

flowchart TD
    L1["第一层：法律、行政法规与部门规章<br/>（按发文属性、适用范围与条款逐条判定强制性）"]
    L2["第二层：行业标准与推荐性国标<br/>（JR/T 0185、JR/T 0197、JR/T 0171、GB/T 39786，区分“应／宜”与适用性）"]
    L3["第三层：密码应用方案选定的技术实现<br/>（TLCP、SM2/SM3/SM4、密码产品，以密评结论为准）"]
    L4["第四层：本行准入与安全增强策略<br/>（报文签名 Profile、Max-Hop=1、合作方密钥保护分档、L3 双人复核）"]
    L1 --> L2 --> L3 --> L4

1. 法律、行政法规与部门规章：《数据安全法》《网络安全法》《个人信息保护法》[14]、《密码法》[33]、《网络数据安全管理条例》[30]、《银行保险机构数据安全管理办法》[31]、《银行保险机构信息科技外包风险监管办法》[32]，以及金发〔2026〕8号指导意见 [10]。指导意见属政策性文件，其强制程度须逐条确认；《生成式人工智能服务管理暂行办法》[34] 只适用于向境内公众提供生成式服务的情形，须按实际服务形态判断，不能因采用 A2A/MCP 就断言适用或豁免。
2. 行业标准与推荐性国标：JR/T 0185 的 A1/A2 接口要求 [1]，JR/T 0197、JR/T 0171 的数据分级与个人金融信息分类 [17][22]，GB/T 39786 第 8 章的第三级密码应用要求 [2]。
3. 密码应用方案选定的技术实现：TLCP、密码机持管私钥及 SM2/SM3/SM4 是候选实现路径，以本行密码应用方案和密评结论为准；引用国标算法不等于自定义信封或部署已通过密评。
4. 本行准入与安全增强策略：本报告提出的报文签名 Profile、Max-Hop=1、合作方密钥保护分档、AgentCard 白名单和 L3 复核矩阵，都属于本层，不得表述为监管强制要求。

判定原则：先由法律监管义务、标准适用范围、数据类别和系统密码应用等级确定保护目标，再选择实现技术。不得把“TLS/TLCP 已加密”等同于已满足需要应用层报文加密的情形，也不得把“所有 SSE 事件逐帧 SM4 加密”表述为标准的明文要求。[1][2][14]

3. 双维分级矩阵（JR/T 0185 接口等级 × 智能体业务影响） #

quadrantChart
    title 金融接口安全等级 (JR/T 0185) vs 智能体业务操作影响分级
    x-axis "低业务影响 (L1/L2)" --> "高资金/法律影响 (L3)"
    y-axis "通用安全保护 (A1)" --> "高等级安全保护 (A2)"
    quadrant-1 "严格受控：智能体仅提交待审批意图"
    quadrant-2 "合规重度：敏感数据查询与非约束性草拟"
    quadrant-3 "基础开放：公开行情与网点查询"
    quadrant-4 "不可行域：禁止无安全控制的资金指令"
    "公开汇率/网点 (L1/A1)": [0.15, 0.2]
    "账户余额/流水 (L1/A2)": [0.25, 0.85]
    "授信预审/调账建议 (L2/A2)": [0.45, 0.8]
    "归集划拨/放款划付 (L3/A2)": [0.88, 0.95]

二、 协议规范事实与可行性边界 #

1. 协议能力边界（按锁定版本核对） #

互操作前提：A2A、MCP 及其扩展均按所锁定的规范版本（标签或提交）实施，并以官方 SDK／一致性测试实测；锁定版本外的兼容性不作宣称。CIMD 动态准入默认不启用，合作方证书／AppID 预注册；RFC 9207 在存在多个授权服务器的回调中启用。[11][12]

三、 目标架构：三层实施与四域治理 #

方案采用“合作方受控 Adapter／银行 SDK + 银行外层金融 API 网关 + 银行内层智能体协议网关”三层部署，由授权决策、任务执行、审计、确定性执行四个逻辑安全域治理。L3 路径单独经交易意图服务和带外审批进入支付核心：

flowchart TB
    subgraph ClientZone["合作方受控域"]
        AgentHost["企业智能体宿主<br/>(标准 MCP / A2A)"]
        Adapter["受控 Adapter / 银行 SDK<br/>(银行提供或认证 · 请求加签 · 响应验签<br/>按授权解密并还原标准消息)"]
        AgentHost <-->|"本地 IPC / 受控 HTTP<br/>工作负载认证与最小授权"| Adapter
    end

    subgraph OuterZone["外层金融 API 网关（边界与密码层）"]
        GW_TLCP["TLCP / mTLS 通道终止"]
        GW_Sign["报文验签 · Nonce 防重放<br/>路由与受众绑定"]
        GW_Stream["响应安全出口<br/>依据内层可信元数据签名／按需加密"]
        GW_TLCP --> GW_Sign --> GW_Stream
    end

    subgraph InnerZone["内层智能体协议网关（协议治理层）"]
        AG_Router["协议解析与路由<br/>(A2A / MCP 锁定版本)"]
        AG_Gov["治理引擎<br/>(Tool Pinning · 状态机 · 轮次熔断)"]
        AG_Filter["Schema / DLP / 数据分级<br/>生成可信事件元数据"]
        AG_Router --> AG_Gov --> AG_Filter
    end

    subgraph AuthDomain["安全域 1：授权与策略决策"]
        PDP["中央 PDP<br/>(主体持续鉴权 · 资源级 ABAC · 撤销处理)"]
        STS["STS<br/>(RFC 8693 委托裁剪 · Max-Hop=1)"]
    end

    subgraph ExecDomain["安全域 2：任务执行与状态隔离"]
        Outbox["Task 状态机 + Outbox<br/>(单库事务 · 幂等持久化)"]
        Adapter_Conv["协议降维转换<br/>(仅 L1/L2 查询与草拟)"]
        DraftSys["交易意图服务 DraftSys<br/>(L3 仅生成待核签草稿，无自主动账权限<br/>仅凭有效 Approval_Proof 经确定性支付接口提交)"]
    end

    subgraph AuditDomain["安全域 3：独立审计"]
        AuditLog["业务审计引擎<br/>(输入摘要 · 决策上下文 · 审批单据)"]
    end

    subgraph CoreZone["安全域 4：银行核心与确定性执行"]
        BizAPI["账务 / 融资业务系统<br/>(只读与草拟接口 · 二次权限校验)"]
        CIBA_Sys["银行带外确认渠道<br/>(展示要素 · 复算摘要)"]
        CorporateMatrix["企业经办／复核流程"]
        CorePayCheck["支付核心执行前硬校验<br/>(草稿 · 摘要 · 审批凭证 · 额度 · 幂等)"]
        CoreAPI["支付核心<br/>(权威记账流水)"]
        CorePayCheck --> CoreAPI
    end

    Adapter <==>|"TLCP 通道 · 请求签名 / 响应签名"| GW_TLCP
    GW_Stream <-->|"内部认证通道 + 绑定本次请求的可信上下文"| AG_Router
    AG_Gov <-->|"持续授权判定"| PDP
    PDP <-->|"凭证降权与受众限制"| STS
    AG_Filter --> Outbox
    Outbox --> Adapter_Conv
    Adapter_Conv ==>|"L1/L2 确定性查询·草拟报文"| BizAPI
    Outbox -->|"L3 交易意图"| DraftSys
    DraftSys -.->|"不可变要素 + 摘要"| CIBA_Sys
    CIBA_Sys -.->|"确认凭据"| CorporateMatrix
    CorporateMatrix -.->|"Approval_Proof"| DraftSys
    DraftSys ==>|"审批凭据 + 幂等键，经确定性支付接口提交"| CorePayCheck
    AG_Gov -.->|"上下文归档"| AuditLog
    CoreAPI -.->|"权威流水与终态"| AuditLog

1. 存量金融 API 网关改造评估 #

成本栏均为初步估计，须按实际网关产品、版本、现网流量与 HSM 容量验证。

2. 双网关可信上下文与明文边界 #

四、 核心安全不变量与技术契约 #

1. 身份、委托与持续授权 #

flowchart TB
    ROOT["三维身份与持续授权契约"]
    subgraph SOURCES["① 身份来源与密钥绑定"]
        direction TB
        PARTNER["合作机构身份<br/>机构证书 + 外层 TLCP/验签确认<br/>绑定 AppID 注册表"]
        USER["终端用户身份"]
        MODE_A["模式 A｜用户交互<br/>Token cnf 绑定的持钥主体<br/>mTLS 校验证书指纹；DPoP 校验逐请求证明"]
        MODE_B["模式 B｜企业无人值守司库 Agent<br/>企业授权经银行验证并登记服务主体<br/>STS 颁发受限持钥服务凭证（账户范围、限额、有效期、撤销）"]
        AGENT["智能体与任务上下文<br/>银行签发的 Task ID + 白名单 Agent ID"]
        USER --> MODE_A & MODE_B
    end
    subgraph MATRIX["② 资源级 ABAC｜中央 PDP 强制核验"]
        direction TB
        B0["通用前提：所有操作均受当前有效的账户、业务资源、任务与字段权限约束<br/>角色或创建者身份不能替代资源授权"]
        B1["提交任务<br/>Partner 资质 &amp;&amp; User 对公授权 &amp;&amp; 目标账户在授权范围 &amp;&amp; 额度合规"]
        B2["查询 / 订阅 / 重放<br/>同租户 &amp;&amp; 对该任务所涉账户与资源当前有权"]
        B3["补充输入<br/>同租户 &amp;&amp; 任务写入权限 &amp;&amp; 任务处于 INPUT_REQUIRED"]
        B4["取消任务<br/>同租户 &amp;&amp;（创建者或企业管理员）&amp;&amp; 资源权限有效"]
        B5["后台推进<br/>执行器推进下一节点或访问敏感资源前向 PDP 复核授权未撤销"]
        B6["获取产物<br/>同租户 &amp;&amp; 对该 Artifact 及其字段当前有读权限"]
        B0 ~~~ B1 ~~~ B2 ~~~ B3 ~~~ B4 ~~~ B5 ~~~ B6
    end
    subgraph REVOCATION["③ 授权撤销分级处理"]
        direction TB
        R1["尚未执行敏感动作<br/>终止推进，置 CANCELED"]
        R2["执行中且可逆<br/>下发取消，回滚完成后置 CANCELED"]
        R3["已不可逆提交或部分成功<br/>冻结后续步骤，进入对账／人工处置<br/>对外状态须携带“对账中、禁止重试”标识"]
        R4["Token 自然到期 ≠ 撤销授权<br/>到期可合规刷新；撤销则永久中止委托"]
        R1 ~~~ R2 ~~~ R3 --> R4
    end
    ROOT --> PARTNER & USER & AGENT
    ROOT --> B0 & R1
    classDef title fill:#203b5b,stroke:#203b5b,color:#ffffff,stroke-width:1px;
    classDef base fill:#eef5fb,stroke:#83a1bd,color:#1b3a53,stroke-width:1px;
    classDef access fill:#edf8f3,stroke:#6ba38e,color:#194b3a,stroke-width:1px;
    classDef caution fill:#fff4e4,stroke:#d5a35b,color:#60421e,stroke-width:1px;
    class ROOT title;
    class PARTNER,USER,AGENT,MODE_A,MODE_B base;
    class B0,B1,B2,B3,B4,B5,B6 access;
    class R1,R2,R3,R4 caution;

持钥证明不可替代：SM3(Token) 只是令牌值绑定摘要，不是持钥证明。模式 A 须在银行资源服务器或可信前置组件核对令牌 cnf 与真实呈现的证明：mTLS 核对匹配的客户端证书，DPoP 核对 htu、htm、iat、jti、ath（适用时）与公钥指纹。Adapter 代发请求时，应经受控令牌交换重新颁发绑定实际调用者的短期凭证，或可靠转发并核验用户证明，不能以机构证书代替用户持钥证明。模式 B 使用显式受限服务主体及其持钥凭证，空 Token 摘要不得作为匿名放行依据。用户对获取、使用、变更账户与资金信息的接口，应用方须先取得用户明示同意，同意内容包含授权有效期（JR/T 0185 第 9.3.2 节）。[1][6][19][20]

2. HTTP 报文签名与防重放 #

本行定义基于 SM2/SM3 的签名 Profile，借鉴 RFC 9421 的覆盖组件与规范化思路，但与其 Signature-Input/Signature 结构不天然兼容。[13]

约束：签名基础串的字节编码、字段顺序、@query 空值哨兵与 SM2 参数（GB/T 32918.2、GM/T 0009）在专项规范中以跨语言测试向量冻结。[23][24] 可在不受信任区做无副作用的协议分类以选择 Profile，但验签与可信身份确认前不得路由至高权限或跨租户后端。重发业务请求换新 Nonce、沿用同一业务幂等键。

3. 异步任务、Transactional Outbox 与故障恢复 #

Task 与 Outbox 原子提交只保证调度意图不丢失，不保证恰好一次执行。 Nonce 防重放与业务幂等键是两个独立机制。

sequenceDiagram
    autonumber
    participant C as 合作方 Adapter
    participant G as 智能体协议网关
    participant DB as Task + Outbox 数据库
    participant D as Dispatcher / CDC
    participant W as Worker
    C->>G: POST /message:send（新 Nonce + 业务幂等键）
    G->>G: 验签、PDP、校验幂等键
    critical 单库事务
        G->>DB: UNIQUE（Partner, Tenant, Operation, IdempotencyKey）
        G->>DB: 原子插入 Task + OutboxEvent（SUBMITTED / NEW）
    end
    DB-->>G: Commit Confirmed
    G-->>C: 返回 Task，或命中幂等记录返回既有 Task
    Note over C,DB: ACK 丢失后换 Nonce 重试也不产生第二任务
    D->>DB: 原子认领 NEW 事件（租约 + 代次）
    D->>W: 至少一次派发（Task ID + 幂等键 + 代次）
    W->>DB: CAS 认领，推进 WORKING
    W->>W: 调用下游前复核授权与幂等状态
    W->>DB: 按代次条件写入结果，事件标记 PROCESSED
    Note over D,W: 崩溃后可重派；下游必须独立幂等
    C->>G: GET /tasks/{id}:subscribe（非终态）
    G-->>C: SSE 事件；断流不取消已持久化 Task
    C->>G: GET /tasks/{id}（终态查询）
    G-->>C: 已签名 Task 状态 / 授权范围内 Artifact

不变量：①幂等冲突时核对请求关键字段摘要，不同则拒绝；②Dispatcher 以 SKIP LOCKED 或 CAS 认领，配置租约与退避；③WORKING 须有续租、超时接管与人工队列，租约失效后的旧 Worker 不得提交副作用或覆盖新执行结果（以接管代次或等效 fencing 机制保证，代次须随下游调用传递，并由副作用提交点校验，或由前置机制保证校验与提交之间不能被接管竞态穿透；仅拒绝数据库写入不足以阻止旧 Worker 的下游副作用；下游不支持代次校验时，相应操作限定为幂等且无外部副作用，否则不纳入本期）；④有副作用的操作依靠下游确定性幂等；⑤Task_ID 由银行签发，跨租户不可推断访问。

4. 响应完整性与 SSE 安全信封 #

业务生效原则：流完整不等于业务完成。正式交付的 Artifact 须同时具备已验证的 Task 终态（TASK_STATE_COMPLETED）、产物版本与摘要、有效业务授权和必要的产物签名；仅通过 GetTask 取得的合法结果不要求额外收到流终态。

试点优先路径：A2 响应签名首先落在权威结果上，即 A2A GetTask 响应与正式 Artifact、MCP Tasks 按锁定版本取得的最终结果，以及同步调用（MCP tools/call、非 returnImmediately 的 A2A SendMessage）的返回结果，含调用停在需补充输入或授权等中断状态时返回的 Task 快照；这些结果同样执行适用的签名、授权及业务结果校验。A2 数据的 MCP 同步工具调用优先以单个 JSON 响应返回并签名；以 SSE 承载最终结果时，该结果事件须按候选增强路径签名，单事件签名形态由专项规范确定 [4][5][29]。其余流式事件只承载进度与非敏感状态，由 TLCP 通道保护，并标注为非权威、不得作为业务依据；A2 数据不得进入非权威事件，由内层 Schema／DLP 拦截。这样进度事件可由标准 MCP/A2A 客户端直接消费，Adapter 只需验证最终结果，HSM 吞吐压力也较小。该解释是否满足 JR/T 0185 对 A2 交互数据签名的要求 [1]，须经合规与密评确认；获确认后方可采用，未获确认时采用满足签名要求的路径（如对流内事件启用下述候选增强路径）。

候选增强路径：需要对流内事件提供第三方可验证证据时，采用银行侧 bank.signed-event / bank.stream-completed 信封。它们不是 MCP/A2A 原生格式，须经 Adapter/SDK 验签、必要时解密并还原标准事件。[4][5]

flowchart TB
    IN["内层协议网关<br/>标准业务事件 + 可信元数据"] --> MODE{"保护等级与明文授权"}
    MODE -->|允许明文| P["payload_mode = plaintext"]
    MODE -->|需加密且接收方获准解密| E["payload_mode = ciphertext<br/>SM4-GCM 认证加密"]
    MODE -->|接收方无明文权限| X["仅脱敏 / 引用输出<br/>或密文经独立通道送达获授权终端"]
    P --> HASH["统一信封<br/>全局 task_event_seq + 单流 stream_chunk_seq<br/>SM3 累积哈希链"]
    E --> HASH
    HASH --> SIGN["网关 HSM 按 Profile SM2 签名"]
    SIGN --> END["签署 stream-completed<br/>承诺事件数与最终链摘要（含零事件流）"]
    END --> TASK["业务生效另需 Task 终态 + 授权 + 产物签名"]
    classDef base fill:#edf5fb,stroke:#87a4be,color:#20435b;
    classDef protect fill:#e8f6ef,stroke:#69a88b,color:#194c37;
    classDef warn fill:#fff3e6,stroke:#d1a15e,color:#5d3c1d;
    class IN,MODE,P,E base;
    class HASH,SIGN,END,TASK protect;
    class X warn;

候选信封须满足以下原则，字节级规则（JCS 编码、摘要的二进制与 Hex 表示、元数据字段集、首帧与零事件流的链初值、签名域分离、AAD 字段）由专项规范与跨语言测试向量冻结 [18]：

1. 覆盖完整：明文与密文两种模式使用相同的元数据、双序号、哈希链与签名范围；AAD 字段同时处于签名覆盖范围。
2. 编码唯一：签名与哈希输入只有一种可复现的字节表示，拒绝重复键与算法、密钥 ID 或编码降级。
3. 流实例证明：结束签名只证明单个流实例完整；跨断流的连续性依赖持久 Task Event Ledger 的全局序号与授权重放，不能用单个流的结束签名证明整个 Task 历史。
4. Nonce 不重复：同一密钥下 SM4-GCM Nonce 绝不重复；同流换密钥仅在接收方具备新密钥、上下文衔接且测试向量通过时允许，否则在新流切换；轮换失败终止受保护流，不降级为明文。
5. 失败即停：签名失败、链断裂、序号重复或 AEAD Tag 错误时，立即停止可信转发并告警。

5. 机密性保护与明文边界 #

三类独立控制：TLCP 通道保护提供链路机密性与实体认证，但不提供应用层签名证据，也不保护终止点之后的明文；SM2/SM3 签名提供来源与完整性证据，不提供机密性；应用层加密（字段、报文或产物级）限制明文可见范围，不替代签名、授权与脱敏。三者分别评估，任何一项不默认替代其余两项。

flowchart TB
    B["银行 MCP / A2A 服务<br/>生成原生业务事件"] --> POLICY["数据分级 + 接口等级 + 接收方明文许可<br/>确定可信解密终点"]
    POLICY --> DEC{"是否需要额外应用层加密？"}
    DEC -->|否| A["路径 A｜TLCP 通道 + 适用的响应签名"]
    DEC -->|是| AUTH{"谁获准接触明文？"}
    AUTH -->|合作方被授权| E["路径 B1｜银行加密<br/>数据密钥只发受授权 Adapter / SDK"]
    AUTH -->|合作方不获授权| N["路径 B2｜合作方 Agent / 普通 Adapter 不获密钥"]
    E --> VERIFY["先验签名与接收者身份<br/>再验 AEAD Tag 并解密"]
    VERIFY --> AGENT["按最小授权交付 Agent"]
    N --> SAN["标准 MCP/A2A 仅返回<br/>脱敏结果、状态或受控 Artifact 引用"]
    N --> SIDE["密文经独立通道直达获授权终端<br/>终端与被排除主体在管理权、密钥、明文输出上隔离"]
    classDef base fill:#edf5fb,stroke:#829ebb,color:#1d3e57;
    classDef safe fill:#e9f7f0,stroke:#6fa68e,color:#194a39;
    classDef warn fill:#fff4e5,stroke:#d0a05c,color:#65421b;
    class B,POLICY,DEC,AUTH base;
    class A,E,VERIFY,AGENT,SAN safe;
    class N,SIDE warn;

落地约束：

1. 先授权，后发密钥：密钥服务核对合作机构、主体、用途、有效期与获准的解密环境；对合作方不得获知明文的数据，合作方 Adapter 没有解密能力。“合作方先解密再禁止展示”不是保护措施。
2. 撤销的真实边界：撤销授权只能停止新增数据、新密钥发放和后续受控访问；已交付的密钥与明文无法远程收回。需要持续可撤销访问时，采用银行控制的在线解密或经验证的隔离执行机制，并验证撤销时延。
3. 引用独立鉴权：Artifact 引用的后续访问须独立鉴权、限时且受用途约束，持有引用不等于可取得明文。
4. 输入侧与输出侧区分：JR/T 0185 第 9.3.3 节在一般性规定应用方“不应采集、存储用户个人金融信息或支付敏感信息”之外，另针对需要用户输入支付敏感信息或身份鉴别信息的场景，要求应用方只作采集与传输通道、部署银行 SDK 并加密，信息不得在应用方留存 [1]；这与银行向合作方推送查询响应是两类场景。

6. 输入与工具安全的真实边界 #

7. L3 资金交易：意图、带外授权与权威对账 #

智能体只可生成待审批的交易意图，不拥有资金执行能力。 本款设计只覆盖资金支付路径，硬校验由支付核心在记账前完成；锁价成交等可能在支付记账前即已生效的约束性操作，支付核心校验不能充当其成交前控制，须另建确定性成交及审批硬校验路径。融资放款中信贷出账审批、借据生成等先于支付生效的环节，同样不由支付核心硬校验替代，由信贷系统的审批控制承担。CIBA 是银行受控带外确认机制，不能取代企业网银的经办／复核与既有法律授权程序；带外确认是否构成《电子签名法》意义上的可靠电子签名，须法务确认。结构化授权可参考 RFC 9396，但非监管必选。[8][25]

sequenceDiagram
    autonumber
    participant Agent as A2A/MCP Agent
    participant Draft as 交易意图服务（DraftSys）
    participant CIBA as 银行带外确认渠道
    participant Maker as 企业经办／复核
    participant Core as 支付核心
    participant Reconcile as 权威对账服务
    Agent->>Draft: 申请生成业务草稿（无动账权限）
    Draft->>Draft: 校验要素，签发 Draft_ID + Intent_Digest + Version
    Draft-->>Agent: 仅返回待确认草稿及摘要
    Draft->>CIBA: Draft_ID + 结构化交易要素 + Intent_Digest
    CIBA->>CIBA: 可信界面展示收款人、账号、金额、币种并复算摘要
    CIBA->>Maker: 确认凭证绑定 Draft_ID / Digest / 审批人 / 时效
    Maker->>Maker: 按本行矩阵完成经办与独立复核
    Maker->>Draft: 提交 Approval_Proof
    Draft->>Draft: 记录 SUBMITTING + 幂等键 / Outbox
    Draft->>Core: 经确定性支付接口提交审批凭据与幂等键
    Core->>Core: 硬校验：Draft、Digest、Proof、限额、幂等未消费
    alt 执行前确定性拒绝且未记账
        Core-->>Draft: 可验证的权威拒绝
        Draft->>Draft: TX_REJECTED
    else 记账成功
        Core-->>Draft: 带流水号的成功通知
        Draft->>Draft: TX_SUCCESS
    else 超时或结果未知
        Draft->>Draft: PENDING_RECONCILIATION，锁定幂等键
        Draft->>Reconcile: 触发对账
        Reconcile->>Core: 按幂等键查询权威状态
        alt 成功且有权威流水
            Reconcile->>Draft: TX_SUCCESS
        else 核心出具终态未执行凭据
            Reconcile->>Draft: TX_ABORTED
        else 未找到 / 处理中 / 清算未决
            Reconcile->>Draft: 保持挂起，继续冻结幂等键
        end
    end

不变量：①Intent_Digest 以确定性编码覆盖草稿 ID、版本、企业、付款方、收款方、金额、币种、用途、有效期等冻结要素，Approval_Proof 覆盖摘要、经办与复核身份、批准范围与有效期，核心校验角色分离与凭证唯一；②“无流水”或“查询未找到”不等于未执行，只有执行前确定性拒绝且未记账，或核心出具的终态未执行凭证，才能关闭指令；③结果未知期间不得以新幂等键重试，长期未决转人工升级，不因超时自动解锁重付；④对账服务须独立获知“已提交及其超时”，不依赖客户端是否收到回包；⑤企业拒批、超时或凭证无效形成明确状态，不向 Agent 下发可执行令牌。以上控制把越权动账限定为必须通过确定性校验才能发生，剩余风险集中在核心规则与审批配置缺陷，不能宣称“杜绝”。

五、 合作方智能体与 Adapter 的技术要求 #

1. 合作方（应用方）义务与本行准入要求 #

2. Adapter／银行 SDK 四维控制 #

Adapter 是本方案默认的接入实现之一，不是 MCP/A2A 协议要求的组件，由银行提供或经银行认证；等效银行 SDK 适用相同准入 Profile。四项控制须独立评估，组合后不自动形成端到端可信链：

flowchart TB
    ROOT["受控 Adapter / 银行 SDK｜四维独立控制"]
    KEY["① 私钥防提取（本行准入策略·第四层，按接入等级分档）<br/>A2 及 L2 以上：私钥在经认证的硬件密码模块内生成且不可导出<br/>形态可为密码机、密码卡、智能密码钥匙或经评估的云密码服务<br/>具体产品与部署由准入评估确定"]
    TEE["② 运行态隔离（可选增强）<br/>关键加签模块运行于硬件 TEE<br/>降低宿主特权对敏感内存的窥探风险<br/>不覆盖全部侧信道与外部 I/O"]
    ATTEST["③ 工作负载完整性（可选增强）<br/>经独立受控通道验证远程证明<br/>绑定工作负载身份与密钥／会话<br/>不假定 TLCP 握手原生携带证明"]
    GUARD["④ 签名接口防滥用（必需）<br/>Local PDP 校验个人令牌或企业服务主体凭证<br/>本地 IPC 工作负载认证、最小权限与审计<br/>未授权加签请求在 Adapter 边界拒绝"]
    ROOT --> KEY & TEE & ATTEST & GUARD
    classDef title fill:#203b5b,stroke:#203b5b,color:#ffffff,stroke-width:1px;
    classDef baseline fill:#e9f4fc,stroke:#779ebd,color:#1d3b54,stroke-width:1px;
    classDef enhanced fill:#edf5ff,stroke:#859ac6,color:#293a67,stroke-width:1px;
    classDef protect fill:#fff4e8,stroke:#d3a15f,color:#62421e,stroke-width:1px;
    class ROOT title;
    class KEY baseline;
    class TEE,ATTEST enhanced;
    class GUARD protect;

边界说明：私钥放在硬件里、代码放进 TEE，都不能推出宿主特权无法诱导加签；须验证 HSM API 访问控制、受认证的加签会话与防绕过能力。AgentHost→Adapter 的 stdio、UDS 或本地 HTTP 通道须结合进程隔离、调用方身份认证（如 SO_PEERCRED）与敏感明文保护设计，不能默认本地即可信。Local PDP 只做第一道拦截，最终授权仍在银行 PDP；机构证书不能替代用户业务授权。

3. 通用智能体宿主的兼容约束 #

• 未改造的通用 MCP/A2A 宿主不能直连 A2 接口：它们无法生成本行签名 Profile、完成 TLCP 双证书握手或解析银行自定义信封，须经本地 Adapter／银行 SDK 接入，且只接收还原后的原生协议消息。
• 不经 Adapter 的直接接入仅限 L1/A1 公开数据，并以 A1 完整性要求可由所选通道与签名机制满足为前提。
• 宿主须支持所锁定的协议版本与认证流程；旧版宿主、浏览器宿主及调用外部模型服务的宿主，另做适配与数据边界评估。

六、 可行性结论与准入前置验证 #

1. 可行性结论 #

• 总体判断：有条件可行。 L1 只读与非约束性 L2 草拟，可在本报告架构下分阶段试点。L3 只在“智能体生成待核签意图 + 银行受控的确定性支付接口执行”的模式下可行（支付核心须新增记账前硬校验，列为前置），本期限于已设计的资金支付路径；锁价成交等非支付类约束性操作在另建确定性成交及审批硬校验路径前不纳入本期可行范围。可行范围以摘要所列五项前提为前置条件：接口与数据分级、合作方数据处理角色及外部模型数据流的合规评估、密码应用方案与密评、协议互操作，以及故障恢复与容量验证（以 PoC 结果证明）。
• 监管与密码路径：方向可行，待验证。 TLCP 通道、A2 双向签名、数据分级驱动的机密性保护与合作方不留存约束，为满足 JR/T 0185 的 A2 要求和 GB/T 39786 第 8 章提供了技术路径。不能仅凭 TLCP 与请求签名推定全部场景合规。
• 协议兼容：有条件可行。 须锁定 A2A 与 MCP 版本、只对外开放一种 A2A 绑定，并通过官方 SDK 互操作和取消语义测试。自定义信封只能经 Adapter/SDK 还原后交给标准客户端。
• 主要制约：合作方智能体背后的外部模型数据流（出境、留存、训练用途）；A2 数据不得在合作方留存与 Agent 会话记忆之间的冲突；HSM 签名容量；合作方 Adapter 的部署成本。前两项不解决，相应场景不纳入本期可行范围。

2. 实施前须形成的合规输入 #

接口 A1/A2 分类台账；JR/T 0197 数据等级台账与 JR/T 0171 个人金融信息分类台账；合作方数据处理角色、外部模型服务与出境适用性评估；对外提供个人信息的法律基础（告知与单独同意等）及个人信息保护影响评估；合作方明文接触许可与不留存承诺的技术核验方式；通道终止与内部明文流转边界图；密码应用方案及密评判定；密钥生命周期与客户侧适配能力清单。仅凭“已启用 HTTPS/TLCP”或“已逐事件加密”不能证明合规。[1][14][30][31]

3. 生产准入前置验证（PoC 分组） #

安全正确性用例以预定义样本全部阻断或状态断言通过为门槛；这只证明所列样本通过，不代表能阻断未知攻击。性能与对抗指标按生产峰值、业务 SLA 与 HSM 容量测算后确定。未启用的部署模式须记录“不适用”及依据。

准入证据包括：规范版本与测试向量、故障注入结果、任务与支付事件日志、数据分级清单、跨网关信任边界图、客户侧解密授权模型、性能基线与获批阈值、风险接受与整改记录。PoC 通过不替代密评和正式生产变更审批。

七、 监管合规追溯与标准映射 #

八、 少数意见 #

以下意见有依据，但未作为本版正文结论，保留供后续评审与专项设计参考：

1. 以 TLCP 免除应用层加密（顾问席）：传输通道已由经密评认定的 TLCP 覆盖、且报文不涉及个人金融信息时，可向密评机构申请评估免除应用层逐事件加密。本版的处理是：GB/T 39786 只规定保护目标，是否需要额外加密由密评判定；“申请免除”是否成立属密评结论，正文不作预判。
2. HSM 只签结束帧（顾问席）：网关在内存中实时计算累积哈希链，HSM 只对 stream-completed 签名，以缓解 HSM 容量压力。限制是：结束前的中间事件没有可验证签名，不能作为可信依据。本版把流式事件定为非权威、优先签权威结果，与此方向一致；具体签名粒度留待 PoC。
3. SSE 逐事件信封是否保留为默认方案（第二主持提请裁决）：原 v3.3.1 把逐事件签名链作为默认架构。本版改为“权威结果签名优先、逐事件信封为候选增强”。反对意见认为这会削弱流式业务的证据粒度。A2 交互数据签名要求是否覆盖中间流事件，须经合规与密评确认。
4. 合作方密钥保护的具体分档（主主持、顾问席）：主主持建议分三档（合作方自持 HSM／密码卡、经认证的云密码服务、仅 L1/A1 可用软件密钥）；顾问席建议通用合作方可用经认证的软件密码模块，仅关键合作方要求硬件。本版只确定“本行策略、按接入等级分档、A2 及 L2 以上使用硬件密码模块”，具体分档由准入评估确定。
5. 国密 DPoP 的实现约束（核验席，按记忆，待核）：DPoP 证明为 JWS，JOSE 算法注册表中未见 SM2 登记，采用国密 DPoP 需自定义算法标识，标准 OAuth 库不支持。建议优先采用 mTLS/TLCP 证书绑定令牌。待核实注册表现状后再决定是否写入正文。
6. A2A 概述文档与 a2a.proto 的映射差异（第二主持）：第二主持称 A2A v1.0.1 概述页把订阅列为 POST，与 a2a.proto 的 GET 不一致。本版只以已核对的 a2a.proto 为准，并要求按锁定版本以 SDK 实测；概述页的差异未经主持人复核，不写入正文。
7. 版本号：第二主持、顾问席建议 v3.3.2；主主持、核验席、质疑席建议 v3.4。v3.4 改动涉及结论、架构图与合作方要求定级，当时采用 v3.4（第 1 轮讨论记录；此后各轮按 v3.5、v3.6 递增）。
8. 流式完整性与合作方侧的增强路径（顾问席，第 2 轮）：建议研究 HTTP Trailers 签名或 MAC 链降载、AgentHost→Adapter 本地 IPC 的内核级身份与度量、L3 带外核签向 FIDO2/WebAuthn 硬件凭据演进，以及在主架构图中区分 L1 无状态查询与 Outbox。本版不改正文：前三项留待专项设计与 PoC 评估；L1 是否经 Outbox 属实现选择，不影响安全边界。顾问席关于机密计算“杜绝落盘”、单网关加插件“同等安全强度”、《民法典》条号区间及 SM2 签名耗时的表述未给出可核查依据，未采纳。
9. 密评的其他上位依据（核验席，第 2 轮）：核验席提出《商用密码管理条例》（2023 年修订）可能把密评义务延伸至等级保护第三级以上网络，后自行更正为条号待核。本版第七节只把《密码法》第二十七条限定于依法须使用商用密码保护的关键信息基础设施，且不由该条推出应用等级；其余系统按定级与适用规定判定，不引用未核对的条号。
10. 来源质量（核验席，第 2 轮）：[32] 原只引用中证网报道，v3.6 已改用商务部政府网站转载的全文；《数据出境安全评估办法》《促进和规范数据跨境流动规定》未在正文点名，第五节第 1 款与第六节第 2 款已要求出境适用性评估，暂不展开。
11. 来源核验状态的区分（质疑席、第二主持，第 3 轮）：建议区分“已补引用锚点”与“已独立核实原文”。截至本版：JR/T 0185 第 6.2、9.3.2–9.3.4 节已由主持人对照人民银行官网全文核对；MCP 2026-07-28 Streamable HTTP 相关事实已对照规范页核对；银保监办发〔2021〕141号第三条第二款、第五条已对照商务部政府网站转载全文核对（2026-10-25）；金发〔2026〕8号只核对了标题、文号与发布日期，具体条款待核；各席自述“已核实”的来源未经主持人复核者不作为核实依据。
12. 顾问席第 3 轮的演进建议：CIBA 宜作带外复核通知器、Approval_Proof 由企业网银协同签名或 FIDO2／国密双证书承担；流式长连接的 HSM 削峰；合作方防留存与机密计算／TEE 的权衡。均属专项设计与 PoC 范围，不改正文。

九、 参考文献 #

1. 中国人民银行. JR/T 0185—2020 商业银行应用程序接口安全管理规范 [S]. 2020-02-13 发布实施. 中国人民银行官网全文：https://www.pbc.gov.cn/zhengwugongkai/4081330/4406346/4693549/4085095/2020030414545789741.pdf （第 6.2、7.2.1、7.2.2、9.2.1、9.2.2、9.3.2–9.3.5 节）。
2. 国家市场监督管理总局, 国家标准化管理委员会. GB/T 39786—2021 信息安全技术 信息系统密码应用基本要求 [S]. 2021. 标准全文（政府网站）：https://www.jsmm.gov.cn/u/cms/www/202110/140914053ph6.pdf （第 8.2(c)、8.4(d) 条）。
3. 国家市场监督管理总局, 国家标准化管理委员会. GB/T 38636—2020 信息安全技术 传输层密码协议 [S]. 2020.
4. Linux Foundation. Agent2Agent (A2A) Protocol Specification v1.0.1, specification/a2a.proto [EB/OL]. 2026. https://github.com/a2aproject/A2A/blob/v1.0.1/specification/a2a.proto
5. Agentic AI Foundation. Model Context Protocol Specification, Revision 2026-07-28 [EB/OL]. 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28
6. IETF. RFC 8693: OAuth 2.0 Token Exchange [S]. 2020.
7. OpenID Foundation. FAPI 2.0 Security Profile (Final) [S/OL]. 2025-02-19 批准为最终规范. https://openid.net/wg/fapi/
8. OpenID Foundation. OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 (CIBA) [S/OL]. 2021-09-01（Final）. https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html
9. LI T, CHU C, ZHENG Y, et al. A2ASecBench: A Protocol-Aware Security Benchmark for Agent-to-Agent Multi-Agent Systems [C]// ICLR 2026. https://proceedings.iclr.cc/paper_files/paper/2026/hash/c6a4c60e4c12b4157d33f34b29d22067-Abstract-Conference.html
10. 国家金融监督管理总局. 国家金融监督管理总局关于银行业保险业人工智能安全开发应用的指导意见 (金发〔2026〕8号) [Z]. 2026-06-18. 金融监管总局官网 docId=1261784（索引号 717804719/2026-365，科技监管司，2026-10-25 经官网文档接口核对标题、文号与发布日期）：https://www.nfra.gov.cn/cn/view/pages/governmentDetail.html?docId=1261784&itemId=861&generaltype=1 （具体条款待逐条核对原文）
11. IETF OAuth WG. OAuth Client ID Metadata Document, draft-ietf-oauth-client-id-metadata-document-02 [S/OL]. 2026-07-06. https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/
12. IETF. RFC 9207: OAuth 2.0 Authorization Server Issuer Identification [S]. 2022.
13. IETF. RFC 9421: HTTP Message Signatures [S]. 2024.
14. 全国人大常委会. 中华人民共和国个人信息保护法 [Z]. 2021（第二十三、五十一、五十五条）. 国家互联网信息办公室发布：https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm
15. IETF RFC Editor. RFC 8998: ShangMi (SM) Cipher Suites for TLS 1.3 [R]. 2021. 信息性 RFC，非 TLCP／SSE 规范. https://www.rfc-editor.org/info/rfc8998/
16. Agentic AI Foundation. Model Context Protocol Specification 2026-07-28, Streamable HTTP [EB/OL]. https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
17. 中国人民银行. JR/T 0197—2020《金融数据安全 数据安全分级指南》[S]. 2020. 中国人民银行标准公开系统：https://cfstc.pbc.gov.cn/bzgk/detail/?bzId=1873&id=0
18. IETF. RFC 8785: JSON Canonicalization Scheme (JCS) [R]. 2020. https://www.rfc-editor.org/rfc/rfc8785
19. IETF. RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens [S]. 2020. https://www.rfc-editor.org/rfc/rfc8705
20. IETF. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) [S]. 2023. https://www.rfc-editor.org/rfc/rfc9449
21. IETF. RFC 8707: Resource Indicators for OAuth 2.0 [S]. 2020. https://www.rfc-editor.org/rfc/rfc8707
22. 中国人民银行. JR/T 0171—2020《个人金融信息保护技术规范》[S]. 2020. 中国人民银行标准公开系统：https://cfstc.pbc.gov.cn/bzgk/detail/?bzId=1856&id=0
23. 国家密码管理局. GM/T 0009—2023《SM2 密码算法使用规范》[S]. 2023-12-04 发布，2024-06-01 实施（代替 GM/T 0009—2012）。
24. 国家质量监督检验检疫总局, 国家标准化管理委员会. GB/T 32918.2—2016《信息安全技术 SM2 椭圆曲线公钥密码算法 第 2 部分：数字签名算法》[S]. 2016.
25. IETF. RFC 9396: OAuth 2.0 Rich Authorization Requests [S]. 2023. https://www.rfc-editor.org/rfc/rfc9396
26. YANG Y, GAO C, WU D, et al. MCPSecBench: A Systematic Security Benchmark and Playground for Testing Model Context Protocols [EB/OL]. arXiv:2508.13220, 2025（v1 2025-08-17，v3 2026-02-12 修订）. https://arxiv.org/abs/2508.13220
27. 国家质量监督检验检疫总局, 国家标准化管理委员会. GB/T 32907—2016《信息安全技术 SM4分组密码算法》[S]. 2016. 国家标准信息公共服务平台：https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=7803DE42D3BC5E80B0C3E5D8E873D56A
28. 国家市场监督管理总局, 国家标准化管理委员会. GB/T 36624—2018《信息技术 安全技术 可鉴别的加密机制》[S]. 2018. 国家标准信息公共服务平台：https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=7DF46F1692B9F774F53E0BEF094379C3
29. Model Context Protocol. Tasks Extension (io.modelcontextprotocol/tasks, SEP-2663), 2026-07-28 [EB/OL]. https://tasks.extensions.modelcontextprotocol.io/specification/2026-07-28/tasks
30. 国务院. 网络数据安全管理条例（国务院令第 790 号）[Z]. 2024-09-24 公布，2025-01-01 施行. 国家互联网信息办公室发布：https://www.cac.gov.cn/2024-09/30/c_1729384452307680.htm
31. 国家金融监督管理总局. 银行保险机构数据安全管理办法（金规〔2024〕24号）[Z]. 2024-12-27. 国务院公报：https://www.gov.cn/gongbao/2025/issue_11906/202503/content_7011160.html
32. 中国银保监会办公厅. 银行保险机构信息科技外包风险监管办法（银保监办发〔2021〕141号）[Z]. 2021-12-30. 商务部政府网站转载全文（2026-10-25 主持人核对标题、文号、日期及第三、五条）：https://policy.mofcom.gov.cn/claw/clawContent.shtml?id=92474 （页面提示须与正式文本核对；金融监管总局官方页面未定位）
33. 全国人大常委会. 中华人民共和国密码法 [Z]. 2019-10-26 通过，2020-01-01 施行（第二十七条）. 国家互联网信息办公室发布：https://www.cac.gov.cn/2019-10/27/c_1573711980953641.htm
34. 国家互联网信息办公室等七部门. 生成式人工智能服务管理暂行办法 [Z]. 2023-07-10 公布，2023-08-15 施行（第二条适用范围）. https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm