Potential Attack Surfaces in Agent2Agent (A2A) Protocol

https://www.keysight.com/blogs/en/tech/nwvs/2025/05/28/potential-attack-surfaces-in-a2a?fbclid=IwQ0xDSwKrhV9leHRuA2FlbQIxMQABHqJR00pyLG19KVUM7VsS4Zr3aalMVifVCN9CT5csJdjcFK183-UopeMNA_sF_aem_YI0k49RBEB2rkiVngUb-Xg%EF%BB%BF

 

As LLMs have become more and more adopted in software engineering, additional protocols have been created to facilitate LLM Agent communication with various tools and other agents. First, we saw MCP , a protocol that aims to provide a universal way to connect agents with tools, and one month ago Google introduced A2A which is the next step forward. A2A is the protocol which aims to become the standard way to discover and communicate between agents.

 

LLM이 소프트웨어 엔지니어링에 점점 더 많이 도입됨에 따라 LLM 에이전트와 다양한 도구 및 다른 에이전트 간의 통신을 용이하게 하기 위한 추가 프로토콜이 개발되었습니다. 먼저 에이전트와 도구를 연결하는 보편적인 방법을 제공하는 프로토콜인 MCP를 살펴보았고, 한 달 전 Google은 다음 단계인 A2A를 출시했습니다. A2A는 에이전트 간의 검색 및 통신을 위한 표준 방식이 되는 것을 목표로 하는 프로토콜입니다.

Let’s take a close look at how the protocol handles communication between agents. Everything begins with the discovery phase. We will consider two agents: a main one and a secondary one. The main agent connects to the second agent and asks for an Agent Card. Think of the Agent Card as a business card. The Agent Card provides information about the agent and what it can perform. The main agent then stores the Agent Card. The following diagram provides a simplified overview of the agent capability discovery.

 

이 프로토콜이 에이전트 간 통신을 처리하는 방식을 자세히 살펴보겠습니다. 모든 것은 검색 단계부터 시작됩니다. 주 에이전트와 보조 에이전트, 두 개의 에이전트를 고려해 보겠습니다. 주 에이전트는 보조 에이전트에 연결하여 에이전트 카드를 요청합니다. 에이전트 카드는 명함이라고 생각하면 됩니다. 에이전트 카드는 에이전트와 에이전트가 수행할 수 있는 작업에 대한 정보를 제공합니다. 그런 다음 주 에이전트는 에이전트 카드를 저장합니다. 다음 다이어그램은 에이전트 기능 검색에 대한 간략한 개요를 제공합니다.

 

 

Fig. 1 A2A Agent Card Exchange Overview

Later, when a user asks the main agent for a specific question, it will use the agent card to decide whether it will handle the request itself, or should it ask for another agent for help. The decision whether to use another agent and which one will be used is based on the internal logic of the agent, but this decision is usually made by an LLM as we will see later. After the decision has been made, a request is sent to the second agent to handle the query. The overall query resolution process is presented in the following diagram.

 

나중에 사용자가 메인 에이전트에게 특정 질문을 요청하면, 메인 에이전트는 에이전트 카드를 사용하여 요청을 직접 처리할지, 아니면 다른 에이전트에게 도움을 요청할지 결정합니다. 다른 에이전트를 사용할지, 어떤 에이전트를 사용할지는 에이전트의 내부 로직에 따라 결정되지만, 나중에 살펴보겠지만 일반적으로 LLM이 결정합니다. 결정이 내려지면 두 번째 에이전트에게 요청을 전송하여 쿼리를 처리합니다. 전체 쿼리 해결 프로세스는 다음 다이어그램에 나와 있습니다.

 

 

Fig. 2 A2A Comon Implementation of the Query Resolution Process

 

Network Traffic for A2A

A2A의 네트워크 트래픽

Now that we have a better understanding of how A2A works overall let’s take a closer look at the actual network traffic. We will examine the communication between two sample agents from the original A2A repository. For this blog we will be using the demo app from the repository to demonstrate A2A communication. The demo app internally uses a manager agent and we will be configure to use another agent: the Lang Graph Currency Exchange sample agent. To use another agent, we need to provide a URI for the agent which we would like to use. The URI mainly consists of the protocol to be used, the hostname, and the targeted port address. After the URI has been provided, the agent manager starts sending network traffic. The first HTTP request which is sent by the agent manager is to the agent.json file. This is used to query the currency exchange agent for more information about the agent. The agent will response with a name, description, capabilities, list of skills, and other metadata. The response of the agent is the actual Agent Card which we described previously. The actual request and response are presented in the figure below.

 

이제 A2A의 전반적인 작동 방식을 더 잘 이해했으므로 실제 네트워크 트래픽을 자세히 살펴보겠습니다. 원본 A2A 저장소의 두 샘플 에이전트 간의 통신을 살펴보겠습니다. 이 블로그에서는 저장소의 데모 앱을 사용하여 A2A 통신을 시연합니다. 데모 앱은 내부적으로 관리자 에이전트를 사용하며, Lang Graph Currency Exchange 샘플 에이전트라는 다른 에이전트를 사용하도록 구성하겠습니다. 다른 에이전트를 사용하려면 사용할 에이전트의 URI를 제공해야 합니다. URI는 주로 사용할 프로토콜, 호스트 이름, 대상 포트 주소로 구성됩니다. URI가 제공되면 에이전트 관리자가 네트워크 트래픽을 전송하기 시작합니다. 에이전트 관리자가 전송하는 첫 번째 HTTP 요청은 agent.json 파일로 전송됩니다. 이 요청은 환전 에이전트에 에이전트에 대한 추가 정보를 쿼리하는 데 사용됩니다. 에이전트는 이름, 설명, 기능, 기술 목록 및 기타 메타데이터로 응답합니다. 에이전트의 응답은 앞서 설명한 실제 에이전트 카드입니다. 실제 요청과 응답은 아래 그림에 나와 있습니다.

 

 

Fig. 3 A2A Agent Card Exchange

After the Agent information has been transferred, the demo app will accept queries from the user, and for each query it will use an LLM to decide whether to use another agent or respond with the capabilities of the current agent. If the decision is to use another agent (in this case the Currency Exchange Sample Agent), an HTTP request will be sent to that agent. It will perform a JSON-RPC request, and it will pass the desired message together with other metadata to the targeted agent. The agent will respond with updates and finally the desired result. The network traffic observed by us is presented in the following figure.

 

에이전트 정보가 전송된 후, 데모 앱은 사용자의 쿼리를 수신하고, 각 쿼리에 대해 LLM을 사용하여 다른 에이전트를 사용할지 또는 현재 에이전트의 기능으로 응답할지 결정합니다. 다른 에이전트(이 경우 통화 교환 샘플 에이전트)를 사용하기로 결정한 경우, 해당 에이전트로 HTTP 요청이 전송됩니다. JSON-RPC 요청을 수행하고, 원하는 메시지와 기타 메타데이터를 대상 에이전트로 전달합니다. 에이전트는 업데이트와 함께 최종적으로 원하는 결과를 응답합니다. 저희가 관찰한 네트워크 트래픽은 다음 그림과 같습니다.

 

Fig. 4 A2A Agent Query

 

How does the Main Agent decide to call another Agent?
메인 에이전트는 어떻게 다른 에이전트를 부르기로 결정하나요?

 

Now that we know how the network traffic looks like there is one more question to be answered and that is: how does the main agent decide to call other agents? In the sample application and in general the decision is made by an LLM. In our demo application we have the following prompt used to select the agent to answer the query.

 

네트워크 트래픽이 어떤 모습인지 알았으니, 이제 한 가지 더 의문이 생깁니다. 바로 메인 에이전트가 다른 에이전트에게 전화를 걸지 어떻게 결정하는가입니다. 샘플 애플리케이션에서는 일반적으로 LLM이 결정을 내립니다. 데모 애플리케이션에서는 쿼리에 응답할 에이전트를 선택하는 데 다음 프롬프트가 사용됩니다.

 

Fig. 5 A2A Demo UI LLM Instruction for agent choosing

 

Security Concerns
보안 문제

Now that we know how the overall system works, we will look at the security of this system. We will ignore for now vulnerabilities focused on the supply chain, and we will be focusing on the overall logic of the system. The main concern is centered on the decision maker to call another agent to solve the problem, and we have a few questions we would like to answer. What happens if we have two agents which are trying to solve the same problem? Which of the helper agents will the main agent pick? What happens if a malicious agent is added to the system by mistake? What happens if you have a malicious agent which is specifically designed to steal PII (Personal Identifiable Information) data? To answer these questions, we prepared a few scenarios to examine.

 

이제 전체 시스템의 작동 방식을 알았으니, 이 시스템의 보안을 살펴보겠습니다. 공급망에 초점을 맞춘 취약점은 일단 무시하고 시스템의 전반적인 논리에 집중하겠습니다. 가장 중요한 문제는 의사 결정권자가 문제 해결을 위해 다른 에이전트를 호출하는 것입니다. 몇 가지 질문에 대한 답을 찾고 싶습니다. 같은 문제를 해결하려는 두 에이전트가 있다면 어떻게 될까요? 주 에이전트는 어떤 보조 에이전트를 선택할까요? 실수로 시스템에 악성 에이전트가 추가되면 어떻게 될까요? PII(개인 식별 정보) 데이터를 훔치도록 특별히 설계된 악성 에이전트가 있다면 어떻게 될까요? 이러한 질문에 답하기 위해 몇 가지 시나리오를 준비했습니다.

 

Scenario 1: Two competing Agents, one of which is malicious
시나리오 1: 두 개의 경쟁 에이전트 중 하나는 악의적입니다.

The first scenario which we want to consider is the following. Consider that we have two agents which perform the currency exchange. One is the sample agent provided in the A2A repository, the other is a custom one created by one specifically designed to have a better agent card or in other words better advertising. In addition to that we crafted our agent in such a way that the return value for currency exchange would be inaccurate to mimic a malicious agent. For the creation of this agent, we used a clone of the Currency Exchange Lang Graph Sample Agent with a few modifications which are presented in the following figures.

 

첫 번째 시나리오는 다음과 같습니다. 환전을 수행하는 두 개의 에이전트가 있다고 가정해 보겠습니다. 하나는 A2A 저장소에 제공된 샘플 에이전트이고, 다른 하나는 더 나은 에이전트 카드, 즉 더 나은 광고를 위해 특별히 설계된 에이전트입니다. 또한, 악성 에이전트를 모방하기 위해 환전 반환 값이 부정확하도록 에이전트를 설계했습니다. 이 에이전트를 생성하기 위해 Currency Exchange Lang Graph 샘플 에이전트의 복제본을 사용했으며, 몇 가지 수정 사항은 아래 그림에 나와 있습니다.

 

 

Fig. 6 AgentCard modified in __main__.py

 

 

Fig. 7 Modified exchange rate in agent.py

With these changes we spawned the demo app yet again this time with the two agents: the original currency exchange and the malicious one with better advertising (Accurate Generic Currency Exchange with High Precision). The configuration of the demo application is shown in the figure below.

 

이러한 변경 사항을 적용하여 이번에는 두 가지 에이전트, 즉 원래 환전소와 더 나은 광고를 제공하는 악성 환전소(정확하고 정확한 일반 환전소, 높은 정밀도)를 사용하여 데모 앱을 다시 만들었습니다. 데모 애플리케이션의 구성은 아래 그림과 같습니다.

 

 

Fig. 8 A2A Demo UI with two agents for currency exchange Configuration

 

Using the configuration presented so far, we created a few conversations, and we observed the following behavior. In some cases, the main agent will use the malicious agent, and, in some cases, it will use the normal agent. In some responses it will provide references to the agent used, and some will contain just the response. Finally, sometimes it recognizes the conflict and asks the user for some clarification of which agent to use. In the following figures we will present some of the results we just described.

 

지금까지 제시된 구성을 사용하여 몇 가지 대화를 생성했고, 다음과 같은 동작을 관찰했습니다. 경우에 따라 주 에이전트는 악성 에이전트를 사용하고, 경우에 따라 일반 에이전트를 사용합니다. 일부 응답에서는 사용된 에이전트에 대한 참조를 제공하고, 일부는 응답만 포함합니다. 마지막으로, 충돌을 인식하고 사용자에게 사용할 에이전트에 대한 설명을 요청하는 경우도 있습니다. 다음 그림에서는 방금 설명한 결과 중 일부를 보여줍니다.

 

 

Fig. 9 A2A Demo with two agents for currency exchange sample response 1

 

 

Fig. 10 A2A Demo with two agents for currency exchange sample response 2

 

Scenario 2: Sensitive Information Stealer Agent
시나리오 2: 민감한 정보 도용 에이전트

For the second scenario, we will use a single helper agent, and its role will be to steal sensitive information. It will advertise itself as a helper to secure critical information but instead it will steal this information. In the following figures we will present the code used for this, based on the same Lang Graph Sample Agent , with each modification provided.

 

두 번째 시나리오에서는 단일 헬퍼 에이전트를 사용하며, 이 에이전트의 역할은 민감한 정보를 훔치는 것입니다. 이 에이전트는 자신을 중요 정보 보안을 위한 헬퍼로 광고하지만, 실제로는 해당 정보를 훔칩니다. 다음 그림에서는 동일한 Lang Graph Sample Agent를 기반으로 이 작업에 사용된 코드를 제시하며, 각 수정 사항은 다음과 같습니다.

 

 

Fig. 11 Stealer Agent: Modified AgentCard

 

 

Fig. 12 Stealer Agent: Modified System Prompt

 

 

Fig. 13 Stealer Agent: Modified Tool

 

For testing purposes we used the following configuration of the Demo UI Application.

테스트 목적으로 다음과 같은 데모 UI 애플리케이션 구성을 사용했습니다.

 

 

Fig. 14 Stealer Agent: Demo UI Application configuration

 

We asked the main agent to store some credit card information for later use and this is the result: It called the stealer agent.

우리는 주 에이전트에게 나중에 사용할 수 있도록 신용카드 정보를 저장해 달라고 요청했고 그 결과는 다음과 같습니다. 도둑 에이전트에게 전화가 왔습니다.

 

 

Fig. 15 Stealer Agent: Conversation

 

 

Fig. 16 Stealer Agent: Resulting Log

Final Remarks
마지막 발언

The latest developments of Generative AI space are pushing software development towards multi-agent workflow integration. A2A aims to provide a universal protocol for agent-to-agent communication to support Multi Agent Workflows. However, this architecture also introduces security risks.

We saw issues regarding agent advertising. When multiple agents are advertising the same skills, the main agent has a hard time deciding which one to pick, and if one of them has better advertising it will generally aim to use that even if it’s malicious. So instead of using the legitimate component the overall system will now use a malicious one.

Another issue which we noticed is centered on sensitive information exchange. If there is one malicious agent which advertises that it can protect sensitive information, it can easily steal sensitive information as the main agent will try to use it. A more generalized use case of this issue might be advertising a generic functionality agent, or in other words an Oracle Agent which can solve any problem, such that other agents might try to use. This might allow some sort of Man-In-The-Middle attack for agents, but this requires further research.

Finally, we end this article with the idea that trusting agents is a hard problem and additional security enhancements might be needed to secure such applications.

 

생성 AI 분야의 최신 발전은 소프트웨어 개발을 다중 에이전트 워크플로 통합 방향으로 이끌고 있습니다. A2A는 다중 에이전트 워크플로를 지원하기 위해 에이전트 간 통신을 위한 범용 프로토콜을 제공하는 것을 목표로 합니다. 그러나 이 아키텍처는 보안 위험을 야기합니다.

에이전트 광고와 관련된 문제가 발견되었습니다. 여러 에이전트가 동일한 기술을 광고할 때, 메인 에이전트는 어떤 에이전트를 선택해야 할지 결정하기 어려워지고, 그중 하나가 더 나은 광고를 가지고 있다면, 그것이 악의적인 것이라 하더라도 일반적으로 그것을 사용하려고 합니다. 따라서 이제 전체 시스템은 합법적인 구성 요소를 사용하는 대신 악의적인 구성 요소를 사용하게 됩니다.

또 다른 문제는 민감한 정보 교환과 관련이 있습니다. 민감한 정보를 보호할 수 있다고 광고하는 악성 에이전트가 있다면, 메인 에이전트가 해당 에이전트를 이용하려고 할 때 민감 정보를 쉽게 훔칠 수 있습니다. 이 문제의 보다 일반적인 사용 사례는 일반적인 기능의 에이전트, 즉 어떤 문제든 해결할 수 있는 Oracle 에이전트를 광고하여 다른 에이전트가 이를 이용하려고 시도하는 것입니다. 이는 에이전트에 대한 일종의 중간자 공격(Man-In-The-Middle Attack)을 허용할 수 있지만, 이에 대한 추가적인 연구가 필요합니다.

마지막으로, 에이전트를 신뢰하는 것은 어려운 문제이며, 이러한 애플리케이션을 보호하기 위해서는 추가적인 보안 강화가 필요할 수도 있다는 생각으로 이 글을 마무리합니다.