> 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/agentic-access/using-the-gateway/requesting-access.md).

# Requesting access

How an AI agent requests, checks, uses, and relinquishes just-in-time access to the MCP servers and agents behind the P0 AI Gateway.

Once an agent [p0 claude mcp add](/p0-cli/p0-commands-and-usage/p0-claude-mcp-add.md), it doesn't hold standing access to the underlying resource. Instead, the gateway wraps the server's tools with **access meta-tools**, and the agent requests just-in-time access through the same P0 workflow that governs human requests, including [Policy Studio](/policy-studio/policy-studio.md), approvals, and audit trail.

## The access meta-tools

Alongside the server's own tools, the gateway exposes four meta-tools to the agent:

| Tool         | What it does                                                                                                                                                                                                          |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `list`       | Lists possible values for access-request fields (for example, available AWS accounts or resources), so the agent can fill in the request correctly. The agent only calls it when it doesn't already know the value.   |
| `access`     | Submits an access request to P0 on behalf of the authenticated identity: the user for a user-driven session, or the agent the token was issued for in a headless one. Returns a request ID and a link to the request. |
| `check`      | Polls whether a submitted request has been granted.                                                                                                                                                                   |
| `relinquish` | Revokes an active grant and tears down the session.                                                                                                                                                                   |

The server's own tools are always visible to the agent, but calling them requires the request ID of a granted access request. Without one, the call fails and directs the agent to use `access` and `check` first. This means a prompt-injected or misbehaving agent can't bypass the request flow: the tools don't work without a live grant.

{% hint style="info" %}
An empty `list` result isn't an error. `list` enumerates resources that exist and that the access policy allows the agent to request. In a new project or account, create at least one resource, such as a bucket or instance, and an access policy that allows access to it before you expect `list` to return values. See [Configure your first access policy](/getting-started/configure-your-first-access-policy.md).
{% endhint %}

## The request loop

A typical session looks like this:

1. **The agent discovers what to request.** If it doesn't already know the right values (for example, which project or account hosts a resource), it calls `list` to enumerate valid options for each request field.
2. **The agent requests access.** It calls `access` with the arguments describing the resource, role, and reason. The gateway submits a P0 access request on behalf of the authenticated identity, and returns the request ID together with a link to the request in P0.
3. **P0 evaluates the request.** Your [Agentic access policies](/policy-studio/policy-studio/agentic-access-policies.md) decide what happens next: the request can be auto-approved, denied, or routed to approvers in Slack or the P0 web app, exactly like a human-initiated request.
4. **P0 provisions access.** Access is provisioned either in the upstream system or in the gateway. (See [Custom](/agentic-access/agentic-gateway/mcp-server/custom.md#access-control-method)).
5. **The agent polls for the outcome.** It calls `check` with the request ID. While the request is pending approval, `check` tells the agent to keep polling, for up to 30 minutes. When the request is granted, `check` confirms the agent can start calling the server's tools. If it's denied or errors, the agent is told to stop.
6. **The agent uses the tools.** Each tool call carries the request ID. The gateway verifies the grant is still live, obtains the short-lived credential for the session, and runs the tool in an isolated, per-session environment. The credential is never exposed to the agent. Some target systems need a moment for a new permission to take effect, so a call made immediately after the grant may need a retry. The tool description tells the agent how long to keep trying: up to 30 seconds for AWS, and up to 2 minutes for Google Cloud, which is the slower of the two to propagate.
7. **The agent relinquishes access.** When the work is done (for example, when the user tells the agent they're finished), the agent calls `relinquish`. The gateway revokes the P0 grant and tears down the session.
8. **P0 removes access.** Access is removed from the upstream system and in the gateway.

## Requesting access to an agent

Agents behind an [A2A bridge](/agentic-access/agentic-gateway/a2a-bridge.md) are requested the same way, through a server P0 adds for you. Configuring the first bridge on a gateway installs an MCP server named `a2a-<gateway>`, labelled **Agentic access**. It appears in your list of configured servers even though you never added it, it carries no tools of its own, and it goes away when you remove the last bridge on that gateway. Its only job is to broker access to the agents your bridges front.

The same meta-tools apply, with different arguments:

* `list` enumerates the bridges configured on the gateway. Agent IDs don't come from `list`. The agent is told which agent to call, usually as `<bridge>/<agent>`.
* `access` takes the bridge, one or more agent IDs, and a reason:

  ```json
  {"argv": ["billing-bridge", "invoice-reader", "--reason", "Reconciling a customer's July invoice"]}
  ```
* `check` polls the request and `relinquish` gives the access back, exactly as they do for a tool-calling server.

P0 evaluates the request against your [Agentic access policies](/policy-studio/policy-studio/agentic-access-policies.md) like any other request, so the same approval routing and audit trail apply.

### Calling the agent

A granted agent calls its target through the gateway rather than at the agent's own address:

```
https://<your-gateway>/a2a/<bridge>/agents/<agent>
```

The target's agent card is served at `.../.well-known/agent-card.json` on that same address. The card and its protected-resource metadata answer without authentication, so an agent can discover what it is about to call. Everything else needs both the caller's gateway token and a live grant for that specific agent.

A call without a grant is refused with `403` and `Not allowed to call agent "<agent>"`. Refusals are recorded in the [Event log](/agentic-access/using-the-gateway/event-log.md) next to the calls that succeed, so a blocked attempt is visible rather than silent.

## Session behavior

* **Per-session isolation.** Each grant runs in its own isolated environment, keyed to the user, the agent session, and the request. Sessions are never shared across users or grants.
* **Continuous verification.** Access is enforced on every tool call, depending on the access control method:
  * *Upstream*. The target system enforces access via its internal IAM controls.
  * *Tool-level.* The gateway enforces access based on permitted tool names.
  * *Annotation-level.* The gateway enforces access based on permitted tool annotations.
* **Expiration.** Access is automatically removed when the access lease expires:
  * The gateway prevents all tool calls within the session.
  * Access is removed from the target system's IAM configuration.
* **Kill switch.** If the access lease is terminated early (due to the agent relinquishing access, or an admin revoking access), session access and authorization is removed per expiration.

### Failure tolerance

If the gateway can't reach P0, it fails open for access that already exists and fails closed for anything that needs P0 to change state:

* *Fail-open.* Existing sessions and access continue as provisioned, access leases expire on schedule, and registered clients can create new sessions.
* *Fail-closed.* New client registrations, new access leases, and the kill switch are unavailable until the controller reconnects.

## Related documentation

* [Agentic access policies](/policy-studio/policy-studio/agentic-access-policies.md): route, auto-approve, or deny agent requests
* [Just-in-time access](/access-management/access-management/just-in-time-access.md): the approval workflow agents participate in
* [p0 claude mcp add](/p0-cli/p0-commands-and-usage/p0-claude-mcp-add.md): connect Claude Code to a gated server