利用Google的A2A协议构建安全的代理AI应用-CSDN博客

本文链接：https://blog.csdn.net/u013524655/article/details/147542903

Idan Habler ${ }^{12}$
对抗性AI安全研究 (A2RS) Intuit
idan_habler@intuit.com

Ken Huang ${ }^{13}$
代理AI安全
DistributedApps.ai
ken.huang@distributedapps.ai
Vineeth Sai Narajala ${ }^{14}$
主动安全
亚马逊网络服务
vineesa@amazon.com

Prashant Kulkarni ${ }^{15}$
谷歌云
谷歌
pskulkarni@google.com

摘要

随着代理AI系统从基本工作流演变为复杂的多代理协作，如Google的Agent2Agent (A2A)等强大协议成为必不可少的推动者。为了促进安全采用并确保这些复杂交互的可靠性，理解A2A的安全实现至关重要。本文通过提供以A2A协议为中心的全面安全分析来实现这一目标。我们检查其基本要素和操作动态，并将其置于代理通信发展的框架内。利用专门设计用于AI风险的MAESTRO框架，我们应用主动威胁建模评估A2A部署中的潜在安全问题，重点关注代理卡管理、任务执行完整性以及身份验证方法等方面。

基于这些见解，我们推荐实用的安全开发方法和架构最佳实践，旨在构建具有弹性和高效的A2A系统。我们的分析还探讨了A2A与模型上下文协议（MCP）之间的协同作用如何进一步增强安全互操作性。本文为开发者和架构师提供了所需的知识和实用指导，以自信地利用A2A协议构建强大且安全的下一代代理应用。

索引术语—代理AI，Google Agent2Agent，代理到代理通信，A2A协议，安全，威胁建模，MAESTRO，MCP，互操作性，安全开发

I. 引言

智能自主代理的出现标志着AI系统开发、部署和扩展方式的关键转变。随着这些代理越来越多地在组织和技术边界之外进行交互，对安全和可互操作通信的需求变得至关重要。本文首先探讨这种转型的基础：代理AI的兴起及其启用协议。

${ }^{1}$ 这些作者对该工作贡献相同。
${ }^{2}$ 本工作与作者在Intuit的职位无关
${ }^{3}$ 本工作与作者在DistributedApp.ai的职位无关
${ }^{4}$ 本工作与作者在Google的职位无关
${ }^{4}$ 本工作与作者在Amazon Web Services的职位无关。A. 代理AI的兴起及对安全互操作性的需求

随着人工智能系统从孤立的任务特定模型演变为动态的多代理生态系统，我们正见证代理AI的出现——能够自主决策、使用工具并与其他代理和人类协作的智能代理。这些代理不仅响应提示，还会发起行动、委派子任务、与其他代理协调并实时适应新目标。从规划文献综述的AI研究助手到跨组织协商物流的供应链代理，代理AI正迅速成为下一代智能应用的支柱。然而，随着这些代理在组织、地理和信任边界之间进行交互和组成工作流，对安全、标准化互操作性的需求变得至关重要。如果没有共享的身份、认证、任务交换和审计协议，代理交互容易出现碎片化、冗余，最重要的是——安全漏洞。诸如伪装、数据泄露、任务篡改和未经授权的特权升级等威胁可能在管理松散的代理生态系统中迅速出现。为解决此问题，像Google的代理到代理（A2A）规范这样的安全互操作性协议提供了一个有希望的基础。A2A提供了一个声明性、身份感知的框架，用于启用结构化、安全的代理间通信——无论是人工编写还是AI驱动的。此类协议使代理能够分享关于其能力的描述性信息，这对于促进有效的交互、发现和互操作性至关重要。接收自潜在不可信同行的交换信息必须谨慎处理并严格验证，以防止如提示注入之类的操纵技术。实现代理AI的全部潜力不仅依赖于此类协议标准，还依赖于强大的实施、严格的威胁建模和持续的安全适应。为帮助开发者构建
安全系统，我们还提供了一个包含安全A2A编码示例的代码库${ }^{1}$。

本文探讨了A2A的安全架构，通过MAESTRO威胁建模框架识别关键风险[1]，[2]，并提出缓解策略和实施最佳实践，以确保代理系统不仅智能——而且设计上值得信赖。

B. Google A2A：基础协议及其背景

由Google引入的代理到代理（A2A）协议代表了在自主代理之间实现结构化、安全和可互操作通信的重大进步。A2A的设计考虑了组合性和信任，允许代理通过标准化的AgentCards发现彼此，使用现代加密协议进行身份验证，并以声明性、可审计的方式交换任务。其架构反映了对模块化AI系统日益增长的需求，这些系统可以在组织、工具和领域之间扩展，同时适应人类和机器驱动的工作流程。A2A的出现恰逢其时，因为AI生态系统越来越向开放式的、代理驱动的应用程序转变，涉及研究、企业自动化、网络安全和科学合作等领域。位于协议工程和AI编排交叉点的A2A提供了构建可靠多代理生态系统的基础设施——在这里，互操作性和安全性不是事后考虑的问题，而是内置的基础。

C. 论文目标：分析A2A，提出改进措施，并指导安全实施

本文旨在从理论设计和实际部署两个方面考察代理到代理（A2A）协议，总体目标是实现安全和值得信赖的代理AI系统。首先，我们通过MAESTRO威胁建模框架分析A2A协议，识别多代理环境中出现的一系列风险，包括伪造、任务重放、权限提升和提示注入。在此分析基础上，我们提出有针对性的安全增强措施，以加强协议及其实施，范围从加密控制和模式强制到安全会话处理和细粒度授权。最后，本文概述了一套构建强化A2A服务器和客户端的实施最佳实践，提供有关安全通信、认证工作流、日志记录和滥用预防的指导。通过弥合协议规范和实际部署之间的差距，本文旨在为开发者、研究人员和架构师提供可行的见解，以设计默认安全的代理生态系统。

II. 文献综述

A. 代理到代理通信文献综述

代理到代理通信是多代理系统（MAS）的基础，使自主实体能够协调

并协作解决复杂问题 [3]。高效和安全的通信协议对于跨异构平台的复杂代理交互至关重要。本综述综合了代理通信的历史发展、协议、理论基础、应用、挑战和未来方向，重点在于安全的A2A多代理系统。

早期的代理通信语言（ACLs）出现在20世纪90年代初的知识共享努力（KSE）中 [4]。开创性的ACL KQML定义了一个多层次的架构，包括内容层、消息层和通信层，通过言语行为理论中的表演性来指定消息意图 [3]。基于KQML，FIPA ACL寻求更严格的语义框架，基于模态逻辑、可行性前提条件和理性效果 [5]，[6]。这些ACL基于言语行为理论、形式语义和信念-欲望-意图（BDI）模型 [7]。

关键协议包括KQML及其LISP样式的语法，以及FIPA ACL，后者通过定义的前提条件和结果细化消息结构和语义 [3]。协议定义了代理之间的交互序列，包括请求、查询、合同网、拍卖和订阅 [5]。最近的努力如Google的A2A协议旨在通过标准化任务谈判、能力共享和安全通信，在不同框架之间实现无缝互操作性 [8]。

MAS中的通信架构可以是直接的（完全、部分或动态网络）或中介的（基于促进者的、黑板系统或全局控制）[9]。多代理强化学习（MARL）允许代理使用不同的可微分、强化、监督或正则化的通信学习方法学习何时、如何以及什么进行通信 [10]。

代理通信的应用范围涵盖了企业知识管理、客户服务、供应链管理、医疗保健、智能电网、自动驾驶汽车、电子商务和灾难响应 [5]，[9]。安全、信任和反馈循环的潜在操控带来了固有的挑战。与现有标准的集成、为效率而扩展通信以及处理学习过程中的非平稳性是开放的研究领域 [4]，[5]，[11]。

未来的研究应关注多模态通信、结构化通信网络、稳健的集中组件、可解释的新兴语言以及与大型语言模型（LLMs）的集成。像A2A和MCP这样的倡议旨在实现标准化的代理通信协议收敛，尽管许多关于这种协议如何出现的问题仍未得到解答。有效的通信对于代理系统的成功至关重要。在整个进化过程中都必须考虑安全。

B. 传统PKI和传输安全

早期实现安全代理系统的尝试利用了公钥基础设施（PKI），每个代理都配备由可信证书颁发机构签名的证书和私钥。这种方法通常结合传输层的SSL/TLS

${ }^{1}$ https://github.com/kenhuangus/a2a-secure-coding-examples
保证了代理通信的加密通道 [12]。虽然PKI解决方案仍然是保障多代理消息安全的基础，但随着代理数量的增长或动态变化，往往需要复杂的证书管理。像JADE（Java Agent DEvelopment Framework）这样的代理平台试图通过集成PKI认证的安全扩展来简化这一过程 [13]。

C. SOAP、WS-Security和企业服务总线

在RESTful服务广泛采用之前，企业级代理应用通常使用SOAP作为基础协议。WS-Security套件 [14] 提供了消息级别的加密、签名和基于令牌的认证，适用于代理到服务或代理到代理的交互。这些框架虽然健壮但冗长；它们非常适合封闭的企业环境，但对于轻量级代理系统或实时AI工作流来说却负担过重。不过，它们在微服务和短暂容器尚未成为标准实践的时代确立了端到端消息保密、完整性和不可否认的基本原则。

D. OAuth 2.0、JSON Web Tokens (JWT) 和服务账户

随着向云计算和用户中心化Web应用的转变，OAuth 2.0 成为委托授权的事实标准框架 [15]。然而，OAuth 2.0 的流程主要关注互动式用户登录。这使得自主代理在没有用户干预的情况下难以安全获取和更新令牌。JSON Web Tokens (JWT) [16] 引入了一种轻量级格式，用于安全传输代理身份和权限。许多从业者采用服务账户或“机器人账户”与静态凭据来模拟代理场景中的用户角色，尽管这引入了密钥轮换和秘密管理的复杂性。

E. 零信任架构和BeyondCorp

随着多代理系统扩展到混合云环境，零信任原则强调即使对于内部请求也需连续验证身份和授权 [17]。像Google的BeyondCorp架构这样的解决方案应用了这些原则，要求每个代理或服务无论网络位置如何都使用强且可验证的凭据进行身份验证 [18]。这为“永不信任，始终验证”的政策铺平了道路，该政策与在异构网络边界上运行的自主AI代理的需求紧密契合。

F. 历史方法的局限性

历史上用于保护代理AI系统的各种方法共享了一些共同的局限性：

手动凭证管理：需要大量手动工作来配置、轮换和撤销代理凭证。
- 适应以用户为中心的模型：需要大量工作将本质上以用户为中心的安全工作流适应仅限机器的环境。
- 分散的实现：缺乏统一标准或对完全自主代理的原生云支持导致不一致的安全实现。
- 扩展挑战：随着代理数量的增长，维护安全通信的操作复杂性呈指数级增加。
这些早期创新及其局限性突显了为分布式AI建立强大身份和信任机制的根本重要性，同时也强调了需要更简单、更自动化的凭证交换流程，特别是为自主代理交互设计的流程。

III. 理解Google的A2A协议

A. 协议概述

A2A协议促进了两种主要类型代理之间的通信：

客户端代理：负责制定和传达任务。
- 远程代理：负责根据任务提供信息或采取行动。
A2A基于已建立的网络标准，包括HTTP、JSONRPC和Server-Sent Events (SSE)，优先考虑与现有系统的兼容性，同时保持以安全为主的方法。其设计遵循几个关键原则：
- 以代理为先：代理独立运作并明确交流信息，没有默认共享内存或工具。
- 符合标准：使用广泛采用的网络技术，减少开发人员的摩擦。
- 默认安全：集成的身份验证和授权措施保护敏感数据和交易。

B. 通信流程

A2A协议定义了代理之间结构化的通信流程，包括以下几个阶段：

发现：客户端通过HTTPS从目标代理的Agent Card（/.well-known/agent.json）获取以了解其功能、端点和认证要求。
启动：在使用Agent Card中指定的方法进行身份验证后，客户端通过HTTPS向服务器的a2aEndpointUrl发送JSON-RPC请求，使用以下两种方法之一：

tasks.send：用于可能同步的任务或启动不需要立即流的任务。
- tasks.sendSubscribe：用于需要流更新的长期任务，建立持久的HTTPS连接以进行服务器发送事件（SSE）。

处理与交互：

非流式（tasks.send）：服务器处理任务并在HTTP响应中返回最终的Task对象。
- 流式（tasks.sendSubscribe）：服务器通过持久连接发送SSE消息，包括TaskStatusUpdateEvent（包含更新的Task对象）和TaskArtifactUpdateEvent（包含生成的Artifact对象）。
1. 需要输入：如果需要额外输入，服务器通过响应或SSE事件发出信号，客户端使用相同的taskId发送后续输入。
1. 完成：任务进入终端状态（完成、失败或取消），通过最终响应或SSE事件进行沟通。
1. 推送通知（可选）：支持推送通知功能的服务器可以通过客户端提供的webhook URL发送异步更新，使用tasks.pushNotification.set注册。

C. 可发现性机制

A2A协议的一个核心创新是其强大的可发现性机制，它使代理能够高效定位和利用彼此的能力。

AgentCard结构：AgentCard是A2A协议可发现性机制的基础。这个结构化的JSON元数据文件位于标准路径/.well-known/agent.json处，作为一个机器可读的“名片”，描述代理的功能和接口。AgentCard包含：

基本代理标识（名称、版本、提供商）。
- A2A通信的HTTPS端点URL（a2aEndpointUrl）。
- 详细的函数目录及参数模式。
- 使用OpenAPI 3.x安全方案对象所需的认证方法（例如apiKey、http bearer、oauth2、openIdConnect）。
- 定义可用功能的能力描述。
- 详细说明可访问性的托管/DNS信息。
  这个标准位置在整个A2A生态系统中创建了一个可预测的发现模式，类似于robots.txt和sitemap.xml对网络爬虫的功能。AgentCard的JSON结构确保了既有人类可读性又便于机器解析，促进了不同代理系统之间的无缝集成。

D. 核心概念

A2A协议围绕几个基本概念构建，这些概念结构化了代理间的交互：

AgentCard：如前所述，Agent Card是一个公共的JSON元数据文件，充当机器可读的名片。Agent Cards的质量和准确性会影响发现的可靠性和安全态势广告。
A2A Server：暴露一个HTTPS端点的代理，实现A2A JSON-RPC方法。它接收请求，管理任务执行，并发送响应/更新。
A2A Client：通过向服务器的a2aEndpointUrl发送JSON-RPC请求来消费A2A服务的应用程序或另一个代理。客户端可以在启动后动态添加和移除服务器，提供灵活性以在运行时发现和利用能力。
Task：A2A协议中的基本工作单元，由客户端提供的唯一taskId标识。任务通过表示为TaskStatus值的定义生命周期进展：

TASK_STATUS_SUBMITTED
- TASK_STATUS_WORKING
- TASK_STATUS_INPUT_REQUIRED
- TASK_STATUS_COMPLETED
- TASK_STATUS_FAILED
- TASK_STATUS_CANCELED
  该协议支持短寿命的请求/响应式交互和长时间运行的异步任务，使其适合可能延续数天或数周的复杂工作流。

Message：代表通信对话中的回合，包含角色（"user"表示客户端发起，"agent"表示服务器发起）和一个或多个Part。
Part：Message或Artifact中的基本内容单元。定义的类型包括：

TextPart：用于无结构的纯文本通信。
- FilePart：用于传输文件，可通过内联Base64编码的字节内容或URI引用。
- DataPart：用于结构化的JSON数据，通过mimeType（如application/json）标识。
1. Artifact：表示代理在任务执行期间生成的输出（如文件、报告、结构化数据），也包含Part。

IV. 使用MAESTRO对基于Google A2A的代理AI应用进行威胁建模

本节将重点介绍使用Google A2A Applications构建的典型代理AI应用。我们将使用MAESTRO威胁建模框架[1]和文档[2]中记载的工作来为使用Google A2A协议构建的代理AI应用构建特定应用的威胁。下一节将深入探讨缓解这些威胁的策略。

A. MAESTRO威胁建模方法回顾

传统的威胁建模框架在应用于代理AI系统时常显得不足。这些系统可以自主做出决策、与外部工具交互并随时间学习——这些能力引入了独特的安全风险。这就是为什么我们将使用MAESTRO框架，这是一个专为代理AI设计的七层威胁建模方法。MAESTRO提供了一种更细致和主动的方法，特别适合像使用A2A构建的代理系统那样的复杂性。MAESTRO（多代理环境、安全、威胁、风险和结果）提供了一种结构化、细致和主动的方法，用于在整个代理AI生命周期中识别、评估和缓解威胁。

简而言之的MAESTRO：

扩展现有框架：建立在现有的安全框架（如STRIDE、PASTA和LINDDUN）之上，但增加了AI特定的考虑因素。
- 层次化安全：认识到必须在代理架构的每一层解决安全问题。
图1. Maestro架构 - 7层
AI特定威胁：专注于来自AI的独特威胁，如对抗性机器学习和自主决策的风险。
- 风险导向方法：根据威胁的可能性和潜在影响对其进行优先排序。
- 持续监控：强调需要持续监控和适应。
MAESTRO的七层（见图1）：

基础模型：代理使用的核AI模型（如LLM）。
数据操作：代理使用的数据，包括存储、处理和向量嵌入。
代理框架：启用代理创建和交互的软件框架和API（如A2A协议）。
部署和基础设施：承载代理和API的底层基础设施（服务器、网络、容器）。
评估和可观测性：用于监控、评估和调试代理行为的系统。
安全和合规：保护整个系统的安全控制和合规措施。
代理生态系统：多个代理交互的环境，包括市场、协作和潜在冲突。

B. 常见的A2A多代理系统威胁

利用MAESTRO威胁建模方法，我们确定了A2A多代理系统的潜在威胁，这些威胁在图2中有所说明，并在下文详细列出：

代理卡伪造：MAESTRO层：3（代理框架），4（部署&基础设施）
攻击者在一个恶意或拼写错误域名上发布伪造的/.well-known/agent.json（代理卡）。当A2A客户端进行代理发现时，可能会信任这张假卡并将敏感的A2A任务发送给流氓A2A服务器。这可能导致任务劫持、数据泄露和代理伪装。
A2A任务重播：MAESTRO层：3（代理框架），2（数据操作）如果攻击者捕获了有效的tasks/send请求并重播给A2A服务器，
同样的A2A任务可能会被执行多次。没有重播保护会导致重复或未经授权的动作。
A2A消息模式违规：MAESTRO层：2（数据操作）恶意A2A客户端可能会构造畸形的A2A消息或部分，以利用A2A服务器中薄弱的模式验证，可能引发代码注入、权限升级或拒绝服务。
A2A服务器伪装：MAESTRO层：4（部署&基础设施）通过DNS欺骗或网络攻击，对手将A2A客户端流量重定向到假的A2A服务器。攻击者可以提供伪造的代理卡和任务结果，破坏信任并窃取数据。
跨代理任务升级：MAESTRO层：7（代理生态系统），3（代理框架）恶意代理枚举可用的代理卡，并尝试通过提交带有伪造凭据的A2A任务来升级权限，违反信任边界并访问未经授权的数据。
通过A2A工件篡改工件：MAESTRO层：2（数据操作），3（代理框架）攻击者拦截或修改在A2A任务执行期间交换的工件，注入恶意内容或破坏结果。
内部威胁/通过A2A任务操纵的日志规避：MAESTRO层：6（安全&合规），3（代理框架）特权用户或代理操纵任务状态转换或禁用A2A服务器上的日志记录，隐藏未经授权的动作。
通过A2A依赖项的供应链攻击：MAESTRO层：4（部署&基础设施），6（安全&合规）在A2A服务器或客户端中存在被入侵或易受攻击的依赖项，可能会导致远程代码执行或凭据窃取。
身份验证&身份威胁：MAESTRO层：3（代理框架），4（部署&基础设施），6（安全&合规），7（代理生态系统）基于A2A的系统使用OAuth/OIDC与JWT令牌进行身份验证。威胁包括：

伪造或被盗的JWT令牌允许未经授权访问A2A任务或代理卡。
- 弱JWT验证（例如，缺少签名检查，不当的受众/发行方声明）。
- 令牌重播或使用过期令牌。
- 不安全的令牌存储或传输。

中毒代理卡：MAESTRO层：1（基础模型），2（数据操作）攻击者使用提示注入技术在代理卡字段中嵌入恶意指令（例如，AgentSkill id、名称、描述、标签或示例）。当另一个代理在发现或交互流程中自动摄取和处理此代理卡数据时，可能会执行这些隐藏指令。这利用了对代理卡内容的信任（数据操作）和使用基础模型在规划期间自动处理此内容。结果，代理的目标被劫持，敏感数据被揭示，或内部安全协议被绕过，突出了需要将代理卡内容视为不受信任的输入，需要仔细验证和清理。

图2. MAESTRO威胁建模方法识别的常见A2A多代理系统威胁列表

C. 其他安全注意事项

除了上述具体控制外，我们认为还应考虑以下其他安全方面：

必须扫描和验证供应链依赖项。（层4, 6）
- 必须制定事件响应和恢复计划。（层6, 7）
- 使用开源库进行验证、认证和监控。（层2, 3, 6）
- 偏好声明式安全配置（YAML/JSON）用于基础设施。（层4）
- 将安全测试（单元、集成、对抗性）集成到CI/CD管道中。（层3, 6）
- 在代理卡中记录所有代理能力和信任边界。（层3, 7）

V. 案例研究

我们将考虑两个案例研究来理解代理系统的威胁建模。

A. 案例研究1：协作文档处理

在此场景中，多个A2A客户端（来自不同供应商）发现并与企业A2A服务器交互以共同编辑、总结和审查文档。每个客户端检索代理卡，进行身份验证，并通过tasks/send启动A2A任务。

第1层：基础模型 - 当敌对输入嵌入A2A消息部分时可能发生提示注入攻击，导致LLM表现异常。
第2层：数据操作 - 攻击者可能通过A2A工件泄露敏感数据或篡改A2A任务状态。
第3层：代理框架 - 易受代理卡伪造和重发的tasks/send请求的影响，特别是如果接受格式错误的代理卡。
第4层：部署&基础设施 - 风险包括通过向A2A服务器发送任务导致的拒绝服务攻击，或使用被入侵的代理卡进行横向移动。
第5层：评估&可观测性 - 日志篡改或对A2A任务转换的审计不足可能导致攻击未被检测。
第6层：安全&合规 - 从代理卡中窃取凭据或通过错误配置的字段绕过策略。
第7层：代理生态系统 - 枚举代理卡和使用假卡的Sybil攻击可能破坏联合A2A部署的信任。
跨层漏洞：

被入侵的代理卡使攻击者能够劫持任务执行（第 $\rightarrow$ 第2层）。
- A2A服务器上的弱身份验证允许重放任务请求（第 $\rightarrow$ 第6层）。
- 对任务状态变更的日志记录不足使攻击未被检测（第 $\rightarrow$ 第7层）。

风险评估：

可能性：高（开放的代理卡发现，多供应商联合）
- 影响：高（数据丢失，合规违约，声誉损害）

B. 案例研究2：分布式数据分析

在此情况下，不同部门的A2A客户端通过向中央A2A服务器启动A2A任务来分析敏感数据集，并通过工件汇总结果。

第1层：基础模型 - 当敌对输入嵌入A2A消息部分时可能发生模型反转攻击，允许攻击者从LLM中提取敏感数据。
第2层：数据操作 - A2A工件中的数据中毒、未经授权的任务结果聚合、工具中毒、代理卡中毒或篡改分布式任务状态是关键威胁。
第3层：代理框架 - 易受通过tasks/send重放任务、代理卡伪造和任务或消息对象中的模式违规的影响。
第4层：部署&基础设施 - 风险包括对A2A任务流量的网络窃听和A2A服务器被攻破。
第5层：评估&可观测性 - 在任务审计日志中不足的异常检测或任务状态事件中的日志伪造可以使攻击未被检测。
第6层：安全&合规 - 由于代理卡配置错误或任务数据加密薄弱导致的数据隐私违规。
第7层：代理生态系统 - 通过代理卡枚举桥接数据孤岛和联合A2A服务器之间的策略冲突可能导致未经授权的数据流动。
跨层漏洞：

中毒的A2A工件腐蚀分析（第 $\rightarrow$ 第1层）
- 弱任务编排允许重放或劫持（第 $\rightarrow$ 第4层）
- 跨部门代理卡信任失败（第 $\rightarrow$ 第6层）

风险评估：

可能性：中高（复杂性，分布式信任）
- 影响：高（商业智能妥协，监管风险）

C. 威胁演变

随着协议、代理卡注册表和部署模式的变化，基于A2A的多代理系统的威胁也在演变。定期通过MAESTRO方法进行威胁建模并更新已识别的威胁，对于应对新的攻击技术和A2A生态系统的变化至关重要。

VI. 缓解基于A2A的多代理系统中的安全威胁

基于MAESTRO威胁建模方法，第四节-B部分概述了A2A基础MAS面临的若干潜在威胁。本节深入探讨针对这些威胁的具体安全控制和最佳实践，以及第四节-C部分的其他安全考虑。此外，它重新审视了第五节-A和B部分的案例研究，以反映这些缓解措施。

A. 应对特定威胁并增强安全

以下各小节详细介绍了针对第四节-B部分中确定的每个威胁的缓解策略，并结合了第四节-C部分的其他考虑：

解决代理卡伪造：解决第四节-B1代理卡伪造问题，攻击者在恶意域发布伪造的/.well-known/agent.json（代理卡），存在重大任务劫持、数据泄露和代理伪装风险。

缓解策略：

代理卡数字签名：使用可信证书颁发机构（CA）的数字签名确保真实性和完整性。
- 安全代理卡解析：使用HTTPS并进行证书验证，可选择使用证书固定。
- 代理卡注册和验证：使用可信注册表或目录进行验证。
- 基于声誉的信任：实施代理卡评级的声誉系统。
- 代理卡清理：在使用基础模型前清理代理卡内容。

防止A2A任务重播：解决第四节-B2缓解策略：

在每个tasks/send请求中包含唯一的随机数。
- 使用带可接受时间窗口的时间戳验证。
- 使用消息认证码（MACs）。
- 设计幂等任务。
- 实现会话管理以跟踪任务。

防止A2A消息模式违规：解决第四节-B3缓解策略：

强制严格执行模式验证。
- 清理所有来自客户端的输入。
- 使用内容安全策略（CSP）。
- 以最小权限执行任务。

防止A2A服务器伪装：解决第四节-B4缓解策略：

使用双向TLS（mTLS）。
- 使用DNSSEC防止欺骗。
- 实施证书固定。
- 应用监控和入侵检测。

防止跨代理任务升级：解决第四节-B5缓解策略：

强制执行严格的认证和授权。
- 验证每个任务的凭据。
- 实施审计日志记录。
- 遵循最小权限原则。
- 使用安全的代理卡发现。

减少通过A2A工件篡改工件的影响：解决第四节-B6缓解策略：

对工件使用数字签名。
- 应用哈希和校验和。
- 使用加密。
- 确保安全存储和传输。

防止内部威胁/通过A2A任务

操控：解决第四节-B7缓解策略：

实施基于角色的访问控制（RBAC）。
- 应用带有完整性检查的审计日志记录。
- 确保职责分离。
- 进行安全审计。
- 对特权角色要求多因素认证（MFA）。

应对通过A2A依赖项的供应链攻击：

解决第四节-B8缓解策略：

使用依赖项扫描。
- 应用依赖项固定。
- 生成和维护软件物料清单（SBOM）。
- 进行供应商安全评估。
- 遵循安全开发实践。

减少身份验证&身份威胁：解决第四节-B9

缓解策略：

应用强大的JWT验证。
- 使用安全的令牌存储。
- 实施令牌轮换。
- 使用mTLS进行API访问。
- 遵循OAuth 2.0最佳实践，包括PKCE。

减少中毒代理卡：解决第四节-B10

缓解策略：

对所有代理卡内容应用输入清理。
- 使用允许字符的白名单。
- 实施特殊字符的转义/编码。
- 强制执行内容安全策略（CSP）。
- 使用模式检查和类型约束进行验证。

B. 其他安全考虑

解决第四节-C

持续扫描和验证供应链依赖项。
- 制定和维护事件响应和恢复计划。
- 评估开源库的安全状况。
- 使用声明式安全配置（YAML/JSON）。
- 将安全测试集成到CI/CD管道中。
- 在代理卡中记录能力和信任边界。
C. 将缓解措施应用于案例研究（第五节-A和B）

案例研究1：协作文档处理：

数字签名所有文档。
- 强制执行精细的访问控制。
- 应用DLP技术。
- 在使用FM之前清理代理卡。
- 验证和认证所有任务提交。

案例研究2：分布式数据分析：

实施差异隐私。
- 使用联邦学习。
- 应用安全多方计算（SMPC）。
- 在使用前清理代理卡。
- 对工件聚合应用严格的审计控制。

VII. 安全应用程序开发策略

A. 使用当前A2A功能安全实现

这涉及到端点加固、必要时增强身份验证机制以及严格的输入/输出验证。

B. 利用增强的A2A功能实现高级安全

未来的增强或补充技术可能包括基于DID的身份验证、细粒度策略执行框架以及建立数据来源的机制。

VIII. 安全A2A部署的关键控制措施

本节涵盖安全部署基于A2A的应用程序的重要控制措施：

端点安全（TLS、网络控制）。
- 强有力的身份验证和授权。
- 全面的输入验证和清理。
- 代理能力和数据访问的最小权限原则。
- 健全的监控、日志记录和警报。
- 安全软件开发生命周期（SSDLC）实践。
- 事件响应计划和执行。
  对于安全的A2A编码示例，请参阅Github代码库 ${ }^{2}$ 。

IX. 安全实施A2A服务器

在本节中，我们将重点建议具体的A2A服务器部署安全控制，旨在增强其对潜在威胁的弹性。这些威胁的高层次概述如图3所示。

A. 保护AgentCard

AgentCard（/.well-known/agent.json）是一个关键的安全元素，因为它公开了有关您的代理功能和身份验证要求的信息。

B. 保护AgentCard

AgentCard是A2A协议中的关键安全元素，因为它公开了有关代理功能和身份验证要求的信息。

AgentCard位置和访问控制

使用适当的访问控制托管AgentCard文件（/.well-known/agent.json）。
- 实施速率限制以防止枚举攻击。
- 考虑使用内容安全头以防止未经授权的嵌入或框架。

AgentCard内容安全

仅包含有关代理功能的必要信息。
- 使用OpenAPI 3.x安全方案对象指定详细的身份验证要求。
- 定期验证AgentCard内容，确保其不泄露敏感信息。
- 保持身份验证细节准确和最新。

C. 身份验证和授权

确立服务器身份：通过可信证书颁发机构提供的数字证书认证服务器身份。使用TLS确保连接安全，使客户端在握手期间验证服务器的真实性并防范中间人攻击。
- 声明身份验证协议：在代理卡中明确声明支持的身份验证方法（如OAuth、OIDC、API密钥）。
${ }^{2}$ https://github.com/kenhuangus/a2a-secure-coding-examples
图3. 安全A2A服务器的最佳实践
验证每个请求：要求对每个传入的HTTP请求进行身份验证。确保每个请求都有正确的凭据（如令牌、证书）。利用适当的HTTP状态码（如401 Unauthorized，403 Forbidden）拒绝缺乏有效凭据的请求。

保护敏感动作和数据

建议A2A服务器通过管理对“技能”和“工具”的授权来保护敏感信息：

技能：代理需要通过代理卡宣传其技能，展示其专业知识。建议代理为每项技能授予许可或按技能授予特定范围的许可，启用不同的访问级别（如只读技能）。
- 工具：代理需要通过使用受控工具限制对敏感数据和动作的访问。因此，当代理流请求数据时，代理将根据此授予权限。

API密钥

对于较简单的实现，可以使用API密钥：

按照密码学最佳实践生成强随机API密钥。
- 实施密钥轮换策略以定期更新API密钥。
- 安全存储API密钥，切勿在客户端代码中暴露它们。

JWT身份验证

对于无状态身份验证：

实现强大的JWT验证，包括签名验证。
- 设置适当的令牌过期时间以限制令牌盗窃的影响。
- 在JWT负载中仅包含必要的声明。

D. 安全通信

传输层安全（TLS）

强制所有A2A通信使用HTTPS，并正确配置TLS（TLS1.3）。
- 定期更新TLS证书并禁用不安全的加密算法。

数据传输中的保护

确保所有A2A消息在传输过程中加密。
- 验证证书链以防止中间人攻击。
- 实施证书固定以保护关键连接。

静态数据保护

加密由您的A2A服务器存储的敏感数据。
- 安全存储来自代理交互的所有持久性数据。
- 实施适当的密钥管理以保护加密密钥。求处理

消息验证

根据A2A协议模式验证所有传入消息。
- 实施强大的输入清理以防止注入攻击。
- 在处理前验证消息格式、大小和内容类型。

URI验证

严格验证消息中包含的所有URI，以防止服务器端请求伪造（SSRF）攻击。
- 实施允许列表以接受可接受的URI方案和域。
- 避免从不受信任或用户提供的URI获取内容。

处理文件部分

在处理A2A消息中的FilePart内容时：

扫描所有上传的文件以检测恶意软件。
- 验证文件类型并强制执行大小限制。
- 安全存储上传的文件，并设置适当的访问控制。
F. 服务器实现最佳实践

错误处理和日志记录

实施全面的错误处理，避免暴露敏感信息。
- 维护详细的认证尝试、授权决策和安全事件的安全日志。
- 确保日志受到保护且无法被篡改。
- 对可疑活动实施监控和警报。
1. 速率限制和拒绝服务防护
对所有A2A端点实施速率限制以防止滥用。
- 考虑对失败的身份验证尝试使用指数退避。
- 监控并缓解针对您A2A服务器的拒绝服务攻击。

安全开发实践

遵循特定于实现语言的安全编码指南。
- 进行定期的安全代码审查。
- 将应用程序安全测试作为开发工作流的一部分。
- 保持所有依赖项更新以解决安全漏洞。

G. 协议特定的安全考虑

流式传输和SSE（服务器发送事件）

对于使用tasks/sendSubscribe和服务器发送事件（SSE）的实现：

对SSE连接实施适当的身份验证。
- 维护长期连接的安全状态管理。
- 监控并缓解资源耗尽攻击。

推送通知

当实现可选的推送通知功能时：

严格验证webhook URL以防止SSRF攻击。
- 对webhook负载实施签名验证。
- 使用HTTPS进行所有webhook通信。
- 实施具有适当退避策略的重试政策。

连接管理和滥用预防

有效的连接管理对于确保A2A服务器流式传输功能（如tasks/sendSubscribe和服务器发送事件（SSE））的可扩展性和弹性至关重要。为防止滥用和资源耗尽，服务器应强制执行以下策略：

连接配额：每个客户端或IP的连接配额，通过超时机制关闭空闲连接，并使用定期的保持活动心跳来检测和清理过时会话。
连接限制：为每个客户端ID/IP设置活跃SSE连接的硬性限制，以防止资源耗尽。
空闲超时&保持活动心跳：强制执行连接空闲超时。使用定期的保持活动心跳并终止过时会话。
压力感知流式传输：丢弃滞后客户端的非关键事件消息或应用退避策略以防止内存堆积。

H. 服务器加固

部署A2A服务器时，必须遵循安全最佳实践使用强化环境。

实施网络分割以隔离A2A服务器。
- 使用Web应用防火墙（WAF）保护免受常见网络攻击。
- 定期应用服务器组件的安全更新。
- 全面监控您的A2A服务器。
- 制定安全漏洞的事件响应程序。
- 进行定期的安全评估和渗透测试。
- 建立安全事件管理流程。

X. MCP与A2A：协同作用

代理到代理（A2A）协议和模型上下文协议（MCP）代表了互补框架，共同为复杂的代理系统创建了一个强大的基础。这些协议并非竞争标准，而是在AI交互堆栈的不同层运行，支持同级代理之间的水平协调以及与专用工具和数据源的垂直集成。表I展示了在代理AI中这两个关键协议的比较分析。

当一起部署时，这些协议创建了一个高效的分层工作流系统。一个代理最初从人类用户或其他代理通过A2A协议接收复杂任务。要成功完成此任务，该代理通常需要超出自身范围的专用能力。使用A2A的发现机制，它识别并委派特定子任务给具有相关专业知识的定制代理，例如索赔代理或租车代理。这些专用代理随后利用MCP连接到结构化数据源、计算工具或外部系统，以履行其分配的责任。已完成的工作通过A2A的结构化任务管理框架回流到代理层次结构中，从而将多个专用系统的成果无缝整合成一个连贯的解决方案交付给原始请求者。图4说明了此类用例的步骤。

索赔代理和租车代理之间的流动将利用A2A协议进行代理间的协调和任务管理，其中索赔代理（作为主A2A客户端）将通过已知的代理注册表发现租车代理的能力，进行身份验证，并委派特定的租车相关任务，附带唯一的任务ID。同时，MCP框架使每个专用代理能够通过连接到外部工具和数据库来扩展其能力——索赔代理可能访问政策数据库，而租车代理则连接到车辆可用性系统。这些框架通过允许索赔代理维持保险索赔过程的高级协调（跟踪状态更新并为用户编译最终结果），而租车代理使用MCP执行专门功能（如查询车辆库存和处理租车协议），最终提供了一个集成解决方案，使索赔处理和租车安排在统一的工作流内无缝进行。

这种架构方法促进了几个关键设计原则。它实现了功能模块化，使组织能够开发具有深厚领域
表I
A2A和MCP的比较分析

特性	Google Agent2Agent (A2A)	Anthropic Model Context Protocol (MCP)
目的	启用不同AI代理之间的互操作性	标准化AI模型/代理与外部工具/数据之间的连接
重点	代理到代理协作、委托、消息传递	和外部工具/数据代理到工具/资源访问，上下文供应
主要交互	客户代理 $\leftrightarrow$ 远程代理	MCP客户端（代理/主机） $\leftrightarrow$ MCP服务器（工具/数据）
关键机制	代理卡（发现），任务对象（生命周期），	工具、资源、提示（由服务器公开），
生态系统角色	水平集成（代理网络通信）	客户端-服务器请求垂直集成（代理能力增强）

图4. 利用A2A和MCP实现端到端代理协作
专长的专用代理。它支持组合灵活性，因为不同的代理组合可以组装起来解决各种问题。它在同级代理协调和工具级别资源访问之间保持明确的关注分离。最重要的是，它创建了一个可扩展的生态系统，新的能力可以逐步添加，而无需重新设计整个系统。

多协议架构在集成边界引入了重要的安全考虑。潜在的攻击向量可能会跨越协议边界——例如，A2A层中的身份验证漏洞可能被利用以获得未经授权的MCP访问，而通过不充分保护的MCP连接暴露的敏感信息可能会导致后续基于A2A的妥协。因此，稳健的安全策略不仅必须单独解决每个协议，还必须解决它们互联的关键接口。这种全面的方法在整个代理工作流链中确保持续保护，特别关注身份验证令牌处理、任务委派权限和索赔代理、租车代理及其各自外部系统之间的安全数据传输。[19]

XI. 结论

A. 回顾A2A的作用、安全挑战及增强潜力

代理到代理（A2A）协议在启用安全、可组合和可扩展的多代理系统方面发挥了基础性作用。通过标准化代理如何发现、认证和相互沟通，A2A促进了自主协作的新范式——从文档联合创作代理到跨分布式数据集的联邦分析。其声明性质和对显式能力（通过代理卡）的强调赋予开发人员构建信任感知、模块化工作流的能力，反映现实世界的界限和角色。然而，随着这些能力的出现，也带来了显著的安全挑战。多代理系统的分布式和动态特性引入了威胁。此外，诸如提示注入到代理卡和跨代理升级等新型风险突显了需要进行情境感知的威胁建模——如MAESTRO框架所提供的那样。为了实现基于A2A系统的全部潜力，安全性必须深入集成到协议设计和服务器实现中。从强大的加密控制和零信任代理认证到模式验证、日志完整性以及弹性的流式协议，稳健的安全控制是必不可少的。随着多代理生态系统的复杂性增加，未来A2A的增强应着重于自适应信任、持续的策略执行和默认安全配置。通过主动应对今天的威胁并预测明天的威胁，A2A可以作为智能、安全和值得信赖的代理AI应用的弹性骨干。

B. 未来安全代理协作的方向

展望未来，自主代理的安全协作取决于协议标准化的持续进步和安全最佳实践的广泛采用。

像A2A和MCP这样的倡议至关重要，但其发展必须优先考虑安全考量，可能结合从适用于代理特定场景的零信任架构中学到的经验教训。未来的工作应集中于开发标准化方法以表达和执行代理之间的复杂授权策略，建立稳健的代理身份验证和声誉管理机制，并创建安全多代理协调框架，特别是在跨越行政或信任边界时。此外，解决在代理工作流中整合大型语言模型的安全影响并确保代理通信对复杂攻击的韧性将是构建可信和可靠的多代理系统的关键。开发全面的威胁模型，如MAESTRO [1]，以及共享的安全实施指南，对于指导开发人员构建下一代安全代理AI应用至关重要。

参考文献

[1] K. Huang, “代理AI威胁建模框架：MAESTRO,” https://cloudsecurityalliance.org/blog/2025/02/06/ agentic-ai-threat-modeling-framework-maestro, 云安全联盟，2025年2月。
[2] K. Huang 和 I. Habler, “Google的A2A协议威胁建模,” https: //kenhuangus.substack.com/p/threat-modeling-googles-a2a-protocol, 2025。
[3] T. Finin, R. Fritzson, D. McKay 和 R. McEntire, “KQML作为一种代理通信语言,” 第三届国际信息和知识管理会议论文集。ACM, 1994, pp. 456-463. [在线]. 可用: https://iII.acm.org/doi/10.1145/191246.191322
[4] Y. Labrou 和 T. Finin, “代理通信语言的历史、现状和挑战,” Informatik/Informatique, 2000. [在线]. 可用: https://cbiquity.umbc.edu/paper/html/id/231/ History-State-of-the-Art-and-Challenges-for-Agent-Communication-Languages
[5] FIPA.org, “FIPA代理通信语言规范,” http: //www.fipa.org/repository/aclspecc.html, n.d.
[6] B. Chaib-draa 和 F. Dignum, “代理通信语言的趋势,” Computational Intelligence, vol. 18, no. 2, pp. 89-101, 2002. [在线]. 可用: https://onlinelibrary.wiley.com/doi/abs/10. 1111/1467-8640.00184
[7] B. Gaudou, A. Herzig, D. Longin 和 M. Nickles, “基于社会态度的FIPA代理通信语言的新语义,” ECAI 2006: 第17届欧洲人工智能大会，IOS出版社，2006，pp. 245-249. [在线]. 可用: https://www.irit.fr/ publis/LILAC/Conf_internationales/2006_Gaudou_et_al_ECAI.pdf
[8] Google Developer Blog, “宣布代理到代理协议（A2A）,” https://developers.googleblog.com/en/ a2a-a-new-era-of-agent-interoperability/, 2025。
[9] A. Dorri, S. S. Kanhere 和 R. Jurdak, “多代理系统：综述,” IEEE Access, vol. 6, pp. 28 573-28 593, 2018. [在线]. 可用: https://ieeexplore.ieee.org/document/8352646/
[10] C. Zhu, M. Dastani 和 S. Wang, “具有通信的多代理深度强化学习综述,” 自主代理和多代理系统，vol. 38, no. 1, 2024. [在线]. 可用: https://link.springer.com/article/10.1007/s10458-023-09633-6
[11] Google Developer Blog, “[具体博客文章标题 - 占位符],” [具体URL - 占位符], 2024。
[12] M. Bellare 和 P. Rogaway, “最优非对称加密,” Journal of Cryptology, vol. 9, no. 2, pp. 137-159, 1995。
[13] JADE 文档, “安全扩展,” TILab, Telecom Italia。
[14] OASIS, “Web服务安全：SOAP消息安全1.0（WS-Security 2004）,” 2004。
[15] D. Hardt, “OAuth 2.0授权框架,” IETF, RFC 6749, 2012年10月。[在线]. 可用: https://tools.ietf.org/html/rfc6749
[16] M. B. Jones, J. Bradley 和 N. Sakimura, “JSON Web Token (JWT),” IETF, RFC 7519, 2015年5月。[在线]. 可用: https: //tools.ietf.org/html/rfc7519
[17] S. Rose, O. Borchert, S. Mitchell 和 S. Connelly, “零信任架构,” 国家标准与技术研究所, NIST Special Publication 800-207, 2020年8月。[在线]. 可用: https://doi.org/10.6028/NIST.SP.800-207
[18] N. Ward 和 Y. He, “企业网络中多代理AI采用BeyondCorp,” 2019。
[19] V. S. Narajala 和 I. Habler, “模型上下文协议（MCP）的企业级安全：框架和缓解策略,” arXiv预印本 arXiv:2504.08623, 2025。[在线]. 可用: https://arxiv.org/abs/2504.08623