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

# Configure Your First Access Policy

By default, P0 routes all access requests to your Security Reviewers. As your team grows, you need more control: route requests to the right approver, restrict access to sensitive resources, or allow automatic approvals for low-risk environments.

*Access policies* let you define these rules. In this tutorial, you create your first access policy that routes requests from your engineering team to a specific approver group.

## What you'll learn

After completing this tutorial, you are able to:

* Navigate to Policy Studio and edit your policy configuration
* Write a policy rule with requestor, resource, and approval sections
* Test your policy with a real access request
* Understand how P0 evaluates multiple policy rules

{% hint style="info" %}
This tutorial takes about 10 minutes.
{% endhint %}

## Before you start

Ensure you have the following:

* A P0 account with Owner permissions
* At least one [resource integration](/integrations/resource-integrations.md) installed (such as AWS, Google Cloud, or Kubernetes)
* A [Slack notifier](/integrations/notifier-integrations/slack.md) connected to receive approval notifications
* A [directory integration](/integrations/directory-integrations.md) installed (Google Workspace, Okta, or Microsoft Entra ID) with at least one group that contains your team members

{% hint style="info" %}
If you haven't set up P0 yet, complete the [Getting started with just-in-time access](/getting-started/getting-started-with-just-in-time-access.md) tutorial first.
{% endhint %}

## Step 1: Open Policy Studio

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

You see a YAML editor where you can define your policy configuration. If this is your first time here, the editor may contain a default configuration or be empty.

{% hint style="info" %}
A *policy configuration* is a collection of one or more policy rules. You have one active policy configuration at any time, but it can contain as many individual rules as you need.
{% endhint %}

## Step 2: Understand the policy structure

Every policy rule has three parts:

| Part          | Purpose                            | Example              |
| ------------- | ---------------------------------- | -------------------- |
| **Requestor** | Who is making the request          | The engineering team |
| **Resource**  | What they are requesting access to | An AWS integration   |
| **Approval**  | Who can approve the request        | The SRE team         |

Here is a minimal policy rule:

```yaml
- requestor:
    type: group
    id: engineering@yourcompany.com
    label: Engineering
    directory: workspace
  resource:
    type: any
  approval:
    - type: group
      id: sre@yourcompany.com
      label: SRE Team
      directory: workspace
```

This rule means: when anyone in the **Engineering** group requests access to any resource, route the approval to the **SRE Team** group.

## Step 3: Create your first policy

Replace the content in Policy Studio with the following configuration, substituting your own values:

```yaml
- requestor:
    type: group
    id: <your-team-group-id>
    label: <Your Team Name>
    directory: workspace
  resource:
    type: any
  approval:
    - type: group
      id: <your-approver-group-id>
      label: <Approver Team Name>
      directory: workspace
      options:
        allowOneParty: false
```

Replace the placeholder values:

| Placeholder                | What to enter                                                                                                                                                                                                         |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `<your-team-group-id>`     | The group identifier for the requestors. For Google Workspace, use the group email (such as `engineering@yourcompany.com`). For Okta, use the group ID from the Okta admin console. For Entra ID, use the group UUID. |
| `<Your Team Name>`         | A human-readable name for the requestor group (such as `Engineering`)                                                                                                                                                 |
| `<your-approver-group-id>` | The group identifier for the approvers, in the same format as above                                                                                                                                                   |
| `<Approver Team Name>`     | A human-readable name for the approver group (such as `SRE Team`)                                                                                                                                                     |

{% hint style="warning" %}
Set the `directory` value based on your identity provider: `workspace` for Google Workspace, `okta` for Okta, or `azure-ad` for Microsoft Entra ID.
{% endhint %}

The `allowOneParty: false` option prevents requestors from approving their own requests. Set this to `true` to allow self-approval.

Click **Save** to activate your policy configuration.

## Step 4: Test your policy

Verify that your policy works by submitting a test access request.

{% tabs %}
{% tab title="Via Slack" %}

1. Open Slack and navigate to the **p0-requests** channel.
2. Enter `/p0 request` and fill in the request details for a resource covered by your policy.
3. Confirm that the approval notification goes to a member of your approver group, not the default Security Reviewers.
   {% endtab %}

{% tab title="Via p0.app" %}

1. Navigate to **Access Management** and click the **Request Access** button.
2. Fill in the request details for a resource covered by your policy.
3. Confirm that the approval notification goes to a member of your approver group, not the default Security Reviewers.
   {% endtab %}
   {% endtabs %}

{% hint style="info" %}
If no policy rule matches a request, P0 blocks the request with the message: *"This resource doesn't exist, or your organization doesn't allow this principal to access this resource."* Ensure your policy configuration covers all requestors who need access.
{% endhint %}

## Step 5: Add a rule for a specific service

Now extend your configuration by adding a second rule that restricts a specific service to a dedicated approver. Add the following rule after your first one:

```yaml
- requestor:
    type: group
    id: <your-team-group-id>
    label: <Your Team Name>
    directory: workspace
  resource:
    type: integration
    service: aws
  approval:
    - type: group
      id: <aws-approver-group-id>
      label: <AWS Approver Team>
      directory: workspace
      options:
        allowOneParty: false
        requireReason: true
```

This rule routes AWS-specific requests to a dedicated approver group and requires the requestor to provide a reason. Your first rule still handles requests for all other services.

Click **Save** to activate the updated configuration.

{% hint style="info" %}
When multiple rules match a request, P0 combines the approvers. Approval from any one matched approver is sufficient to grant access. See [how P0 evaluates access policies](/access-management/just-in-time-access/request-routing.md#evaluation-of-access-policies) for the full evaluation logic.
{% endhint %}

## Summary

You created an access policy configuration in Policy Studio that:

* Routes your team's access requests to a specific approver group
* Adds a service-specific rule for AWS with a required reason
* Replaces the default Security Reviewer approval flow with targeted routing

## What's next

Now that you have a working policy, you can:

* [Deny access](/access-management/just-in-time-access/request-routing.md#deny) to sensitive resources by adding `type: deny` approval rules
* [Filter by resource attributes](/access-management/just-in-time-access/request-routing.md#integration) to restrict which specific roles, policies, or permission sets users can request
* [Set up auto-approval](/access-management/just-in-time-access/request-routing.md#auto) with PagerDuty or Incident.io for on-call engineers
* [Allow standing access](/access-management/just-in-time-access/request-routing.md#always-allowed) for low-risk resources with `type: persistent` rules
* Review the complete [access policies reference](/access-management/just-in-time-access/request-routing.md) for all configuration options