A2A Protocol Security Guide: Authenticating and Authorising Agent-to-Agent Traffic

The Agent2Agent (A2A) protocol tells agents how to find and talk to each other, but it deliberately leaves most of the security decisions to the people who deploy it. The specification says identity is handled at the transport layer, not inside A2A messages, and that authorisation logic is implementation specific. That makes the security of an A2A deployment depend on choices about Agent Card trust, credential types, task scoping, in-task authorisation and webhooks. This guide works through them against A2A specification version 1.0 (the latest released version shown on a2a-protocol.org when checked on 27 October 2026). It is written for engineers and security architects building or reviewing A2A servers and clients, and goes deeper on the protocol mechanics than our general Multi-Agent and A2A Security Guide.

Key takeaways

• A2A carries no identity in the payload. Clients learn the required schemes from the Agent Card, get credentials out of band and send them in HTTP headers or gRPC metadata on every request; the server must authenticate every call.
• An unsigned Agent Card is just a claim. Version 1.0 defines JWS signatures over an RFC 8785 canonicalised card; clients should verify at least one signature, fetch keys over HTTPS and refuse expired or revoked keys.
• Authorisation is yours to design. The specification requires checks on every operation and scoping of ListTasks and GetTask to the caller, but it does not define the model: map OAuth scopes to skills and tasks to owners yourself.
• TASK_STATE_AUTH_REQUIRED is a signal, not a grant. The specification says the state transition by itself must not be treated as authorisation, and credentials passed in band across a chain should be bound to the requesting agent.
• Push notifications are an outbound request you did not write. Validate webhook URLs against SSRF, authenticate every notification, and use a unique, rotated token per push configuration.

What A2A defines and what it leaves to you

A2A is an open protocol for communication between independent, often opaque agent systems. An A2A server publishes an Agent Card describing its identity, capabilities, skills and authentication requirements; an A2A client reads the card, authenticates and then sends messages that create and update tasks. Version 1.0 defines three standard bindings (JSON-RPC, gRPC and HTTP+JSON/REST), uses PascalCase operation names such as SendMessage, GetTask, ListTasks, CancelTask, SubscribeToTask and GetExtendedAgentCard, and adds an A2A-Version header so a server can reject versions it does not support with VersionNotSupportedError. Earlier releases (0.1.0, 0.2.6, 0.3.0) differ, so pin the version you accept.

"A2A compliant" therefore says little about security posture.

Agent Card trust: discovery, signing and verification

The Agent Card is how a client decides who it is talking to and how to authenticate, so tampering with it changes where credentials go. Section 8.2 lists three discovery routes: the well-known URI https://{server_domain}/.well-known/agent-card.json (registered in Section 14.3), curated registries or catalogues, and direct configuration. Each route has a different trust anchor: the domain's TLS certificate, the registry operator, or your own configuration management.

How signing works in version 1.0

1. Prepare the payload: remove properties holding default values according to Protocol Buffer field presence rules (Section 5.7), exclude the signatures field, and canonicalise the result with the JSON Canonicalization Scheme, RFC 8785.
2. Build the protected header: it must include alg (for example ES256 or RS256), typ (SHOULD be "JOSE") and kid; it may include jku, a URL to a JSON Web Key Set.
3. Sign the JWS signing input as defined in RFC 7515 and store the result in an AgentCardSignature object with protected, signature and an optional unprotected header.
4. Verify on the client by repeating the same default removal and canonicalisation, retrieving the key by kid and jku or from a trusted key store, and checking the signature.

The specification's security considerations for signing are short and worth adopting as policy: clients SHOULD verify at least one signature before trusting a card, keys SHOULD be fetched over HTTPS, clients MAY keep a trusted key store per provider, expired or revoked keys MUST NOT be used, and multiple signatures MAY be present to support key rotation.

• Do not trust jku blindly: a card naming its own key URL proves only that whoever controls that URL signed it. Restrict jku hosts to the provider's domain or use a trust store you manage.
• Canonicalisation bugs are signature bugs: a card rebuilt by an SDK can serialise differently; test verification across your SDKs before making signing mandatory.
• Treat card changes as configuration changes: a new security scheme, skill or interface URL should trigger review and an alert, not silent acceptance.

For the identity concepts behind signed agent metadata, see the Agent-to-Agent Authentication Guide and the Know Your Agent (KYA) Guide.

Client authentication: choosing a security scheme

The SecurityScheme object in version 1.0 is a choice of five types, modelled on OpenAPI. The card declares them in securitySchemes and states which combinations are required in securityRequirements; individual skills can also carry their own securityRequirements. In the OAuth flows, implicit and password are marked deprecated in the protocol definition, and the authorisation code flow carries a pkceRequired flag.

Decision guidance: for agents calling agents inside one organisation, workload identity with mTLS or short lived client credentials tokens is usually the right baseline, with token exchange when a user's authority must flow through. Across organisations, prefer OAuth with a federation agreement over shared API keys, because keys cannot express delegation or be revoked per user. Small teams can start with gateway issued bearer tokens, one per calling agent. The Agent Identity and Access Guide and the AI Agent Authorisation Guide cover the identity model in more depth.

On failure, return HTTP 401 with a WWW-Authenticate header for missing or invalid credentials and 403 for valid credentials without permission (gRPC: UNAUTHENTICATED and PERMISSION_DENIED).

Server-side authorisation and task scoping

Once a request is authenticated, Section 7.5 says the server authorises it against its own policies, and may consider the skill requested, actions within the task, data access policies and OAuth scopes. Section 13.1 turns this into hard requirements that are easy to miss in an SDK quick start:

• Every operation: servers MUST implement authorisation checks on every A2A operation request, not only SendMessage.
• Listing: ListTasks MUST only return tasks visible to the authenticated client, even when no contextId or filter is supplied.
• Direct access: GetTask MUST verify the client may see the task, and cancel, subscribe and push notification configuration operations MUST check access rights too.
• Ordering: checks MUST run before any query that could reveal resources outside the caller's scope.

Task IDs are object references in the sense of OWASP API1:2023 Broken Object Level Authorization: store the owning principal (client, user, tenant) with each task and check it on every lookup. On multi-tenant servers, treat the tenant field as routing data and enforce tenancy from the authenticated identity.

In-task authorisation and the AUTH_REQUIRED state

When an agent needs more authority mid-task, such as an OAuth token for another API or human approval for a destructive action, Section 7.6 lets the agent hand that problem back to its client by moving the task to TASK_STATE_AUTH_REQUIRED, one of the two interrupted states alongside TASK_STATE_INPUT_REQUIRED.

• Agent duties: track the operation in a task, set the state, and include a status message explaining what is needed unless that was negotiated out of band or by an extension. Credentials should arrive out of band over a secure channel such as HTTPS.
• Client duties: respond to negotiate, correct or reject, contact a human or another service, or fulfil the request out of band. A client that is itself an agent may push the request up its own chain by moving its task to the same state, which creates a chain of tasks awaiting authorisation.

Two rules from Section 7.6.4 should be written into your design standard. First, agents MUST NOT treat the transition to TASK_STATE_AUTH_REQUIRED as authorisation for any operation; the meaning of any resulting credential is defined by the implementation, the issuer or an extension. Second, a credential obtained in that state MUST NOT be assumed to authorise later messages on the task unless that behaviour is explicitly defined. In practice: bind each approval to a specific operation, amount and target, and expire it after use.

If credentials travel in band, Section 7.6.3 recommends binding them to the originating agent (sender constrained, audience restricted tokens) and encrypting sensitive ones so intermediaries cannot use them; see the Human-in-the-Loop for AI Agents Guide for approval design.

Push notification and webhook security

For long running tasks, a client can register a webhook with CreateTaskPushNotificationConfig. The TaskPushNotificationConfig holds a url, an optional token and an AuthenticationInfo object with a scheme and credentials. The server then sends HTTP POST requests to that URL. This turns every A2A server with push enabled into a component that makes outbound requests to addresses supplied by callers, which is a classic server-side request forgery surface (OWASP API7:2023).

Push configuration calls are task operations too: one client must not be able to replace another client's webhook and redirect its results.

Extended Agent Card access control

When capabilities.extendedAgentCard is true, authenticated clients can call GetExtendedAgentCard to receive a richer card, which MAY list extra skills, rate limits or organisation specific configuration. Section 13.3 requires authentication for this operation using a scheme from the public card, and requires the agent to validate permissions before returning privileged information. Two design points follow:

• Tier the content: document which caller groups see which skills. Hiding a skill is not access control; the skill must still authorise each call.
• Assume leakage: extended cards SHOULD NOT include internal service URLs or unmasked credentials. Clients SHOULD use the extended card only for the authenticated session.

Test that anonymous calls fail: an extended card returned without authentication is an information disclosure finding.

Monitoring and detection

Section 13.4 asks agents to log authentication failures, authorisation denials and suspicious requests, to watch for unusual patterns such as rapid task creation or excessive cancellations, and to keep audit trails for sensitive operations without logging credentials or personal data. The enterprise guidance adds OpenTelemetry tracing with W3C Trace Context and logging of task and correlation IDs on both sides.

• Identity events: 401 and 403 rates per client, unexpected token issuers or audiences, API key use from new networks.
• Card and webhook events: signature failures, unknown kid values, changes to securitySchemes or skills, blocked SSRF attempts.
• Task events: GetTask or SubscribeToTask calls for tasks the caller did not create (should be zero after authorisation), spikes in TASK_STATE_AUTH_REQUIRED transitions, long chains of delegated auth requests.

Metrics that show the controls work:

1. Percentage of A2A servers in inventory that require authentication on every operation (target 100%).
2. Percentage of partner Agent Cards that are signed and verified by clients before use.
3. Share of agent-to-agent calls using short lived or sender constrained credentials rather than static API keys.
4. Number of cross-principal task access attempts denied per month, and time to investigate each.
5. Push configurations with unique tokens rotated within policy, and webhook URLs on the allowlist.

See the AI Agent Observability and Incident Response Guide.

Implementation roadmap

1. Inventory: list every A2A server and client, the version each speaks (A2A-Version), the bindings exposed and the security schemes declared. Unknown servers found by scanning for /.well-known/agent-card.json go into shadow agent triage (see the Shadow AI Discovery Guide).
2. Transport baseline: enforce TLS 1.3 where possible (the enterprise topic page still says 1.2 or higher is acceptable), HSTS on HTTP bindings and certificate validation in every client. Note the two documents differ and set your own minimum.
3. Credential migration: replace shared API keys with per-agent OAuth clients or workload certificates. Run old and new schemes side by side by declaring both in securitySchemes, then remove the old one once logs show no use. Rollback is re-adding the old scheme for named clients only.
4. Authorisation tests: add automated tests that one client cannot list, get, cancel, subscribe to or change push configurations for another client's tasks. Run them in CI against every server release.
5. Webhook hardening: route all push delivery through an egress proxy with an allowlist, enable SSRF checks in report-only mode first, review blocked destinations for a fortnight, then enforce.
6. Card signing: sign your own cards, publish keys through a JWKS on your domain, and run client verification in log-only mode before making it blocking.

Framework mapping

Common failure patterns

• Authentication on SendMessage only: SDK examples protect message sending, while GetTask, ListTasks and push configuration endpoints are left open or checked only for a valid token, not for ownership.
• One API key for every caller: a single static key shared by all client agents makes attribution impossible and turns one leaked key into access for everyone. Treat agent credentials as non-human identities with owners and rotation; see the Credential Vaulting for AI Agents Guide.
• Trusting whatever card is fetched: clients accept cards from registries or redirects without signature checks, so an attacker who can alter a card can redirect traffic and harvest the credentials the client sends.
• Webhook URLs accepted as given: push delivery to internal ranges or metadata endpoints turns the agent into an SSRF proxy, and webhook tokens copied from the caller's access token leak real credentials to third parties.
• Approval reused as standing permission: an approval given during TASK_STATE_AUTH_REQUIRED for one action is silently honoured for later messages on the same task, which the specification explicitly warns against.
• Skill descriptions treated as trusted text: agents feed remote card descriptions straight into their planning prompt; a hostile description becomes an indirect prompt injection. Treat remote card content as untrusted input, as the Prompt Injection Guide describes.

Practitioner checklist

• Record the A2A version, bindings and schemes of every server and client.
• Require HTTPS everywhere, prefer TLS 1.3, enable HSTS and validate server certificates in every client.
• Give every calling agent its own credential; retire shared API keys and implicit or password OAuth flows.
• Authorise every operation, scope ListTasks and GetTask to the caller and check ownership before any data lookup.
• Sign your Agent Cards with JWS over RFC 8785 canonical JSON, publish keys on your domain and verify partner cards against a trust store.
• Treat TASK_STATE_AUTH_REQUIRED approvals as single use and operation specific; bind any in-band credential to the requesting agent.
• Validate webhook URLs against private, loopback and link-local ranges, send through an egress proxy and use a unique rotated token per configuration.
• Require authentication for GetExtendedAgentCard and keep internal URLs and credentials out of all cards.
• Log authentication failures, denials, card changes and webhook blocks with trace context, and alert on cross-principal task access.

Standards and references

• A2A Project: Agent2Agent (A2A) Protocol Specification
• A2A Project: Enterprise Implementation of A2A
• IETF: RFC 7515 JSON Web Signature (JWS)
• IETF: RFC 8785 JSON Canonicalization Scheme (JCS)
• OWASP: API Security Top 10 2023
• OWASP GenAI Security Project: Top 10 for Agentic Applications
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Adversary-in-the-Middle

Related NHI Mgmt Group resources: Multi-Agent and A2A Security Guide · Agent-to-Agent Authentication Guide · MCP Security Guide · Agent Skills Security Guide · Zero Trust for AI Agents Guide