# 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


---

# Agent Instructions: 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:

```
GET https://docs.p0.dev/getting-started/configure-your-first-access-policy.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.