A2A protocol explained: agent cards, tasks and security

What is the A2A protocol?

A2A is a protocol for one agent to give work to another: the client sends a message, and the remote agent answers with a reply or a task to follow until the work is done. The specification lets agents collaborate "without needing access to each other's internal state, memory, or tools": a supplier's ordering agent or a partner's support agent can take requests from yours without either side exposing its prompts, model or systems.

A2A does not replace the Model Context Protocol. MCP connects an agent to tools and data; A2A connects it to another agent as a peer, and that agent may use MCP internally. The comparison is in A2A vs MCP, and the tool side in the best MCP servers for business agents.

Is the A2A protocol from Google, and who runs it now?

Google created A2A but no longer controls it alone. It announced the protocol in April 2025, contributed it to the Linux Foundation in June 2025, and in August 2026 A2A became a hosted project of the Agentic AI Foundation, the Linux Foundation body that also hosts MCP.

A steering committee with seats for Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP and IBM sets technical direction, per the governance file. The specification is Apache 2.0 licensed.

How does the A2A protocol work?

A client reads the remote agent's Agent Card, obtains the credential it asks for, and sends a message. The agent replies with a message or, for anything that takes time, a task whose results come back as artifacts.

While a task runs, the client can stream updates over Server-Sent Events, poll with GetTask, or register a webhook if the card supports pushNotifications.

What does an A2A agent card look like?

An Agent Card is a JSON document, served by convention at https://{server_domain}/.well-known/agent-card.json, that names the agent, lists its skills, and says where to call it and which credentials it accepts. This illustrative version 1.0 card uses the specification's exact field names; the company, URLs and skill are made up.

{
  "name": "Invoice Desk",
  "description": "Answers invoice status questions for Example Co customers. Needs an invoice number. Will not change invoices or issue refunds.",
  "supportedInterfaces": [
    {
      "url": "https://agents.example.com/a2a/invoice-desk",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "provider": { "organization": "Example Co", "url": "https://www.example.com" },
  "version": "1.0.0",
  "capabilities": { "streaming": true, "pushNotifications": false },
  "securitySchemes": {
    "bearer": { "httpAuthSecurityScheme": { "scheme": "Bearer" } }
  },
  "securityRequirements": [ { "schemes": { "bearer": { "list": [] } } } ],
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "invoice-status",
      "name": "Invoice status",
      "description": "Looks up whether an invoice is open, paid or overdue.",
      "tags": ["invoices"],
      "examples": ["Has invoice INV-1042 been paid?"]
    }
  ]
}

• Required in 1.0: name, description, supportedInterfaces, version, capabilities, defaultInputModes, defaultOutputModes and skills.
• Interfaces are in preference order. Each gives a url, a protocolBinding (JSONRPC, GRPC or HTTP+JSON) and a protocolVersion.
• Cards can be signed with a JSON Web Signature, so a client can check a card came from its claimed provider unaltered.

A tutorial that uses message/send, parts with a "kind" field or states such as "completed" was written for version 0.3; the specification's migration appendix covers the changes.

Is the A2A protocol over HTTP?

Yes. Version 1.0 defines three standard bindings, all over HTTP(S): JSON-RPC 2.0, gRPC and HTTP+JSON (REST). Every binding an agent offers must provide the same operations and authentication.

Clients send an A2A-Version header such as 1.0; an agent that receives none assumes 0.3. A minimal JSON-RPC call to the agent above is an HTTPS POST to its interface URL with a bearer token:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "6f1c2d1e-0001",
      "role": "ROLE_USER",
      "parts": [{ "text": "Has invoice INV-1042 been paid?" }]
    }
  }
}

A reply that finishes in one step returns the answer as an artifact:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "task": {
      "id": "task-8812",
      "contextId": "ctx-311",
      "status": { "state": "TASK_STATE_COMPLETED" },
      "artifacts": [
        { "artifactId": "art-1", "parts": [{ "text": "INV-1042 was paid on 3 October." }] }
      ]
    }
  }
}

Does A2A support OAuth?

Yes. An Agent Card can declare OAuth 2.0 (authorisation code, client credentials or device code flows), OpenID Connect, bearer tokens, API keys and mutual TLS. The client obtains a credential out of band and sends it with every request; A2A messages carry no identity of their own.

The server must authenticate every request; what an authenticated caller may then do is left to the implementation. And TASK_STATE_AUTH_REQUIRED lets an agent pause a task to ask its caller for an authorisation, such as a person's approval before a destructive action.

How do you secure A2A?

Use HTTPS, authenticate every call, scope credentials to named agents, treat inbound callers as strangers rather than owners, let your agent contact only remote agents you listed, and treat replies as untrusted input. The table pairs each control with how we implement it on Olano.

If you use push notifications, validate webhook URLs too: the specification warns that a client-supplied webhook is a server-side request forgery risk.

Is A2A production ready, and is it still a thing?

Yes, with conditions. Version 1.0 is a stable specification, the Linux Foundation reported production deployments in April 2026, and the Python SDK was still shipping releases in October 2026. The open questions sit on the other side of each connection: 0.3 agents are still in service, not every agent serves every binding, and the protocol supplies no approvals, audit or rate limits.

How can I test my A2A agents?

Validate the Agent Card, send a real message, then break things on purpose.

1. A2A Inspector: fetches and checks the card, gives you a chat with the agent and shows the raw JSON-RPC traffic.
2. Technology Compatibility Kit: a conformance suite over gRPC, JSON-RPC and HTTP+JSON that writes a report per run.
3. Unhappy paths: no token, a token for another agent, a request needing more input, a cancelled task, an unsupported version.
4. Behaviour: ask for something the agent should refuse or hold for approval, and check that it does.

How Olano helps: A2A in both directions

Olano speaks A2A both ways, with the controls above built in, and both directions are off by default.

Inbound. Only an administrator can publish an agent: switch on the A2A endpoints under Config → External access, then on the agent's External access tab switch on Reachable over A2A and write its public description. Each exposed agent gets an Agent Card at <public URL>/api/a2a/agents/<agent>/.well-known/agent-card.json plus a JSON-RPC endpoint, declaring both bearer and OAuth sign-in. The description is compulsory and is never the system prompt. An administrator mints tokens (shown once, revocable), or a client signs in through Olano's own OAuth 2.1 server and an administrator approves it on a consent page. Callers never see the agent's configuration, files or other threads, and inbound task records are kept 7 days by default. The full walkthrough is in exposing your agent as an MCP server or agent card.

Outbound. On the agent's Advanced tab, the Remote Agents list holds a name, an https:// URL, an authentication mode and a vault reference for each agent it may call. That gives it tools to list, discover, message and poll remote agents. Sending counts as an external write, so an agent in Supervised or Locked-down mode asks first.

Visibility. The Agent to Agent view keeps outside traffic in its own External segment, with an A2A or MCP badge, apart from delegation between your own agents.

The limits: Olano does not make a remote agent trustworthy or find agents for you, and inbound A2A needs a public HTTPS address. See our security page for the isolation, vault and audit trail underneath, and the platform page for the rest.

Common mistakes

• Reading the card as a promise. It is self-description. Pin the endpoint and verify signatures where offered.
• Reusing the system prompt as the description. It publishes your instructions and still does not tell a stranger when to call.
• Giving inbound callers owner rights. A partner's agent is not your operator.
• Mixing 0.3 and 1.0 payloads. Names differ, so a mismatch looks like a malformed request. Send the version header.