🤖Govern what your AI agents can do

Deploy the P0 AI Gateway, expose your cloud to agents under policy, and connect Claude Code, so every tool call your agents make is authenticated, authorized, and attributable.

An AI agent with a static cloud credential can do anything that credential allows, at any time, with nothing tying the action back to a person. P0 puts runtime authorization in front of the agent instead. Every tool call is checked against your access policy before it reaches the resource, and each one is attributed to a named person, a specific agent, and the policy that allowed it.

This guide walks the path end to end: deploying the gateway into your cluster, giving it a way to reach your cloud, exposing the first MCP server behind it, writing the policy that governs it, and connecting an agent.

Steps to get started

1. Deploy and register the gateway

2. Federate your cloud credentials

3. Configure an MCP server

4. Write an agentic access policy

5. Connect Claude Code

This guide uses the following terms:

• Gateway: The self-hosted P0 AI Gateway, which runs in your Kubernetes cluster and sits in the data path between your agents and your MCP servers.

• Actor: The agent making a tool call.

• Subject: The person, or other agent, the actor is acting for.

Deploy and register the gateway

The gateway runs in your own Kubernetes cluster, so your data and your upstream credentials stay inside your perimeter. You need a cluster (EKS, GKE, or AKS) and an OAuth 2.0 client at your identity provider for user sign-in.

The P0 console installer is the standard path. It collects your environment's details, generates a Terraform snippet that deploys the gateway, and registers the deployment with P0 in the same pass.

Deploying the gateway

Registration is what lets P0 push configuration to your gateway and enforce policy against it. If you deploy with either Helm chart rather than the console installer, register the gateway afterward with the P0 Terraform provider. See Register a gateway you deployed yourself.

Federate your cloud credentials

For an agent to reach AWS or Google Cloud through the gateway, your cloud has to trust the gateway's identity. You install a federation component once per account or project. It registers the gateway as an OIDC identity provider in your cloud and provisions the roles P0 assumes on the agent's behalf, so agents get short-lived, policy-scoped credentials and you issue no static keys.

Install the component that matches your cloud. The OIDC provider URL it asks for derives from your gateway's own URL, so do this after the gateway is deployed.

📦AWS OIDCGCP Workload Identity Federation

Both components build on the base AWS or Google Cloud integration with IAM management installed on the same account or project.

Configure an MCP server

A registered gateway exposes nothing by itself. You declare each MCP server you want to put behind it, and P0 pushes that definition to the gateway, which then fronts the server for every P0-managed agent in your organization.

P0 ships predefined definitions for AWS and Google Cloud. For anything else, define a custom server.

MCP server

Write an agentic access policy

Agents behind the gateway hold no standing access. They request it through the same just-in-time workflow that governs human requests, and your policy decides what to allow.

Write the rule in Policy Studio with the agentic requestor type, which matches on two halves that must both pass: the actor, the agent making the call, and the subject, whoever it is acting for. A rule that matches any agent acting for a member of your engineering group is a reasonable first policy.

Agentic access policies

Agent-driven requests only match policies whose requestor type is agentic or any. Your existing human-only rules never apply to agents.

Connect Claude Code

Configuring a server is an admin task, and it connects nobody's client. Each developer points their own agent at the gateway from their own machine, using the P0 CLI:

p0 claude mcp list
p0 claude mcp add aws

Quit and reopen Claude Code after adding a server so it reloads the configuration.

Use MCP servers with Claude Code

Your agent now sees the server's tools plus four access meta-tools. It requests access, waits for the grant, and only then can call the tools. See Requesting access for how that exchange works.

Optional components

None of these are required to get an agent working through the gateway:

• Identity provider: enroll an external issuer so agents presenting its JWTs are trusted at the gateway. Use this for headless agents that authenticate with their own tokens rather than a signed-in user.

• A2A bridge: put an upstream agent host behind the gateway so agent-to-agent calls pass under policy too.

• Connect an MCP client: connect a client other than Claude Code, including one you register yourself.

• JWT-SVID: identify workloads with SPIFFE identities issued by your own infrastructure.

• Event log: link a log provider so P0 shows every tool call your agents made, the caller behind it, and whether policy allowed it.