Securing A2A: Authentication, Authorization, and Zero Trust Between Agents

A2A builds authentication and authorization on OAuth 2.0 and JSON Web Tokens — the same mechanisms that protect ordinary web APIs. An agent proves who it is and is granted access without ever sharing a password or private credential.

An Agent Card declares the authentication schemes the remote agent requires. The client obtains a scoped token, presents it with each request, and the remote agent validates it before doing any work.

The safest default is zero trust: assume every peer is untrusted until it proves otherwise, on every request — not once per session.

How agents authenticate

An Agent Card declares the authentication schemes the remote agent requires. A client reads those requirements, obtains the appropriate token — typically an OAuth 2.0 access token — and presents it with each request. The remote agent validates the token before doing any work.

Because this is standard OAuth, it plugs directly into existing identity providers rather than requiring a new trust system.

• OAuth 2.0 — for obtaining and presenting scoped access tokens.
• JSON Web Tokens — for compact, verifiable, signed credentials.
• Signed Agent Cards — so a client can verify a card's authenticity before trusting its endpoint.

Authenticate is not authorize

Authentication proves identity; authorization decides what that identity may do. A remote agent should grant a client only the access a given task requires, and no more.

Scoped tokens make this natural: a client delegating a research task receives a token good for that, not blanket access to everything the agent can do. Least privilege is as important between agents as it is between users and systems.

Zero trust between agents

The safest default in a multi-agent system is to assume every peer is untrusted until it proves otherwise, on every request. That sounds harsh, but it is simply how the rest of secure computing already works.

An agent you call today may be operated by another team or company tomorrow. A token valid a minute ago may have been revoked. Re-verifying identity and authorization per call, rather than per session, is what lets agents from different trust domains collaborate without exposing each other to risk.

In a multi-agent system, the agent talking to you now
may not be the one that talked to you a moment ago.

The largest failure surface

A hard-won lesson from production agent systems: the tools and endpoints an agent exposes are the biggest attack surface in the whole architecture. When you make an agent callable over A2A, you are opening a door.

Validate every incoming request. Authenticate before acting. Rate-limit aggressively. And never trust input just because it arrived from another agent. An agent that blindly executes what a peer sends is a liability, however well-behaved that peer is supposed to be.

Common security mistakes

• Implicit trust. Treating any agent that speaks A2A as safe. Authenticate and authorize every caller, every time.
• Over-broad tokens. Handing a peer a token that grants far more than the task needs. Scope tokens to the specific skill being used.
• Unvalidated input. Acting on incoming Parts without checking them. A file or data Part from a peer is untrusted input like any other.
• No rate limits. Leaving an exposed agent open to being called without bound, whether by accident or abuse.
• Session-only auth. Verifying identity once and trusting it thereafter, when the peer on the other end can change between calls.

Building a trust boundary

Setting up authentication between agents is mostly a matter of reusing what your organization already has. Point your agents at your existing identity provider, issue scoped tokens for specific skills, and validate them at the edge of every agent.

Because it is standard OAuth and JWT, you inherit rotation, revocation, and auditing for free rather than inventing a private trust scheme. The boundary you build this way is the same kind that already protects your ordinary services.

A security checklist

• Serve signed Agent Cards where trust matters; verify them client-side.
• Require authentication on every endpoint, validated per request rather than per session.
• Scope authorization to the specific task; never hand a peer broad access.
• Validate and sanitize all incoming Parts before acting on them.
• Rate-limit and set timeouts.
• Log every task with a correlation id for later tracing.

Design for the agent you cannot see

In production, some agents you interact with will be operated by other teams or companies. Assume you cannot inspect or fix them.

Defensive clients, strict validation, and graceful degradation are what keep your system stable when a peer misbehaves. This is not paranoia — it is the same posture you already take with any third-party API, applied to a peer that happens to be an agent.