If you are reading this, it's probably because you've heard or read something about Agentic AI sytems(and you care about security). Just so we are on the same page, Agentic AI sytems are autonomous entities capable of perceiving their environment, making decisions, and executing actions with minimal human intervention, typically with the help of an LLM(Large Languauge Model). And as for agent-2-agent agentic ai systems, you guessed it, it means exactly what it sounds like: multi-agent interaction and interoperability. As these intelligent agents increasingly interact and compose workflows across organizational, geographical, and trust boundaries(health and legal spaces), the demand for secure, standardized interoperability becomes paramount. Without shared protocols governing identity, authentication, task exchange, and auditability, agent interactions are prone to fragmentation, redundancy, and critical security vulnerabilities such as impersonation, data exfiltration, and unauthorized privilege escalation.
As we go, I will leave short side notes translating a few things to native SWE lingua, or general lingua.
The cornerstone of modern Agent 2 Agent (A2A) security currently revolves around protocols that emphasize structured communication and identity awareness. One such foundational protocol is Google’s Agent-to-Agent (A2A) specification, which provides a declarative, identity-aware framework designed for composability and trust.
The Foundational A2A Protocol and Secure Interoperability
The A2A protocol allows autonomous agents to discover each other via standardized AgentCards [side note: kind of like a business card containing details about yourself, how to reach you and your role in the business. more on this later], authenticate using modern cryptographic protocols, and exchange tasks in a declarative, auditable manner [side note: I want to be abe to tell you what i want you to do, and i want to be able to tell when you do it]. The protocol facilitates communication between a Client Agent (formulating tasks) and a Remote Agent (acting on tasks). It is built on established web standards like HTTPS, JSON-RPC, and Server-Sent Events (SSE), prioritizing compatibility while adhering to a security-first approach.
A core mechanism is the AgentCard, a structured JSON metadata file located at the standardized path /.well-known/agent.json. This card functions as a machine-readable "business card," containing identification, the A2A endpoint URL (a2aEndpointUrl), detailed function catalogs, capability descriptions, and required authentication methods utilizing OpenAPI 3.x Security Scheme objects (e.g., oauth2, http bearer).
The standard A2A communication flow involves:
- Discovery: The client fetches the remote agent's AgentCard via HTTPS to learn its capabilities and authentication requirements. [side note: this is similar to a prefech done by web apps]
- Initiation: The client authenticates (using the method specified in the AgentCard) and sends a JSON-RPC request over HTTPS via
tasks.send(synchronous) ortasks.sendSubscribe(streaming updates using SSE). [side note: this is like sending a Bearer token in the header or X-API-Key along with your request, depending on the API specs] - Processing & Interaction: The server processes the task and returns the resulting Task object or streaming updates (TaskStatusUpdateEvent, TaskArtifactUpdateEvent).
Assessing the Agentic Threat Landscape
The autonomous nature of agentic AI required specialized security analysis, an entire system was birthed because of this. The MAESTRO framework (Multi-Agent Environment, Security, Threat, Risk, and Outcome) is often leveraged for this purpose, providing a structured, granular, and proactive methodology tailored to the complexities of systems like those built using A2A. MAESTRO recognizes that security must be addressed across seven layers, from Foundation Models (Layer 1) up to the Agent Ecosystem (Layer 7). [side note: these layer methodology is similar to the 7 network layers in a way, but for agentic ai, just in case you're familiar with that.]
The following image is a illustration of the 7 layers:
Key A2A multi-agent system threats identified through MAESTRO include:
| Threat | Description | MAESTRO Layers | Mitigation Focus |
|---|---|---|---|
| Agent Card Spoofing | An attacker publishes a forged Agent Card at a malicious domain, leading to task hijacking and data exfiltration. | 3 (Agent Frameworks), 4 (Deployment & Infrastructure) | Digital Signatures, Secure Resolution |
| Poisoned AgentCard | Prompt injection techniques are embedded within AgentCard fields (like descriptions), causing another agent processing the card to execute hidden instructions. | 1 (Foundation Model), 2 (Data Operations) | Input Sanitization, Schema Checks |
| A2A Task Replay | An attacker captures and replays a valid tasks/send request, leading to duplicate or unauthorized actions. |
3 (Agent Frameworks), 2 (Data Operations) | Nonces, Timestamp Verification, Idempotency |
| Cross-Agent Task Escalation | A malicious agent attempts to escalate privileges by submitting tasks with forged credentials, breaching trust boundaries. | 7 (Agent Ecosystem), 3 (Agent Frameworks) | Strict Authorization, Least Privilege |
If you are a software engineer or a CS student, then the threats mentioned above probalbly sound like something you've heard before, e.g spoofing, SQL injection, CSRF, e.g..
Enhancing Security and Governance: Layered Architectures
To address these vulnerabilities, robust protocols must integrate security deep within the system design right from the get-go. The goal is to develop a layered architecture that embeds governance and security across all system layers.
Zero-Trust for Agent Interaction
The principle of Zero-Trust architecture—"never trust, always verify"—is not new to software engineering and is essential for multi-agent systems, requiring continuous validation of identity and authorization for every agent, communication, and action. Implementation strategies include:
- Implementing strong authentication mechanisms, ensuring each agent has a unique, cryptographically verifiable identity.
- Applying fine-grained authorization controls so agents receive only the minimum necessary permissions for their specific tasks [side note: if you are familiar with the Principle of Least Privilege, this is exactly what it entails).
- Setting up encrypted communications end-to-end (TLS/HTTPS) to prevent eavesdropping and message tampering, complemented by integrity checks.
Now, with MAESTRO we are able to identify layers in A2A systems and the various angle of attacks by malicious users, the next obvious question would be how do we prevent these issues. The following paragraph outlines the security model thta have been agreed upon and put in place to curb these loop holes.
SAGA: Granular Access Control and Oversight
While the A2A protocol facilitates decentralized identity and interoperability, it has been noted to lack policy enforcement mechanisms and runtime mediation of agent interactions.
The SAGA (Security Architecture for Governing Agentic systems) architecture addresses this by enhancing governance and security through a Provider-mediated approach that gives users control and oversight over their agents’ lifecycles. SAGA enables users to define an Access Contact Policy (CP) for their agents, governing permissible incoming communication.
SAGA integrates with A2A by protecting Agent Cards under user-specified access control policies and encapsulating A2A messages within its secure communication layer. Key to SAGA’s security model is the use of cryptographic access control tokens. These tokens are generated by the receiving agent and encrypted using a dynamically derived shared key, providing fine-grained control over inter-agent communication and limiting the vulnerability window.
This shared key derivation relies on One-Time Keys (OTKs) obtained from the Provider, which enforces the user's Contact Policy during the initial request. The token includes an expiration timestamp and a limit on the number of permitted requests (Qmax), which allows tokens to be reused for subsequent communication without involving the centralized Provider, here bybalancing security and performance overhead.
Workflow Illustration: Secure A2A Task Delegation using SAGA/Policy Enforcement
The following diagram illustrates the flow required to establish secure communication for a delegated A2A task, incorporating the cryptographic policy enforcement mechanisms found in SAGA.
Secure Implementation: Code Controls
Secure implementation of an A2A Server requires rigorous validation of inputs, tokens, and authorization against threats like replay attacks and token misuse. Agent frameworks should apply controls such as input sanitization to all AgentCard content to mitigate poisoned AgentCard risks. Furthermore, strong token and task validation is crucial.
The following pseudo-code illustrates essential server-side logic for handling an incoming request that carries an Access Control Token, incorporating checks recommended for mitigating replay and misuse threats:
# Function to validate the Access Control Token (ACT) attached to an A2A request
def validate_access_token ( token , initiating_agent_id , request_nonce ):
"""
Validates the cryptographic token against expiry, quota, and identity.
Mitigates: A2A Task Replay, Authentication & Identity Threats, Token Misuse.
"""
# 1. Decrypt token using shared key (SDHK, derived during initial handshake)
try :
decrypted_claims = decrypt_token ( token , SDHK )
except DecryptionError :
return False , " Invalid token encryption. "
# 2. Check Expiration Time (Texpire)
if decrypted_claims [ ' Texpire ' ] < current_timestamp ():
return False , " Token has expired. "
# 3. Check Initiating Agent Identity (PACB)
# Ensures the token wasn't issued to a different agent (mitigates A5)
if decrypted_claims [ ' PACB ' ] != initiating_agent_id :
return False , " Token issued for different agent identity. "
# 4. Check Usage Quota (Qmax)
# Requires backend storage to track remaining requests against Qmax
if get_token_usage ( token ) >= decrypted_claims [ ' Qmax ' ]:
# If quota is exceeded, the token is invalid (A3)
return False , " Token usage quota exceeded. "
# 5. Check for Nonce/Task Replay (Mitigation for A2A Task Replay)
# If the request used a nonce, ensure it hasn't been seen recently.
if request_nonce and is_nonce_replayed ( request_nonce , initiating_agent_id ):
return False , " Replayed request nonce detected. "
# 6. If all checks pass, increment usage and proceed.
increment_token_usage ( token )
return True , " Token Valid. "
By adopting security frameworks like MAESTRO, layering Zero-Trust principles, and implementing specialized protocols like A2A, augmented by fine-grained control systems such as SAGA, developers can build robust and trustworthy security protocols essential for the next generation of autonomous agent systems.
Thank you for reading, and may the Force be with you.
Resources/References:
https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
https://arxiv.org/html/2504.21034v2#S3
https://a2a-protocol.org/dev/specification/
https://a2aprotocol.ai/docs/guide/a2a-protocol-specification-python
https://www.youtube.com/watch?v=56BXHCkngss
Where to find me:
Top comments (1)
I am trying to put together a full code implementation on a few security layer and their guard rails as per SAGA methodology, will share here as soon as I have it ready.