Authentication, Authorization, and Security Considerations

A2A treats agents as standard enterprise applications and relies on established web security practices. Identity is handled at the protocol layer (HTTP headers or gRPC metadata) and is not part of A2A message semantics. This page organizes chapters 7 and 13 of the official specification; for the enterprise perspective, see Enterprise Implementation of A2A . MUST / SHOULD / MAY carry their RFC 2119 meanings.

Transport security and server identity

• Production deployments MUST use encrypted communication: HTTPS for the HTTP-based bindings and TLS for gRPC.
• Implementations SHOULD use a modern TLS configuration (TLS 1.3 or later is recommended) with strong cipher suites, SHOULD enforce HSTS on the HTTP-based bindings, and SHOULD disable SSLv3, TLS 1.0, and TLS 1.1.
• Clients SHOULD verify the server’s identity by validating its TLS certificate against trusted certificate authorities (CAs) during the TLS handshake.

Authentication

The client authenticates in three steps:

1. Discover the requirements: read the authentication schemes the server requires from securitySchemes in the Agent Card (see Data Structures for the scheme types).
2. Acquire credentials out of band: obtain the credentials through a process specific to the scheme, such as an OAuth 2.0 flow.
3. Transmit credentials: include them in protocol-appropriate headers or metadata on every A2A request.

The server:

• MUST authenticate every incoming request based on the credentials provided and its declared authentication requirements.
• SHOULD use the binding-specific error codes for authentication challenges or rejections, and SHOULD include the relevant challenge information in the error response.

Authorization

Once the caller is authenticated, the server authorizes the request based on the caller’s identity and its own policies. The protocol does not prescribe an authorization model; the logic is implementation-specific and MAY consider the skills requested, the actions attempted within tasks, data access policies, and OAuth scopes.

Whatever the model (user-based, role-based, project-based, multi-tenant, or custom), these requirements apply:

• Servers MUST perform an authorization check on every request.
• Results MUST be scoped to the caller’s authorized access boundaries, even when contextId or other filters are not specified.
• Authorization checks MUST occur before any database query or operation that could leak the existence of resources outside the caller’s scope.
• Agents SHOULD document their authorization model and access control policies.

In-task authorization

While performing a task, an agent may need authorization for some action, for example an OAuth access token to call an API or another agent, or human approval before a destructive action. The object that represents the approved authorization is called a credential here. A2A lets the agent hand the fulfillment of this authorization to the client through the TASK_STATE_AUTH_REQUIRED task state, as a fallback when the agent cannot obtain it by itself (for example by messaging a human directly).

Agent responsibilities

To ask the client to fulfill an authorization request, the agent:

1. MUST track the operation with a Task;
2. MUST transition the task to TASK_STATE_AUTH_REQUIRED;
3. MUST include a TaskStatus message explaining the required authorization, unless the details have been negotiated out of band or through an extension.

Agents MUST arrange to receive the credential out of band, unless an in-band mechanism has been negotiated out of band or through an extension. If the credential arrives out of band, the agent SHOULD keep any active response streams open after entering TASK_STATE_AUTH_REQUIRED, and MAY continue processing immediately once the credential arrives, without requiring a follow-up message from the client. Agents SHOULD accept messages directed to the task while it stays in TASK_STATE_AUTH_REQUIRED, so the client can negotiate, correct, or reject the request.

Client responsibilities

On receiving a task in TASK_STATE_AUTH_REQUIRED, the client is expected to act on the request. It may:

• send a message to the task to negotiate, correct, or reject the authorization request;
• contact another human, agent, or service to fulfill it;
• fulfill it directly through an out-of-band or extension-negotiated means.

If the client is itself an A2A agent processing a task, it may delegate the request further up by moving its own task to TASK_STATE_AUTH_REQUIRED (following the agent responsibilities above), which forms a chain of tasks in that state.

Because a client may not know when the agent receives the credential and resumes work, a client without an active response stream risks missing task updates. To avoid this it SHOULD do one of the following:

• subscribe to the task’s events with SubscribeToTask;
• register a webhook with CreateTaskPushNotificationConfig, if the agent supports it;
• poll the task with GetTask.

Security considerations

• Agents SHOULD receive the credential out of band through a secure channel such as HTTPS, so it is provided directly to the agent.
• In-band exchange, if negotiated out of band or through an extension, can pass credentials along a chain of A2A agents and expose them to every agent in it. In that case:
  • credentials SHOULD be bound to the agent that originated the request, so only that agent can use them;
  • credentials containing sensitive information SHOULD be readable only by the originating agent, for example by encrypting them.

Scope of the authorization

TASK_STATE_AUTH_REQUIRED only signals that more authorization is needed to continue. The protocol does not define the scope, representation, validity, or revocation semantics of the decision or credential obtained in response.

• Agents MUST NOT treat the TASK_STATE_AUTH_REQUIRED transition, by itself, as authorization for any particular operation.
• The meaning and scope of the resulting decision or credential MUST be defined by the agent’s implementation, the credential issuer, or an A2A extension. An implementation that requires authorization for specific operations is responsible for defining how the authorized operation is identified and checked before it runs.
• A credential or decision obtained while a task is in TASK_STATE_AUTH_REQUIRED MUST NOT be assumed to authorize subsequent messages on the task, unless the implementation, issuer, or extension explicitly defines that behavior.

Push notification security

Both the agent (the webhook caller) and the client (the webhook receiver) have responsibilities. See Streaming and Asynchronous Operations for how push notifications work.

Agent (webhook caller)

• MUST include the credentials specified in TaskPushNotificationConfig.authentication in webhook requests.
• SHOULD use reasonable request timeouts (10 to 30 seconds recommended) and retry failed deliveries with exponential backoff; it MAY stop after a configured number of consecutive failures.
• SHOULD validate webhook URLs to prevent SSRF (server-side request forgery): reject private IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), localhost, and link-local addresses, and use URL allowlists where appropriate.

Client (webhook receiver)

• MUST validate the authenticity of each notification using the provided credentials, and MUST respond with an HTTP 2xx status to acknowledge receipt.
• SHOULD check that the task ID in the payload matches a task it created, process notifications idempotently (duplicates can occur), rate-limit incoming notifications, and use HTTPS webhook URLs.

Configuration

• Tokens in TaskPushNotificationConfig SHOULD be treated as secrets and rotated periodically; clients SHOULD use a unique, single-purpose token for each configuration.
• Agents SHOULD store push notification configurations and credentials securely.

Extended Agent Card access control

The extended Agent Card gives authenticated clients more information than the public card does (see Agent Discovery and the Agent Card ).

• GetExtendedAgentCard MUST require authentication, using one of the schemes declared in the public card’s securitySchemes and security.
• Agents MAY return different extended card content according to the caller’s identity or authorization level (additional skills, finer-grained capability information such as rate limits and quotas, organization- or user-specific configuration), and SHOULD document what each authentication level can see.
• Agents MUST verify permissions before returning privileged information, and extended cards SHOULD NOT contain information that is dangerous if leaked, such as internal service URLs or unmasked credentials.
• Agents SHOULD version extended cards, honor client cache invalidation, and use caching headers to control client-side caching. Clients SHOULD replace their cached public card with the extended one for the duration of the authenticated session.
• When capabilities.extendedAgentCard is false or absent, the operation MUST return UnsupportedOperationError; when it is declared but no extended card is configured, it MUST return ExtendedAgentCardNotConfiguredError.

General best practices

Related pages

• Core Protocol Specification : error codes, version negotiation, and the mapping across the three bindings.
• Protocol Bindings in Detail : how credentials and service parameters travel in each binding.
• Enterprise Implementation of A2A and Life of a Task .

Source: A2A official specification