🔑Identity provider

Enroll an identity provider with the P0 AI Gateway so its JWT-authenticated agents are trusted to access the gateway.

The Identity provider integration enrolls an external identity provider (IdP) with the P0 AI Gateway. 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 integration to federate the gateway with the issuer that mints your agents' tokens, so those agents can reach the MCP servers behind the gateway.

The AI gateway integration is available as an opt-in capability. Contact P0 to enable it for your organization.

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 you define in P0.

Prerequisites

• An existing P0 account at p0.app.

• A registered Gateway component of the AI gateway integration, and the gateway deployed in your environment. See Deploying the P0 AI Gateway.

• 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 and select Identity provider.

2. Click Add provider.

3. Enter the identity provider details, then click Next:

   • Provider identifier: the provider identifier is a unique label which will be used to identify this identity provider in the P0 interface.

   • 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.

4. You will then be provided with a Terraform script to update your agentic gateway resource block. Once complete click Next.

5. Enter your details for the below fields.

   • 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.

   • Replay protection (preview): whether this provider's tokens may be presented more than once. Choose Allow replay (default) to accept a valid assertion every time it arrives, Prevent replay to reject any assertion the gateway has already seen, or Allow replay within grace period to accept a repeat within a Grace period (seconds) you set. Use the grace period for issuers that legitimately re-serve the same signed token, such as SPIRE or GCP service accounts, so a bounded amount of reuse is allowed without turning protection off entirely.

6. Click Finish and now the identity provider now appears in the integration's list of enrolled providers.

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 .*.

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.
Replay protection (preview)	—	Select	Whether this provider's tokens may be presented more than once. Allow replay (default) accepts every repeat. Prevent replay rejects any repeat. Allow replay within grace period accepts a repeat within a Grace period (seconds) you set. The gateway enforces the chosen policy.

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. It maps the client subject from the first available of the federating token's:

• external_sub claim, if set

• email claim, if set and if the email_verified claim is true

• sub claim

• 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.

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

When a provider sets Replay protection, the gateway applies that policy to each assertion the provider presents. Matching the provider tells the gateway which policy to enforce; the gateway then decides whether to accept a repeated assertion. Prevent replay rejects any assertion it has already seen. Allow replay within grace period accepts a repeat within the grace period you set, which lets issuers that legitimately re-serve the same signed token, such as SPIRE or GCP service accounts, keep working. Allow replay, the default, accepts every repeat.

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 and open the Clients tab.

2. Click Register 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, in this order:

   • Use the external_sub claim if the provider sets one. Some providers set this claim to group several of their subjects into a single agent.

   • If the provider does not set it, use the verified email. For a GCP service account, use its email, such as [e-mail].

   • If there is no verified email either, use the token subject (the sub claim). For GitHub Actions, use a subject such as repo:my-org/my-repo:ref:refs/heads/main.

   The order matters. P0 turns the identity you enter into a subject the same way it turns an incoming token into a subject. If a provider sets external_sub and you register the agent's email instead, the client is stored under a subject that token validation never looks up, and the agent can never authenticate.

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.

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 Event Log tab of the Agentic Access page: the identity must match the claim its provider presents.

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 you want to expose behind the gateway.

• Define the Agentic access policies that govern what trusted agents can do.