A2A 代理通信安全怎么配：身份、通道与权限检查
A2A 安全配置要解决的是“谁可以调用代理、调用内容是否可信、传输过程是否被窃听或篡改”。
它不依赖某一个开关，而是由代理卡访问控制、传输层加密、调用方身份校验和任务级权限共同组成。
下面按从外到内的顺序说明配置位置和验证方式，适用于自建 A2A 代理服务、通过 HTTP 或 JSON-RPC 暴露端点的场景。
先确定要保护的对象
动手前先列出三样东西：代理卡地址、任务端点地址、允许调用的客户端。
代理卡通常是一个公开的 JSON 文件，描述代理名称、版本、能力和端点；
任务端点才是真正接收任务请求的接口。
两者可以同域，也可以分开。
如果代理卡本身包含内部地址、调试参数或未公开能力，建议对代理卡也做访问控制，而不是默认全公网可读。
至少确认：
- 任务端点只暴露必要路径，管理接口不对外。
- 代理卡中的
url字段指向 HTTPS 地址，不写内网 IP 或http://。 - 调用方有明确标识，例如客户端证书、JWS 签名或受控的 API Key。
传输层：优先启用 HTTPS，敏感场景再上 mTLS
A2A 通信一般走 HTTP，因此第一层是 TLS。
用 Nginx 反向代理时，最小配置是强制 HTTPS 并关闭旧协议：
server {
listen 443 ssl;
server_name agent.example.com;
ssl_certificate /etc/nginx/ssl/agent.crt;
ssl_certificate_key /etc/nginx/ssl/agent.key;
ssl_protocols TLSv1.2 TLSv1.3;
location /a2a/ {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}
}如果调用方和代理都在受控网络内，且需要双向确认身份，可以在 Nginx 上开启客户端证书校验：
ssl_client_certificate /etc/nginx/ssl/ca.crt;
ssl_verify_client on;开启后，没有客户端证书的请求会在 TLS 握手阶段被拒绝。
注意这会影响所有经过该 server 块的请求，建议单独为 A2A 端点建一个 server 块，避免影响其他业务。
验证时用 curl 分别测试带证书和不带证书：
curl -v https://agent.example.com/a2a/health
curl -v --cert client.crt --key client.key https://agent.example.com/a2a/health第一条应失败，第二条应返回正常状态。
如果两条都成功，说明 ssl_verify_client 没有生效，检查是否放错了 server 块或证书链不完整。
调用方身份：JWS 签名与 API Key 的取舍
A2A 消息支持用 JWS 对请求签名，适合需要确认消息来源和完整性的场景。
配置时重点不是算法，而是三件事：签名原文是否与验签方一致、公钥是否对得上、时间戳是否在允许窗口内。
一个常见的服务端校验顺序是：
- 从请求头或消息体中取出 JWS。
- 用预先登记的调用方公钥验签。
- 检查
iat或exp是否在允许偏差内。 - 验签通过后再解析业务字段。
如果验签失败，先打印服务端实际参与验签的原始字符串，和签名方生成时使用的字符串逐字节比对。
很多失败是 JSON 序列化顺序变化、多了一次 URL 编码，或换行符被改写导致的。
对内部调用量不大、不方便维护密钥对的场景，可以用 API Key 加 IP 白名单做基础控制，但不要把 Key 放在 URL 查询参数里，避免进入访问日志。
更稳妥的做法是放在请求头，并在反向代理层校验：
location /a2a/ {
if ($http_authorization !~ "^Bearer\s+([A-Za-z0-9._-]+)$") {
return 401;
}
proxy_pass http://127.0.0.1:8080/;
}这段只做格式检查，真实 Key 比对仍应在应用层完成，避免把密钥写死在 Nginx 配置中。
任务权限：按代理能力做最小授权
身份通过不代表可以调用所有任务。
代理卡里声明的能力应当和实际授权一致。
例如代理卡只声明了文本摘要能力，就不应接受文件删除类任务。
配置时建议：
- 在服务端维护任务类型白名单，未声明的任务直接返回 403。
- 不同调用方分配不同权限集，不要共用一个全权限账号。
- 对高风险任务增加二次确认或人工审批，不要只靠调用方自律。
- 记录每次任务调用的调用方标识、任务类型和结果，便于审计。
验证权限是否生效，可以用一个低权限身份调用高权限任务，观察是否返回 403。
如果返回 200，说明白名单没有落到执行层，需要检查任务分发代码是否在鉴权之前就执行了。
常见失败点与排查顺序
遇到调用失败时，按从外到内的顺序查，不要一上来就改应用代码：
- 先看 TLS 握手是否完成，证书是否过期、域名是否匹配。
- 再看反向代理是否返回 401 或 403，确认鉴权头或客户端证书是否传到后端。
- 如果返回 200 但业务报错，检查 JWS 验签原文和时间戳窗口。
- 如果任务被拒绝，核对代理卡声明的能力和服务端白名单是否一致。
- 最后查日志中是否有调用方标识，没有标识说明身份信息在代理层丢失。
完成上述配置后，至少做一次端到端验证：用允许的调用方发一个最小任务，确认返回成功；
再用未授权调用方重试，确认被拒绝。
两条结果都符合预期，才算安全配置真正生效。
