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

# Requesting access

Once an agent [connects to a server behind the gateway](/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 your [access policies](/access-management/just-in-time-access/access-policies.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 the user's behalf. 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.

## 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 as the authenticated user, and returns the request ID together with a link to the request in P0.
3. **P0 evaluates the request.** Your [agentic access policies](/access-management/just-in-time-access/access-policies/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. **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 (the gateway instructs it to back off exponentially, 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.
5. **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.
6. **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.

## Session isolation and expiry

* **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.** The gateway re-verifies the grant with P0 during use. If access is revoked in P0 (by the user, an admin, or expiry), the agent's tool calls stop working as soon as the access revocation propagates in the target system (typically under 30 seconds).
* **Idle teardown.** The gateway tears down session environments after 10 minutes of inactivity; the agent's next granted call transparently starts a fresh one.

## Related documentation

* [Agentic access policies](/access-management/just-in-time-access/access-policies/agentic-access-policies.md): route, auto-approve, or deny agent requests
* [Just-in-time access overview](/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