> 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/getting-started/govern-what-your-ai-agents-can-do.md). # 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 [P0 Runtime Access for AI](/readme/agentic-control-plane.md) 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](#deploy-and-register-the-gateway "mention") 2. [#federate-your-cloud-credentials](#federate-your-cloud-credentials "mention") 3. [#configure-an-mcp-server](#configure-an-mcp-server "mention") 4. [#write-an-agentic-access-policy](#write-an-agentic-access-policy "mention") 5. [#connect-claude-code](#connect-claude-code "mention") {% hint style="info" %} 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. {% endhint %} ## 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. {% content-ref url="/pages/DxDPvztKcu10tMdbyT9p" %} [Deploying the gateway](/agentic-access/agentic-gateway/gateway/deploy.md) {% endcontent-ref %} 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 [Gateway](/agentic-access/agentic-gateway/gateway.md#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. {% content-ref url="/pages/X0ARfqCNcZ5IGLrJ9d2b" %} [AWS OIDC](/agentic-access/credential-sources/aws-oidc.md) {% endcontent-ref %} {% content-ref url="/pages/m5v1AsKgVJsjKd4waW4G" %} [GCP Workload Identity Federation](/agentic-access/credential-sources/gcp-wif.md) {% endcontent-ref %} Both components build on the base [AWS](/integrations/resource-integrations/aws.md) or [Google Cloud](/integrations/resource-integrations/google-cloud.md) 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. {% content-ref url="/pages/p5ryVVs9GVMeChc6rwLf" %} [MCP server](/agentic-access/agentic-gateway/mcp-server.md) {% endcontent-ref %} ## 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. {% content-ref url="/pages/uo6UZ93RDDYYPSaE1fh1" %} [Agentic access policies](/policy-studio/policy-studio/agentic-access-policies.md) {% endcontent-ref %} {% hint style="info" %} Agent-driven requests only match policies whose requestor type is `agentic` or `any`. Your existing human-only rules never apply to agents. {% endhint %} ## 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 ([Installing p0 CLI](/p0-cli/installing-p0-cli.md)): ```bash p0 claude mcp list p0 claude mcp add aws ``` Quit and reopen Claude Code after adding a server so it reloads the configuration. {% content-ref url="/pages/KY5ElNpzG5WySBPKUpJC" %} [Use MCP servers with Claude Code](/agentic-access/using-the-gateway/using-mcp-servers.md) {% endcontent-ref %} 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](/agentic-access/using-the-gateway/requesting-access.md) for how that exchange works. ## Optional components None of these are required to get an agent working through the gateway: * [Identity provider](/agentic-access/identity-provider.md): 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](/agentic-access/agentic-gateway/a2a-bridge.md): put an upstream agent host behind the gateway so agent-to-agent calls pass under policy too. * [Connect an MCP client](/agentic-access/using-the-gateway/connect-an-mcp-client.md): connect a client other than Claude Code, including one you register yourself. * [JWT-SVID](/agentic-access/using-the-gateway/spiffe-svid.md): identify workloads with SPIFFE identities issued by your own infrastructure. * [Event log](/agentic-access/using-the-gateway/event-log.md): link a log provider so P0 shows every tool call your agents made, the caller behind it, and whether policy allowed it.