Requesting access

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

Once an agent connects to a server behind the gateway, 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, 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 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: route, auto-approve, or deny agent requests

• Just-in-time access overview: the approval workflow agents participate in

• p0 claude mcp add: connect Claude Code to a gated server