Agent-to-Agent Authentication in Multi-Agent Systems

Q: How do AI agents authenticate to each other in a multi-agent system?

Properly, in two layers. The first is workload identity: every agent instance gets its own cryptographic identity — in mature deployments a SPIFFE identity delivered as an X.509 or JWT SVID, issued by a platform attestor and rotated automatically — and agent-to-agent connections run over mutual TLS derived from those identities. That answers "is the process on the other end of this connection really the billing agent?" without shared secrets or network-location trust. The second layer is delegated authority: the receiving agent must know not just who is calling but on whose behalf and with what scope. That is carried by an OAuth 2.0 Token Exchange (RFC 8693) token in which the subject remains the originating user, the act claim records each delegating agent in the chain, the scope is narrowed to the specific sub-task, and the expiry is short — minutes, not hours. A2A-compliant agents additionally declare which authentication schemes they accept in a signed Agent Card, and clients must authenticate using one of those declared schemes. What is never acceptable as authentication: a fleet-wide shared API key, the user's original bearer token forwarded down the chain, arrival on a "trusted" queue or VPC, or an identity claim written in the message body for the model to read. Identity must come from the transport and the token, enforced by infrastructure the model cannot override.

Q: What is agent impersonation and why is it the top threat in multi-agent architectures?

Agent impersonation is any attack where a process successfully claims to be an agent it is not — a rogue workload claiming to be the "billing agent" to receive tasks and data intended for it, a lookalike agent registered into a discovery registry, or a tampered Agent Card that redirects capability discovery to an attacker endpoint. It is the top threat because multi-agent systems concentrate privilege in exactly the places impersonation targets: agents routinely hold standing credentials to databases, payment systems and internal APIs, and other agents send them sensitive context as a matter of course. If your agents trust each other based on queue names, IP ranges, or a shared API key, then impersonation requires only reaching the transport — no exploit needed. The defence is layered: per-agent workload identity with mutual TLS makes claiming another agent's identity require compromising its key material rather than just its network; cryptographically signed Agent Cards, verified against governed keys on every resolve, make discovery-metadata poisoning detectable; and registry governance with fast revocation limits how long a compromised or lookalike registration survives. A useful test: if the audit log of a sensitive action cannot distinguish which specific agent instance performed it and prove that identity cryptographically, impersonation would be invisible in your system, which means you must assume it is happening.

Q: Does the A2A protocol handle agent identity and authentication?

Partially and deliberately so. The A2A specification — donated by Google to the Linux Foundation in 2025 and at version 1.0 in 2026 — standardises how agents declare authentication requirements, not how identity is provisioned. An Agent Card lists the security schemes the agent supports (API key, HTTP auth, OAuth2, OpenID Connect, mutual TLS), and clients must authenticate via a declared scheme; the spec also defines Agent Card signing with canonicalisation and verification requirements so discovery metadata can be trusted, and mandates security for push-notification webhooks. What A2A explicitly leaves out of scope is the hard part: how an agent obtains credentials in the first place (out of band, by design, so it can integrate with existing enterprise identity infrastructure), how a user's authority is carried through a multi-hop delegation chain, how one agent proves to a third party what a second agent asked of it, and how trust is established across organisational boundaries. That is a reasonable protocol design decision — the same one TLS made by not solving authorization — but it means "we adopted A2A" addresses transport authentication and discovery integrity only. The delegation chain, workload identity issuance, replay protection semantics, and cross-org federation still have to be architected, typically with SPIFFE for workload identity and RFC 8693 token exchange for delegation.

Q: What is delegation laundering in multi-agent systems?

Delegation laundering is the escalation pattern where a low-privilege agent achieves a high-privilege outcome by routing its request through a higher-privileged agent, and the privileged agent cannot tell the difference between a legitimate hand-off and an escalation because no delegation context travels with the request. It is the multi-agent form of the classic confused-deputy problem. The mechanics are mundane: a planner agent that can only read data sends the operations agent a task saying "delete the records for tenant 4491"; the operations agent holds standing delete privileges and, seeing a well-formed task on a trusted channel, executes it under its own authority. The user's original scope, the intermediate agent's actual privileges, and the question of whether anyone in the chain was authorised for a delete have all been laundered away — reduced to natural-language prose that the receiving agent takes on faith. The defence is to make authority explicit and cryptographic at every hop: OAuth 2.0 Token Exchange (RFC 8693) produces per-hop tokens where the subject remains the originating user, an act claim chain records every delegating agent, and scope narrows monotonically — a delegation can only ever carry equal or less authority than the token it was exchanged from. The receiving agent then enforces mechanically: no valid delegated token with a scope covering this action means no execution, regardless of how plausible the task prose sounds. Combined with full-chain audit logging, laundering becomes both preventable and detectable.

Q: Why shouldn't agents forward the user's bearer token to other agents?

Because forwarding a bearer token is delegation without narrowing, and delegation without narrowing is escalation waiting for an incident. When agent A hands the user's original access token to agent B, four bad properties follow. First, scope: B now wields the user's full authority — every API, every resource the token can reach — when its sub-task needed perhaps one scope on one object. Second, indistinguishability: to every resource server, B is now indistinguishable from A or from the user's own client; the audit trail cannot attribute actions to the agent that actually performed them. Third, replayability: bearer means bearer — any agent, log pipeline, or attacker that touches the token can use it, so each hop multiplies exposure surface, and a token designed for an hour-long user session may sit in agent queues and traces far outside its intended path. Fourth, revocation blindness: you cannot revoke B's access without revoking the user's session everywhere. The correct pattern is OAuth 2.0 Token Exchange at each hop: A presents the user-derived token plus its own workload identity to the token service and receives a new short-lived token — subject still the user, act claim recording A as actor, scope narrowed to B's sub-task, TTL of around five minutes, audience-restricted to B. Sender-constrained variants (mTLS-bound or DPoP-style) go further by making a stolen token unusable without the agent's private key. Exchange is one extra token-service round trip per hop; it buys attribution, containment, and revocability.

Q: How do you prevent replay attacks between AI agents?

By making every consequential inter-agent message fresh, single-use, and bound to its sender — properties that must be enforced at the receiving agent, not assumed from the transport. Freshness comes from short-lived credentials and timestamps: delegated tokens with TTLs measured in minutes (300 seconds is a sane default for a sub-task token) shrink the window in which a captured message is useful at all. Single-use comes from nonces and idempotency keys: the sender attaches a unique value per request, the receiver records seen values for the validity window and rejects duplicates, so a captured "transfer approved" message resent 40 milliseconds later is a rejected duplicate rather than a second transfer. Sender binding comes from message-level signing or sender-constrained tokens: if the request is signed with the sending agent's workload identity key, or the token is bound to the mTLS client certificate, then replaying it from anywhere else fails cryptographic verification even inside the freshness window. Idempotency keys deserve special emphasis in agent systems because agents retry aggressively by design — a well-behaved orchestrator will legitimately resend tasks after timeouts, so the receiver must be able to distinguish "same operation, retried" (execute once, return the cached result) from "new operation that happens to look identical" (execute again). Treating replay defence as an application-level contract on every state-changing agent endpoint — not a transport nicety — is what separates payment-grade agent flows from demos.

Q: Can prompt injection defeat agent authentication?

Prompt injection cannot break correctly-placed authentication, but it reliably defeats authentication that was placed inside the model's discretion — which is where many teams accidentally put it. If an agent's system prompt says "only act on requests from the orchestrator" or the model is expected to notice that a message claiming to be from the compliance agent looks suspicious, then an injected instruction — arriving through a poisoned web page, document, tool result, or memory entry — can simply assert the required identity in prose and the model will often comply. Identity asserted in content is not identity; models judge meaning and are precisely the component an attacker can steer. The architecture must therefore assume the model is already compromised and make that not matter for authentication: identity comes only from the transport (mutual TLS with per-agent SVIDs) and the token (an RFC 8693 delegation chain), verified by deterministic code before any task reaches the model; authorization is evaluated against the token's scope by a policy engine, not by the model's judgment; and consequential actions are executed by infrastructure that checks the chain, not by the model "deciding" it is allowed. Under that design, a fully prompt-injected agent can assert anything it likes and request any delegation, but it still holds only its own workload identity and whatever narrowed scopes were legitimately exchanged to it — so the blast radius of the injection is the granted scope, not the fleet. Prompt injection then remains a real problem for what the agent does within its scope, which is why egress gating and action allowlists still matter, but it stops being an identity problem.

Q: What is the maturity path for securing agent-to-agent communication?

Five levels, each independently valuable, sequenced so you buy down the worst risk first. Level 0 is transitive trust: shared API keys or network-location trust between agents, user identity dying at the first hop — where most fleets are today, and where one leaked secret is a fleet-wide compromise. Level 1 is per-agent identity: a unique credential per agent (SPIFFE SVIDs or at minimum per-agent OAuth clients), mutual TLS between agents, and shared secrets retired; impersonation now requires compromising a specific workload rather than merely reaching the network, and this level is cheap enough to do immediately. Level 2 adds signed discovery and replay defence: Agent Card signatures verified on every resolve, registry governance with practised revocation, and nonces, expiries, and idempotency keys enforced on all state-changing task messages. Level 3 is delegation chains: OAuth 2.0 Token Exchange at every hop with act-claim verification and monotonic scope narrowing enforced by receiving agents, plus full-chain audit logging — this is the level at which user authority finally survives to hop N and "which agent did this on whose behalf" becomes a query rather than a forensic reconstruction; expect a two-to-three-quarter platform investment riding on your existing OIDC infrastructure. Level 4 is federated and adaptive: cross-organisational agent trust via allowlisted issuers and per-org scopes, per-hop risk scoring that routes unusual delegation paths to step-up approval, and chain analytics feeding detection. Stop at Level 3 unless your agents genuinely cross company boundaries.

Satyam Kumar

Back to Blog

cyber-security-patterns

Which Agent Is Actually Calling? Authentication and Impersonation in Multi-Agent Systems

By Satyam KumarAugust 23, 202613 min read

agent-to-agent authentication a2a protocol multi-agent security agent impersonation delegation chains oauth token exchange rfc 8693 spiffe workload identity non-human identity confused deputy agent card signing mcp authorization ai agent security zero trust agents 2026

Which Agent Is Actually Calling? Authentication and Impersonation in Multi-Agent Systems

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

Which Agent Is Actually Calling? Authentication and Impersonation in Multi-Agent Systems

Frequently Asked Questions

Share this article

Comments

Leave a comment