Who’s on FirstChoose a flow

Flows / Agent to agent, agent to web

Agent-to-agent (A2A)

One agent discovers another, reads what credentials it wants, and presents them. When the remote agent needs more, it says so mid-task.

Based onA2A 1.0Final spec, version 1Guide reviewedNovember 2026

Sources and review details
This page
Implementation guideAn explanation, not a specification
Primary specification
Agent2Agent (A2A) ProtocolFinal spec · Version 1.0.0 released March 2026; 1.0.1 in May 2026
All 5 specifications
4 published, 1 draft
Flow maturity
EmergingWhat the rating means
Human involvement
With or without a human
Review
Checked against sources in November 2026How it was checked

The Agent2Agent protocol lets independently built agents hand work to each other. Its position on security is deliberately conservative: an agent is an ordinary enterprise application, and should be authenticated the way web services already are. A2A does not invent a token format or an identity scheme. It defines how a remote agent declares what it requires, and leaves obtaining the credential to existing standards.

The declaration lives in the Agent Card, a JSON document published at a well-known URL. It lists security schemes in a form borrowed from OpenAPI: API key, HTTP bearer, OAuth 2.0, OpenID Connect, or mutual TLS. The calling agent reads the card, gets a matching credential by whatever means apply, and sends it on every request in an HTTP header.

Two parts of version 1.0 matter for trust. Agent Cards can be signed, so a caller can check that a card was issued by who it claims. And there is a defined task state for the moment a remote agent needs further authorization partway through the work.

Step by step

11 steps between 4 parties. Each step shows the message and who holds which credential afterward. Use ←→ or select any arrow.

Sequence diagram4 participants, 11 steps
  • Direct call
  • Via the user’s browser or device
  • Response
  • Local action

Drag to see every party and step. Tap a step to jump to its explanation.

1Fetch Agent Card2Agent Card + signatures3Verify signature; pick scheme4Obtain a token5Access token6Send message + Bearer token7Authenticate; authorize skill8Task: auth required9Relay:approval needed10Authorize out of band11Task completed + artifacts

  1. 1Client agentRemote agentDirect call

    The client agent discovers the remote agent

    Every A2A server must publish an Agent Card. The well-known location is /.well-known/agent-card.json; cards can also come from a registry or be configured directly.

  2. 2Remote agentClient agentResponse

    The card declares skills and security requirements

    securitySchemes names the mechanisms on offer and securityRequirements says which are needed. Individual skills can carry their own requirements. An OAuth scheme can point at authorization server metadata so the client knows where to get a token.

    {
  "name": "Travel Booking Agent",
  "capabilities": { "extendedAgentCard": true },
  "securitySchemes": {
    "corp": {
      "openIdConnectSecurityScheme": {
        "openIdConnectUrl": "https://id.example.com/.well-known/openid-configuration"
      }
    }
  },
  "securityRequirements": [
    { "schemes": { "corp": { "list": ["openid", "travel.book"] } } }
  ],
  "signatures": [ { "protected": "eyJhbGciOiJFUzI1NiIsImtpZCI6Ii4uLiJ9", "signature": "QFdkNLNszlGj3z3u0YQGt_T9LixY3qtdQpZmsTdDHDe3fXV9y9-B3m2-XgCpzuhiLt8E0tV6HXoZKHv4GtHgKQ" } ],
  "skills": [ { "id": "book-flight", "name": "Book a flight" } ]
}

  3. 3Client agentLocal action

    The client checks the card

    If the card is signed, the client canonicalizes it and verifies the JSON Web Signature against a key it has reason to trust. It then chooses a security scheme it can satisfy.

  4. 4Client agentAuthorization serverDirect call

    The client gets a credential, outside A2A

    A2A says only that credentials are obtained out of band. In practice this is one of the other flows on this site: client credentials if the agent acts as itself, token exchange if it is acting for a user, authorization code or device code if someone needs to sign in.

  5. 5Authorization serverClient agentResponse

    A token for the remote agent

    Audience-restricted to the remote agent, like any other resource.

    Who holds what after this step

    Client agent
    newaccess token (aud: remote agent)

    Parties not listed hold none of this flow’s credentials at this point.

  6. 6Client agentRemote agentDirect call

    The client sends a task with its credential

    Credentials travel in HTTP headers on every request and never inside the A2A message payload. Servers must authenticate every request and authorize each operation.

    Who holds what after this step

    Client agent
    access token (aud: remote agent)

    Parties not listed hold none of this flow’s credentials at this point.

  7. 7Remote agentLocal action

    The remote agent decides what this caller may do

    Authorization is the remote agent’s own business: which skills, which data, at what scopes. It starts work.

    Who holds what after this step

    Client agent
    access token (aud: remote agent)

    Parties not listed hold none of this flow’s credentials at this point.

  8. 8Remote agentClient agentResponse

    Partway through, the remote agent needs more

    To finish, it needs something it lacks, such as the user’s authorization at an airline. It moves the task to the TASK_STATE_AUTH_REQUIRED state with a message explaining what is needed. If the client is itself an agent acting for someone else, it can pass the same state up its own chain.

    Who holds what after this step

    Client agent
    access token (aud: remote agent)

    Parties not listed hold none of this flow’s credentials at this point.

  9. 9Client agentUserDirect call

    The request reaches a human

    The client agent surfaces the request to the user it is working for.

    Who holds what after this step

    Client agent
    access token (aud: remote agent)

    Parties not listed hold none of this flow’s credentials at this point.

  10. 10UserRemote agentVia the user’s browser or device

    The user authorizes the remote agent directly

    For example by completing an OAuth flow in a browser with the remote agent’s service. The specification discourages passing the resulting credential back through the client agent.

    Who holds what after this step

    Client agent
    access token (aud: remote agent)

    Parties not listed hold none of this flow’s credentials at this point.

  11. 11Remote agentClient agentResponse

    The task finishes

    The remote agent resumes and returns its results. The client agent never held the airline credential.

    Who holds what after this step

    Client agent
    access token (aud: remote agent)

    Parties not listed hold none of this flow’s credentials at this point.

Watch out for

  • A2A carries credentials; it does not define delegation. Whether the remote agent learns which user the task is for depends entirely on the token you send. Use token exchange so that it does.
  • An unsigned Agent Card is a claim by whoever answered the URL. A signed one is only as good as your reason to trust the signing key; the protocol defines no trust anchor.
  • The remote agent is a full autonomous system. Authenticating it tells you who operates it, not what it will do with your data.
  • In-task authorization happens out of band. The state change is a request, not proof that anything was granted.

A2A and MCP

The two protocols are complementary: MCP connects an agent to tools, A2A connects agents to each other. Both are Linux Foundation projects, and both lean on OAuth. The difference in their security models is one of emphasis. MCP specifies a complete discovery and authorization profile. A2A specifies how requirements are declared and stops there.

Standards in play

See the full tracker for status and links.

Final specA2A 1.0

Agent2Agent (A2A) Protocol

Defines how requirements are declared between agents, and leaves obtaining credentials to OAuth and its relatives.

WG draftdraft-ietf-oauth-v2-1

OAuth 2.1

The baseline MCP profiles. Worth knowing that the normative base of most agent authorization is still, formally, a draft.

RFCRFC 8693

Token Exchange

The primitive under on-behalf-of flows, ID-JAG, identity chaining and transaction tokens.

Final specOpenID Connect Discovery 1.0

OpenID Connect Discovery

An MCP authorization server publishes this or RFC 8414 metadata, and an MCP client must support both. It is also the format Kubernetes clusters and CI systems use to publish workload-identity signing keys.

Token exchange

Trade the token you were given for a new one that names both the user and the service now acting for them.

With or without a humanStable standards

Client credentials

The agent authenticates as itself. No user, no consent screen, no one to ask.

No humanStable standards

Web Bot Auth

An agent that browses the open web signs its requests, so a site can tell which operator it belongs to without trusting a user-agent string.

With or without a humanEmerging

MCP authorization

How an MCP client that has never seen a server before discovers where to sign in, identifies itself, and gets a token good for that server alone.

Human presentEmerging