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 version 1.0, delegation across several hops, containment, cross-organisation trust and monitoring. It is written for architects, IAM engineers and platform teams building or approving multi-agent workflows.

Key takeaways

Every agent is a client and a potential attacker. In a multi-agent system, do not trust a request because it came from "inside"; OWASP's ASI03 calls this "Cross-Agent Trust Exploitation".
Authenticate with cryptography, not names. Use mutual TLS, sender-constrained tokens and workload identity, never display names, descriptions or network location.
Delegation must narrow at each hop. A worker should receive only the authority its sub-task needs, never the planner's full privileges, and each hop should be recorded.
A2A authenticates; you authorise. The A2A specification requires servers to authenticate every request and supports signed Agent Cards, but states that authorisation logic is "implementation-specific".
Design for containment. Separate planning from execution, validate between steps, add circuit breakers and keep a per-agent kill switch, because ASI08 cascades turn one fault into many.

Common multi-agent patterns

Each pattern creates trust boundaries between agents, but they concentrate risk in different places. CSA's MAESTRO framework gives a threat for each: in a hierarchical system the risk is "Compromise of a Higher-Level Agent to Control Subordinates", while in a distributed ecosystem it is a "Sybil Attack through Agent Impersonation".

Pattern	How it works	Where risk concentrates	First control
Orchestrator and workers	A central agent breaks a goal into tasks and assigns them to specialist agents	The orchestrator, which holds the widest authority	Per-worker scoped tokens; independent policy check before execution
Pipeline	Agents pass work along a sequence, such as research, draft, review and publish	Each hand-off, where bad output flows downstream	Schema and policy validation between stages
Peer collaboration	Agents negotiate or exchange information directly, including across organisations	Every connection, and discovery	Mutual authentication and an allowlist of peers and keys
Agent as a tool	One agent is exposed to another through a tool interface, such as an MCP server wrapping an agent	The tool host, which sees the caller's credentials	Treat the wrapped agent as a third-party tool with its own identity

The orchestrator pattern concentrates risk in one place, which makes it easier to monitor but more damaging to lose. Peer patterns spread risk across every connection, which makes discovery and key management the hard problems. Many real systems mix patterns, so model each hand-off separately. See the AI Agent Threat Modelling Guide.

What goes wrong between agents

The OWASP Top 10 for Agentic Applications 2026 dedicates three risks specifically to multi-agent systems, and a fourth applies directly to delegation.

Risk	What OWASP describes	Example from OWASP	Key mitigations (OWASP)
ASI07 Insecure Inter-Agent Communication	Exchanges that "lack proper authentication, integrity, or semantic validation", across transport, routing, discovery and semantic layers	A2A registration spoofing: a fake peer registered in discovery with a cloned schema intercepts privileged traffic	Mutual authentication with per-agent credentials; signed messages; nonces and timestamps against replay; signed agent cards
ASI08 Cascading Failures	A single fault that "propagates across autonomous agents, compounding into system-wide harm"	One faulty decision triggering many downstream agents or tasks in a short time	Separate planning and execution via an external policy engine; circuit breakers between planner and executor; rate limits
ASI10 Rogue Agents	Agents that "deviate from their intended function or authorized scope"	An agent whose individual actions look legitimate but whose combined behaviour is harmful	Signed audit logs; trust zones; kill switches and credential revocation; per-agent identity attestation
ASI03 Identity and Privilege Abuse	Exploiting "dynamic trust and delegation" to escalate access	A finance agent delegates to a query agent but passes all its permissions	Task-scoped, time-bound tokens; per-action authorisation; no privilege inheritance without re-validated intent

ASI03 also describes a time-of-check to time-of-use gap: permissions validated at the start of a workflow may "change or expire before execution". Long multi-agent workflows are where that gap opens widest. ATLAS now tracks attackers using agent-to-agent channels themselves (AML.T0118.001 Direct Agent Communication), and the Anthropic GTG-1002 Campaign 2025 showed attackers orchestrating Claude Code agents through MCP tools, with credential harvesting central to the operation.

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. OWASP's ASI07 guidance is to "use end-to-end encryption with per-agent credentials and mutual authentication".

Method	What it proves	Strengths	Watch for
Mutual TLS with workload identity (SPIFFE SVIDs)	Both ends hold a certificate for a SPIFFE ID in a trust domain	Authenticates at connection time; short-lived, automatically rotated certificates	Trust domain design; federation between domains
OAuth 2.0 access token, certificate-bound (RFC 8705)	The caller holds the private key behind the token's certificate	Audience and scope in the token; replay resistant	Needs TLS client authentication end to end
OAuth 2.0 access token with DPoP (RFC 9449)	The caller can sign proofs with the key bound to the token	Works where TLS client certificates are not practical	RFC 9449 notes stolen pre-generated proofs can be misused if the client is compromised
Signed agent metadata (signed Agent Cards)	The card was published by the holder of a trusted key	Protects discovery against tampering	Proves who published the card, not that the agent is safe
Static API keys or shared secrets	Possession of a string	Simple	Copyable, often long-lived (NHI7) and reused (NHI9); avoid between agents

SPIFFE defines an SVID as "the document with which a workload proves its identity", in X.509 or JWT form, signed by an authority in the SPIFFE ID's trust domain. Never rely on an agent's display name, description or network location as proof of identity: ASI03 lists "Synthetic Identity Injection" using unverified descriptors such as "Admin Helper". See the NHI Authentication Guide and the Cloud Workload Identity Guide.

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 identifies the current actor, and "a chain of delegation can be expressed by nesting one act claim within another". Note the limit: RFC 8693 says prior actors in nested claims "are informational only and are not to be considered in access control decisions", so the authorisation decision must rest on the top-level claims and the current actor.
Delegation, not impersonation. RFC 8693 distinguishes the two: an impersonating party "is indistinguishable" from the subject, while a delegate keeps its own identity. Prefer delegation, so logs show which agent acted. The Entra ID Actor Token Flaw 2025 shows the risk of service-to-service impersonation tokens that could not be logged, restricted or revoked.
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. ASI08's mitigations include "short-lived, task-scoped credentials for each agent run".
Per-step authorisation. Check authority at each action, not only when the workflow starts, to close the time-of-check to time-of-use gap.

Standards for multi-hop delegation are still developing. The IETF OAuth working group's Transaction Tokens draft is designed to "maintain and propagate user identity, workload identity and authorization context" through a call chain within a trusted domain, and the OAuth Identity and Authorization Chaining Across Domains draft addresses hops between trust domains; both were active Internet-Drafts at the time of writing. See the OAuth Token Exchange and Delegation Guide and the Agent Identity Standards Tracker.

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 announced it on 9 April 2025 with more than 50 technology partners, and the Linux Foundation launched the A2A project on 23 June 2025. The project changelog records version 1.0.0 on 12 March 2026 and 1.0.1 on 26 May 2026. Version 1.0 added Agent Card signature verification, mutual TLS security schemes and PKCE, and removed the deprecated implicit and password OAuth flows. Check the current specification for exact requirements.

A2A element	What the specification says	What you still decide
Transport	Production deployments "MUST use encrypted communication"; TLS 1.3 or later recommended	Certificate validation and pinning policy
Agent Card discovery	Cards at `/.well-known/agent-card.json`, in registries or by direct configuration	Which sources of cards you accept
Signed Agent Cards	Cards "MAY be digitally signed" with JWS (RFC 7515) over a JCS-canonicalised form (RFC 8785); clients "SHOULD verify at least one signature"	Which publishing keys you trust; make verification mandatory
Security schemes	Declared in the card, based on OpenAPI 3.2: API key, HTTP auth, OAuth 2.0, OpenID Connect or mutual TLS; credentials obtained out of band	Which schemes you allow; reject API keys for sensitive agents
Server authentication	Servers "MUST authenticate every incoming request"	Nothing: enforce it
Authorisation	Authorisation logic is "implementation-specific"; servers "MUST implement authorization checks on every" operation and scope results to the caller	The whole authorisation policy
In-task authorisation	`TASK_STATE_AUTH_REQUIRED` lets an agent ask the client for authorisation or approval; the state "by itself" is not authorisation	Scope, validity and revocation of what is granted
Extended Agent Card	Requires authentication; should not include internal URLs or credentials	What each caller is allowed to see

The in-task authorisation section matters for multi-hop flows. A client agent may pass an authorisation request up its own chain, and the specification warns that in-band credential exchange "can allow credentials to be passed across chains of multiple A2A agents, exposing those credentials to each agent". It recommends that such credentials be bound to the agent that originated the request.

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.
Enforce protocol versions and reject downgrades, as ASI07 recommends.
Rate limit and budget per calling agent, and log authentication failures and authorisation denials.

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. OWASP recommends separating them "via an external policy engine".
Validate between steps. Check outputs from one agent against policy or schema before another acts on them, particularly for financial, destructive or external actions. ASI07 recommends "versioned, typed message schemas with explicit per-message audiences".
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. See the AI Agent Memory Security Guide.
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, then require fresh attestation before it returns.
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.

Detection and monitoring

Containment depends on noticing. OWASP's ASI08 lists observable symptoms that make good detections: "rapid fan-out", spread beyond the original context or tenant, "oscillating retries or feedback loops between agents" and repeated identical intents. Useful signals:

Delegation anomalies: a low-privilege agent receiving higher-privilege scopes, or tokens used outside their audience or task window (ASI03 recommends monitoring for both).
Discovery changes: new or changed Agent Cards, new signing keys and new registry entries claiming a trusted name.
Protocol anomalies: downgrade attempts, unsigned cards accepted, failed signature checks and authentication failures per caller.
Behaviour against declared purpose: tool calls or data volumes outside the agent's expected profile.

Record inter-agent messages and policy decisions in tamper-evident logs bound to agent identities, as ASI08 recommends. See the AI Agent Observability and Incident Response Guide.

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, and who to call when something goes wrong.
Share the minimum data: do not let an external agent pull from your agent's full context.
Apply third-party NHI controls: contractual and technical controls equivalent to other third-party NHIs (OWASP NHI3, Vulnerable Third-Party NHI).
Watch for change: monitor the partner's Agent Card and signing keys and re-verify when they change.
Plan for the platform: if partners' agents run on a hosting platform, its deployment credentials are part of your risk. In the Smithery.ai MCP Hosting Breach 2025, one token controlled thousands of hosted servers.

See the Third-Party Access Guide.

Common failure patterns

One identity for every agent: a single service account used across a framework, so any agent can do anything the system can (NHI9).
Network location as trust: worker agents accepting any message from the orchestrator's network segment without authentication.
Full-scope token forwarding: orchestrators passing the user's full token to every worker, the "Un-scoped Privilege Inheritance" ASI03 describes.
Trust by name: discovery that accepts any agent claiming a trusted name or an unsigned card.
Impersonation where delegation was needed: downstream logs show the user, not the agent, so nobody can tell which agent acted.
No correlation: agent actions cannot be linked across hops, making reconstruction after an incident impossible.

Framework mapping

This is an indicative alignment prepared by NHI Mgmt Group, not an official mapping. IDs were checked against NIST CSWP 29 (CSF 2.0), the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls (control level) and a published ISO/IEC 27001:2022 Annex A list.

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP
Per-agent identity and mutual authentication	PR.AA-01, PR.AA-03	IA-9, IA-5	A.5.16, A.5.17, A.8.5	5, 6	ASI07; NHI9
Scoped delegation and per-step authorisation	PR.AA-05	AC-3, AC-6, AC-4	A.5.15, A.8.2, A.8.3	6	ASI03
Assertion and message integrity	PR.AA-04, PR.DS-02	SC-8, SC-23, SC-13	A.8.24, A.5.14	3	ASI07
Containment and trust zones	PR.IR-01, RS.MI-01	SC-7, AC-5, IR-4	A.8.22, A.5.26	12, 13, 17	ASI08, ASI10
Inter-agent logging and traceability	PR.PS-04, DE.CM-09, DE.AE-03	AU-2, AU-3, AU-10, SI-4	A.8.15, A.8.16	8	ASI08, ASI10
Cross-organisation agent trust	GV.SC-05, GV.SC-07, DE.CM-06	SA-9, SR-6, CA-3	A.5.19, A.5.20, A.5.22	15	NHI3

See the Zero Trust for AI Agents Guide for the architectural principles behind these controls.

Metrics that show progress

Metric	What it shows	Target direction
Agents with a unique cryptographic identity	Removal of shared and static credentials between agents	Up, towards all agents
Inter-agent calls using sender-constrained or mTLS-bound credentials	Resistance to token theft and replay	Up
Delegated tokens with a narrower scope than their parent	Attenuation at each hop	Up
Median lifetime of inter-agent tokens	Exposure window if a token leaks	Down
Agent Cards accepted without a verified signature	Exposure to discovery spoofing	Down, towards zero
Actions traceable end to end to an originating user or request	Readiness for investigation	Up
Time to isolate a single agent (revoke and remove from discovery)	Containment speed	Down

Implementation roadmap

Phase	Actions	Done when
First 30 days	Inventory multi-agent workflows and every inter-agent connection; find shared credentials and full-scope token forwarding; add correlation IDs	Every connection listed with its authentication method and owner
Days 31 to 90	Issue per-agent workload identities; move inter-agent calls to mTLS or sender-constrained tokens; introduce token exchange with narrowed scopes for the highest-risk workflow; verify Agent Card signatures	No shared secrets between agents in priority workflows; unsigned cards rejected
Days 91 to 180	External policy engine between planning and execution; circuit breakers and budgets; per-agent kill switch tested; partner agent trust agreements; detections for delegation and discovery anomalies	Kill switch exercised; metrics reported; partner keys pinned

See the Identity Governance for AI Agents Guide for ownership and review of agent identities.

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.
Prefer delegation to impersonation so logs show which agent acted.
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.
Monitor for fan-out, delegation anomalies and changes to Agent Cards and keys.

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