🤖AI gateway
Configure the P0 AI Gateway and the upstream MCP servers and agents it fronts, so P0-managed AI agents can reach them under runtime authorization policy.
The AI gateway integration puts runtime authorization in front of what your agents call: the MCP servers in your environment, and, through an A2A bridge, other agents. Agents don't operate on loose delegation or standing privilege, and every action stays attributable. The P0 AI Gateway sits in the data path, verifies the identity of the originator and the agent on every call, and evaluates each action against the authorization policy defined in P0 Runtime Access for AI before it reaches its target.
This integration has four components:
Registers your self-hosted P0 AI Gateway deployment with P0 so it can enforce policy and report activity.
Configures an upstream MCP server behind the gateway. Once configured, it becomes available to P0-managed agents across your organization.
Places an upstream agent host behind the gateway so agent-to-agent (A2A) calls pass through the gateway under policy.
Points P0 at the logs holding the gateway's tool-call activity, so the Event log can show it.
Prerequisites
An existing P0 account at p0.app.
A Kubernetes cluster to run the gateway in, and permission to create the cloud resources it federates with.
Set up agentic access
Work through these five steps in order. Each one depends on the one before it, and at the end a developer's agent can reach a server behind the gateway under policy.
Deploy and register the gateway. Install the gateway into your own environment and register it with P0, so P0 Runtime Access for AI can supply policy and collect audit activity. The console installer does both in one pass. If you deploy with Helm instead, register the gateway separately as described on the Gateway page.
Federate cloud credentials. Give the gateway an identity your cloud trusts, so it can obtain short-lived credentials for the agents it serves. For AWS, install AWS OIDC. For Google Cloud, install GCP Workload Identity Federation. Install the one that matches the servers you are about to configure, or both.
Configure MCP servers. Declare each MCP server you want to expose behind the gateway. Choose a server P0 defines for you, such as AWS or GCP, or define your own. Nothing is reachable through the gateway until you configure at least one.
Write an agentic access policy. Decide which agents may act, whom they may act for, and what they may reach. Until a policy matches, the gateway authenticates agents but authorizes nothing.
Connect your agents. Each developer connects their own client to the servers behind the gateway, per user and per machine. For Claude Code, the P0 CLI lists the available servers and adds each one you want. For an agent you write yourself, connect an MCP client with the Python example. For an unattended workload with no one to sign in, authenticate with a JWT-SVID.
Optional, depending on your install
These branch off the five steps above. Add the ones your environment calls for.
Enroll an identity provider. For agents that authenticate with a JWT from your own IdP, tell the gateway which token issuer to trust. Agents that sign in interactively don't need this.
Add an A2A bridge. Place an upstream agent host behind the gateway so agent-to-agent calls pass through under the same policy.
Add a log provider. Link one to the gateway so P0 can read back the activity it logs on the Event log tab. Without one, the tab is empty.
Runtime reference
Once agents are connected, these describe what happens on each call rather than anything you set up:
Requesting access: how an agent requests, checks, uses, and relinquishes just-in-time access to the servers and agents behind the gateway.
Agentic client registration API: the API behind client registration, for scripting it yourself.
Event log: review the tool calls your agents made, filter and export them, and open the access request behind each one.
Last updated