> 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/request-routing/configure-your-first-access-policy.md).

# Configure your first access policy

Access policies give you fine-grained control over who can request access, which resources they can request, and how those requests are approved. This guide walks you through creating your first policy in Policy Studio.

{% hint style="info" %}
Access policies require a **Pro-tier** P0 subscription.
{% endhint %}

## Prerequisites

Before you begin, confirm the following:

* A P0 account with a **Pro-tier** subscription.
* **Owner** or **Security Reviewer** role in your P0 organization.
* At least one [resource integration](/integrations/resource-integrations.md) installed (AWS, Google Cloud, Azure, Kubernetes, or another supported resource).
* A [directory integration](/integrations/directory-integrations.md) configured (Google Workspace, Okta, or Microsoft Entra ID) if you plan to use group-based policies.

## Open Policy Studio

1. Sign in to [p0.app](https://p0.app).
2. Navigate to **Policy Studio** in the sidebar, or go to `https://p0.app/o/<your-organization>/policies`.

You see a list of existing policies. If this is your first time, the list may be empty or contain a default policy.

{% hint style="info" %}
Toggle between **Table View** and **YAML View** using the segmented control at the top of the list to see your policies in different formats.
{% endhint %}

## Create a new policy

1. Click **Add New Policy**.

   The policy editor opens in **Guided mode**, which provides a visual form for building your policy. To edit raw YAML instead, select **Advanced mode** from the dropdown menu in the header.
2. Enter a descriptive name for your policy in the name field at the top (for example, "Engineering — AWS read-only").

The editor has three sections: **Identity**, **Resource(s)**, and **Actions**. Configure each one in order.

## Define the identity (who can request)

The **Identity** section specifies which users can make requests that match this policy.

1. In the **Identity** section, select one of the following:
   * **Any** — Matches all users in your organization.
   * **User** — Matches a specific user or directory group.
2. If you selected **User**, choose either:
   * **Specific user** — Enter the user's email address.
   * **Directory group** — Select your directory provider and enter the group identifier.

{% hint style="info" %}
**Finding your group identifier:**

* **Google Workspace:** The group email address (for example, `engineering@yourcompany.com`).
* **Okta:** The group ID from the admin console URL. See the [Okta documentation](https://support.okta.com/help/s/article/how-to-find-group-ids-through-the-okta-user-interface?language=en_US) for details.
* **Microsoft Entra ID:** The group's UUID from the Entra admin center.
  {% endhint %}

### Example

To create a policy for your engineering team using Google Workspace:

* Select **User** then **Directory group**.
* Directory: **Google Workspace**
* Group ID: `engineering@yourcompany.com`
* Label: `Engineering`

## Define the resource (what they can request)

The **Resource** section specifies which resources this policy applies to.

1. In the **Resource** section, select one of the following:
   * **Any resource** — Matches all integrated resources.
   * A specific integration (for example, **AWS**, **Google Cloud**, **Kubernetes**).
2. If you selected a specific integration, optionally configure:
   * **Access type** — Restrict to a specific type (for example, `role`, `permission-set`, or `resource` for AWS).
   * **Filters** — Narrow the scope further by matching resource properties.

### Add a resource filter

Filters let you control which specific resources within an integration can be requested.

1. Click **Add Filter** in the resource section.
2. Select the **filter type** (for example, `policy`, `role`, `resource`).
3. Choose the **effect**:
   * **Include only** — Allow requests for resources that match the pattern.
   * **Exclude only** — Block requests for resources that match the pattern.
   * **Exclude all** — Disable this resource type entirely.
4. Enter the **pattern** (a regular expression) to match against.

{% hint style="info" %}
Patterns are unanchored by default. Use `^` and `$` to anchor patterns. For example, `^true$` matches the exact string "true", while `FullAccess` matches any resource containing "FullAccess" in its name.
{% endhint %}

### Example

To restrict AWS access to non-admin permission sets:

* Integration: **AWS**
* Access type: **permission-set**
* Filter: `permission-set`, Effect: **Exclude only**, Pattern: `FullAccess|Admin`

## Define the actions (how requests are approved)

The **Actions** section specifies how matching requests are handled.

1. Select an approval type:

| Approval type  | Behavior                                                                                                                                                                                        |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **P0**         | Routes to your configured Security Reviewers                                                                                                                                                    |
| **Group**      | Routes to members of a specific directory group                                                                                                                                                 |
| **Persistent** | Automatically grants access (standing access)                                                                                                                                                   |
| **Deny**       | Denies all matching requests                                                                                                                                                                    |
| **Auto**       | Automatically approves if the requestor is on-call (requires [PagerDuty](/integrations/approval-integrations/pagerduty.md) or [Incident.io](/integrations/approval-integrations/incidentio.md)) |
| **Escalation** | Routes to on-call users for priority approval                                                                                                                                                   |

2. Configure approval options as needed:
   * **Require reason with request** — Requestors must provide a justification.
   * **Allow self-approvals** — Requestors can approve their own requests.
3. To add multiple approvers, click **Add** to create additional approval rules. When multiple approvers are configured, approval from any one approver is sufficient.

### Example

To route engineering AWS requests to the SRE team with mandatory justification:

* Approval type: **Group**
* Directory: **Google Workspace**
* Group ID: `sre-team@yourcompany.com`
* Label: `SRE Team`
* Enable **Require reason with request**

## Save and enable the policy

1. Review your policy configuration across all three sections.
2. Click **Save Policy**.
3. Confirm the policy appears in the policies list with the **Enabled** toggle turned on.

{% hint style="warning" %}
Policies take effect immediately after saving. When you save a new policy, it becomes part of your active workflow and applies to all later access requests.
{% endhint %}

## Verify the policy

1. Have a user who matches the identity criteria make a test access request via Slack (`/p0 request`), the [P0 CLI](/p0-cli/p0-commands-and-usage/p0-request.md), or the [web request modal](/access-management/just-in-time-access/requesting-access/web-request-modal.md).
2. Confirm the following:
   * The request is created (not blocked by a missing match).
   * The correct approvers receive the approval notification.
   * Resources outside the policy's filters are not available for request.

{% hint style="info" %}
If the requestor sees *"This resource doesn't exist, or your organization doesn't allow this principal to access this resource"*, no policy matches their request. Review the identity and resource criteria in your policy.
{% endhint %}

## Common policy patterns

### Separate approvers by environment

Route development requests to peer engineers with self-approval, and production requests to managers without self-approval:

```yaml
# Development — peer approval with self-approve
- requestor:
    type: group
    id: engineering@yourcompany.com
    label: Engineering
    directory: workspace
  resource:
    type: integration
    service: aws
    filters:
      policy:
        effect: keep
        key: arn
        pattern: "^arn:aws:iam::111111111111:policy/"
  approval:
    - type: group
      id: engineering@yourcompany.com
      label: Engineering
      directory: workspace
      options: { allowOneParty: true }

# Production — manager approval, no self-approve
- requestor:
    type: group
    id: engineering@yourcompany.com
    label: Engineering
    directory: workspace
  resource:
    type: integration
    service: aws
    filters:
      policy:
        effect: keep
        key: arn
        pattern: "^arn:aws:iam::222222222222:policy/"
  approval:
    - type: group
      id: eng-managers@yourcompany.com
      label: Engineering Managers
      directory: workspace
      options: { allowOneParty: false, requireReason: true }
```

### Auto-approve on-call engineers

Automatically approve requests from engineers who are currently on-call in PagerDuty:

```yaml
- requestor:
    type: group
    id: engineering@yourcompany.com
    label: Engineering
    directory: workspace
  resource:
    type: any
  approval:
    - type: auto
      integration: pagerduty
      options: { requireReason: true }
```

### Block sensitive roles

Deny all requests for the Google Cloud Owner role:

```yaml
- requestor:
    type: any
  resource:
    type: integration
    service: gcloud
    accessType: role
    filters:
      role:
        effect: keep
        key: id
        pattern: roles/owner
  approval:
    - type: deny
```

## Understand policy evaluation order

When a request matches multiple policies, P0 evaluates them in this order:

1. **Deny** — If any matching policy specifies **Deny**, the request is denied immediately.
2. **Persistent** — If any matching policy specifies **Persistent** (always allowed), the request is automatically approved.
3. **Auto** — If a matching policy specifies auto-approval, P0 checks the requestor's on-call status.
4. **Manual approval** — For all other matches, P0 notifies the combined set of approvers. Approval from any one approver is sufficient.

{% hint style="info" %}
For a complete reference of policy syntax, filter options, and evaluation logic, see the [Access Policies](/access-management/just-in-time-access/request-routing.md) reference.
{% endhint %}

## Next steps

* Add [resource-specific filters](/access-management/just-in-time-access/request-routing/aws-filtering.md) to fine-tune which AWS, [Google Cloud](/access-management/just-in-time-access/request-routing/google-cloud-filtering.md), [Azure](/access-management/just-in-time-access/request-routing/microsoft-azure-filtering.md), or [SSH](/access-management/just-in-time-access/request-routing/ssh-filtering.md) resources users can request.
* Configure [PagerDuty](/integrations/approval-integrations/pagerduty.md) or [Incident.io](/integrations/approval-integrations/incidentio.md) for on-call auto-approvals.
* Use the [Access Policies API](/access-management/just-in-time-access/just-in-time-api/routing-rules-api.md) to manage policies programmatically.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.p0.dev/access-management/just-in-time-access/request-routing/configure-your-first-access-policy.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.