Ctrlk
Sign up for FreeKnowledge Base
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Agentic access policies

When an AI agent requests access through the P0 AI Gateway, the request is evaluated against your access policies just like a human request, but you can match it with a dedicated agentic requestor type. An agentic rule matches on two halves: the actor, the agent that is acting, and the subject, whoever it is acting for.

Configure these rules in Policy Studio, alongside your other access policies. See Access policies for the general policy format.

The agentic requestor

requestor:
  type: agentic
  actor: <actor rule>
  subject: <subject rule>

Both halves must match. The actor rule matches the agent identity bound to the session. The subject rule matches whoever the agent is acting for — a human user, another agent, or anyone.

Agent-driven requests only match policies whose requestor type is agentic or any. Policies with a user or group requestor never match agent-driven requests, so your existing human-only rules don't accidentally apply to agents. Conversely, an agentic rule never matches a request a human makes directly.

Actor rules

The actor is the agent doing the work: the agent directly connected to the gateway, making the call. In an agent-to-agent chain it is the nearest hop, not an agent deeper in the chain.

"Any agent"

actor:
  type: any

Matches any agent. Use this for blanket rules such as "all agent requests require human approval."

"Gateway client"

Matches an agent using a specific gateway client, identified by the client_id issued when the agent registered with P0.

"User owned"

Matches any agent owned by a specific user.

"Group owned"

Matches agents whose owner is (keep) or isn't (remove) a member of one of the listed IdP groups. The group id, label, and directory fields work the same way as in group requestor rules.

Note the two levels of groups here. The actor rule's groups field holds a whole group rule of its own: type: group, an effect, and the list of groups, rather than the list directly.

If you manage policies with the P0 Terraform provider, write groups and effect as direct attributes of the actor block. The provider wraps them into the nested form described earlier in this section when it sends the policy to P0, so the Terraform configuration is flatter than the YAML by one level.

"Federated"

The Federated actor rule is in preview.

Matches agents that authenticate to the gateway by federating a token from an external identity provider, rather than registering as a P0 gateway client. Use this rule to define policy for federated agents by provider instead of per agent.

  • providerId is the identifier of an identity provider enrolled with your P0 AI Gateway (for example, okta or azure-ad). The rule matches when the acting agent was federated by this provider.

  • subjectPattern is an optional regular expression matched against the acting agent's token subject. Set it to narrow the match to specific agents; omit it to match any agent from the provider.

"Same as subject"

Matches only when the acting agent is the same agent as the subject: a headless agent, acting for itself, that reached the resource directly rather than through another agent. Use it to write rules that apply to an agent working on its own behalf without naming a particular client.

Because it requires the actor and subject to be the same identity, this rule never matches a request made on a human's behalf, and never matches a multi-hop agent-to-agent request.

Subject rules

The subject is whoever the actor is acting for. Unlike the actor, it takes a wrapper that says which kind of identity you are matching.

Any subject

A human user. Nest a standard user rule under user:

The nested rule accepts type: any, type: user with uid: <email>, or type: group. A group rule lists its groups under a groups field and needs an effect:

All three of type, groups, and effect are required, and nothing else is accepted. keep matches users who are in one of the listed groups; remove matches users who are in none of them. Approval rules of type: group take the same three fields, plus an optional options block.

Another agent. Nest an actor rule under agent. Only any, agent-client, agent-owner, owner-group, and provider are allowed here — same-as-subject is valid only as an actor rule, and schema validation rejects it under a subject:

This matches requests made on another agent's behalf, which is what an agent-to-agent call looks like from the far end of the chain.

See Access policies for field definitions.

Headless agents

Autonomous agents that don't act on a specific person's behalf (for example, a scheduled reporting job or a CI pipeline) make requests without a bound human identity. Their requests appear in P0 attributed to the agent itself ("Agent <client id> requests…").

There are two ways to match them. Name the agent on the subject side with type: agent when you want a rule for one particular headless agent, or set actor: { type: same-as-subject } when you want a rule that covers any agent acting for itself. A subject of type: user whose nested rule is type: user or type: group never matches a headless session, since there is no human identity to match. A nested type: any still matches headless sessions.

Headless agents run unattended, so their policies typically pair automatic approval with a narrowly scoped resource: the agent gets exactly the access its job needs, without waking a human. For example, auto-approve a nightly reporting agent's AWS requests, but only for a single reports bucket:

Any request the agent makes outside this scope (a different bucket, a different service) doesn't match this rule and falls through to your other policies.

A subject of type: any matches both headless and user-driven sessions. To govern a headless agent distinctly, give it its own gateway client registration and match on its clientId, or use same-as-subject.

Resource and approval

The resource and approval parts of an agentic policy stay the same. The resource is the underlying service the agent is requesting (for example, aws when an agent requests AWS access through the AWS MCP server). The same resource filters you use for human requests apply to agent requests too.

Requests to call another agent are the one case where the resource is the P0 AI Gateway rather than a downstream service. Match them with service: agentic and accessType: agent. Three filters narrow them, each keyed on id:

  • gateway: the gateway that hosts the bridge

  • server: the A2A bridge that fronts the agent

  • agent: the agent being called

See Requesting access for how an agent submits one of these requests.

Any approval rule can be attached: route agent requests to human approvers (p0, group), deny them outright (deny), or approve them automatically based on on-call status (auto, escalation).

Examples

Require Security Reviewer approval for everything any agent requests:

Block a specific gateway client from requesting any AWS access:

Let engineers' agents (provided the Platform team owns the agent) request S3 access, with approval routed to Platform:

Require approval before any agent may call the invoice agents behind the billing-bridge A2A bridge:

Auto-approve AWS access for agents federated by Okta whose subject starts with ci-, and only for a single S3 bucket:

Related documentation

PreviousSSH filtering
NextAccess bundles

Last updated