A2A 协议如何保障通信安全？

1. 传输层安全（TLS）

A2A 协议强制要求使用 TLS 1.2 或更高版本对通信内容进行加密，推荐采用 TLS 1.3+ 以获得更强的安全保障。加密的 HTTPS 连接防止任何中间方窃听或篡改智能体之间的通信内容。协议还要求服务端设置 HSTS（HTTP Strict Transport Security）头，强制客户端始终使用安全连接与服务端通信，防止降级攻击。

2. 双向 TLS（mTLS）认证

A2A v1.0 将双向 TLS（mTLS）正式化为支持的安全方案。mTLS 要求通信双方（客户端和服务端）都出示并验证对方的 TLS 证书，实现相互身份认证。这在金融、医疗等高敏感度领域的智能体通信中提供了最高级别的身份保证。通过 mTLS，即使在不安全的网络环境中，智能体之间的通信也能保持高强度的身份认证和加密保护。

3. Signed Agent Cards（签名智能体名片）

A2A v1.0 引入了 Signed Agent Cards 特性，允许智能体对其 Agent Card 进行加密签名。客户端在获取 Agent Card 后，可以验证签名以确保该 Agent Card 确实由宣称的智能体发布，且在传输过程中未被篡改。这防止了在开放网络（如公共 A2A 网络）中的智能体冒充攻击——恶意第三方可能试图发布伪造的 Agent Card 诱骗其它智能体向其发送任务请求。

4. 推送通知安全机制

A2A 协议的推送通知机制面临服务端主动向客户端 webhook 发送 HTTP POST 请求的场景，这引入了特定的安全挑战。服务端安全方面：服务端绝不能盲目信任客户端提供的 webhook URL，防止 SSRF（服务端请求伪造）攻击——恶意客户端可能指向内部服务进行攻击；服务端必须使用 PushNotificationConfig.authentication 中指定的认证方案向 webhook 进行身份认证；服务端应实现允许列表、所有权验证或网络控制。客户端安全方面：客户端必须验证传入通知的真实性（验证签名、token）；客户端应拒绝带有旧时间戳的通知；客户端应实现 nonce/唯一 ID 验证以防止通知重放攻击。

5. 现有基础设施复用

A2A 协议的安全模型建立在行业历经 20 年加固的相同 HTTP 安全模式之上，而非重新发明轮子。企业现有的 API 网关、WAF（Web 应用防火墙）规则和速率限制策略可以直接转移到 A2A 部署中，无需修改即可工作。运维团队不需要学习新的安全模型——A2A 智能体可以像任何其它 REST API 服务一样被保护。这种与现有安全基础设施的兼容性大大降低了企业将 A2A 协议引入生产环境的门槛。