A2A AUTH_REQUIRED：任务暂停信号不是授权回执

wiki/ai/sources/a2a-auth-required-state-is-not-authorization.md

分类：ai / sources · 更新：2026-10-18 09:03

A2A AUTH_REQUIRED：任务暂停信号不是授权回执

知识点轴：A2A / MCP Gateway / harness-runtime / sandbox-security / benchmark-evaluation。 2026-10-18 阅读官方规范固定文件提交 7c861a5 §3.2.2、§7.3–7.6、§13.1；该提交 10-12 修复的是 Agent Card 示例，不是今天发布了新的授权协议。raw 保存固定规范源文件原字节；这里是规范与工程推导，没有运行 A2A SDK/网关/真实三主体任务测试。

对用户的价值和核心结论

A2A-Agent2Agent-Protocol 中多 agent 委托可能要等用户批准、另一个系统颁发 OAuth 凭据、或通过公司网关办理更高风险动作。规范提供 TASK_STATE_AUTH_REQUIRED 用于表达任务等待授权，但明确没有定义具体授权决定的 scope、表示、有效期或撤销。将 task 状态、卡片声明、上游一句“已批准”当成可执行权限，会让 MCP-Gateway-Runtime 的后端工具边界与 Harness-Engineering 的审计变成摆设。真正的权限仍应由凭据发行方/执行方针对 caller、操作对象、权限与时点核验。

一阶机制：把等待流程和执行许可分开

声明需求而非自动授予。 固定规范 §7.6.1 要求代理用 Task 追踪、转 TASK_STATE_AUTH_REQUIRED、以 TaskStatus 解释需求（已带外协商者可例外）；§7.6.4 明示不得因转入该状态就认为某操作已获授权，也不得默认一次授权覆盖任务的后续消息。它是协调协议，不是 permission token。§7.5 要求服务按已认证身份结合自身策略做请求授权，但具体模型留给实现。
凭据到达方式和恢复订阅。 默认在 A2A 之外接收授权凭据；带内交换只有预先带外协商/扩展下才可用。若 agent 带外收到凭据，可无需 client 再发送消息就恢复执行；未保留流的 client 应主动订阅、配置 push 或轮询，否则漏看任务重启/完成。§3.2.2 的阻塞 send 在 AUTH_REQUIRED 等 interrupted state 即返回，等待态不是 completed、也不是安全拦截最终态。
多跳转交不是权限传递。 中间 agent 可将其 Task 同样转为 AUTH_REQUIRED 将取凭据需求上传；但规范警告带内凭据可能暴露给每个中间 agent，建议绑定原发起 agent 并使其单独可读。工程上应逐跳绑定受众、发行者、scopes/动作/资源、过期与撤销；这是建议验收设计，非协议自动提供的能力。OTel trace/contextId 可用于关联，但不等于被授权主体。
任务数据操作另有强制访问边界。 §13.1 要求每个 A2A 操作按认证 caller 检查，List/Get/Cancel/Subscribe/Push 配置均各自控制；无 contextId 过滤也不能列出别人的任务，且查库或可能泄露存在性前先授权。这和 AUTH_REQUIRED 批准某个业务动作是两套门：拿到了业务 OAuth token 不自动拥有 task owner 的读取/续订权；task owner 也不自动拥有后端写权限。参见 agentops-a2a-confirmation-principal-and-terminal-state 与 go-micro-a2a-gateway-task-owner-push-boundaries。

Hermes / 企业 A2A 验收合同（提议，不是已上线）

状态/边界	可验证回执	负例
请求待授权	taskId、caller、要求的动作/对象与可回复渠道	只设 `AUTH_REQUIRED` 不取到有效授予 → 后端无副作用
带外凭据与多跳	issuer、audience、subject、scope、resource、expiry、审批 id 及发给最终 agent 的通道	上游 token 被另一个 agent 重用、旧批准跨对象复用 → 拒绝
恢复与结果	subscribe/push/poll 收到终态；真实后端执行回执与合法完成	断流后自动执行但 client 未看到状态 → 标未观测，不报完成
任务所有权	三主体的 list/get/cancel/subscribe/push config 逐方法授权	不传 contextId / 猜 taskId / 同任务不同 caller → 不泄露存在性与推送 token

对于无人定时任务，若不存在能实际完成审批的渠道，就不能因为 trace 多出 approval_id 或等到 AUTH_REQUIRED 而提升权限。formal-runtime-verification-trace-provenance-approval-readiness 的审批历史可达与可信来源绑定，是本规范在运行时的必要配套；a2a-push-dial-ip-proxy-final-target-boundaries 则补偿 push 出站最终目标和实际投递回执。

失败模式与证据边界

规范文字本身不证明任何 SDK 完全实现，更不证明用户当前 Hermes 的 A2A plugin 已启用、已支持多跳授权或已接生产审批。两类常见错报：AUTH_REQUIRED → “已防住攻击”（缺恢复及合法完成）；凭据返回 → “任务全部可执行”（缺精确 scope/下游验权及后续消息隔离）。实际应在固定 SDK/网关版本上运行三主体任务与回调隔离、过期/撤销/断流恢复测试；测试判分记录合法任务完成和违规副作用各自独立。规范文件含未渲染 proto 模板，本文只依据明文条款，不以模板占位推导 SDK 字段或 conformance 结果。官方企业指南的 TLS/trace 是一般要求，不等于凭据端到端保密或委托可追责。

写入记录

2026-10-18 09:03 CST：固定官方规范文件版本并归档原文；深析待授权态/授予范围/多跳凭据/任务可见性双门，形成可复核隔离验收合同与失败边界。