← 返回藏书阁

SAP A2A Bridge：用户断言、客户端身份与任务证据分界

wiki/ai/sources/sap-a2a-bridge-principal-resource-and-task-boundaries.md
分类：ai / sources · 更新：2026-10-29 09:13

SAP A2A Bridge：用户断言、客户端身份与任务证据分界

知识点轴：A2A / MCP Gateway / harness-runtime / sandbox-security / benchmark-evaluation。实际证据是官方架构/部署配方与固定示例源码，不是本机云部署、live Agent Card、认证负例或企业生产互通实测。

为什么值得用户深挖

A2A-Agent2Agent-Protocol讲协议，MCP-Gateway-Runtime讲控制层；这个案例把两者之间最易偷换的链条具体化：发现了agent，不能推出允许调用；应用能签JWT，不能推出能代表任意用户；bridge能返回文字，不能推出远端任务完成。 它适合用来设计Hermes未来跨系统委托的验收合同，而不是建议现在接入SAP。

来源不是只有发布新闻：2026-10-27 SAP架构文章给设计时发现/信任/授权与运行时A2A的分层；GCP配方和代码进一步暴露身份换发、Card生成和结果降维的具体边界。

一阶机制：把三个身份对象拆开

链路为 Gemini Enterprise → GCP-Agent-Bridge → SAP IAS → Agent Gateway → SAP agent，但IAS是认证换发服务，不是请求内容必须依次经过的业务节点。

  1. 终端用户断言：前端完成SAP IAS三方OAuth，把取得的用户token交给bridge；bridge不自行选择任意用户sub。
  2. 客户端断言：bridge用GCP IAM signJwt签短期JWT，sub=OAUTH_CLIENT_ID，证明“是哪一个应用”；不是替用户新造的用户JWT。固定实现含iss/aud/jti/iat/nbf/exp，TTL为300秒；有jti不证明服务端已实现一次性消费。
  3. 下游资源：agent.py向IAS提交用户token作为assertion、客户端JWT作为client_assertion、resource=TOKEN_EXCHANGE_RESOURCE；得到下游token后才把Bearer发给配置的Agent Gateway endpoint。

协议名按实际wire保存。 配方引用RFC 7523/8693并通称token exchange，但固定代码的grant是 urn:ietf:params:oauth:grant-type:jwt-bearer，不是RFC 8693的token-exchange grant。不要凭教程标题替换成另一组字段，也不要由“请求resource”推断实际返回token的aud/权限已经核验。

无secret有明确作用域。 配方说bridge runtime不持有静态client secret，签名私钥也不下载到runtime；同一配方仍要求在Gemini Enterprise授权配置中填client secret。因此正确表述是“bridge这一跳无静态secret”，不是“全系统无secret”。IAM TokenCreator权限、用户会话token与IAS信任配置仍需管理。

发现、注册与授权不是同一道门

共同配方要求在SAP for Me创建 Agent Gateway Consumer，依次完成三项formation：Cloud Identity Services建立身份、Agent Gateway建立路由、Agent Gateway Consumer限定可调用agent集合。上一项READY后再做下一项；这是官方配置依赖，不是本机测到的失败等待时间。

架构文档谈Agent Card和ARD目录发现；目录可见性、consumer准入、当前用户对最终业务资源的权限必须分验。本轮只读ARD README并保留spec原件，不能据此称ARD已在客户环境完成联邦部署。SAP对外agent路径说明A2A，不把内部MCP、ODATA/REST背景图拼成同一gateway已实现MCP/A2A/REST/gRPC四协议联邦。

与langchain-per-caller-connections-credential-ownership一样，机器身份和人的身份需独立记账；与a2a-auth-required-state-is-not-authorization一样，授权流程存在也不是每次调用获批回执。

固定源码提供了什么，又没有提供什么

固定仓库 SAP-samples/agent-interoperability，commit 4510da124aec0928e733ccc499b36994d60d5b3f。本轮读取common/GCP README和五个实现/依赖文件。

观测对象固定源码/配方证据不能据此宣称
Cardapp_utils/a2a.py动态生成Card，advertise streaming，追加v0.3兼容interface并启用兼容routes已取到live Card、全部版本互通或全链路流式
注册路径GCP README明确该bridge以ADK部署，在registry显示Non A2A，前端到bridge是否使用A2A未保证Gemini→bridge→SAP每一跳都是A2A
下游调用agent.py直接POST JSON-RPC message/send，每次生成messageId和RPC idSDK版本要求自动等于该wire版本，或可跨重试业务幂等
任务状态FastAPI入口使用InMemoryTaskStore；下游回包递归提取text重启后接管、GetTask/Cancel/续订、artifact结构或终态已保留
错误传播HTTP/JSON-RPC失败转成给上层的聊天文字；源码会取correlation header上层成功响应就是下游业务成功，或全链trace已连通
用户token选择设置GE_AUTH_ID时按key取；否则仅当整个session.state长度为1时取唯一value任意session state都能可靠识别授权token或可信用户

特别是_extract_text并不判读Task状态：返回有文字不能等于completed，更不能等于业务effect已提交。Card对bridge入口宣称streaming，不会让下游同步message/send自动变成可续订流。root_agent仍由模型执行“原文转发”指令并调工具，不是经代码强制的字节透明代理；用户请求是否逐字保持要另验。

GCP README还明确每请求新签断言/换token，不复用仍有效下游token。缓存若后续引入，至少按用户、客户端、issuer、resource和权限维度隔离并处理过期/撤销，不能只按agent URL存一枚全局Bearer。此为工程推论，不是已审到的缓存实现。

对Hermes与agent workflow的可执行启发

  • 每跳身份表：记录真实caller、用户sub、客户端iss/sub/aud、目标resource、最终peer和允许agent集合；token值不进wiki、模型上下文或公开trace。
  • 两组独立负例：用户A的token换到B目标/另一resource应拒绝且零业务effect；合法用户换发成功后，仍测试无权agent/对象拒绝。请求字段合规不代替服务端执行结果。
  • 任务证据不降维：保留taskId/contextId、状态、artifact、结构化error和可信业务读回；让调用失败与业务失败可被上层判断，而不是只读聊天文字。
  • 版本与恢复合同：按实际Card、入口注册方式、wire方法、SDK依赖各记版本；测试异步working、断流、进程重启、重试与已提交effect，再谈互通。
  • 全链总预算：签名、换token、模型转发、下游请求分别计时；两个60秒HTTP阶段不等于外层绝对60秒，超时后先回查任务/effect再重试。

这些是可在获准隔离环境落实的验收项，本轮没有更改Hermes gateway、启用A2A或触碰生产凭据。Harness-Engineering应把它们作为控制逻辑，而不只写进模型提示。

边界与未解问题

未连接SAP/GCP、未安装依赖、未实际换token/调用agent，未取live Card；源码局部证据也不足以证明平台缺失认证或用户实例存在漏洞。未核验IAS最终token claims、跨用户session隔离、task-owner授权、信任撤销传播、stream/push和完整OTel链路。依赖要求Python>=3.11,<3.14，本轮没有为运行示例安装或污染本机环境。

深度判断：身份/资源/任务三类对象具有迁移价值，且实现局限能修正架构图造成的过度推断，故晋升正式source；不为SAP、bridge或ARD另造薄entity/concept页。

原始来源

写入记录

  • 2026-10-29 09:10 CST：新增SAP/GCP A2A bridge深读，区分用户/客户端断言、真实JWT-bearer grant、resource授权与Card/任务/纯文本证据；固定源码不冒称云部署或互通实测。
藏书阁 · Published from llm-wiki · 2026-11-02 09:29:27