PromptMaster

Posted on Jul 18

Securing Agent-to-Agent Communication: OAuth, JWT, and Zero Trust

#ai #agents #oauth #security

The moment you make an agent callable over A2A, you open a door. Here's how to make sure only the right callers walk through it.

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

An Agent Card declares which authentication schemes the remote agent requires. The client obtains the appropriate token and presents it with every request; 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. The agent talking to you now may not be the one that talked to you a moment ago.

Why this stops being optional immediately

The moment agents from different teams or vendors interact, security stops being a later concern. When you make an agent callable over A2A, you are opening a door into whatever that agent can do — and whatever its tools can reach.

A hard-won lesson from production agent systems: the tools and endpoints an agent exposes are the biggest attack surface in the whole architecture. An agent that blindly executes what a peer sends is a liability, however well-behaved that peer is supposed to be.

How agents authenticate

The flow is standard OAuth, which is exactly the point:

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

Because this is standard OAuth, it plugs directly into existing identity providers rather than requiring a new trust system. You inherit rotation, revocation, and auditing from infrastructure you already run.

The three mechanisms

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.

That third one deserves attention. A card tells a client where to send work and how to authenticate. An attacker who can serve a convincing card can redirect that work — so wherever trust matters, verify the card rather than taking it at face value.

Authenticate proves who; authorize decides what

Authentication proves identity. Authorization decides what that identity may do. Conflating them is how agents end up with far more access than any single task requires.

A remote agent should grant a client only the access a given task needs, 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 matters as much between agents*as it does between users and systems.*

Zero trust, and why per-session auth isn't enough

The safest default in a multi-agent system is to assume every peer is untrusted until it proves otherwise — on every request, not once per session.

That sounds harsh until you consider what changes underneath you. An agent you call today may be operated by another team or company tomorrow. A token valid a minute ago may have been revoked. The peer on the other end of this call may not be the one from the last call.

Re-verifying identity and authorization per call is what lets agents from different trust domains collaborate without exposing each other to risk. It is simply how the rest of secure computing already works.

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.
Validate at the edge of every agent, before any work happens.

The boundary you build this way is the same kind that already protects your ordinary services — which means your existing security practice, tooling, and audits apply unchanged.

Five mistakes that open doors

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 unbounded calls, 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.

A security checklist

Serve only signed Agent Cards where trust matters; verify them client-side.
Require authentication on every endpoint, and validate the token on every request rather than once 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, and 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 them, cannot fix them, and cannot rely on them behaving well.

Defensive clients, strict validation, and graceful degradation are what keep your system stable when a peer misbehaves. The protocol gives you the mechanisms — using them is on you.

Frequently asked questions

How does authentication work in A2A?
A2A uses OAuth 2.0 and JSON Web Tokens. The remote agent's Agent Card declares its required authentication schemes; the client obtains a scoped access token and presents it with each request; the remote agent validates it before doing any work.

What is a signed Agent Card and why does it matter?
A cryptographically signed card lets a client verify it genuinely belongs to the claimed agent. Since a card tells clients where to send work and how to authenticate, an attacker serving a fake card could redirect that work. Verify cards wherever trust matters.

Should I authenticate once per session or per request?
Per request. In a multi-agent system the peer talking to you now may not be the one from a moment ago, tokens may have been revoked, and agents may change hands between teams or companies. Per-call verification is the only safe default.

Is A2A secure by default?
The protocol provides the mechanisms — OAuth 2.0, JWT, signed cards, scoped authorization — but using them is on you. An agent that skips validation, uses broad tokens, or trusts peers implicitly is exposed regardless of what the protocol supports.

What's the biggest security risk in a multi-agent system?
The tools and endpoints your agents expose. Making an agent callable opens a door into everything it can do and everything its tools can reach. Validate every request, authenticate before acting, rate-limit, and never trust input just because it came from another agent.

Want to go deeper?

I wrote two guides on this.

A2A Quick-Start — free, 6 pages. The Agent2Agent protocol in 15 minutes: what it is, the five building blocks, the task lifecycle, and where MCP fits.

A2A: The Complete Guide — 42 pages. 15 chapters, 5 appendices. Discovery, security, building your first agent with the SDK, orchestration patterns, extensions and AP2, production and scaling — plus a full worked example of two agents talking and a 30-day adoption path.

Independent educational content. Not affiliated with, endorsed by, or sponsored by Google, the Linux Foundation, Anthropic, or any vendor named. A2A and MCP are evolving specifications — confirm details against the official specification for your target version.

DEV Community