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 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 Policy Studio, 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.

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 configure an access policy that allows access to it before you expect list to return values.

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 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 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 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:

  {"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 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 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. When the P0 control plane is unreachable, the gateway continues configured access:

  • Existing sessions / access continue as provisioned

  • Access leases expire on schedule

  • New sessions can be created by registered clients

  • New client registrations, new access leases, and kill switch are unavailable until controller reconnection

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