Authentication and Access for A2A

When using A2A, all endpoints require an authenticated caller. Here are some key points about the Fusion Applications A2A surface:

• It's externally exposed to authorized clients and integrations
• It's not anonymous or publicly open without authentication
• It's authenticated for discovery, invocation, status retrieval, and streaming

The agent card advertises the Bearer authentication.

Authorization Behavior

All endpoints require authentication, but clients must also understand the distinction between discovery and execution behavior. A client might be able to discover an agent entry, but actual processing or status access might still depend on user-specific authorization. Status retrieval is user-scoped, and authorization to process is enforced at processing time.

Clients must therefore treat discovery as a way to find candidate agents, and processing as the point where final access is confirmed.

Auth, OAuth, Bearer Tokens, and Authorization

Authentication means proving the identity of the caller. Here OAuth is the standard token-based mechanism used to obtain access credentials. A bearer token is the token the client sends on the request, usually in the Authorization header. Authorization means determining what the authenticated caller is allowed to access or do.

A high-level overview of the authentication process includes the following:

• Clients authenticate by presenting a bearer token
• That bearer token is obtained through an OAuth flow
• Authentication gives access to the API
• Authorization determines whether the client can run a workflow or retrieve a task