# 商业银行开放银行场景下引入 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. 核心术语与规范依据
| 术语 / 规范 | 出处 | 属性 | 本方案中的定位 |
|---|---|---|---|
| **A2A 1.0** | Linux Foundation，`a2a.proto` v1.0.1 标签 [4] | 行业事实标准 | 以 `a2a.proto` 为规范性来源，定义 gRPC、JSON-RPC 2.0、HTTP/REST 三种绑定；9 个任务状态枚举（含 `TASK_STATE_UNSPECIFIED`）；AgentCard 支持 JWS 签名 |
| **MCP 2026-07-28** | Agentic AI Foundation（Linux Foundation 旗下）[5][16] | 行业事实标准 | 无状态 Streamable HTTP：取消协议级会话与 GET 流端点，请求通过 `_meta` 自描述；`MCP-Protocol-Version`、`Mcp-Method` 为所有请求必需，`Mcp-Name` 仅 `tools/call`、`resources/read`、`prompts/get` 必需；服务端到客户端的交互改为 MRTR（Multi Round-Trip Requests，SEP-2322） |
| **MCP Tasks（SEP-2663）** | MCP 扩展 `io.modelcontextprotocol/tasks` [29] | 可选扩展，须显式 opt-in | 定义 `tasks/get`、`tasks/update`、`tasks/cancel`；未 opt-in 时按扩展规定返回 `-32021`（Missing Required Client Capability）；采用版本须锁定 |
| **CIMD** | IETF OAuth WG `draft-ietf-oauth-client-id-metadata-document`（-02，2026-07-06）[11] | IETF 工作草案 | URL 形式的客户端元数据发现；本行默认不采用动态准入 |
| **RFC 9207 / 9421 / 8705 / 9449 / 8707 / 8693 / 8785** | IETF [12][13][19][20][21][6][18] | RFC | 发行方识别；HTTP 报文签名（本行 Profile 仅借鉴，不宣称兼容）；mTLS 证书绑定令牌与 DPoP 持钥证明；资源受众限制；令牌交换；JSON 规范化 |
| **JR/T 0185—2020** | 中国人民银行 [1] | 推荐性金融行业标准 | 《商业银行应用程序接口安全管理规范》：按服务类型分 A2（资金交易与账户信息查询）、A1（与用户个体无直接关联的产品信息只读查询）两级 |
| **JR/T 0197—2020 / JR/T 0171—2020** | 中国人民银行 [17][22] | 推荐性金融行业标准 | 金融数据安全分级；个人金融信息 C1/C2/C3 分类。二者与接口 A1/A2 并行判定，互不替代 |
| **GB/T 39786—2021** | 市场监管总局、国家标准委 [2] | 推荐性国家标准 | 信息系统密码应用基本要求；对依法须使用商用密码保护的关键信息基础设施，经《密码法》第二十七条的密评义务形成实际约束；适用的密码应用等级按系统定级确定 [33] |
| **TLCP（GB/T 38636—2020）** | [3] | 推荐性国家标准 | 国密双证书传输层协议，提供通道机密性与实体认证 |
| **SM4-GCM** | GB/T 32907—2016 [27]、GB/T 36624—2018 [28]；RFC 8998 为 TLS 1.3 商密套件参考 [15] | 候选实现 | 应用层认证加密的算法与机制依据；用于 SSE 事件时，信封、密钥分发与部署须由密评确认 |
### 2. 四层合规分类
```mermaid
flowchart TD
L1["第一层：法律、行政法规与部门规章
（按发文属性、适用范围与条款逐条判定强制性）"]
L2["第二层：行业标准与推荐性国标
（JR/T 0185、JR/T 0197、JR/T 0171、GB/T 39786，区分“应／宜”与适用性）"]
L3["第三层：密码应用方案选定的技术实现
（TLCP、SM2/SM3/SM4、密码产品，以密评结论为准）"]
L4["第四层：本行准入与安全增强策略
（报文签名 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 接口等级 × 智能体业务影响）
```mermaid
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]
```
| 业务分级 | JR/T 0185 级别 | 典型对公场景 | 主要控制要求 | 协议边界 |
|---|---|---|---|---|
| **L1** 只读 | **A1** | 基准利率、公开牌价、网点与公开产品信息 | TLS/TLCP 通道；A1 完整性保护（MAC 校验等，必要时数字签名）[1]；AppID 识别与限流 | MCP `tools/call`、A2A `SendMessage` |
| **L1** 只读 | **A2** | 企业账户余额、交易流水、授信可用额度 | 双向身份认证；请求与响应数字签名；银行端 PDP 与凭据绑定；按数据分级落实脱敏、加密与**合作方不留存**约束 | 同上，经 PDP 鉴权；仅经银行提供或认证的 Adapter/SDK |
| **L2** 草拟 | **A2** | 单证预审、授信方案磋商、未达账调账建议、非约束性询价 | A2 全部控制；任务持久化（Outbox）；AgentCard 准入；`Max-Hop=1`；审计。**输出不得构成对银行或客户有约束力的要约、承诺、批复或额度占用**，构成者按 L3 管理（识别规则由准入评估确定）；流式事件按第四节第 4 款处理 | A2A `SendMessage(returnImmediately=true)` + `SubscribeToTask`；MCP Tasks（须协商） |
| **L3** 动账及约束性操作 | **A2** | 本期：资金归集划拨、融资放款资金划付。锁价成交与交割等非支付类约束性操作须另建确定性成交及审批硬校验路径，完成前不纳入本期 | 智能体无执行权限；不可变要素摘要；银行带外确认（CIBA 等）；企业经办／复核；核心执行前硬校验 | **禁止经 A2A/MCP 触发或携带可执行动账指令**（本行策略）；智能体只可提交待审批意图，执行由 DraftSys 凭有效审批凭证经银行受控的确定性支付接口（与网银／银企直连同属确定性渠道；支付核心须新增第四节第 7 款所述记账前硬校验）提交，智能体凭证不得调用提交步骤；本期非支付类约束性请求由 PDP 操作白名单拒绝 |
---
## 二、 协议规范事实与可行性边界
### 1. 协议能力边界（按锁定版本核对）
| 协议 | 已核对的规范事实 | 对银行接入的约束 |
|---|---|---|
| **A2A 1.0**（v1.0.1 `a2a.proto`）[4] | REST 映射：`POST /message:send`、`POST /message:stream`、`GET /tasks/{id}`、`GET /tasks`、`POST /tasks/{id}:cancel`、`GET /tasks/{id}:subscribe`，各方法另有 `/{tenant}/…` 绑定；另有推送通知配置与扩展 AgentCard 端点；`SendMessageConfiguration.return_immediately` 存在；对终态任务订阅返回 `UnsupportedOperationError` | 网关路由白名单**默认拒绝**未列入的方法与租户前缀变体；推送通知配置涉及银行侧出站回调，未经 SSRF 与出站控制评估不开放；对外**只开放一种绑定**（建议 HTTP+JSON/REST），开放 JSON-RPC 时内层须按 Body 内方法名重新授权，gRPC 不对外；“L2/L3 提交类调用必返回 Task”为本行 Profile 约束 |
| **MCP 2026-07-28** [16] | 每个 JSON-RPC 消息一个 POST，响应为 JSON 或请求作用域 SSE；不支持 `Last-Event-ID` 恢复；关闭 SSE 即取消该请求；服务端须校验 `Origin`；头与 Body 不一致返回 `-32020`（HeaderMismatch）；长期变更通知经 `subscriptions/listen` 长连接流下发 | MCP 短时 SSE 断开即取消，不能照搬 A2A 已持久化任务“断开继续执行”的语义；网关须区分请求作用域 SSE 与 `listen` 长连接的超时策略 |
| **MCP Tasks** [29] | 扩展，须客户端 opt-in；`tasks/get`、`tasks/update`、`tasks/cancel` | 不支持 Tasks 的客户端不得被隐式降级为同步长调用；按扩展返回 `-32021`，或引导至银行异步通道（本行约定） |
**互操作前提**：A2A、MCP 及其扩展均按所锁定的规范版本（标签或提交）实施，并以官方 SDK／一致性测试实测；锁定版本外的兼容性不作宣称。CIMD 动态准入默认不启用，合作方证书／AppID 预注册；RFC 9207 在存在多个授权服务器的回调中启用。[11][12]
---
## 三、 目标架构：三层实施与四域治理
方案采用“**合作方受控 Adapter／银行 SDK + 银行外层金融 API 网关 + 银行内层智能体协议网关**”三层部署，由授权决策、任务执行、审计、确定性执行四个逻辑安全域治理。L3 路径单独经交易意图服务和带外审批进入支付核心：
```mermaid
flowchart TB
subgraph ClientZone["合作方受控域"]
AgentHost["企业智能体宿主
(标准 MCP / A2A)"]
Adapter["受控 Adapter / 银行 SDK
(银行提供或认证 · 请求加签 · 响应验签
按授权解密并还原标准消息)"]
AgentHost <-->|"本地 IPC / 受控 HTTP
工作负载认证与最小授权"| Adapter
end
subgraph OuterZone["外层金融 API 网关（边界与密码层）"]
GW_TLCP["TLCP / mTLS 通道终止"]
GW_Sign["报文验签 · Nonce 防重放
路由与受众绑定"]
GW_Stream["响应安全出口
依据内层可信元数据签名／按需加密"]
GW_TLCP --> GW_Sign --> GW_Stream
end
subgraph InnerZone["内层智能体协议网关（协议治理层）"]
AG_Router["协议解析与路由
(A2A / MCP 锁定版本)"]
AG_Gov["治理引擎
(Tool Pinning · 状态机 · 轮次熔断)"]
AG_Filter["Schema / DLP / 数据分级
生成可信事件元数据"]
AG_Router --> AG_Gov --> AG_Filter
end
subgraph AuthDomain["安全域 1：授权与策略决策"]
PDP["中央 PDP
(主体持续鉴权 · 资源级 ABAC · 撤销处理)"]
STS["STS
(RFC 8693 委托裁剪 · Max-Hop=1)"]
end
subgraph ExecDomain["安全域 2：任务执行与状态隔离"]
Outbox["Task 状态机 + Outbox
(单库事务 · 幂等持久化)"]
Adapter_Conv["协议降维转换
(仅 L1/L2 查询与草拟)"]
DraftSys["交易意图服务 DraftSys
(L3 仅生成待核签草稿，无自主动账权限
仅凭有效 Approval_Proof 经确定性支付接口提交)"]
end
subgraph AuditDomain["安全域 3：独立审计"]
AuditLog["业务审计引擎
(输入摘要 · 决策上下文 · 审批单据)"]
end
subgraph CoreZone["安全域 4：银行核心与确定性执行"]
BizAPI["账务 / 融资业务系统
(只读与草拟接口 · 二次权限校验)"]
CIBA_Sys["银行带外确认渠道
(展示要素 · 复算摘要)"]
CorporateMatrix["企业经办／复核流程"]
CorePayCheck["支付核心执行前硬校验
(草稿 · 摘要 · 审批凭证 · 额度 · 幂等)"]
CoreAPI["支付核心
(权威记账流水)"]
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 容量验证。
| 维度 | 必须的改造 | 初步判断 |
|---|---|---|
| 多谓词与路由 | 放行锁定版本的 A2A REST 端点（含 GET 订阅与查询、POST 取消）；租户前缀变体与推送通知端点按白名单显式决定；未列入方法默认拒绝；空 Body 签名规范 | 可行，配置为主 |
| 分块传输与流 | 支持 chunked 与 HTTP/2；可增量计算摘要，但**完整 Body 验签前不得转发至有副作用的后端**；设置大小、时长上限与有界缓冲；SSE 路径关闭代理缓冲，空闲超时与心跳按业务 SLA 确定 | 可行，需插件升级 |
| 头透传与一致性 | 白名单放行 MCP 头（`MCP-Protocol-Version`、`Mcp-Method`、`Mcp-Name`、`Mcp-Param-*`）与 A2A 头（`A2A-Version`、`A2A-Extensions`）；只依据已验证字段路由；内层按 MCP 规范做头与 Body 一致性校验；校验 `Origin` | 可行 |
| 签名插件 | 支持第四节第 2 款的基础必签与安全关键头扩展覆盖 | 可行，需算法逻辑升级 |
| 响应签名与机密性 | A2 响应签名；按数据类型落实通道机密性、必要的字段／产物加密与密钥管理；内层向外层传递可信事件元数据 | **待专项验证**，HSM 签名 TPS、首事件延迟与客户端适配须压测 |
| 出站控制 | AgentCard、附件、Artifact 外链与推送回调涉及银行侧出站访问，须有目的地白名单与 SSRF 防护 | 可行，需策略补充 |
### 2. 双网关可信上下文与明文边界
| 边界 | 约束 | 责任 |
|---|---|---|
| 外层 → 内层 | 外层验签并认证 Partner/AppID 后，经双向认证、完整性保护的内部通道传递签发者、证书指纹、持钥验证结果、租户、请求 ID、签名覆盖清单等上下文；上下文**绑定本次请求的目标、正文摘要、受众与有效期**，内层校验关联一致性，防止复用；剥离客户端伪造的同名内部头；内层不接受绕过外层的调用 | 外层生成，内层验证；关键操作仍由 PDP 独立授权 |
| 内层 → 外层出口 | 内层负责协议解析、数据分类、敏感字段标记与事件顺序；外层执行签名、按需加密与通道出口，不以未解析头决定字段级加密 | 内层定策略，外层做密码封装 |
| 内网明文跳数 | TLCP 终止后每个跨服务跳点须有加密、身份鉴别、最小权限与禁止敏感明文日志措施；若须防止中间网关获知明文，加密应前移至可信业务层 | 网关、安全、业务与密评团队联合确认 |
---
## 四、 核心安全不变量与技术契约
### 1. 身份、委托与持续授权
```mermaid
flowchart TB
ROOT["三维身份与持续授权契约"]
subgraph SOURCES["① 身份来源与密钥绑定"]
direction TB
PARTNER["合作机构身份
机构证书 + 外层 TLCP/验签确认
绑定 AppID 注册表"]
USER["终端用户身份"]
MODE_A["模式 A｜用户交互
Token cnf 绑定的持钥主体
mTLS 校验证书指纹；DPoP 校验逐请求证明"]
MODE_B["模式 B｜企业无人值守司库 Agent
企业授权经银行验证并登记服务主体
STS 颁发受限持钥服务凭证（账户范围、限额、有效期、撤销）"]
AGENT["智能体与任务上下文
银行签发的 Task ID + 白名单 Agent ID"]
USER --> MODE_A & MODE_B
end
subgraph MATRIX["② 资源级 ABAC｜中央 PDP 强制核验"]
direction TB
B0["通用前提：所有操作均受当前有效的账户、业务资源、任务与字段权限约束
角色或创建者身份不能替代资源授权"]
B1["提交任务
Partner 资质 && User 对公授权 && 目标账户在授权范围 && 额度合规"]
B2["查询 / 订阅 / 重放
同租户 && 对该任务所涉账户与资源当前有权"]
B3["补充输入
同租户 && 任务写入权限 && 任务处于 INPUT_REQUIRED"]
B4["取消任务
同租户 &&（创建者或企业管理员）&& 资源权限有效"]
B5["后台推进
执行器推进下一节点或访问敏感资源前向 PDP 复核授权未撤销"]
B6["获取产物
同租户 && 对该 Artifact 及其字段当前有读权限"]
B0 ~~~ B1 ~~~ B2 ~~~ B3 ~~~ B4 ~~~ B5 ~~~ B6
end
subgraph REVOCATION["③ 授权撤销分级处理"]
direction TB
R1["尚未执行敏感动作
终止推进，置 CANCELED"]
R2["执行中且可逆
下发取消，回滚完成后置 CANCELED"]
R3["已不可逆提交或部分成功
冻结后续步骤，进入对账／人工处置
对外状态须携带“对账中、禁止重试”标识"]
R4["Token 自然到期 ≠ 撤销授权
到期可合规刷新；撤销则永久中止委托"]
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]
| 组件组 | 内容 | 验证规则 |
|---|---|---|
| 目标绑定 | `@authority`、`@method`、`@path`、`@query` | 精确定义代理前后 URI 规范化；拒绝 Host 歧义、路径解码差异与重复字段 |
| 请求者与时效 | AppID、UTC 秒级时间戳、128 位随机 Nonce | 时间窗校验，`AppID+Nonce` 原子登记（如 Redis `SET NX EX`），TTL 覆盖可接受的最晚时刻；去重能力故障时拒绝请求 |
| 载荷与凭据 | 原始 Body 的 SM3 摘要；原始 Access Token 的 SM3 摘要 | 空 Body 使用空字节串摘要；无个人 Token 时摘要仅为占位，另需独立服务主体凭据 |
| MCP 镜像字段 | `mcp-protocol-version`、`mcp-method`、`mcp-name` | 与解析后的 JSON-RPC 字段一致；**规范不要求 `Mcp-Name` 的 MCP 方法及非 MCP 请求，使用 Profile 约定的缺省值，不要求客户端伪造该头** |
| 安全关键扩展 | 参与路由、租户、授权、重放与降级决策的头（`Mcp-Param-*`、`A2A-Version`、`A2A-Extensions`、幂等键等） | 覆盖清单本身纳入签名，客户端不能通过遗漏字段降级；空 Body 的 GET 同样签这些头 |
**约束**：签名基础串的字节编码、字段顺序、`@query` 空值哨兵与 SM2 参数（GB/T 32918.2、GM/T 0009）在专项规范中以跨语言测试向量冻结。[23][24] 可在不受信任区做无副作用的协议分类以选择 Profile，但**验签与可信身份确认前不得路由至高权限或跨租户后端**。重发业务请求换新 Nonce、沿用同一业务幂等键。
### 3. 异步任务、Transactional Outbox 与故障恢复
**Task 与 Outbox 原子提交只保证调度意图不丢失，不保证恰好一次执行。** Nonce 防重放与业务幂等键是两个独立机制。
```mermaid
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]
```mermaid
flowchart TB
IN["内层协议网关
标准业务事件 + 可信元数据"] --> MODE{"保护等级与明文授权"}
MODE -->|允许明文| P["payload_mode = plaintext"]
MODE -->|需加密且接收方获准解密| E["payload_mode = ciphertext
SM4-GCM 认证加密"]
MODE -->|接收方无明文权限| X["仅脱敏 / 引用输出
或密文经独立通道送达获授权终端"]
P --> HASH["统一信封
全局 task_event_seq + 单流 stream_chunk_seq
SM3 累积哈希链"]
E --> HASH
HASH --> SIGN["网关 HSM 按 Profile SM2 签名"]
SIGN --> END["签署 stream-completed
承诺事件数与最终链摘要（含零事件流）"]
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 签名提供来源与完整性证据，不提供机密性；应用层加密（字段、报文或产物级）限制明文可见范围，不替代签名、授权与脱敏。三者分别评估，任何一项不默认替代其余两项。
```mermaid
flowchart TB
B["银行 MCP / A2A 服务
生成原生业务事件"] --> POLICY["数据分级 + 接口等级 + 接收方明文许可
确定可信解密终点"]
POLICY --> DEC{"是否需要额外应用层加密？"}
DEC -->|否| A["路径 A｜TLCP 通道 + 适用的响应签名"]
DEC -->|是| AUTH{"谁获准接触明文？"}
AUTH -->|合作方被授权| E["路径 B1｜银行加密
数据密钥只发受授权 Adapter / SDK"]
AUTH -->|合作方不获授权| N["路径 B2｜合作方 Agent / 普通 Adapter 不获密钥"]
E --> VERIFY["先验签名与接收者身份
再验 AEAD Tag 并解密"]
VERIFY --> AGENT["按最小授权交付 Agent"]
N --> SAN["标准 MCP/A2A 仅返回
脱敏结果、状态或受控 Artifact 引用"]
N --> SIDE["密文经独立通道直达获授权终端
终端与被排除主体在管理权、密钥、明文输出上隔离"]
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]；这与银行向合作方推送查询响应是两类场景。
| 数据类型 | 保护基线 | 接收与留存边界 |
|---|---|---|
| 公开产品与行情（A1） | 通道保护 + A1 完整性校验；无证据表明须逐事件加密 | 公开或授权范围内正常接收 |
| 企业对公余额、流水（A2） | 请求与响应签名；重要数据传输机密性；含个人金融信息或有专项保密要求时加字段／报文保护 | PDP 限定账户、主体与用途；适用 JR/T 0185 第 7.2.2 节“查询结果在应用方本地不得保存”的场景，**禁止留存**，范围覆盖 Agent 会话历史、向量库、遥测与外部模型服务日志 |
| 账号、卡号、姓名、证件号、手机号等个人金融信息 | 按 JR/T 0185 第 7.2.2 节使用 SDK 加密组件或报文整体加密；向应用方反馈账号、卡号、姓名时脱敏或去标识化 | 应用方不应采集、存储个人金融信息（第 9.3.3 节）；确需提供时另须个人信息保护法下的告知、单独同意等法律基础 |
| 支付敏感信息与身份鉴别信息 | 银行 SDK、报文加密、受信任采集通道；不经普通 Agent 处理 | 应用方不得留存 |
| 贸易融资文件等重要 Artifact | 通道保护、响应签名与正式产物签名；视敏感度独立加密 | 按企业授权、岗位与用途限制下载与再共享 |
### 6. 输入与工具安全的真实边界
| 控制 | 能做到 | 做不到 |
|---|---|---|
| Tool Pinning（工具元数据哈希固化） | 发现 MCP Server 工具名称、描述、Schema 的未授权变更 | 后端逻辑被替换而元数据不变时失效，须配合服务工作负载身份 |
| Schema 强校验 | 降低畸形输入触发解析漏洞的风险 | 合法字符串字段仍可承载语义注入 |
| 来源标记（Provenance） | 将外部输入标为不可信数据，降低越狱概率 | 依赖模型遵循，可被对抗样本绕过 |
| 确定性业务规则 | 限额、账户状态、黑白名单、幂等等独立于模型判断的控制 | 规则遗漏与配置缺陷仍须独立审查 |
### 7. L3 资金交易：意图、带外授权与权威对账
**智能体只可生成待审批的交易意图，不拥有资金执行能力。** 本款设计只覆盖资金支付路径，硬校验由支付核心在记账前完成；锁价成交等可能在支付记账前即已生效的约束性操作，支付核心校验不能充当其成交前控制，须另建确定性成交及审批硬校验路径。融资放款中信贷出账审批、借据生成等先于支付生效的环节，同样不由支付核心硬校验替代，由信贷系统的审批控制承担。CIBA 是银行受控带外确认机制，不能取代企业网银的经办／复核与既有法律授权程序；带外确认是否构成《电子签名法》意义上的可靠电子签名，须法务确认。结构化授权可参考 RFC 9396，但非监管必选。[8][25]
```mermaid
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. 合作方（应用方）义务与本行准入要求
| 要求 | 依据 | 属性 |
|---|---|---|
| A2 接口双向身份认证（证书或公私钥对） | JR/T 0185 第 7.2.1、9.2.1 节 [1] | 第二层 |
| A2 交互数据数字签名，A1 采用 MAC 等完整性保护 | JR/T 0185 第 7.2.2、9.2.2 节 [1] | 第二层 |
| 不采集、存储个人金融信息与支付敏感信息；适用的 A2 只读查询结果不在本地保存；合作终止后按约定删除所获数据 | JR/T 0185 第 7.2.2、9.3.3 节 [1] | 第二层 |
| 密钥存储采取加密等方式防护；银行提供 SDK 时须使用且不得反编译、篡改或二次封装 | JR/T 0185 第 9.3.5 节 [1] | 第二层 |
| 符合网络安全等级保护要求；接口集成相关日志留存不少于 6 个月；防止接口滥用 | JR/T 0185 第 9.3.4 节 [1] | 第二层 |
| A2 服务以 API 直连方式提供时，银行须评估接入风险并制定专门接口 | JR/T 0185 第 6.2 节 [1] | 第二层（银行义务） |
| 明确合作方的数据处理角色（委托处理、共同处理或独立接收）；评估外部模型服务、转委托、训练用途与境外访问／出境；按适用情形纳入第三方合作与外包管理 | [30][31][32][14] | 第一层，逐场景判定 |
| 私钥保护分档、AgentCard 白名单、`Max-Hop=1`、Local PDP | 本行策略 | 第四层 |
### 2. Adapter／银行 SDK 四维控制
Adapter 是本方案默认的接入实现之一，**不是 MCP/A2A 协议要求的组件**，由银行提供或经银行认证；等效银行 SDK 适用相同准入 Profile。四项控制须独立评估，组合后不自动形成端到端可信链：
```mermaid
flowchart TB
ROOT["受控 Adapter / 银行 SDK｜四维独立控制"]
KEY["① 私钥防提取（本行准入策略·第四层，按接入等级分档）
A2 及 L2 以上：私钥在经认证的硬件密码模块内生成且不可导出
形态可为密码机、密码卡、智能密码钥匙或经评估的云密码服务
具体产品与部署由准入评估确定"]
TEE["② 运行态隔离（可选增强）
关键加签模块运行于硬件 TEE
降低宿主特权对敏感内存的窥探风险
不覆盖全部侧信道与外部 I/O"]
ATTEST["③ 工作负载完整性（可选增强）
经独立受控通道验证远程证明
绑定工作负载身份与密钥／会话
不假定 TLCP 握手原生携带证明"]
GUARD["④ 签名接口防滥用（必需）
Local PDP 校验个人令牌或企业服务主体凭证
本地 IPC 工作负载认证、最小权限与审计
未授权加签请求在 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 容量测算后确定。未启用的部署模式须记录“不适用”及依据。
| 组别 | 必须证伪的失败场景 | 优先级 |
|---|---|---|
| 任务恢复与幂等 | Task+Outbox 提交后网关、Dispatcher、Worker 各自崩溃；ACK 丢失后同幂等键换 Nonce 重试只返回既有 Task；旧 Worker 恢复后不能产生未经当前代次授权的下游副作用或覆盖新结果（含前置校验通过后被接管、旧代次请求先于新代次到达下游的交错时序）；并发派发、取消与完成竞态不产生孤儿任务 | P0 |
| 签名、持钥与跨网关身份 | 篡改目标、Body、安全关键头或覆盖清单；`cnf` 不匹配、DPoP 缺失／重放；伪造内网身份头、旁路外层网关、复用他人请求上下文，均须拒绝 | P0 |
| 响应完整性与 SSE | 权威结果签名可验证；启用候选信封时，跨语言测试向量一致，篡改、截流、拼接不同流与伪造结束签名均被拒绝；流完整但 Task 非 COMPLETED 时不交付正式 Artifact；非权威进度事件中不出现 A2 数据 | P0 |
| 机密性与明文边界 | B2 场景普通 Agent 只得到原生协议的脱敏结果或引用；错签名、错 Tag、错 `key_id` 在明文交付前拒绝；Agent 会话、日志、向量库不留存受限数据；撤销后停止新增数据与密钥发放，并验证撤销时延 | P0 |
| L3 审批与对账 | 带外渠道展示真实要素并复算摘要；智能体凭证直接调用提交接口、无有效 Approval_Proof 的提交均被拒绝；错账户、摘要、签名、额度、重复幂等在记账前拒绝；回包丢失→TX_SUCCESS，终态未执行凭证→TX_ABORTED，无流水→保持挂起且不能换新幂等键重发 | P0 |
| 互操作、攻防与容量 | 标准 A2A 方法与 MCP 单请求 SSE 在 Adapter 还原后运行；无 Tasks opt-in 时不隐式同步长调用；以 A2ASecBench [9]、MCPSecBench [26] 及自建注入、Rug Pull、路由欺骗样本复现攻防基线；HSM TPS、首事件延迟、连接数与过载退避达到既定门槛 | P0／P1 |
准入证据包括：规范版本与测试向量、故障注入结果、任务与支付事件日志、数据分级清单、跨网关信任边界图、客户侧解密授权模型、性能基线与获批阈值、风险接受与整改记录。PoC 通过不替代密评和正式生产变更审批。
---
## 七、 监管合规追溯与标准映射
| 依据 | 条款要点 | 本方案落实与边界 | 层级 |
|---|---|---|---|
| 《密码法》[33] | 第二十七条：法律、行政法规和国家有关规定要求使用商用密码保护的关键信息基础设施，其运营者应使用商用密码保护，自行或委托检测机构开展商用密码应用安全性评估，并与等级测评等相衔接 | 属于依法须使用商用密码保护的关键信息基础设施时，应依法开展密评；该条不指定 GB/T 39786 的应用等级，具体等级及适用条款按系统定级、等级保护及其他适用规定确认；定级与评估边界由本行确认 | 第一层 |
| 《个人信息保护法》[14] | 第二十三条向其他处理者提供须告知并取得单独同意；第五十一条按风险采取加密、去标识化等措施；第五十五条规定须事前开展个人信息保护影响评估的情形 | 对公场景中的法定代表人、经办人、代发工资、个体工商户等个人信息，须有提供的法律基础并开展影响评估 | 第一层 |
| 《网络数据安全管理条例》（国务院令第 790 号）[30] | 网络数据处理、委托处理与提供、跨境安全管理 | 合作方数据处理角色、外部模型与出境评估 | 第一层 |
| 《银行保险机构数据安全管理办法》（金规〔2024〕24号）[31] | 数据分类分级、数据目录与差异化保护；涉及第三方的数据提供与委托处理等要求须逐条核对原文 | 作为 JR/T 0197 分级台账的上位依据；合作方准入与数据提供审批 | 第一层 |
| 《银行保险机构信息科技外包风险监管办法》（银保监办发〔2021〕141号）[32] | 外包准入、尽调、合同与监控；第三条第二款：与其他第三方合作中涉及重要数据和客户个人信息处理的信息科技活动，按本办法相关要求管理（法律法规另有要求的除外）；第五条：不得将信息科技管理责任、网络安全主体责任外包 | 按合作关系判断是否适用；合作方智能体处理本行重要数据或客户个人信息时纳入管理 | 第一层，按情形适用 |
| 金发〔2026〕8号 [10] | 金融监管总局 2026-06-18 发布的人工智能安全开发应用指导意见：AI 治理、数据治理、风险管理、外包与外部模型管理等 | 独立业务审计域；L3 人工审批；外部模型评估纳入合作方准入；具体条款逐条确认适用性 | 第一层（政策性文件） |
| 《生成式人工智能服务管理暂行办法》[34] | 适用于向境内公众提供生成式服务 | 按银行或合作方的实际服务形态判断 | 第一层，按情形适用 |
| JR/T 0185—2020 [1] | 第 6.2 节 A1/A2 分级；第 7.2.2 节 A2 签名、个人金融信息加密与脱敏、A2 只读查询结果不在应用方保存；第 9.2.2 节 A1 MAC／A2 签名与安全通道；第 9.3.2 节明示同意含授权有效期；第 9.3.3–9.3.5 节应用方不采集存储、日志留存（不少于 6 个月）、密钥防护与 SDK 使用 | 双向签名、数据不留存、Adapter/SDK 由银行提供或认证；A2 API 直连须专门评估 | 第二层 |
| JR/T 0197—2020 / JR/T 0171—2020 [17][22] | 金融数据分级；个人金融信息 C1/C2/C3 | 分级台账驱动加密粒度、明文授权与密钥发放 | 第二层 |
| GB/T 39786—2021 [2] | 第 8.2(c)、8.4(d) 条：第三级应保障通信与应用重要数据传输机密性 | 规定保护目标，未限定 SSE 逐事件 SM4；TLCP 覆盖相应边界时可作为通道机密性实现 | 第二层 |
| GB/T 38636、GB/T 32907、GB/T 36624 [3][27][28] | TLCP；SM4；可鉴别加密机制 | 候选实现，以密评为准 | 第三层 |
| RFC 9421、8705、9449、8707、8693 [13][19][20][21][6] | 报文签名；证书绑定令牌；DPoP；受众限制；令牌交换 | 本行签名 Profile 与持钥校验选型；`Max-Hop=1` 为本行策略 | 第四层 |
| RFC 8998、8785、9396，CIBA，FAPI 2.0 [15][18][25][8][7] | 商密 TLS 套件、JSON 规范化、结构化授权、带外认证、金融级安全配置 | 技术参考，不作为独立监管义务 | 技术参考 |
| A2A 1.0、MCP 2026-07-28 及 Tasks 扩展 [4][5][16][29] | 任务协议、无状态 Streamable HTTP、可协商扩展 | 协议兼容基线；签名／加密信封、路由白名单与降级为本行策略 | 协议基线 + 第四层 |
---
## 八、 少数意见
以下意见有依据，但未作为本版正文结论，保留供后续评审与专项设计参考：
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
---
## 十、 更新历史
### 1. 版本记录
以下 v1.0–v3.3.1 各行为原报告既有记录，原文保留（仅删去原表中 v3.3.1 行前导致表格断开的空行）。其中“评审通过”“冻结基线”“四轮／第六轮审查”等为原版本自述，原报告未附评审主体、纪要或签批记录，不构成本轮认可、正式审批或生产准入结论。v3.1 行关于 A2A Overview 文档把订阅写为 POST 的陈述同样未经复核，见第八节少数意见第 6 条。v3.4 行所称“原 751 行”按原报告快照实为 750 行，原文保留。
| 版本号 | 更新日期 | 评审状态 / 阶段 | 核心演进历程与审查复核记录 |
|---|---|---|---|
| **v1.0** | 2026-10-22 | 初稿提交评审 | 首次提出商业银行引入 A2A/MCP 的基本场景边界、国密与大模型交互冲突、双层网关初步雏形与 A2A 六道防线设计。 |
| **v1.1** | 2026-10-22 | 第一轮审查修订 | 增加术语表与 L1/L2/L3 业务操作分级；补充 MCP 四道安全防线、Adapter 加固说明与初步局限性说明。 |
| **v2.0** | 2026-10-22 | 第二轮技术审查重大修订 | 响应第一轮 14 项意见，引入 JR/T 0185 A1/A2 分级、三维身份体系、A2A 1.0 与 MCP 2026 规范初次对齐、Outbox 模型与不可变交易意图草稿。 |
| **v2.1** | 2026-10-22 | 第三轮技术审查修订 | 完善两级流式恢复模型、全要素 HTTP 签名草案、Task ID 银行端签发、流式外显信封与核心 5 维校验。 |
| **v3.0** | 2026-10-22 | 第四轮审查前基线版 | 规范 A2A `returnImmediately: true`、动态 Nonce TTL 公式、后台持续鉴权与操作级 ABAC 矩阵、四层合规分类体系。 |
| **v3.1** | 2026-10-22 | **总体架构评审通过·实施前关键安全不变量定稿版** | **全面解决第四轮审查提出的 5 项高优先级（H4-01～H4-05）与 4 项中优先级（M4-01～M4-04）机制与规范不变量，冻结总体架构基线**：
1. **锁定 A2A SubscribeToTask 规范性来源 (H4-01)**：明确以官方 `a2a.proto` 规范性映射 `GET /tasks/{id}:subscribe` 为准，客观记录 Overview 概述文档中错误写为 POST 的不一致；
2. **确立 Transactional Outbox 调度原子性不变量 (H4-02)**：在单数据库事务内原子写入 Task 记录与 OutboxEvent 调度事件，杜绝网关进程崩溃导致的调度丢失；明确操作契约强制要求返回 Task 实例；
3. **严格解耦流式完整性与业务任务终态 (H4-03)**：确立 `stream-completed` 仅代表传输层未被截断，业务产物必须在同时满足“流验签通过”与“任务状态机明确到达 `TASK_STATE_COMPLETED`”时方可使用；
4. **资金交易异常恢复三大不变量 (H4-04)**：严禁将“无核心流水”直接等价为“未入账”，明确只有获得核心系统权威终态未入账凭据后方可关闭订单，其余状态一律保持 `PENDING_RECONCILIATION` 并锁定对账幂等键；
5. **全量覆盖路由安全边界 (H4-05)**：将 `@authority`、所有参与路由决策的头字段纳入 12 要素签名基础串；规范无用户 Token 场景的空值 SM3 摘要契约；确立网关验签前禁止高权限路由三大不变量；
6. **细化 DPoP/mTLS 密钥绑定模型 (M4-01)**：区分用户交互授权模式与企业无人值守司库 Agent 预授权凭据模式；
6a. **统一无用户 Token 空值及服务主体前提 (M4-02)**：固定认证绑定空摘要并要求企业受限服务凭证或其他经认证的主体；
7. **细化授权撤销分级处理 (M4-03)**：区分尚未执行（终止）、执行中可逆（取消）与已不可逆提交（冻结人工核查）；
8. **理清任务事件全局序号与流实例序号关系 (M4-04)**：明确任务事件全局单调递增序号与单连接流序号的分离；
9. **正式通过总体架构评审**：冻结架构基线，将底层实现与 PoC 准入交由后续专项实施规范承接。 |
| **v3.2** | 2026-10-23 | **总体架构基线延续 · 机密性与 SSE 适配专项增补** | **依据监管与原始标准条款补足机密性控制，不改动主体三层／四域架构**：1. 核对 JR/T 0185—2020 第 7.2.2、9.2.2、9.3.3 节，明确 A2 请求／响应数字签名与特定个人金融信息 SDK／报文加密措施；2. 核对 GB/T 39786—2021 第 8.2(c)、8.4(d) 条、第三级重要数据传输机密性“应”要求，明确标准未指定逐 SSE 帧 SM4；3. 增加《个人信息保护法》第五十一条、金发〔2026〕8号数据保护依据；4. 增加“通道加密／响应签名／应用层加密”三层独立安全不变量；5. 新增 SSE 加密双路径 Mermaid 图及密文信封 PoC 示例，说明协议兼容、解密端授权和密钥管理；6. 更新 L1/A2、L2/A2 安全矩阵、网关改造、合规映射和参考文献；7. 生产准入验证由 12 项增至 15 项（响应签名、敏感明文边界、SSE 加密性能与兼容性）。 |
| **v3.3** | 2026-10-23 | **总体架构基线保持 · 安全契约一致性整改** | 根据外部审查与独立核验选择性采纳问题，五个工作包完成受控修订：①将 SSE `curr_hash` 的单帧摘要改为累计 `chain_hash`，统一明文／密文信封、双序号、AAD、JCS 字节规范与流终结签名；②补充 Sender-Constrained Token 持钥验证、关键扩展头签名和外层→内层可信上下文；③引入 JR/T 0197／0171 并落实授权优先的密钥分发和合作方明文接触限制；④增加任务提交幂等、Worker 恢复、CIBA 要素核签、核心确定性拒绝与未知结果挂账对账；⑤更新 20 项 PoC 和参考文献，纠正 RFC 9421 分类与 M4-02 漏项。**仍需生产前测试与密评，不代表加密协议已正式标准化。** |
| **v3.3.1** | 2026-10-23 | **总体架构基线保持 · SSE 契约精确化小版本** | 根据第六轮审查的有效建议定向收口：①明确首帧 `start_task_event_seq` 实时推导及零事件流占位／`C_0` 验证；②固定 `M_i` 九项字段、`PayloadObject_i` 两种模式、摘要二进制／Hex 编码及 `BANK-SSE-COMPLETED-v1` 独立签名域；③将 B2 无明文权限的标准 MCP/A2A 脱敏／引用响应与受控终端独立密文交付区分，禁止普通 Agent 直接消费非标密文信封；④补充 GB/T 32907、GB/T 36624 国标参考并保留正式密评门槛；⑤修正两处 Mermaid 文图用语及补足对应 PoC 断言。三层架构、其余安全不变量及生产准入条件不变。 |
| **v3.4** | 2026-10-25 | **再次审议修订版（技术可行性研判稿）** | 依据管理员发起的再次审议第 1 轮意见收集（五席独立意见，均为 REVISE）修订，并由主持人核对原始来源：①结论由“具备坚实可行性”“杜绝越权动账”收敛为“有条件可行”，L2 限定为非约束性草拟，约束性操作按 L3 管理；②修正主架构图：L3 经交易意图服务、带外确认与复核后才进入支付核心，L1/L2 降维转换不再连向支付校验；L3 表述改为“禁止经 A2A/MCP 触发或携带可执行动账指令”；③合作方“受控机房 + HSM／密码卡”由“强制基础合规”改为本行第四层准入策略、按接入等级分档，并补 JR/T 0185 第 9.3.5 节密钥防护与 SDK 使用要求；④对照人民银行官网 JR/T 0185 原文，更正第 9.3.3 节措辞（“不应采集、存储”，原稿误加“原则上”），补第 6.2 节 API 直连须专门评估、第 7.2.2 节 A2 只读查询结果不得在应用方本地保存、第 9.3.4 节日志留存等应用方义务；⑤补充《密码法》第二十七条、《网络数据安全管理条例》、金规〔2024〕24号、银保监办发〔2021〕141号、个人信息保护法第二十三、五十五条及生成式人工智能办法的适用判定，新增合作方数据处理角色与外部模型数据流评估前提；⑥协议事实更正：MRTR 全称为 Multi Round-Trip Requests，`Mcp-Name` 仅三类方法必需，Tasks 扩展错误码 `-32021`，补 `Origin` 校验、`/{tenant}` 绑定与推送回调出站风险；⑦授权矩阵改为资源级约束，补旧 Worker fencing、长期未决人工升级、密钥撤销不能收回已交付数据；⑧SSE 改为“权威结果签名优先、逐事件信封为候选增强”，字节级规则移交专项规范；20 项 PoC 归并为 6 组；删除正文版本沿革与版本标签；⑨参考文献更正 [1][4][5][7][9][11][23][24]，新增 [29]–[34]。正文由原 751 行压缩，未增加篇幅。本版尚待复审与终审，不代表已通过。 |
| **v3.5** | 2026-10-25 | **再次审议第 2 轮复审后修订版（技术可行性研判稿）** | 依据第 2 轮复审（研讨完整完成，三家投票席位均为 APPROVE，强席位无阻塞项；不计票的第二主持互评投 REVISE）定向收口，篇幅基本不变：①采纳第二主持意见，本期 L3 可行范围限于已设计的资金支付路径，锁价成交等非支付类约束性操作须另建确定性成交及审批硬校验路径，摘要、矩阵、第四节第 7 款与第六节同步收窄；②统一 L3 执行通道称谓为“银行受控的确定性支付接口”，DraftSys 注明仅凭有效审批凭证提交；③权威结果签名范围补 MCP 同步最终响应、MCP Tasks 最终结果与非 `returnImmediately` 的 `SendMessage`，中间事件免签改为“获合规与密评确认后方可采用”的条件分支；④旧 Worker fencing 要求代次随下游调用传递，PoC 验收补“下游副作用”；⑤对照人民银行官网 JR/T 0185 原文复核第 6.2、9.3.2、9.3.3、9.3.4 节，统一第 9.3.3 节转述口径，明示同意条款补注第 9.3.2 节；对照 MCP 2026-07-28 Streamable HTTP 规范页复核 `-32020`（HeaderMismatch）、`subscriptions/listen`、不支持 `Last-Event-ID` 与 `Origin` 校验；⑥《密码法》第二十七条映射限定于关键信息基础设施；摘要前提单列密评；⑦参考文献 [10] 改为经官网文档接口核对的正式页面；⑧新增少数意见第 8–10 条，附录新增第 2 轮意见处理表。本版尚待第 3 轮复审与终审，不代表已通过。 |
| **v3.6** | 2026-10-25 | **再次审议第 3 轮复审后修订版（技术可行性研判稿）** | 依据第 3 轮复审（研讨完整完成，五席在独立意见与互评中均为 APPROVE，强席位无阻塞项）按各席少数意见做措辞与验收收口，结论不变，篇幅略有增加（集中在附录）：①《密码法》第二十七条映射改为“依法须使用商用密码保护的关键信息基础设施应开展密评，该条不指定 GB/T 39786 应用等级”，术语表同步；②旧 Worker fencing 要求由副作用提交点校验或保证校验与提交不被接管竞态穿透，下游不支持代次校验的操作限定为幂等且无外部副作用，PoC 补“前置校验后被接管”“旧代次先到达下游”交错时序；③权威结果签名范围补同步调用中断态返回的 Task 快照，“标准客户端可直接消费流”改为“进度事件可直接消费”，A2 数据不得进入非权威事件并补 PoC 断言，单事件签名形态由专项规范确定；④L3 行与第六节注明支付核心须新增记账前硬校验，本期非支付类约束性请求由 PDP 操作白名单拒绝，PoC 补“智能体凭证直接调用提交接口被拒绝”；融资放款的信贷出账审批不由支付核心硬校验替代；⑤第六节前置条件与摘要五项前提统一；“提交必返回 Task”限定为 L2/L3 提交类调用；L2 约束性输出识别规则由准入评估确定；⑥参考文献 [32] 改用经主持人核对的商务部政府网站转载全文，第七节外包办法行补第三条第二款、第五条；⑦少数意见第 7 条注明版本号为第 1 轮记录，新增少数意见第 11–12 条，附录新增第 3 轮意见处理表。本版尚待终审，不代表已通过。 |
| **v3.7** | 2026-10-25 | **再次审议定稿版（技术可行性研判稿）** | 以 v3.6 为基础定稿，正文结论、架构与安全不变量不变：第 2、3 轮复审均研讨完整完成，强席位（核验席、质疑席）无阻塞项，第 1 轮强席位阻塞项已在 v3.4 逐条闭环（见本节第 3 款）。主持人对照原始页面复核参考文献书目信息，更正 [26] 作者列表（补列第二作者，其余以 et al. 表示）及版本日期，[7] 补最终规范批准日期，[8] 采用规范原标题并补发布日期与 Final 状态。本版须经终审复核后方可作为通过依据；终审后如有改动须重新复核。 |
### 2. 原正文版本摘要（自 v3.3.1 第 7–11 行原样移入）
> **v3.2 专项修订摘要（历史沿革）**：在保留 v3.1 架构基线及全部 11 张 Mermaid 图的基础上，按 JR/T 0185—2020 第 7.2.2、9.2.2、9.3.3 节、GB/T 39786—2021 第 8.2(c)、8.4(d) 条、《个人信息保护法》第五十一条，以及金发〔2026〕8号的数据治理要求，补齐**传输机密性、应用层报文加密与 SSE 流式适配**。确立“**标准与数据分类决定保护目标，密评方案决定实施路径**”的判定原则；明确 A2 双向数字签名基线与数据机密性要求互不替代；建立 TLCP 通道保护、按场景逐事件／字段级认证加密、敏感信息明文边界、合作方 Adapter 或等效 SDK 解密适配及专项 PoC 验收机制。**标准没有普遍要求所有 SSE 事件逐帧使用 SM4 加密，且具体合规结论须结合接口范围、数据类型、合作方角色及密评确定。**
> **v3.3 专项整改摘要（历史沿革）**：在 v3.2 三层实施架构、四个逻辑安全域、既有可视化风格和合规分层体系不变的前提下，针对外部审查中成立的问题进行**五项受控修订**：①统一 SSE 明文／密文事件信封，改为累积 SM3 哈希链、可复现签名原文与双序号；②完善 DPoP/mTLS 持钥验证、12 项基础必签字段以外的安全关键头覆盖、双网关可信上下文传递；③按 JR/T 0197、JR/T 0171 明确金融数据分级与**解密前的主体准入**；④补足 Outbox 幂等、Worker 恢复、CIBA 交易要素核对及核心权威结果分支；⑤细化 PoC 故障注入与合规映射。**本版不声称自定义信封属于 MCP/A2A 原生协议，亦不声称密码应用或生产准入已经验证通过。**
> **v3.3.1 定向收口说明**：本版不改变总体三层架构、业务授权及 L3 资金交易设计，只明确 SSE 累积链初始值与空流证明、固定公开元数据集合及签名字节表示、流结束签名域分离；将合作方无明文权限（B2）时的标准协议脱敏／引用响应与受控终端独立密文交付分开描述；补充 SM4 算法及可鉴别加密机制国家标准依据 [27][28]，修正文图笔误并增加对应 PoC 断言。上述为**文本契约精确化**，仍须通过跨语言密码学测试向量和正式密评确认。
### 3. 第 1 轮强席位阻塞项处理
| 来源席位 | 阻塞项 | 处理 |
|---|---|---|
| 质疑席 F1／核验席 1 | 可行性结论强于正文限定；L2 遗漏约束性后果 | 已修复：摘要、第一节第 3 款、第六节第 1 款 |
| 核验席 2 | 主架构图与 L3 禁止直连矛盾 | 已修复：第三节主架构图、第一节矩阵 L3 行 |
| 质疑席 F2 | JR/T 0185 第 9.3.3 节误加“原则上”，弱化留存限制 | 已对照官方原文修复：第四节第 5 款、第五节第 1 款 |
| 质疑席 F3／核验席 3 | 遗漏数据安全、第三方合作、出境等监管依据 | 已修复：第一节第 2 款、第五节第 1 款、第六节第 2 款、第七节；各文件文号与日期已核对 |
| 质疑席 F4 | `Mcp-Name` 统一必签会拒绝合法请求；MRTR 术语；Tasks 状态 | 已修复：第一节术语表、第二节、第四节第 2 款；Tasks 状态改为“按锁定版本” |
| 质疑席 F6／核验席 4 | 合作方 HSM 被误标为强制合规 | 已修复：第五节第 2 款；具体分档列入少数意见第 4 条 |
| 质疑席 F7 | 授权矩阵以同租户、角色为充分条件；旧 Worker；未决交易超时解锁 | 已修复：第四节第 1、3、7 款 |
| 质疑席 F8 | 承诺撤销已发密钥的离线解密能力 | 已修复：第四节第 5 款、第六节第 3 款 |
| 质疑席 F10／核验席 5 | 过程状态无据、轮数前后矛盾 | 已修复：状态行、摘要；附录既有记录保留并加注 |
### 4. 第 2 轮复审意见处理
第 2 轮强席位（核验席、质疑席）在独立意见与互评中均投 APPROVE，无阻塞项。下表列出各席提出的修改意见及处理；未列入的替代方案见第八节少数意见第 8–10 条。
| 来源席位 | 意见 | 处理 |
|---|---|---|
| 第二主持（互评 REVISE，不计票） | L3 矩阵含锁价成交，但架构只设计了支付核心校验，L3 结论强于架构 | 采纳：摘要、第一节第 3 款、第四节第 7 款、第六节第 1 款收窄为资金支付路径 |
| 主主持、核验席、第二主持 | L3 执行通道称谓不一致；DraftSys“无动账权限”与提交连线字面张力 | 采纳：第一节矩阵 L3 行、主架构图 DraftSys 节点 |
| 主主持、核验席、质疑席 | 权威结果签名范围未覆盖同步调用与 MCP 最终结果；中间事件免签应为条件分支 | 采纳：第四节第 4 款 |
| 质疑席 | 旧 Worker 验收只验覆盖结果，未验下游副作用 | 采纳：第四节第 3 款不变量③、第六节第 3 款 |
| 主主持、核验席 | 第 9.3.3 节适用范围三处口径不一 | 对照原文核实后采纳：第四节第 5 款第 4 项 |
| 主主持 | L2 行“A2 全部控制”易被误读为流事件已签名 | 采纳：第一节矩阵 L2 行 |
| 主主持、核验席、第二主持 | 《密码法》第二十七条映射偏满 | 采纳：第七节 |
| 核验席 | 摘要前提未单列密评 | 采纳：摘要 |
| 核验席、主主持 | `-32020`、`subscriptions/listen`、明示同意含授权有效期、日志不少于 6 个月、第 6.2 节专门接口缺锚点 | 已对照原文核实，均与正文一致；明示同意补注第 9.3.2 节 |
| 主主持 | 附录 v3.1 行 Overview 陈述未覆盖加注；v3.4 行行数口径 | 采纳：本节第 1 款加注 |
| 核验席 | [10] 链接参数为空；[32] 仅媒体报道 | [10] 已替换；[32] 列入少数意见第 10 条 |
### 5. 第 3 轮复审意见处理
第 3 轮五席在独立意见与互评中均投 APPROVE，强席位（核验席、质疑席）无阻塞项，`strong_objections`、`strong_unparsed` 均为空。下表列出各席修改意见及处理；顾问席的演进建议见第八节少数意见第 12 条。
| 来源席位 | 意见 | 处理 |
|---|---|---|
| 质疑席、主主持 | 《密码法》第二十七条不直接指定 GB/T 39786 第三级 | 采纳：第一节术语表、第七节；条文对照国家密码管理局公布文本 |
| 质疑席、主主持 | fencing 前置校验须防检查与提交竞态、旧代次先到达下游；下游不支持代次校验时的处理 | 采纳：第四节第 3 款不变量③、第六节第 3 款 |
| 质疑席、第二主持 | 来源宜区分“已补引用”与“已独立核实”；[32] 可改用政府网站全文 | 采纳：[32] 经主持人核对后替换，第七节补条款；核验状态见第八节少数意见第 11 条 |
| 核验席 | “标准客户端可直接消费流”偏宽；同步调用中断态返回的签名边界 | 采纳：第四节第 4 款 |
| 核验席 | 放款前置的信贷出账审批不由支付核心硬校验替代 | 采纳：第四节第 7 款 |
| 核验席 | 第六节前置条件与摘要五项前提表述不一致 | 采纳：第六节第 1 款 |
| 核验席 | 非支付约束性请求本期由哪个组件拒绝未写明 | 采纳：第一节矩阵 L3 行（PDP 操作白名单） |
| 主主持 | 智能体凭证不得调用提交步骤缺 PoC 断言；“既有确定性渠道”易被读成核心无需改造 | 采纳：第一节矩阵 L3 行、第六节第 1 款与第 3 款 |
| 主主持 | 免签条件缺执行手段与验收；SSE 最终结果单事件签名形态与锚点 | 采纳：第四节第 4 款、第六节第 3 款 |
| 主主持 | “提交必返回 Task”适用范围；L2 约束性输出缺识别手段 | 采纳：第二节、第一节矩阵 L2 行 |
| 主主持 | v3.5 更新历史“篇幅基本不变”偏弱 | v3.5 行为历史记录不改；本版记录写明篇幅略有增加 |
| 第二主持、主主持、顾问席 | 少数意见第 7 条“本版采用 v3.4”与当前版本不符 | 采纳：第八节第 7 条加注 |
| 核验席、第二主持 | MCP 2026-07-28 与 JR/T 0185 条款本席未独立核实 | 主持人已于第 2 轮及本轮对照原文核实相关条款，见第八节少数意见第 11 条；席位自述的核实不作依据 |