Damian Schenkelman

Damian was one of Auth0's earliest employees. He loves building products for developers and taking things from 0 to 1.
<br><br>
He played key roles in implementing product features and growing the engineering organization in the early stages, and later on defining Auth0's architecture for scale and creating new products. Today he helps shape Auth0's long term strategy and leads Auth0Lab, a small and amazing team doing research and development of forward-looking products.
<br><br>
He spends his spare time with family, and friends, exercising, and catching up on all things NBA.

VP R&D (Auth0Lab)

Production-ready AI agents need to be secure, and auth is a big part of security. Auth0 is partnering with Google Cloud to help deliver secure authentication for the Agent2Agent (A2A) protocol.

## What Is the Agent2Agent Protocol?

[Agent2Agent (or A2A)](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) is a new open interoperability protocol created by Google Cloud, and launched a month ago,  with support and contributions from 60+ companies.

It aims to allow agents to communicate with other agents regardless of their implementation framework or tech stack. For example, a “client” agent should be able to communicate with server agents implemented with LangGraph, Google ADK, Vercel AI SDK, any other agentic framework, or any agent implemented without one.

![A2A Protocol](https://images.ctfassets.net/23aumh6u8s0i/RYuhvCQkWJzgSl1ZoZGqj/62881d062e978f8d733ed58ad743e3bf/01_Agent2Agent_protocol.png)

## Why Is Auth Important for AI Agents?

As companies and developers deploy AI agents into production, interactions between these agents will be common. And naturally, these interactions need to be secure.

We can say that each AI agent can act as a client (when requesting data from other AI agents) and as a server (when responding to data requests from other AI agents).

![A2A Protocol](https://images.ctfassets.net/23aumh6u8s0i/54RtL5WuaBcv9Tu1He2ngO/4131696834c22e88ec061edad4d07dab/02_Agent2Agent_protocol.png)

So we ended up with some auth-related questions that needed to be answered. These matters are important when implementing any system, and agentic systems are no exception. But there are also a few questions that become more prevalent with the rise of AI agents:

* **Authentication:** How does the server agent know who is trying to perform an action?
* **Delegation:** Is the agent acting on its behalf, or on behalf of a user?
* **Consent:** If the client is acting on behalf of a user, how does the user consent to this operation?
* **Authorization:** How does the server agent know if the caller can perform the action (e.g., call a specific tool)? If the client is acting on behalf of a user, is the user authorized to perform this action?
* **Auth for headless agents (agents without a UI):** How should AI agents without a UI authenticate users?
* **Fine-grained authorization:** How do we ensure AI agents only have the permissions they need to perform their task, and not more?

## What Are We Partnering On?

A2A is being designed to support enterprise-grade authentication and authorization from day one. This means the protocol should be able to provide good answers to those questions and support all of those scenarios in multi-agent systems built with A2A.

We are working with Google Cloud to define A2A auth specs based on secure standards and build SDKs and code samples that showcase A2A auth capabilities. This will include how to integrate A2A with [Auth0](https://auth0.com/) and our new product [Auth for GenAI](https://auth0.com/ai), providing both great security and great auth user experiences.

## How Does Auth Work in A2A?

Agents expose how they operate via [Agent Cards](https://google.github.io/A2A/topics/key-concepts/#fundamental-communication-elements), which include what they can do, how they can communicate (e.g. support streaming?), and how clients should authenticate to them following the [OpenAPI spec](https://github.com/google/A2A/pull/359). Clients use the Agent Card to discover agents and understand how to interact with them.

For example, this agent card defines an HR agent as someone who can receive an email and reply if a person works at a company or not. Clients can authenticate by obtaining an access token via a [client credentials](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) OAuth flow and then providing the token to the agent to authenticate.


```py
AgentCard(
    name='Staff0 HR Agent',
    description='This agent handles external verification requests about Staff0 employees made by third parties.',
    url=f'http://{host}:{port}/',
    version='1.0.0',
    defaultInputModes=HRAgent.SUPPORTED_CONTENT_TYPES,
    defaultOutputModes=HRAgent.SUPPORTED_CONTENT_TYPES,
    capabilities=AgentCapabilities(streaming=True),
    skills=[
        AgentSkill(
            id='is_active_employee',
            name='Check Employment Status Tool',
            description='Confirm whether a person is an active employee of the company.',
            tags=['employment status'],
            examples=[
                'Does John Doe with email jdoe@staff0.com work at Staff0?'
            ],
        )
    ],
    authentication=AgentAuthentication(schemes=['public']),
    securitySchemes={
        'oauth2_m2m_client': OAuth2SecurityScheme(
            description='',
            flows=OAuthFlows(
                authorizationCode=ClientCredentialsOAuthFlow(
                    tokenUrl=f'https://{os.getenv("HR_AUTH0_DOMAIN")}/oauth/token',
                    scopes={
                        'read:employee_status': 'Allows confirming whether a person is an active employee of the company.',
                    },
                ),
            ),
        ),
    },
    security=[{
        'oauth2_m2m_client': [
            'read:employee_status',
        ],
    }],
)
```

One thing we have also been exploring with the Google Cloud team is how agents that don't have a UI (“headless agents”) should authenticate users. For these scenarios, we believe the [Client Initiated Backchannel Authentication](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) (CIBA) flow will be a very valuable tool for developers and architects. CIBA is an OpenID Connect flow that does not rely on redirects in the user's browser. Instead, Agents can reach out to users outside via push notification, email, SMS, etc., for them to authenticate. To give you an idea about what CIBA provides from a security standpoint, it can also be used to meet the strong auth requirements of [FAPI](https://openid.net/wg/fapi/) for financial transactions.

## A Working Sample

Enough chat, let's see some working code :) We've worked with the Google Cloud A2A team to build a demo showcasing these capabilities. Imagine a scenario where:

1. John Doe, who works at Staff0, wants to open a bank account by talking to a chatbot agent
2. Because of internal policies, the bank agent needs to verify that the user is an employee at Staff0, so it contacts the Staff0 HR agent.
3. The Staff0 HR agent can use the Staff0 HR API to check if the user is an employee or not.

For example, it could result in an application flow like this:

<iframe class="vidyard_iframe" title="Auth0 + Google A2A & ADK sample" src="//play.vidyard.com/utu4caQfTCBHbbnXDaWo9a.html?" width="640" height="360" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen referrerpolicy="no-referrer-when-downgrade"></iframe>

To make it simple to run such a sample, we uploaded it to the A2A repo [here](https://github.com/google/A2A/tree/main/samples/python/agents/headless_agent_auth). The sample A2A client plays the part of the Bank Agent. When you run the demo, this is what happens behind the scenes:

![A2A Protocol](https://images.ctfassets.net/23aumh6u8s0i/4NIuz6gLOicE7kPjRnqvuG/25b9a819ef795458117927f488235919/03_Agent2Agent_protocol.png)

## Closing Thoughts

At Auth0 we believe AI has the potential to radically reshape software in general and identity in particular. We believe there will be an explosion in AI agents (non-human identities), which requires more security, finer grained access control and support for various delegation scenarios. 

We look forward to continuing our collaboration with Google Cloud, and helping builders secure their AI agents, both by contributing to AI protocols (e.g. MCP, A2A), new capabilities of [Auth for GenAI](https://auth0.ai/), and developing new products and features that enable an AI powered world.


"a2a"