Multi-Agent and A2A Security: Agent-to-Agent Trust

When agents start working with other agents, trust stops being a question about one piece of software and becomes a question about a network. A planner hands work to specialist agents; an internal agent calls a partner's agent; an orchestrator fans one request out to a dozen workers. Each hand-off needs answers to the same questions: is this really the agent it claims to be, is it acting for someone who is allowed to ask, and has the request been tampered with on the way? This guide covers how to secure multi-agent systems and agent-to-agent communication, including the Agent2Agent (A2A) protocol, delegation across several hops, and how to stop one compromised agent from compromising the rest.

Key takeaways

In a multi-agent system, every agent is both a client and a potential attacker to every other. Do not trust a request because it came from "inside" the system.
Authenticate agents to each other with cryptographic identities (mutual TLS, signed tokens, workload identity), not names or network location.
Delegation must narrow at each hop. A worker agent should receive only the authority it needs for its sub-task, never the planner's full privileges.
The A2A protocol provides discovery through Agent Cards, declares authentication requirements, and supports signed Agent Cards, but it leaves authorisation decisions to you.
Design for containment: circuit breakers, independent checks between planning and execution, and the ability to isolate one agent quickly.

Common multi-agent patterns

Orchestrator and workers: a central agent breaks a goal into tasks and assigns them to specialist agents.
Pipeline: agents pass work along a sequence, such as research, draft, review and publish.
Peer collaboration: agents negotiate or exchange information directly, including across organisations (for example, a buyer's agent and a supplier's agent).
Agent as a tool: one agent is exposed to another through a tool interface, such as an MCP server that wraps an agent.

Each pattern creates trust boundaries between agents. The orchestrator pattern concentrates risk in the orchestrator; peer patterns spread it across every connection.

What goes wrong between agents

The OWASP Top 10 for Agentic Applications dedicates three risks specifically to multi-agent systems:

ASI07 Insecure Inter-Agent Communication: messages sent without encryption or sender verification, payloads modified in transit, old delegation messages replayed, and discovery poisoned so agents talk to impostors.
ASI08 Cascading Failures: a bad output from one agent (hallucinated, manipulated or poisoned) propagating through planner-to-executor chains with no validation between steps.
ASI10 Rogue Agents: an agent that drifts from its intended behaviour, or a malicious agent inserted into a workflow, which other agents then trust.

ASI03 Identity and Privilege Abuse also applies directly: worker agents inheriting the full rights of a manager agent, agents trusting internal requests without verifying the original intent, and fake agents gaining trust by name alone.

Agent-to-agent authentication

Agents should prove who they are to each other the same way workloads do, with credentials that are cryptographic, short-lived and bound to the agent:

Mutual TLS using certificates from a workload identity system such as SPIFFE/SPIRE, so both sides authenticate at connection time. See our guide to SPIFFE and SPIRE.
OAuth 2.0 access tokens issued to the calling agent for the receiving agent's audience, ideally sender-constrained (mTLS-bound or DPoP) so they cannot be replayed.
Signed agent metadata, so a caller can verify that an agent's advertised identity, endpoint and capabilities were published by the organisation that operates it.

Avoid shared secrets between agents, and never rely on an agent's display name, description or network location as proof of identity. The NHI Authentication Guide compares these methods.

Delegation across multiple hops

Consider a user who asks an orchestrator to "prepare the quarterly supplier report". The orchestrator asks a data agent to query the finance system, and a writing agent to draft the report. For each hop, the receiving system needs to know:

Who is calling (the immediate agent).
On whose behalf (the original user, and the chain of agents in between).
With what authority for this task (read supplier spend for the last quarter, not all of finance).

Patterns that support this:

Token exchange per hop. OAuth 2.0 Token Exchange (RFC 8693) lets each agent trade the token it received for a new one, scoped to the next audience and narrowed to the sub-task. Its act claim can record the acting party, and nested act claims can record a chain.
Attenuation, never amplification. Each hop may remove authority but never add it. A worker's token should be a strict subset of what the orchestrator held.
Short lifetimes tied to the task. Tokens should expire when the sub-task should be finished, not hours later.
Per-step authorisation. Check authority at each action, not only when the workflow starts; a long workflow may outlive the conditions under which it was approved (OWASP highlights this time-of-check to time-of-use gap under ASI03).

Standards for multi-hop delegation are still developing. OAuth drafts on transaction tokens and cross-domain identity chaining, and the OpenID Foundation's work on agent identity, address parts of the problem. Our Agent Identity Standards Tracker follows their status.

Securing A2A

Agent2Agent (A2A) is an open protocol for agents built on different frameworks to discover each other, exchange tasks and collaborate without exposing their internal state, memory or tools. Google introduced it in April 2025 and it has been governed under the Linux Foundation since June 2025; public release notes report version 1.0 in March 2026. Check the current specification for exact requirements.

Security-relevant elements of A2A:

Agent Cards. An agent publishes a card, commonly at a well-known URL, describing its identity, endpoints, skills and supported authentication methods. The card is how other agents decide whether and how to call it, so it is also an attack surface: a tampered card can redirect callers or carry instructions into a calling agent's context.
Signed Agent Cards. The specification supports signing Agent Cards with JSON Web Signature (RFC 7515) over a canonicalised form (JSON Canonicalization Scheme, RFC 8785). Callers should verify signatures against keys they trust before relying on a card.
Declared security schemes. Agent Cards declare the authentication schemes an agent accepts, following the shape of OpenAPI security schemes, such as OAuth 2.0, OpenID Connect or mutual TLS. Credentials themselves are obtained and presented outside the A2A messages.
Authorisation during tasks. A task can signal that additional authorisation is required before it continues, allowing step-up without abandoning the task.

What A2A does not do is decide what a calling agent is allowed to ask for. That remains your authorisation policy.

A2A controls:

Accept requests only from agents you can authenticate cryptographically, and reject unauthenticated calls.
Verify Agent Card signatures, and pin or allowlist the agents and publishing keys you trust, especially across organisations.
Treat the contents of Agent Cards, including names, descriptions and skills, as untrusted input to your model.
Authorise each task against the calling agent and the user it represents, using least privilege.
Use TLS for all transports, with anti-replay protection on messages.
Rate limit and budget per calling agent.

Designing for containment

Assume one agent in the system will eventually be manipulated or malfunction. Limit how far that spreads:

Separate planning from execution. The agent that decides what to do should not also hold the credentials to do it without an independent check.
Validate between steps. Check outputs from one agent against policy or schema before another acts on them, particularly for financial, destructive or external actions.
Isolate identities and memory. Each agent has its own identity and memory; no shared "system" credential or shared scratchpad that one agent can poison for all.
Circuit breakers and budgets. Stop workflows that exceed expected step counts, spend, data volumes or error rates.
Kill switch per agent. Be able to revoke one agent's credentials and remove it from discovery without stopping the whole system. See the AI Agent Observability and Incident Response Guide.
End-to-end traceability. Propagate a correlation ID and the delegation chain through every hop, so any action can be traced back to the original request and user.

Cross-organisation agent trust

When your agents interact with agents run by suppliers, customers or partners, treat them like any third-party integration, with extra caution because their behaviour is not fixed:

Establish trust formally: which agents, which keys, which skills, which data may be shared.
Share the minimum data needed; do not let an external agent pull from your agent's full context.
Apply contractual and technical controls equivalent to other third-party NHIs (OWASP NHI3, Vulnerable Third-Party NHI).
Monitor for changes to the partner's Agent Card and re-verify when it changes.

Common failure patterns

A single service account used by every agent in a framework, so any agent can do anything the system can.
Worker agents trusting any message from the orchestrator's network segment without authentication.
Orchestrators forwarding the user's full-scope token to every worker.
Agent discovery that accepts any agent claiming a trusted name.
No correlation between agent actions, making it impossible to reconstruct what happened after an incident.

Practitioner checklist

Give every agent its own cryptographic identity and require mutual authentication between agents.
Narrow authority at every delegation hop; never pass a planner's full privileges to workers.
Use audience-bound, short-lived, sender-constrained tokens between agents.
Verify signed Agent Cards and allowlist trusted agents and keys; treat card contents as untrusted input.
Authorise each task and each action, not just the start of a workflow.
Separate planning from execution and validate outputs between agents.
Add circuit breakers, budgets and per-agent kill switches.
Propagate correlation IDs and delegation chains for end-to-end audit.

Standards and references

Related NHI Mgmt Group resources: Agentic AI Security Guide · AI Agent Authorisation Guide · MCP Security Guide · Zero Trust for AI Agents

Securing Multi-Agent Systems and Agent-to-Agent (A2A) Trust