🛡️Configure Your First Access Policy
Create an access policy in P0 Security's Policy Studio to control who can request access, what they can access, and who approves. A step-by-step tutorial for security administrators.
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
This tutorial takes about 10 minutes.
Before you start
Ensure you have the following:
A P0 account with Owner permissions
At least one resource integration installed (such as AWS, Google Cloud, or Kubernetes)
A Slack notifier connected to receive approval notifications
A directory integration installed (Google Workspace, Okta, or Microsoft Entra ID) with at least one group that contains your team members
If you haven't set up P0 yet, complete the Getting started with just-in-time access tutorial first.
Step 1: Open Policy Studio
Sign in to p0.app.
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.
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.
Step 2: Understand the policy structure
Every policy rule has three parts:
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:
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:
Replace the placeholder values:
<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)
Set the directory value based on your identity provider: workspace for Google Workspace, okta for Okta, or azure-ad for Microsoft Entra ID.
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.
Open Slack and navigate to the p0-requests channel.
Enter
/p0 requestand fill in the request details for a resource covered by your policy.Confirm that the approval notification goes to a member of your approver group, not the default Security Reviewers.
Navigate to Access Management and click the Request Access button.
Fill in the request details for a resource covered by your policy.
Confirm that the approval notification goes to a member of your approver group, not the default Security Reviewers.
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.
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:
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.
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 for the full evaluation logic.
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 to sensitive resources by adding
type: denyapproval rulesFilter by resource attributes to restrict which specific roles, policies, or permission sets users can request
Set up auto-approval with PagerDuty or Incident.io for on-call engineers
Allow standing access for low-risk resources with
type: persistentrulesReview the complete access policies reference for all configuration options
Last updated