Foundry + APIM 的 A2A 实践：发现、调用和逐跳凭据不能混验

wiki/ai/sources/foundry-apim-a2a-discovery-and-credential-hops.md

分类：ai / sources · 更新：2026-09-15 09:20

Foundry + APIM 的 A2A 实践：发现、调用和逐跳凭据不能混验

知识点轴：A2A / MCP Gateway / harness-runtime / sandbox-security。一次 JSON-RPC 调用可用，不等于 Agent Card 发现、用户授权、stream/push 或任务恢复已经可用。

为什么值得深挖

这不是又一个“支持 A2A”的产品介绍：公开教程给出 Foundry agent application、APIM 路由、managed identity、角色、policy XML、测试方法及未解决的 Card 路径问题；Microsoft 官方文档提供产品约束和逐跳认证规则。它将 A2A-Agent2Agent-Protocol 的协议对象落实为可审计配置，补充 microsoft-a2a-adapter-host-ownership 的 host 责任边界。

本轮阅读完整教程与四份官网文档，并解析教程原始 XML；没有 Azure 实例、真实部署后 Card、鉴权调用、SSE、push 或跨租户实测。配置证据足以沉淀接入机制，不足以宣称本机或企业 E2E 成功。

调用链先按方向拆开

外部 caller
  → APIM 入口（caller 的认证/订阅/授权由此负责）
  → APIM managed identity 换取后端 token
  → Foundry application /endpoint/protocols/a2a

Foundry 作为 client
  → project connection 定义的外部 A2A endpoint
  → 先获取 Agent Card，再调用工具/任务

这两条链不是同一个凭据配置：send_credentials_for_agent_card 属于 Foundry 作为 A2A client 的 tool definition，不能用来自动修复 APIM portal 导入 Foundry Card 的失败。

机制一：三个身份不能被一个“认证成功”覆盖

教程的 policy 将 backend 指向 application A2A 路径、设置 A2A-Version: 1.0，通过 authentication-managed-identity 申请 audience https://ai.azure.com 的 token；本机 XML 解析确认这些字段存在，但未提交给 Azure 校验。

应分别记录：

入口是谁： caller 的 token/订阅如何验证、哪些 caller 能调用此 agent。订阅 key 不是自动的用户委托语义。
出口借谁的权： APIM 用自己的 managed identity 访问 Foundry；不能据此称为原用户身份透传，必须检查 caller 能否借用这项服务身份权限。
后端最终认谁： Foundry 校验 token 并按该身份角色授权。官方 managed-identity 文档明确 APIM 不验证 token 被发往哪个 backend，URL allowlist、audience 和目标绑定仍需网关配置兜底。

教程使用 Foundry User 作为 portal 选角受限时的可用方案，提及更小权限的 Foundry Agent Consumer；不要把操作便利当最小权限证明。本轮未分配任何角色。与 enterprise-mcp-persona-credential-boundaries 的 User→SA entitlement 检查是同一类问题。

机制二：Card fetch 与 invocation 是两个认证门

官方 Foundry client 文档说明：默认凭据只附加到工具调用，Card 请求匿名；受保护 Card 需要显式 send_credentials_for_agent_card: true。凭据只发给 base_url 同 host 的 HTTPS 路径；HTTP 或跨 host 的完整 agent_card_path 会忽略该设置、匿名获取。启用前还要确认 Card 确实需要认证，避免扩大 secret 暴露面。^[raw/articles/foundry-apim-a2a-discovery-and-credential-hops-2026-09-15.md]

但教程中的 APIM 导入是另一个实现：匿名拉取受保护 Foundry Card 失败后手动填写 API 元数据。作者还明确记录网关 agent-card.json 返回 405 的遗留问题。可用的 invocation route 与不可用的 discovery route 可以同时存在。 该 405 是作者配置的观察，不外推为 APIM 产品普遍缺陷。

真实验收应保存网关外侧 Card URL、status/body/hash、指向的 runtime URL、protocolVersion/binding/capabilities；手写 Card 必须与有效路由同步，不能以 portal 里看见一个 URL 代替实际 GET。

机制三：外层流式响应不证明远端 A2A 支持 streaming

APIM 官网当前说明 A2A API 使用 JSON-RPC。Foundry incoming A2A 文档列出 SSE streaming 不支持；同一文档展示的 openai.responses.create(..., stream=True) 是上层 Responses 流式体验，不能据此推出远程 A2A 流式 task/update 已实现。^[raw/articles/foundry-apim-a2a-discovery-and-credential-hops-2026-09-15.md]

因此要在 MCP-Gateway-Runtime 的 registry 中分开记录 transport binding、外层 client streaming、远端 A2A streaming、push、history、cancel/resubscribe。未读到或未测试的能力保持 unknown/未验证，不能根据协议规范自动填 true。此处不是规范与实现互相矛盾，而是产品实现子集和外层调用层次不同。

对 Hermes 接入的最小验收表

验收对象	需要的证据	常见误判
discovery	实际 Card status/body/hash、URL 重写	手动导入成功就算发现成功
caller→gateway	两个不同权限身份的允许/拒绝记录	key 有效就能借所有服务身份
gateway→backend	audience、managed identity、实际目标、后端角色	拿到 token 就证明目标合法
task lifecycle	task id、状态、错误、取消/恢复实际响应	同步文字响应代表完整 A2A
stream/push	对应 binding 下独立测试及不支持原因	UI 在逐字显示就代表 A2A SSE

低风险启发已写入 AI-Knowledge-Point-Radar：继续寻找有真实 Card/路由/认证/失败回执的 A2A 案例，但按证据层级入库，不把教程升级为部署认证。实际接入前建议隔离环境做匿名/授权/跨身份 Card 和调用矩阵；不在无人雷达中创建云资源或授权角色。

原始来源

写入记录

2026-09-15 09:17 CST：新增 Foundry/APIM 逐跳身份、Card 与调用认证、有效 binding/streaming 的分层机制；记录 XML 实核、作者 405 观察及未运行 Azure E2E 的边界。