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 the agent and user combination: which agent is acting, and which human 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
  agent: <agent rule>
  user: <user rule>

Both halves must match: the agent rule matches the agent identity bound to the session, and the user rule matches the human on whose behalf the agent acts.

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.

Agent rules

"Any agent"

agent:
  type: any

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

"MCP client"

agent:
  type: mcp-client
  clientId: <client id>

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

"User owned"

agent:
  type: agent-owner
  owner: <owner's email address>

Matches any agent owned by a specific user.

"Group owned"

agent:
  type: owner-group
  groups:
    type: group
    effect: keep|remove
    groups:
      - id: <group identifier>
        label: <human-readable name>
        directory: azure-ad|okta|workspace

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.

"Federated"

The Federated agent rule is in preview.

agent:
  type: provider
  providerId: <identity provider id>
  subjectPattern: <regular expression>   # optional

Matches agents that authenticate to the gateway by federating a token from an external identity provider, rather than registering as a P0 MCP 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 only when every agent in the session was federated by this provider.

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

Federated agents act without a bound human user, so a Federated rule always pairs with user: { type: none }. In Policy Studio, selecting the Federated agent type fixes the User selector to No user.

User rules

The user half accepts the same rule types as a top-level requestor:

• type: any matches any user

• type: user with uid: <email> matches a specific user

• type: group with id, label, and directory matches members of an IdP group

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 user identity. Their requests appear in P0 attributed to the agent itself ("Agent <client id> requests…").

Constrain the agent side to match these sessions: use mcp-client, agent-owner, owner-group, or provider and pair it with user: { type: any }. The provider rule instead pairs with user: { type: none }, which matches only sessions that have no human user. A user or group user rule never matches a headless session, since there is no human identity to match.

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:

- requestor:
    type: agentic
    agent:
      type: mcp-client
      clientId: nightly-reporting-agent
    user:
      type: any
  resource:
    type: integration
    service: aws
    accessType: resource
    filters:
      resource:
        effect: keep
        key: arn
        pattern: ^arn:aws:s3:::nightly-reports$
  approval:
    - type: persistent

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.

user: { type: any } matches both headless and user-driven sessions. To govern a headless agent distinctly, give it its own MCP client registration and match on its clientId.

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.

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:

- requestor:
    type: agentic
    agent:
      type: any
    user:
      type: any
  resource:
    type: any
  approval:
    - type: p0

Block a specific MCP client from requesting any AWS access:

- requestor:
    type: agentic
    agent:
      type: mcp-client
      clientId: my-ci-agent
    user:
      type: any
  resource:
    type: integration
    service: aws
  approval:
    - type: deny

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

- requestor:
    type: agentic
    agent:
      type: owner-group
      groups:
        type: group
        effect: keep
        groups:
          - id: [e-mail]
            label: Platform
            directory: workspace
    user:
      type: group
      id: [e-mail]
      label: Engineering
      directory: workspace
  resource:
    type: integration
    service: aws
    filters:
      resource:
        effect: keep
        key: service
        pattern: ^s3$
  approval:
    - type: group
      id: [e-mail]
      label: Platform
      directory: workspace

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

- requestor:
    type: agentic
    agent:
      type: provider
      providerId: okta
      subjectPattern: ^ci-
    user:
      type: none
  resource:
    type: integration
    service: aws
    accessType: resource
    filters:
      resource:
        effect: keep
        key: arn
        pattern: ^arn:aws:s3:::ci-artifacts$
  approval:
    - type: persistent

Related documentation

• Access Policies: the general policy format, resource filters, and approval options

• Requesting access through the Agentic Gateway: how agents submit and use the requests these policies govern