> 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/access-management/just-in-time-access/access-policies/agentic-access-policies.md). # Agentic access policies When an AI agent requests access through the [P0 AI Gateway](/readme/agentic-control-plane.md), 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](/access-management/just-in-time-access/access-policies.md) for the general policy format. ## The agentic requestor ```yaml requestor: type: agentic actor: subject: ``` 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. {% hint style="info" %} 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. {% endhint %} ### 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" ```yaml actor: type: any ``` Matches any agent. Use this for blanket rules such as "all agent requests require human approval." #### "Gateway client" ```yaml actor: type: agent-client clientId: ``` Matches an agent using a specific gateway client, identified by the `client_id` issued when the agent registered with P0. #### "User owned" ```yaml actor: type: agent-owner owner: ``` Matches any agent owned by a specific user. #### "Group owned" ```yaml actor: type: owner-group groups: type: group effect: keep|remove groups: - id: label: directory: azure-ad|entra-id|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](/access-management/just-in-time-access/access-policies.md#group). 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. {% hint style="info" %} If you manage policies with the [P0 Terraform provider](https://registry.terraform.io/providers/p0-security/p0/latest/docs/resources/access_policy), 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. {% endhint %} #### "Federated" {% hint style="info" %} The Federated actor rule is in preview. {% endhint %} ```yaml actor: type: provider providerId: subjectPattern: # optional ``` 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" ```yaml actor: type: 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** ```yaml subject: type: any ``` **A human user.** Nest a standard user rule under `user`: ```yaml subject: type: user user: type: any | user | group ``` The nested rule accepts `type: any`, `type: user` with `uid: `, or `type: group`. A group rule lists its groups under a `groups` field and needs an `effect`: ```yaml subject: type: user user: type: group effect: keep|remove groups: - id: label: directory: azure-ad|entra-id|okta|workspace ``` 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 P0 rejects it under a subject: ```yaml subject: type: agent agent: type: agent-client clientId: ``` 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](/access-management/just-in-time-access/access-policies.md#requestor) 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 *\* 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](/access-management/just-in-time-access/access-policies.md#always-allowed) 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: ```yaml - requestor: type: agentic actor: type: agent-client clientId: nightly-reporting-agent subject: type: agent agent: type: agent-client clientId: nightly-reporting-agent 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. {% hint style="warning" %} 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`. {% endhint %} ## 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](/agentic-access/agentic-gateway/mcp-server/aws.md)). The same [resource filters](/access-management/just-in-time-access/access-policies.md#resource) 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](/agentic-access/agentic-gateway/a2a-bridge.md) that fronts the agent * `agent`: the agent being called See [Requesting access](/agentic-access/using-the-gateway/requesting-access.md) for how an agent submits one of these requests. Any [approval rule](/access-management/just-in-time-access/access-policies.md#approval) 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: ```yaml - requestor: type: agentic actor: type: any subject: type: any resource: type: any approval: - type: p0 ``` Block a specific gateway client from requesting any AWS access: ```yaml - requestor: type: agentic actor: type: agent-client clientId: my-ci-agent subject: 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: ```yaml - requestor: type: agentic actor: type: owner-group groups: type: group effect: keep groups: - id: platform@yourorg.com label: Platform directory: workspace subject: type: user user: type: group effect: keep groups: - id: engineering@yourorg.com label: Engineering directory: workspace resource: type: integration service: aws filters: resource: effect: keep key: service pattern: ^s3$ approval: - type: group effect: keep groups: - id: platform@yourorg.com label: Platform directory: workspace ``` Require approval before any agent may call the invoice agents behind the `billing-bridge` A2A bridge: ```yaml - requestor: type: agentic actor: type: any subject: type: any resource: type: integration service: agentic accessType: agent filters: server: effect: keep key: id pattern: ^billing-bridge$ agent: effect: keep key: id pattern: ^invoice- approval: - type: p0 ``` Auto-approve AWS access for agents federated by Okta whose subject starts with `ci-`, and only for a single S3 bucket: ```yaml - requestor: type: agentic actor: type: provider providerId: okta subjectPattern: ^ci- subject: type: any 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](/access-management/just-in-time-access/access-policies.md): the general policy format, resource filters, and approval options * [Requesting access through the Agentic gateway](/agentic-access/using-the-gateway/requesting-access.md): how agents submit and use the requests these policies govern