> For the complete documentation index, see [llms.txt](https://docs.p0.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.p0.dev/integrations/resource-integrations/agentic-gateway/identity-provider.md).

# Identity provider

The **Identity provider** component enrolls an external identity provider (IdP) with the [P0 AI Gateway](/readme/agentic-control-plane.md). Once enrolled, agents that present a JWT issued by that provider are trusted at the gateway, provided the token's claims match the patterns you configure. Use this component to federate the gateway with the issuer that mints your agents' tokens, so those agents can reach the [MCP servers](/integrations/resource-integrations/agentic-gateway/mcp-server.md) behind the gateway.

{% hint style="info" %}
The Agentic Gateway integration is available as an opt-in capability. Contact P0 to enable it for your organization.
{% endhint %}

Enrolling an identity provider establishes **issuer trust**: it tells the gateway which token issuers to accept and which audience and subject claims those tokens must carry. When a matching token arrives, P0 resolves it to an individual agent client, either by registering the client automatically or by matching one you pre-registered, depending on the provider's **Dynamic registration** setting. Enrolling a provider does not, on its own, grant access to any resource. Every accepted request is still authorized against the [policies](/access-management/just-in-time-access/access-policies/agentic-access-policies.md) you define in P0.

## Prerequisites

* An existing P0 account at [p0.app](https://p0.app/).
* A registered [Gateway](/integrations/resource-integrations/agentic-gateway/gateway.md) component, and the gateway deployed in your environment. See [Deploying the P0 AI Gateway](/getting-started/deploying-the-p0-mcp-gateway.md).
* The details of the issuer whose tokens you want to trust: its issuer URL (the `iss` claim) and the audience (`aud`) claim its agent tokens carry, plus the subject (`sub`) or email (`email`) claim values to narrow matching to specific agents.

## Enroll an identity provider

1. Navigate to **Integrations** on [p0.app](https://p0.app) and select **Agentic gateway**, then choose the **Identity provider** component.
2. Click **Add identity provider**.
3. Enter the identity provider details, then finish the configuration:
   * **Issuer**: the issuer URL of the identity provider, matching the `iss` claim in the tokens it issues. Enter it as a full URL, such as `https://your-idp.example.com/`. P0 matches this value against the token's `iss` claim exactly, so it must match the issuer your provider presents character for character.
   * **Audience pattern**: a pattern that a token's audience (the `aud` claim) must match to be accepted. A token is accepted when at least one of its audience values matches this pattern.
   * **Subject pattern**: an optional pattern that a token's subject (the `sub` claim) must match to be accepted. Leave it empty to accept any subject.
   * **Email pattern**: an optional pattern that a token's email (the `email` claim) must match to be accepted. When set, the email must also be verified. Leave it empty to accept any email.
   * **Dynamic registration**: whether P0 automatically registers agents whose tokens match this provider. Enable it to let P0 register each matching agent as a client the first time it validates the agent's token. Leave it disabled to require that each agent client be pre-registered before P0 accepts its tokens.
4. The identity provider now appears in the component's list of enrolled providers.

{% hint style="info" %}
**Audience pattern**, **Subject pattern**, and **Email pattern** are regular expressions, not literal strings. To match an exact value, anchor the expression, for example `^my-agent$`. To accept any value, either leave the optional **Subject pattern** or **Email pattern** empty or use `.*`.
{% endhint %}

You can enroll more than one identity provider. A token is trusted if it matches **any** enrolled provider.

## Fields

| Field                    | Claim   | Matching                      | Description                                                                                                                                                            |
| ------------------------ | ------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Issuer**               | `iss`   | Exact match                   | The issuer URL of the identity provider. Must be a valid URL and match the token's `iss` claim exactly.                                                                |
| **Audience pattern**     | `aud`   | Regular expression            | A token is accepted when at least one of its `aud` values matches this pattern.                                                                                        |
| **Subject pattern**      | `sub`   | Regular expression (optional) | When set, the token's `sub` claim must match this pattern. Leave empty to accept any subject.                                                                          |
| **Email pattern**        | `email` | Regular expression (optional) | When set, the token's `email` claim must match this pattern and must be verified. Leave empty to accept any email.                                                     |
| **Dynamic registration** | —       | Toggle                        | When enabled, P0 registers a matching agent as a client automatically on first validation. When disabled, the agent client must be pre-registered or validation fails. |

## How it works

When an agent presents a JWT to the gateway, the gateway asks P0 to validate it against the enrolled identity providers. P0 first rejects the token outright if it carries no audience or has a missing, malformed, or expired `exp` claim. It then looks for an enrolled provider that satisfies all of the following:

* The provider's **Issuer** equals the token's `iss` claim.
* At least one of the token's `aud` values matches the provider's **Audience pattern**.
* If the provider sets a **Subject pattern**, the token's `sub` claim matches it.
* If the provider sets an **Email pattern**, the token's `email` claim matches it and is verified.

If no enrolled provider matches, the token is rejected. Matching a provider establishes that the token comes from a trusted issuer and satisfies the configured claim constraints (audience, and any subject/email patterns). It is a trust decision about the issuer, not an authorization decision about a specific resource.

Once a token matches a provider, P0 resolves it to an individual agent client, identified by the token's verified email when it carries one, or by its subject otherwise:

* If the client is already registered, P0 accepts the token, unless that client has been disabled.
* If the client is not yet registered, the provider's **Dynamic registration** setting decides the outcome. With dynamic registration enabled, P0 registers the client automatically and accepts the token. With it disabled, P0 rejects the token until you [register the agent identity](#register-an-agent-identity).

After the token is accepted, the gateway authorizes each tool call against your P0 policies and logs it.

## Register an agent identity

When a provider has **Dynamic registration** disabled, P0 rejects an agent's tokens until you register that agent's identity in advance. Register each agent identity once, before it connects for the first time. Providers that have dynamic registration enabled register their agents automatically, so this step is not required for them.

Registering an agent identity does not create a secret. The agent still authenticates with the JWT its identity provider issues; registration only tells P0 to trust the resolved client.

1. Navigate to **Agentic Access** on [p0.app](https://p0.app) and open the **MCP clients** tab.
2. Click **Register MCP client**.
3. For **Client type**, select **Federated**.
4. Select the **Identity provider** to register the agent against. Only installed identity providers appear in the list.
5. In the **Agent identity** field, enter the identity the way the provider presents it in its tokens:
   * Use the verified email if the provider's tokens carry one. For a GCP service account, use its email, such as `agent@my-project.iam.gserviceaccount.com`.
   * Otherwise, use the token subject (the `sub` claim). For GitHub Actions, use a subject such as `repo:my-org/my-repo:ref:refs/heads/main`.
6. Click **Register agent identity**.

P0 issues a subject for the client and shows it as the **Issued subject**. The agent can now connect through the gateway using a token from this provider.

{% hint style="info" %}
The identity you register must match the claim the provider actually issues. If a registered agent cannot connect, compare its **Issued subject** with the caller shown on the **Activity** tab of the Agentic Access page: the identity must match the claim its provider presents.
{% endhint %}

You can register each identity once per provider. If you register an identity that already exists for the provider, P0 returns an error and leaves the existing client unchanged. A new registration does not reactivate a client that was disabled, and registering the same workload name against two providers creates two distinct clients.

## Next steps

* Configure the [MCP servers](/integrations/resource-integrations/agentic-gateway/mcp-server.md) you want to expose behind the gateway.
* Define the [Agentic Access Policies](/access-management/just-in-time-access/access-policies/agentic-access-policies.md) that govern what trusted agents can do.