Philippians 4:13
Building A Secure Agentic AI Application Leveraging Google’s A2A Protocol 본문
Building A Secure Agentic AI Application Leveraging Google’s A2A Protocol
Ted zhao 2025. 6. 21. 17:05
Abstract
As Agentic AI systems evolve from basic workflows to complex multi-agent collaboration, robust protocols such as
Google’s Agent2Agent (A2A) become essential enablers. To foster secure adoption and ensure the reliability of
these complex interactions, understanding the secure implementation of A2A is essential.
This paper addresses this goal by providing a comprehensive security analysis centered on the A2A protocol.
We examine its fundamental elements and operational dynamics, situating it within the framework of
agent communication development.
Utilizing the MAESTRO framework, specifically designed for AI risks, we apply proactive threat modeling to
assess potential security issues in A2A deployments, focusing on aspects such as Agent Card management,
task execution integrity, and authentication methodologies.
Based on these insights, we recommend practical secure development methodologies and architectural best practices
designed to build resilient and effective A2A systems. Our analysis also explores how the synergy
between A2A and the Model Context Protocol (MCP) can further enhance secure interoperability.
This paper equips developers and architects with the knowledge and practical guidance needed
to confidently leverage the A2A protocol for building robust and secure next-generation agentic applications.
Agentic AI 시스템이 기본 워크플로에서 복잡한 다중 에이전트 협업으로 진화함에 따라,
Google의 Agent2Agent(A2A)와 같은 강력한 프로토콜이 필수적인 요소가 되고 있습니다.
이러한 복잡한 상호작용의 안전한 도입을 촉진하고 안정성을 보장하기 위해서는 A2A의 안전한 구현을 이해하는 것이 필수적입니다.
본 논문은 A2A 프로토콜을 중심으로 포괄적인 보안 분석을 제공함으로써 이러한 목표를 달성합니다.
본 논문에서는 A2A 프로토콜의 기본 요소와 운영 역학을 살펴보고, 이를 에이전트 통신 개발 프레임워크에 적용합니다.
AI 위험에 특화 설계된 MAESTRO 프레임워크를 활용하여 사전 위협 모델링을 적용하여 A2A 배포 시 발생할 수 있는 잠재적 보안 문제를 평가합니다. 특히 Agent Card 관리, 작업 실행 무결성, 인증 방법론 등에 중점을 둡니다.
이러한 통찰력을 바탕으로 복원력 있고 효과적인 A2A 시스템을 구축하도록 설계된 실용적인 보안 개발 방법론과 아키텍처 모범 사례를 제시합니다. 본 분석에서는 A2A와 모델 컨텍스트 프로토콜(MCP) 간의 시너지 효과가 어떻게 안전한 상호운용성을 더욱 향상시킬 수 있는지도 살펴봅니다.
본 논문은 개발자와 설계자에게 A2A 프로토콜을 활용하여 강력하고 안전한 차세대 에이전트 애플리케이션을 구축하는 데 필요한 지식과 실질적인 지침을 제공합니다.
Index Terms
Agentic AI, Google Agent2Agent, Agent-to-Agent Communication, A2A Protocol, Security, Threat Modeling, MAESTRO, MCP, Interoperability, Secure Development
I. INTRODUCTION
The emergence of intelligent, autonomous agents marks a pivotal shift in how AI systems are developed, deployed, and
scaled. As these agents increasingly interact across organizational and technological boundaries, the need for secure,
interoperable communication becomes critical.
This paper begins by exploring the foundation of this transformation: therise of Agentic AI and the protocols that enable it.
1. These authors contributed equally to this work.
2. This work is not related to the author’s position at Intuit
3. This work is not related to the author’s position at DistributedApp.ai
5. This work is not related to the author’s position at Google
4. This work is not related to the author’s position at Amazon Web Services.
I. 서론
지능적이고 자율적인 에이전트의 등장은 AI 시스템의 개발, 배포 및 확장 방식에 있어 중대한 변화를 의미합니다. 이러한 에이전트들이 조직 및 기술적 경계를 넘어 점점 더 상호 작용함에 따라 안전하고 상호 운용 가능한 통신의 필요성이 더욱 중요해지고 있습니다.
본 논문은 이러한 변화의 기반, 즉 에이전트 AI의 등장과 이를 가능하게 하는 프로토콜을 탐구하는 것으로 시작합니다.
1. 본 저자들은 본 연구에 동등한 기여를 했습니다.
2. 본 연구는 Intuit에서의 저자의 직책과 관련이 없습니다.
3. 본 연구는 DistributedApp.ai에서의 저자의 직책과 관련이 없습니다.
5. 본 연구는 Google에서의 저자의 직책과 관련이 없습니다.
4. 본 연구는 Amazon Web Services에서의 저자의 직책과 관련이 없습니다.
A. The Rise of Agentic AI and the Need for Secure Interoperability
As artificial intelligence systems evolve from isolated, task-specific models to dynamic, multi-agent ecosystems,
we are witnessing the emergence of Agentic AI—intelligent agents capable of autonomous
decision-making, tool use, and collaboration with other agents and humans.
These agents do not merely respond to prompts; they initiate actions, delegate subtasks,
coordinate with peers, and adapt to new goals in real time.
From AI research assistants that plan literature reviews to supply chain agents negotiating logistics
across organizations, agentic AI is rapidly becoming the backbone of next-generation intelligent applications. However,
as these agents interact and compose workflows across organizational, geographical, and trust boundaries,
the need for secure, standardized interoperability becomes paramount.
Without a shared protocol for identity, authentication, task exchange, and auditability, agent interactions are prone to
fragmentation, redundancy, and most critically—security vulnerabilities.
Threats such as impersonation, data exfiltration[1], task tampering, and unauthorized privilege escalation can
quickly arise in loosely governed agent ecosystems.
To address this, secure interoperability protocols like Google’s Agent-to-Agent (A2A) specification offer
a promising foundation. A2A provides a declarative, identity-aware framework for enabling structured,
secure communication between agents—whether human-authored or AI-powered.
Such protocols enable agents to share descriptive information about their capabilities,
which is essential for facilitating effective interaction, discovery, and interoperability. This exchanged information,
especially when received from potentially untrusted peers, must be handled with care and rigorously validated
to prevent manipulation techniques like prompt injections. Realizing the full potential of agentic AI will depend
not only on such protocol standards, but on robust implementations, rigorous threat modeling, and
continuous security adaptation. To aid developers in building secure systems, we also offer a repository containing secure A2A coding examples 1.
This paper explores the security architecture of A2A, identifies critical risks through the MAESTRO threat modeling lens
[2], [3] and proposes mitigation strategies and implementation best practices to ensure that agentic systems remain
not just intelligent—but trustworthy by design.
A. 에이전트 AI의 부상과 안전한 상호운용성의 필요성
인공지능 시스템이 고립된 작업별 모델에서 역동적인 다중 에이전트 생태계로 진화함에 따라,
우리는 자율적인 의사 결정, 도구 사용, 그리고 다른 에이전트 및 인간과의 협업이 가능한 지능형 에이전트인 에이전트 AI의 등장을 목격하고 있습니다.
이러한 에이전트는 단순히 지시에 응답하는 것이 아니라, 작업을 시작하고, 하위 작업을 위임하고,
동료와 협력하고, 새로운 목표에 실시간으로 적응합니다.
문헌 검토를 계획하는 AI 연구 보조원부터 조직 간 물류를 협상하는 공급망 에이전트까지, 에이전트 AI는 차세대 지능형 애플리케이션의 중추로 빠르게 자리 잡고 있습니다. 그러나
이러한 에이전트들이 조직, 지역 및 신뢰 경계를 넘어 상호 작용하고 워크플로를 구성함에 따라,
안전하고 표준화된 상호운용성의 필요성이 무엇보다 중요해지고 있습니다.
신원, 인증, 작업 교환 및 감사 기능을 위한 공유 프로토콜이 없으면 에이전트 상호 작용이 단편화, 중복성, 그리고 가장 중요한 보안 취약성에 취약해집니다.
사칭, 데이터 유출[1], 작업 변조, 무단 권한 상승과 같은 위협은 느슨하게 관리되는 에이전트 생태계에서 빠르게 발생할 수 있습니다.
이러한 문제를 해결하기 위해 Google의 에이전트 간(A2A) 사양과 같은 안전한 상호 운용성 프로토콜이
유망한 기반을 제공합니다. A2A는 사람이 작성했든 AI 기반이든 에이전트 간의 구조적이고 안전한 통신을 지원하는 선언적 신원 인식 프레임워크를 제공합니다.
이러한 프로토콜을 통해 에이전트는 자신의 기능에 대한 설명 정보를 공유할 수 있으며, 이는 효과적인 상호 작용, 검색 및 상호 운용성을 촉진하는 데 필수적입니다. 이러한 교환된 정보는 특히 신뢰할 수 없는 피어로부터 수신된 경우,
즉각적인 주입과 같은 조작 기법을 방지하기 위해 신중하게 처리하고 엄격한 검증을 거쳐야 합니다.
에이전트 AI의 잠재력을 최대한 발휘하려면 이러한 프로토콜 표준뿐만 아니라 견고한 구현, 엄격한 위협 모델링, 그리고
지속적인 보안 적응이 필수적입니다. 개발자의 보안 시스템 구축을 지원하기 위해 안전한 A2A 코딩 예제 1이 포함된 저장소도 제공합니다.
본 논문에서는 A2A의 보안 아키텍처를 살펴보고, MAESTRO 위협 모델링 관점을 통해 중요한 위험을 식별하며 [2], [3], 에이전트 시스템이 단순히 지능적인 것이 아니라 설계상 신뢰할 수 있도록 보장하기 위한 완화 전략과 구현 모범 사례를 제시합니다.
B. Google A2A: A Foundational Protocol and its Context
The Agent-to-Agent (A2A) protocol, introduced by Google, represents a significant step forward in enabling structured,
secure, and interoperable communication between autonomous agents.
Designed with composability and trust in mind, A2A
allows agents to discover each other via standardized Agent-
Cards, authenticate using modern cryptographic protocols,
and exchange tasks in a declarative, auditable manner. Its
architecture reflects the growing demand for modular AI
systems that can scale across organizations, tools, and domains—
while remaining adaptable to both human and machinedriven
workflows. A2A’s emergence is timely, as the AI
ecosystem increasingly shifts toward open-ended, agent-driven
applications in areas like research, enterprise automation,
cybersecurity, and scientific collaboration. Positioned at the
intersection of protocol engineering and AI orchestration,
A2A provides the plumbing needed to build reliable, multiagent
ecosystems—where interoperability and security are not
afterthoughts, but built-in foundations.
C. Paper Objectives: Analyzing A2A, Proposing Enhancements,
and Guiding Secure Implementation
This paper sets out to examine the Agent-to-Agent (A2A)
protocol in both its theoretical design and practical deployment,
with the overarching goal of enabling secure and trustworthy
agentic AI systems. First, we analyze the A2A protocol
through the lens of the MAESTRO threat modeling framework,
identifying a comprehensive set of risks that emerge in multiagent
environments—including spoofing, task replay, privilege
escalation, and prompt injection. Building on this analysis,
we propose targeted security enhancements to strengthen the
protocol and its implementations, ranging from cryptographic
controls and schema enforcement to secure session handling
and fine-grained authorization [4]. Finally, the paper outlines a
set of implementation best practices for building hardened A2A
servers and clients, offering guidance on secure communication,
authentication workflows, logging, and abuse prevention. By
bridging the gap between protocol specification and real-world
deployment, this paper aims to equip developers, researchers,
and architects with actionable insights for designing secure-bydefault
agentic ecosystems.
II. LITERATURE REVIEW
A. Agent to Agent Communication Literature Review
Agent-to-agent communication is fundamental to multi-agent
systems (MAS), enabling autonomous entities to coordinate and collaborate to solve complex problems [5]. Efficient and
secure communication protocols are critical for sophisticated
agent interactions across heterogeneous platforms. This review
synthesizes the historical development, protocols, theoretical
foundations, applications, challenges, and future directions of
agent communication, with a focus on secure A2A multi-agent
systems.
Early agent communication languages (ACLs) emerged
from the Knowledge Sharing Effort (KSE) in the early 1990s
[6]. KQML, the pioneering ACL, defined a multi-layered
architecture including content, message, and communication
layers using speech act theory through performatives to specify
message intentions [5]. Building upon KQML, the FIPA ACL
sought more rigor with a semantic framework based on modal
logic, feasibility preconditions, and rational effects [7], [8].
These ACLs are based on speech act theory, formal semantics,
and the Belief-Desire-Intention (BDI) model [9].
Key protocols include KQML with its LISP-like syntax,
and FIPA ACL which refines message structure and semantics
with defined preconditions and outcomes [5]. Protocols define
interaction sequences between agents, including request, query,
contract net, auction, and subscription [7]. Recent efforts like
Google’s A2A protocol aim to enable seamless interoperability
between AI agents across different frameworks by standardizing
task negotiation, capability sharing, and secure communication
[10].
Communication architectures in MAS can be direct (full,
partial, or dynamic networks) or mediated (facilitator-based,
blackboard systems, or global control) [11]. Multi-agent reinforcement
learning (MARL) allows agents to learn when, how,
and what to communicate using differentiable, reinforcement,
supervised, or regularized communication learning methods
[12].
Applications of agent communication range across enterprise
knowledge management, customer service, supply chain
management, healthcare, smart grids, autonomous vehicles,
e-commerce, and disaster response [7], [11]. Security, trust,
and the potential manipulation of feedback loops present
inherent challenges. Integration with existing standards, scaling
communication for efficiency, and handling non-stationarity in
learning processes are open research areas [6], [7], [13].
Future research should focus on multimodal communication,
structured communication networks, robust centralized
components, interpretable emergent languages, and integration
with LLMs. Initiatives like A2A and MCP are aiming for
protocol convergence for standardized agent communication,
although many questions regarding how this may emerge are
still unanswered. Effective communication remains crucial for
the success of agent systems. Security must be considered
throughout their evolution.
B. Traditional PKI and Transport Security
Early implementations of secure agentic systems leveraged
public key infrastructure (PKI), with each agent provisioned
a certificate and private key signed by a trusted certificate
authority. This approach, frequently combined with SSL/TLS at the transport layer, guaranteed encrypted channels for agent
communication [14]. While PKI solutions remain fundamental
to securing multi-agent messages, they often required complex
certificate management, especially as agent populations grew
or changed dynamically. Agent platforms such as JADE (Java
Agent DEvelopment Framework) attempted to simplify this via
security extensions that integrated PKI-based authentication[15].
C. SOAP, WS-Security, and Enterprise Service Buses
Prior to the widespread adoption of RESTful services,
enterprise-grade agentic applications often employed SOAP
as the foundational protocol. The WS-Security suite [16]
provided message-level encryption, signatures, and token-based
authentication for agent-to-service or agent-to-agent interactions.
These frameworks were robust but verbose; they were
well-suited to closed enterprise environments yet burdensome
for lightweight agentic systems or real-time AI workflows. Still,
they established fundamental principles of end-to-end message
confidentiality, integrity, and non-repudiation at a time when
microservices and ephemeral containers were not standard
practice.
D. OAuth 2.0, JSON Web Tokens (JWT), and Service Accounts
With the shift to cloud and user-centric web applications,
OAuth 2.0 became the de facto framework for delegated
authorization [17]. However, OAuth 2.0’s flows primarily
focus on interactive user login. This made it challenging for
autonomous agents to securely obtain and renew tokens without
user intervention. JSON Web Tokens (JWT) [18] introduced
a lightweight format for securely transmitting agent identity
and privileges. Many practitioners adopted service accounts or
“robot accounts” with static credentials to simulate user roles
in an agent scenario, though this introduced key-rotation and
secret-management complexities.
E. Zero-Trust Architectures and BeyondCorp
As multi-agent systems expanded across hybrid cloud
environments, Zero-Trust principles emphasized continuous
validation of identity and authorization, even for internal
requests [19]. Solutions like Google’s BeyondCorp architecture
applied these principles, requiring every agent or service to
authenticate with strong, verifiable credentials irrespective of
network location [20]. This paved the way for “never trust,
always verify” policies, which align closely with the needs of
autonomous AI agents that may operate across heterogeneous
network boundaries.
F. Limitations of Historical Approaches
The historical approaches to securing agentic AI systems
shared several common limitations:
• Manual Credential Management: Significant manual effort
was required to provision, rotate, and revoke agent credentials.
• Adapting User-Centric Models: Substantial work was
needed to adapt inherently user-centric security workflows
to machine-only environments.
• Fragmented Implementations: The lack of uniform standards
or cloud-native support for fully autonomous agents
resulted in inconsistent security implementations.
• Scaling Challenges: As agent populations grew, the operational
complexity of maintaining secure communication
increased exponentially.
These early innovations and their limitations highlighted the
fundamental importance of establishing robust identity and trust
mechanisms for distributed AI, while also underscoring the
need for simpler, more automated credential exchange processes
specifically designed for autonomous agent interactions.
III. UNDERSTANDING GOOGLE’S A2A PROTOCOL
A. Protocol Overview
The A2A protocol facilitates communication between two
primary types of agents:
• Client Agent: Responsible for formulating and communicating
tasks.
• Remote Agent: Responsible for acting on those tasks to
provide information or take action.
Built on established web standards including HTTP, JSONRPC,
and Server-Sent Events (SSE), A2A prioritizes compatibility
with existing systems while maintaining a security-first
approach. Its design follows several key principles:
• Agentic-first: Agents operate independently and communicate
explicitly to exchange information, without shared
memory or tools by default.
• Standards-compliant: Utilization of widely adopted web
technologies minimizes developer friction.
• Secure by default: Integrated authentication and authorization
measures safeguard sensitive data and transactions.
B. Communication Flow
The A2A protocol defines a structured communication flow
between agents that consists of several stages:
1) Discovery: The client fetches the target agent’s
Agent Card (from /.well-known/agent.json) via
HTTPS to learn about its capabilities, endpoint, and
authentication requirements.
2) Initiation: After authenticating using a method specified
in the Agent Card, the client sends a JSON-RPC request
over HTTPS to the server’s a2aEndpointUrl using
one of two methods:
• tasks.send: Used for potentially synchronous tasks
or initiating tasks where immediate streaming isn’t
required.
• tasks.sendSubscribe: Used for long-running
tasks requiring streaming updates, establishing a persistent
HTTPS connection for Server-Sent Events (SSE).
3) Processing & Interaction:
• Non-Streaming (tasks.send): The server processes
the task and returns the final Task object in the HTTP
response.
• Streaming (tasks.sendSubscribe): The
server sends SSE messages over the persistent
connection, including TaskStatusUpdateEvent
(containing the updated Task object) and
TaskArtifactUpdateEvent (containing
generated Artifact objects).
4) Input Required: If additional input is needed, the server
signals this via the response or an SSE event, and the
client sends subsequent input using the same taskId.
5) Completion: The task transitions to a terminal state
(completed, failed, or canceled), communicated via the
final response or an SSE event.
6) Push Notifications (Optional): Servers supporting
the pushNotifications capability can send asynchronous
updates to a client-provided webhook URL,
registered using tasks.pushNotification.set.
C. Discoverability Mechanism
A central innovation of the A2A protocol is its robust
discoverability mechanism, which enables agents to efficiently
locate and leverage each other’s capabilities.
1) AgentCard Structure: The AgentCard serves as the foundation
of the A2A protocol’s discoverability mechanism. This
structured JSON metadata file, located at the standardized path
/.well-known/agent.json, functions as a machinereadable
”business card” describing an agent’s capabilities
and interfaces. The AgentCard contains:
• Basic agent identification (name, version, provider).
• HTTPS endpoint URL for A2A communication
(a2aEndpointUrl).
• Detailed function catalogs with parameter schemas.
• Required authentication methods using OpenAPI 3.x Security
Scheme objects (e.g., apiKey, http bearer, oauth2,
openIdConnect).
• Capability descriptions that define available functions.
• Hosted/DNS information detailing accessibility.
This standardized location creates a predictable discovery
pattern across the entire A2A ecosystem, similar to how
robots.txt and sitemap.xml function for web crawlers.
The AgentCard’s JSON structure ensures both human readability
and machine parsability, facilitating seamless integration
between disparate agent systems.
D. Core Concepts
The A2A protocol is built around several fundamental
concepts that structure agent interactions:
1) AgentCard: As described earlier, the Agent Card is a
public JSON metadata file that acts as a machine-readable
business card. The quality and accuracy of Agent Cards can
vary, which directly impacts discovery reliability and security
posture advertisement.
2) A2A Server: An agent exposing an HTTPS endpoint that
implements the A2A JSON-RPC methods. It receives requests,
manages task execution, and sends responses/updates.
3) A2A Client: An application or another agent that consumes
A2A services by sending JSON-RPC requests to a
server’s a2aEndpointUrl. Clients can dynamically add
and remove servers after launch, offering flexibility in how
capabilities are discovered and utilized during runtime.
4) Task: The fundamental unit of work in the A2A protocol,
identified by a unique taskId provided by the client.
Tasks progress through a defined lifecycle represented by
TaskStatus values:
• TASK_STATUS_SUBMITTED
• TASK_STATUS_WORKING
• TASK_STATUS_INPUT_REQUIRED
• TASK_STATUS_COMPLETED
• TASK_STATUS_FAILED
• TASK_STATUS_CANCELED
The protocol supports both short-lived request/response style
interactions and long-running asynchronous tasks, making it
suitable for complex workflows that may extend over days or
weeks.
5) Message: Represents a turn in the communication dialogue,
containing a role (”user” for client-originated, ”agent”
for server-originated) and one or more Parts.
6) Part: The basic unit of content within a Message or
Artifact. Defined types include:
• TextPart: For unstructured plain text communication.
• FilePart: For transferring files, either via inline Base64
encoded bytesContent or a URI reference.
• DataPart: For structured JSON data, identified by a
mimeType (e.g., application/json).
7) Artifact: Represents outputs generated by the agent
during task execution (e.g., files, reports, structured data), also
containing Parts.
IV. THREAT MODELING GOOGLE A2A BASED AGENTIC AI
APPS WITH MAESTRO
This section will focus on typical agentic AI applications
built using Google A2A Applications. We will use the MAESTRO
threat modeling framework [2] and the work documented
in [3] to build application-specific threats for Agentic AI
applications built using the Google A2A protocol. The next
section will dive deep into strategies to mitigate the threats.
A. Recap of MAESTRO Threat Modeling Methodology
Traditional threat modeling frameworks often fall short when
applied to agentic AI systems. These systems can autonomously
make decisions, interact with external tools, and learn over
time – capabilities that introduce unique security risks. That’s
why we’ll use the MAESTRO framework, a seven-layer
threat modeling approach specifically designed for agentic AI.
MAESTRO offers a more granular and proactive methodology
uniquely suited for the complexities of agentic systems like
those built using A2A. MAESTRO (Multi-Agent Environment,
Security, Threat, Risk, and Outcome) provides a structured,
granular, and proactive methodology for identifying, assessing,
and mitigating threats across the entire agentic AI lifecycle.
MAESTRO in a Nutshell:
• Extends Existing Frameworks: Builds upon established
security frameworks like STRIDE, PASTA, and LINDDUN,
but adds AI-specific considerations.
• Layered Security: Recognizes that security must be addressed
at every layer of the agentic architecture.
• AI-Specific Threats: Focuses on the unique threats arising
from AI, such as adversarial machine learning and the risks
of autonomous decision-making.
• Risk-Based Approach: Prioritizes threats based on their
likelihood and potential impact.
• Continuous Monitoring: Emphasizes the need for ongoing
monitoring and adaptation.
The Seven Layers of MAESTRO (See Figure 1):
1) Foundation Models: The core AI models (e.g., LLMs)
used by the agents.
2) Data Operations: The data used by the agents, including
storage, processing, and vector embeddings.
3) Agent Frameworks: The software frameworks and APIs
that enable agent creation and interaction (like the A2A
protocol).
4) Deployment and Infrastructure: The underlying infrastructure
(servers, networks, containers) that hosts the agents
and API.
5) Evaluation and Observability: The systems used to monitor,
evaluate, and debug agent behavior.
6) Security and Compliance: The security controls and
compliance measures that protect the entire system.
7) Agent Ecosystem: The environment where multiple agents
interact, including marketplaces, collaborations, and potential
conflicts.
B. Common A2A Multi-Agent System Threats
Leveraging MAESTRO threat modeling methodology, we
identified potential threats for A2A multi-agent systems, which
are illustrated in Figure 2 and detailed below:
1) Agent Card Spoofing: MAESTRO Layers: 3 (Agent
Frameworks), 4 (Deployment & Infrastructure)
An attacker publishes a forged /.well-known/agent.json (Agent
Card) at a malicious or typosquatting domain. When an A2A
Client performs agent discovery, it may trust this fake card and
send sensitive A2A Tasks to a rogue A2A Server. This can result
in task hijacking, data exfiltration, and agent impersonation.
2) A2A Task Replay: MAESTRO Layers: 3 (Agent Frameworks),
2 (Data Operations) If an attacker captures a valid
tasks/send request and replays it to the A2A Server, the same A2A Task may be executed multiple times. Without replay
protection, this leads to duplicate or unauthorized actions.
3) A2A Message Schema Violation: MAESTRO Layer:
2 (Data Operations) A malicious A2A Client may craft
malformed A2A Messages or Parts to exploit weak schema
validation in the A2A Server, potentially causing code injection,
privilege escalation, or denial of service.
4) A2A Server Impersonation: MAESTRO Layer: 4
(Deployment & Infrastructure) Through DNS spoofing or
network attacks, an adversary redirects A2A Client traffic to a
fake A2A Server. The attacker can serve forged Agent Cards
and Task results, undermining trust and stealing data.
5) Cross-Agent Task Escalation: MAESTRO Layers: 7
(Agent Ecosystem), 3 (Agent Frameworks) A malicious agent
enumerates available Agent Cards and attempts to escalate
privileges by submitting A2A Tasks with forged credentials,
breaching trust boundaries and accessing unauthorized data.
6) Artifact Tampering via A2A Artifacts: MAESTRO Layers:
2 (Data Operations), 3 (Agent Frameworks) Attackers
intercept or modify Artifacts exchanged during A2A Task
execution, injecting malicious content or corrupting results.
7) Insider Threat/Logging Evasion via A2A Task Manipulation:
MAESTRO Layers: 6 (Security & Compliance), 3
(Agent Frameworks) A privileged user or agent manipulates
Task state transitions or disables logging on the A2A Server,
concealing unauthorized actions.
8) Supply Chain Attack via A2A Dependencies: MAESTRO
Layers: 4 (Deployment & Infrastructure), 6 (Security &
Compliance) A compromised or vulnerable dependency in the
A2A Server or Client can enable remote code execution or
credential theft.
9) Authentication & Identity Threats: MAESTRO Layers:
3 (Agent Frameworks), 4 (Deployment & Infrastructure),
6 (Security & Compliance), 7 (Agent Ecosystem) A2Abased
systems use OAuth/OIDC with JWT tokens for identity
validation. Threats include:
• Forged or stolen JWT tokens allowing unauthorized access
to A2A Tasks or Agent Cards.
• Weak JWT validation (e.g., missing signature check, improper
audience/issuer claims).
• Token replay or use of expired tokens.
• Insecure storage or transmission of tokens.
10) Poisoned AgentCard: MAESTRO Layers: 1 (Foundation
Model), 2 (Data Operations) An attacker embeds malicious
instructions using prompt injection techniques within the
fields of an AgentCard (e.g., AgentSkill id, name, descriptions,
tags or examples). When another agent automatically ingests
and processes this AgentCard data as part of its discovery
or interaction flow, it may execute these hidden instructions.
This exploits the trust placed in AgentCard content (Data
Operations) and the automated processing of this content using
the foundation model during its planning. As a result, the
agent’s goals being hijacked, sensitive data being revealed, or
internal security protocols being bypassed, highlighting the
need to treat AgentCard content as untrusted input requiring
careful validation and sanitization.
C. Additional Security Considerations
In addition to the above specific controls, we think following
additional security aspects should be considered:
• Supply chain dependencies must be scanned and verified.
(Layers 4, 6)
• Incident response and recovery plans must be in place.
(Layers 6, 7)
• Use open-source libraries for validation, authentication, and
monitoring. (Layers 2, 3, 6)
• Prefer declarative security configurations (YAML/JSON) for
infrastructure. (Layer 4)
• Integrate security testing (unit, integration, adversarial) into
CI/CD pipelines. (Layers 3, 6)
• Document all agent capabilities and trust boundaries in the
Agent Card. (Layers 3, 7)
V. CASE STUDY
We will consider two case studies to understand the threat
modeling of the agentic system.
A. Case Study 1: Collaborative Document Processing
In this scenario, multiple A2A Clients (from different
vendors) discover and interact with an enterprise A2A Server to
co-edit, summarize, and review documents. Each client retrieves
the Agent Card, authenticates, and launches A2A Tasks via
tasks/send.
1) Layer 1: Foundation Models — Prompt injection attacks
can occur when adversarial input is embedded in A2A
Message Parts, causing the LLM to behave unexpectedly.
2) Layer 2: Data Operations — Attackers may leak
sensitive data through A2A Artifacts or tamper with A2A
Task state.
3) Layer 3: Agent Frameworks — Vulnerable to Agent
Card spoofing and replayed tasks/send requests, especially
if malformed Agent Cards are accepted.
4) Layer 4: Deployment & Infrastructure — Risks include
denial-of-service attacks via flooding the A2A Server
with tasks, or lateral movement using compromised Agent
Cards.
5) Layer 5: Evaluation & Observability — Log tampering
or insufficient auditing of A2A Task transitions can let
attacks go undetected.
6) Layer 6: Security & Compliance — Credential theft
from Agent Cards or bypassing policies via misconfigured
fields.
7) Layer 7: Agent Ecosystem — Enumeration of Agent
Cards and Sybil attacks with fake cards can undermine
trust in federated A2A deployments.
1) Cross-Layer Vulnerabilities:
• Compromised Agent Card enables attacker to hijack Task
execution (Layer 3 → Layer 2).
• Weak authentication on A2A Server allows replayed Task
requests (Layer 3 → Layer 6).
• Insufficient logging of Task state changes enables undetected
attacks (Layer 5 → Layer 7).
2) Risk Assessment:
• Likelihood: High (open Agent Card discovery, multi-vendor
federation)
• Impact: High (data loss, compliance breach, reputational
damage)
B. Case Study 2: Distributed Data Analysis
Here, A2A Clients in different departments analyze sensitive
datasets by launching A2A Tasks to a central A2A Server,
aggregating results via Artifacts.
1) Layer 1: Foundation Models — Model inversion attacks
may occur when adversarial input is embedded in A2A
Message Parts, allowing attackers to extract sensitive data
from LLMs.
2) Layer 2: Data Operations — Data poisoning in A2A
Artifacts, unauthorized aggregation of Task results, tool
poisoning, agent card poisoning, or tampering with distributed
Task state are key threats.
3) Layer 3: Agent Frameworks — Susceptible to Task replay
via tasks/send, Agent Card spoofing, and schema violations
in Task or Message objects.
4) Layer 4: Deployment & Infrastructure — Risks include
network eavesdropping on A2A Task traffic and A2A
Server compromise.
5) Layer 5: Evaluation & Observability — Insufficient
anomaly detection in Task audit logs or log forgery in
Task status events can enable undetected attacks.
6) Layer 6: Security & Compliance — Data privacy violations
due to misconfigured Agent Cards or weak
encryption of Task data.
7) Layer 7: Agent Ecosystem — Data silo bridging via Agent
Card enumeration and policy conflicts between federated
A2A Servers can lead to unauthorized data flows.
1) Cross-Layer Vulnerabilities::
• Poisoned A2A Artifacts corrupting analytics (Layer 2 →
Layer 1)
• Weak Task orchestration enabling replay or hijacking (Layer
3 → Layer 4)
• Cross-department Agent Card trust failures (Layer 7→Layer
6)
2) Risk Assessment:
• Likelihood: Medium-High (complexity, distributed trust)
• Impact: High (business intelligence compromise, regulatory
risk)
C. Threat Evolution
Threats to A2A-based multi-agent systems evolve as the
protocol, Agent Card registry, and deployment patterns change.
Regular threat modeling via the MAESTRO methodology, and
updates to identified threats, are essential to address new attack
techniques and changes in the A2A ecosystem.
VI. MITIGATING SECURITY THREATS IN A2A-BASED MULTI-AGENT SYSTEMS
Drawing from the MAESTRO threat modeling methodology,
Section-IV-B outlined several potential threats facing A2Abased
MAS. This section delves into specific security controls
and best practices to address these threats, as well as additional
security considerations from Section-IV-C. Moreover, it recontextualizes
the case studies of Sections-V-A and V-B in
light of those mitigations.
A. Addressing Specific Threats and Enhancing Security
The following subsections detail mitigation strategies for
each threat identified in Section-IV-B, incorporating the additional
considerations of Section-IV-C:
1) Addressing Agent Card Spoofing: Addressing Section-
IV-B1 Agent Card Spoofing, where an attacker publishes a
forged /.well-known/agent.json (Agent Card) at a malicious domain,
poses a significant risk of task hijacking, data exfiltration,
and agent impersonation.
Mitigation Strategies:
• Digital Signatures on Agent Cards: Use digital signatures
via a trusted Certificate Authority (CA) to ensure authenticity
and integrity.
• Secure Agent Card Resolution: Use HTTPS with certificate
validation and optionally, certificate pinning.
• Agent Card Registry and Validation: Use a trusted registry
or directory for validation.
• Reputation-Based Trust: Implement a reputation system
for rating Agent Cards.
• Agent Card Sanitization: Sanitize AgentCard content before
using it with Foundational Models.
2) Preventing A2A Task Replay: Addressing Section-IV-B2
Mitigation Strategies:
• Include a unique nonce in each tasks/send request.
• Use timestamp verification with an acceptable time window.
• Use Message Authentication Codes (MACs).
• Design tasks to be idempotent.
• Implement session management to track tasks.
3) Preventing A2A Message Schema Violations: Addressing
Section-IV-B3
Mitigation Strategies:
• Enforce strict schema validation.
• Sanitize all input from clients.
• Use Content Security Policies (CSP).
• Execute tasks with least privilege.
4) Preventing A2A Server Impersonation : Addressing
Section-IV-B4
Mitigation Strategies:
• Use Mutual TLS (mTLS).
• Use DNSSEC to protect against spoofing.
• Implement certificate pinning.
• Apply monitoring and intrusion detection.
5) Preventing Cross-Agent Task Escalation: Addressing
Section-IV-B5
Mitigation Strategies:
• Enforce strict authentication and authorization.
• Validate credentials for every task.
• Implement audit logging.
• Follow least privilege principles.
• Use secure discovery for Agent Cards.
6) Mitigating Artifact Tampering via A2A Artifacts: Addressing
Section-IV-B6
Mitigation Strategies:
• Use digital signatures on artifacts.
• Apply hashing and checksums.
• Use encryption.
• Ensure secure storage and transmission.
7) Preventing Insider Threat/Logging Evasion via A2A Task
Manipulation: Addressing Section-IV-B7
Mitigation Strategies:
• Implement RBAC.
• Apply audit logging with integrity checks.
• Ensure separation of duties.
• Conduct security audits.
• Require MFA for privileged roles.
8) Addressing Supply Chain Attacks via A2A Dependencies:
Addressing Section-IV-B8
Mitigation Strategies:
• Use dependency scanning.
• Apply dependency pinning.
• Generate and maintain a Software Bill of Materials
(SBOM).
• Conduct vendor security assessments.
• Follow secure development practices.
9) Mitigating Authentication & Identity Threats: Addressing
Section-IV-B9
Mitigation Strategies:
• Apply strong JWT validation.
• Use secure token storage.
• Implement token rotation.
• Use mTLS for API access.
• Follow OAuth 2.0 best practices, including PKCE.
10) Mitigating Poisoned AgentCard: Addressing Section
IV-B10
Mitigation Strategies:
• Apply input sanitization to all AgentCard content.
• Use a whitelist of allowed characters.
• Implement escaping/encoding of special characters.
• Enforce Content Security Policy (CSP).
• Validate structure with schema checks and type constraints.
B. Additional Security Considerations
Addressing Section-IV-C
• Continuously scan and verify supply chain dependencies.
• Develop and maintain incident response and recovery plans.
• Evaluate security posture of open-source libraries.
• Use declarative security configurations (YAML/JSON).
• Integrate security testing into CI/CD pipelines.
• Document capabilities and trust boundaries in Agent Cards.
C. Applying Mitigations to Case Studies (Sections V-A and
V-B)
1) Case Study 1: Collaborative Document Processing:
• Digitally sign all documents.
• Enforce granular access control.
• Apply DLP techniques.
• Sanitize Agent Cards before using with FMs.
• Validate and authenticate all task submissions.
2) Case Study 2: Distributed Data Analysis:
• Implement differential privacy.
• Use federated learning.
• Apply secure multi-party computation (SMPC).
• Sanitize Agent Cards before use.
• Apply strict audit controls on artifact aggregation.
VII. SECURE APPLICATION DEVELOPMENT STRATEGIES
A. Securely Implementing with Current A2A Features
This involves endpoint hardening, augmenting authentication
mechanisms beyond the basic requirements if necessary, and
rigorous input/output validation.
B. Leveraging Enhanced A2A Features for Advanced Security
Future enhancements or complementary technologies could
include DID-based authentication, granular policy enforcement
frameworks, and mechanisms for establishing data provenance.
VIII. KEY CONTROL MEASURES FOR SAFE A2A
DEPLOYMENT
This section covers essential controls for deploying A2Abased
applications securely:
• Endpoint security (TLS, network controls).
• Strong authentication and authorization.
• Comprehensive input validation and sanitization.
• Principle of least privilege for agent capabilities and data
access.
• Robust monitoring, logging, and alerting.
• Secure software development lifecycle (SSDLC) practices.
• Incident response planning and execution.
For secure A2A coding examples, please refer to the Github
repository 2.
IX. IMPLEMENTING A2A SERVER SECURELY
In this section, we will focus on suggesting specific security
controls to implement for the A2A Server deployment, aiming
to enhance its resilience against potential threats. A high-level
overview of these threats is illustrated in Figure 3.
A. Securing the AgentCard
The AgentCard (/.well-known/agent.json) is a
critical security element as it exposes information about your
agent’s capabilities and authentication requirements.
B. Securing the AgentCard
The AgentCard is a critical security element in the A2A
protocol as it exposes information about an agent’s capabilities
and authentication requirements.
1) AgentCard Location and Access Controls
• Host the AgentCard file
(/.well-known/agent.json) with appropriate
access controls.
• Implement rate limiting to prevent enumeration attacks.
• Consider using content security headers to prevent
unauthorized embedding or framing.
2) AgentCard Content Security
• Include only necessary information about your agent’s
capabilities.
• Specify detailed authentication requirements using OpenAPI
3.x Security Scheme objects.
• Validate the AgentCard content regularly to ensure it
doesn’t expose sensitive information.
• Keep authentication details accurate and up to date.
C. Authentication and Authorization
• Establish Server Identity: Authenticate the server’s identity
via digital certificates provided by trustworthy Certificate
Authorities. Employ TLS to secure connections, enabling
clients to authenticate the server’s authenticity during the
handshake and mitigate man-in-the-middle attacks.
• Declare Authentication Protocols: Explicitly declare the
supported authentication methods (e.g., OAuth, OIDC, API
Keys) in the Agent Card.
• Authenticate Each Request: Require authentication for each
incoming HTTP request. Ensure that every request has proper
credentials (e.g., tokens, certificates). Reject requests that
lack the valid credentials by utilizing suitable HTTP status
codes (e.g., 401 Unauthorized, 403 Forbidden).
1) Protecting Sensitive Actions and Data
It is recommended that A2A server will protect sensitive
information by managing authorization to both ‘skills’ and
‘tools’:
• Skills: Agents are required to advertise their skills
through an Agent Card, showcasing their expertise. It
is recommended for agents to grant permission for
each skill or grant permission on a per-skill basis using
specific scopes, enabling different access levels (e.g.,
read-only skills).
• Tools: Agents are required to limit access to sensitive
data and actions by securing using controlled tools.
Therefore, when agentic flow requests data, the agent
will grant permissions based on this.
2) API Keys
For simpler implementations, API keys may be used:
• Generate strong, random API keys following cryptographic
best practices.
• Implement key rotation policies to regularly update API
keys.
• Store API keys securely and never expose them in
client-side code.
3) JWT Authentication
For stateless authentication:
• Implement robust JWT validation including signature
verification.
• Set appropriate token expiration times to limit the impact
of token theft.
• Include only necessary claims in the JWT payload.
D. Secure Communication
1) Transport Layer Security (TLS)
• Enforce HTTPS for all A2A communications with
proper TLS configuration (TLS1.3).
• Regularly renew TLS certificates and disable insecure
ciphers.
2) Data Protection in Transit
• Ensure all A2A messages are encrypted during transmission.
• Validate certificate chains to prevent man-in-the-middle
attacks.
• Consider implementing certificate pinning for critical
connections.
3) Data Protection at Rest
• Encrypt sensitive data stored by your A2A server.
• Secure storage of any persistent data from agent
interactions.
• Implement proper key management for encryption keys.
E. Input Validation and Request Processing
1) Message Validation
• Validate all incoming messages against the A2A protocol
schema.
• Implement robust input sanitization to prevent injection
attacks.
• Verify message formats, sizes, and content types before
processing.
2) URI Validation
• Strictly validate any URIs included in messages to
prevent Server-Side Request Forgery (SSRF) attacks.
• Implement allow-lists for acceptable URI schemes and
domains.
• Avoid fetching content from untrusted or user-supplied
URIs.
3) Processing File Parts
When handling FilePart content in A2A messages:
• Scan all uploaded files for malware.
• Validate file types and enforce size limits.
• Store uploaded files securely with appropriate access
controls.
F. Server Implementation Best Practices
1) Error Handling and Logging
• Implement comprehensive error handling that doesn’t
expose sensitive information.
• Maintain detailed security logs for authentication attempts,
authorization decisions, and security events.
• Ensure logs are protected and cannot be tampered with.
• Implement monitoring and alerting for suspicious activities.
2) Rate Limiting and DoS Protection
• Implement rate limiting on all A2A endpoints to prevent
abuse.
• Consider using exponential backoff for failed authentication
attempts.
• Monitor for and mitigate denial of service attacks
targeting your A2A server.
3) Secure Development Practices
• Follow secure coding guidelines specific to your implementation
language.
• Conduct regular security code reviews.
• Implement application security testing as part of your
development workflow.
• Keep all dependencies updated to address security
vulnerabilities.
G. Protocol-Specific Security Considerations
1) Streaming and SSE (Server-Sent Events)
For implementations using tasks/sendSubscribe and Server-
Sent Events (SSE):
• Implement proper authentication for SSE connections.
• Maintain secure state management for long-lived connections.
• Monitor for and mitigate resource exhaustion attacks.
2) Push Notifications
When implementing the optional push notifications capability:
• Validate webhook URLs rigorously to prevent SSRF
attacks.
• Implement signature verification for webhook payloads.
• Use HTTPS for all webhook communications.
• Implement retry policies with appropriate backoff.
3) Connection Management and Abuse Prevention
Effective connection management is essential to ensure
the scalability and resilience of A2A Server streaming
features such as tasks/sendSubscribe and Server-
Sent Events (SSE). To prevent abuse and resource exhaustion,
the server should enforce various strategies depicted
below.
4) Connection Quotas: connection quotas per client or IP,
close idle connections through timeout mechanisms, and
use periodic keep-alive pings to detect and clean up stale
sessions.
5) Connection limits: Set hard limits on the number of
active SSE connections per client ID/IP to prevent resource
exhaustion.
6) Idle Timeout & Keep-Alive Pings: Enforce connection
idle timeouts. Use periodic keep-alive pings and terminate
stale sessions.
7) Backpressure-Aware Streaming: Drop non-critical event
messages for lagging clients or apply backoff strategies
to prevent memory build-up.
H. Server Hardening
When deploying A2A server, it is essential to use a hardened
environment following security best practices.
• Implement network segmentation to isolate the A2A server.
• Use Web Application Firewalls (WAF) to protect against
common web attacks.
• Regularly apply security updates to server components.
• Implement comprehensive monitoring of your A2A server.
• Develop incident response procedures for security breaches.
• Conduct regular security assessments and penetration tests.
• Establish a security incident management process.
X. MCP AND A2A: A SYNERGY
The Agent-to-Agent (A2A) protocol and Model Context
Protocol (MCP) represent complementary frameworks that
together create a robust foundation for sophisticated agentic
systems. Rather than competing standards, these protocols
operate at different layers of the AI interaction stack, enabling
both horizontal coordination between peer agents and vertical
integration with specialized tools and data sources. Table I
presents a comparative analysis of these two critical protocols
in Agentic AI.
When deployed together, these protocols create an efficient
hierarchical workflow system. An agent initially receives a
complex task from either a human user or another agent through
A2A protocols. To successfully complete this assignment, the
agent often needs specialized capabilities beyond its own scope.
Using A2A’s discovery mechanism, it identifies and delegates
specific subtasks to purpose-built agents with relevant expertise,
such as Claim Agents or Rental Car Agents. These specialized
agents then leverage MCP to connect with structured data
sources, computational tools, or external systems required
to fulfill their assigned responsibilities. The completed work
flows back through the agent hierarchy via A2A’s structured
task management framework, enabling seamless integration
of results from multiple specialized systems into a cohesive
solution delivered to the original requestor. Figure 4 illustrates
the steps in such a use case.
The flow between a Claim Agent and Rental Car Agent
would utilize the A2A protocol for agent-to-agent coordination
and task management, where the Claim Agent (acting as the
Main A2A Client) would discover the Rental Car Agent’s
capabilities through the well-known agent registry, authenticate,
and delegate specific rental-related tasks with unique taskIds.
Meanwhile, the MCP framework enables each specialized agent
to extend its capabilities by connecting to external tools and
databases - the Claim Agent might access policy databases
while the Rental Car Agent connects to vehicle availability
systems. These frameworks complement each other by allowing
the Claim Agent to maintain high-level coordination of the
insurance claim process (tracking status updates and compiling
final results for the user) while the Rental Car Agent uses MCP
to perform specialized functions like querying vehicle inventories
and processing rental agreements, ultimately delivering
an integrated solution where claim processing and rental car
arrangements happen seamlessly within a unified workflow.
This architectural approach promotes several key design
principles. It enables functional modularity, allowing organizations
to develop specialized agents with deep domain
expertise. It supports compositional flexibility, as different agent
combinations can be assembled to address diverse problems. It
maintains clear separation of concerns between peer-level agent
coordination and tool-level resource access. Most importantly,
it creates an extensible ecosystem where new capabilities can
be added incrementally without redesigning the entire system.
The multi-protocol architecture introduces important security
considerations at integration boundaries. Potential attack vectors
may cross protocol boundaries—for example, an authentication
vulnerability in the A2A layer could be exploited to gain
unauthorized MCP access, while sensitive information exposed
through inadequately protected MCP connections might enable
subsequent A2A-based compromises. Therefore, robust security
strategies must address not only each protocol individually
but also the critical interfaces where they interconnect. This
comprehensive approach ensures continuous protection throughout
the entire agent workflow chain, with special attention to
authentication token handling, task delegation permissions, and
secure data transmission between the Claim Agent, Rental Car
Agent, and their respective external systems. [21]
XI. CONCLUSION
A. Recap of A2A’s Role, Security Challenges, and Enhancement
Potential
The Agent-to-Agent (A2A) protocol plays a foundational
role in enabling secure, composable, and scalable multi-agent
systems. By standardizing how agents discover, authenticate,
and communicate with one another, A2A facilitates a
new paradigm of autonomous collaboration—ranging from
document co-authoring agents to federated analytics across
distributed datasets. Its declarative nature and emphasis on
explicit capabilities (via AgentCards) empower developers to
build trust-aware, modular workflows that reflect real-world
boundaries and roles. However, with these capabilities come
significant security challenges. The distributed and dynamic
nature of multi-agent systems introduces threats. Furthermore,
novel risks such as prompt injection into AgentCards and
cross-agent escalation highlight the need for context-aware
threat modeling—such as that provided by the MAESTRO
framework. To realize the full potential of A2A-based systems,
security must be deeply integrated into both protocol design and
server implementation. From strong cryptographic controls and
zero-trust agent authentication to schema validation, logging
integrity, and resilient streaming protocols, robust security
controls are essential. As multi-agent ecosystems grow in
complexity, future enhancements to A2A should emphasize
adaptive trust, continuous policy enforcement, and secure-bydefault
configurations. By proactively addressing today’s threats
and anticipating tomorrow’s, A2A can serve as a resilient
backbone for intelligent, secure, and trustworthy agentic AI
applications.
B. Future Directions for Secure Agent Collaboration
Looking ahead, the secure collaboration of autonomous
agents hinges on continued progress in protocol standardization
and the widespread adoption of security best practices.
Initiatives like A2A and MCP are crucial, but their evolution
must prioritize security considerations, potentially incorporating
lessons from Zero Trust architectures adapted for agentspecific
contexts. Future work should focus on developing
standardized methods for expressing and enforcing complex
authorization policies between agents, establishing robust
mechanisms for agent identity verification and reputation
management, and creating frameworks for secure multi-agent
coordination, especially when crossing administrative or trust
boundaries. Furthermore, addressing the security implications
of integrating Large Language Models within agentic workflows
and ensuring the resilience of agent communication against
sophisticated attacks will be paramount for building trustworthy
and reliable multi-agent systems. The development of comprehensive
threat models, like MAESTRO [2], and shared
security implementation guidelines will be vital for guiding
developers in building the next generation of secure agentic
AI applications.
REFERENCES
[1] E. G. Junior, S. Clinton, C. Hughes, V. S. Narajala, and T. Holmes,
“LLM and GenAI data security best practices,” Feb. 2025. [Online].
Available: https://www.researchgate.net/publication/391204648 LLM
and GenAI Data Security Best Practices
[2] K. Huang, “Agentic AI threat modeling framework:
MAESTRO,” https://cloudsecurityalliance.org/blog/2025/02/06/
agentic-ai-threat-modeling-framework-maestro, Cloud Security Alliance,
feb 2025.
[3] K. Huang and I. Habler, “Threat modeling Google’s A2A protocol,” https:
//kenhuangus.substack.com/p/threat-modeling-googles-a2a-protocol,
2025.
[4] K. Huang, A. Sheriff, J. Sotiropoulos, R. F. Del, and
V. Lu, “Multi-agentic system threat modelling guide OWASP
GenAI security project,” Apr. 2025. [Online]. Available:
https://www.researchgate.net/publication/391204915 Multi-Agentic
system Threat Modelling Guide OWASP GenAI Security Project
[5] T. Finin, R. Fritzson, D. McKay, and R. McEntire, “KQML
as an agent communication language,” in Proceedings of the
Third International Conference on Information and Knowledge
Management. ACM, 1994, pp. 456–463. [Online]. Available:
https://dl.acm.org/doi/10.1145/191246.191322
[6] Y. Labrou and T. Finin, “History, state of the art and challenges
for agent communication languages,” Informatik/Informatique,
2000. [Online]. Available: https://ebiquity.umbc.edu/paper/html/id/231/
History-State-of-the-Art-and-Challenges-for-Agent-Communication-Languages
[7] FIPA.org, “FIPA agent communication language specifications,” http:
//http://www.fipa.org/repository/aclspecs.html, n.d.
[8] B. Chaib-draa and F. Dignum, “Trends in agent communication
language,” Computational Intelligence, vol. 18, no. 2, pp. 89–101,
2002. [Online]. Available: https://onlinelibrary.wiley.com/doi/abs/10.
1111/1467-8640.00184
[9] B. Gaudou, A. Herzig, D. Longin, and M. Nickles, “A new semantics
for the FIPA agent communication language based on social attitudes,”
in ECAI 2006: 17th European Conference on Artificial Intelligence.
IOS Press, 2006, pp. 245–249. [Online]. Available: https://www.irit.fr/
publis/LILAC/Conf internationales/2006 Gaudou et al ECAI.pdf
[10] Google Developer Blog, “Announcing the agent2agent
protocol (A2A),” https://developers.googleblog.com/en/
a2a-a-new-era-of-agent-interoperability/, 2025.
[11] A. Dorri, S. S. Kanhere, and R. Jurdak, “Multi-agent systems: A survey,”
IEEE Access, vol. 6, pp. 28 573–28 593, 2018. [Online]. Available:
https://ieeexplore.ieee.org/document/8352646/
[12] C. Zhu, M. Dastani, and S. Wang, “A survey of multi-agent deep
reinforcement learning with communication,” Autonomous Agents
and Multi-Agent Systems, vol. 38, no. 1, 2024. [Online]. Available:
https://link.springer.com/article/10.1007/s10458-023-09633-6
[13] Google, “Google developer blog,” 2024.
[14] M. Bellare and P. Rogaway, “Optimal asymmetric encryption,” Journal
of Cryptology, vol. 9, no. 2, pp. 137–159, 1995.
[15] JADE Documentation, “Security extensions,” TILab, Telecom Italia.
[16] OASIS, “Web services security: SOAP message security 1.0 (WS-Security
2004),” 2004.
[17] D. Hardt, “The OAuth 2.0 authorization framework,” IETF, RFC 6749,
October 2012. [Online]. Available: https://tools.ietf.org/html/rfc6749
[18] M. B. Jones, J. Bradley, and N. Sakimura, “JSON web token
(JWT),” IETF, RFC 7519, May 2015. [Online]. Available: https:
//tools.ietf.org/html/rfc7519
[19] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust
architecture,” National Institute of Standards and Technology, NIST
Special Publication 800-207, August 2020. [Online]. Available:
https://doi.org/10.6028/NIST.SP.800-207
[20] N. Ward and Y. He, “Adopting BeyondCorp for multi-agent AI in
enterprise networks,” 2019.
[21] V. S. Narajala and I. Habler, “Enterprise-Grade Security for
the Model Context Protocol (MCP): Frameworks and Mitigation
Strategies,” arXiv preprint arXiv:2504.08623, 2025. [Online]. Available:
https://arxiv.org/abs/2504.08623
