Configure your first access policy

Create and manage access policies in P0 Security's Policy Studio to control who can request access to which resources and how requests are approved.

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.

Access policies require a Pro-tier P0 subscription.

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 installed (AWS, Google Cloud, Azure, Kubernetes, or another supported resource).

• A directory integration 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.

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.

Toggle between Table View and YAML View using the segmented control at the top of the list to see your policies in different formats.

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.

Finding your group identifier:

• Google Workspace: The group email address (for example, [e-mail]).

• Okta: The group ID from the admin console URL. See the Okta documentation for details.

• Microsoft Entra ID: The group's UUID from the Entra admin center.

Example

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

• Select User then Directory group.

• Directory: Google Workspace

• Group ID: [e-mail]

• 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.

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.

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 or Incident.io)
Escalation	Routes to on-call users for priority approval

1. Configure approval options as needed:

   • Require reason with request — Requestors must provide a justification.

   • Allow self-approvals — Requestors can approve their own requests.

2. 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: [e-mail]

• 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.

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.

Verify the policy

1. Have a user who matches the identity criteria make a test access request via Slack (/p0 request), the P0 CLI, or the web request modal.

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.

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.

Common policy patterns

Separate approvers by environment

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

# Development — peer approval with self-approve
- requestor:
    type: group
    id: [e-mail]
    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: [e-mail]
      label: Engineering
      directory: workspace
      options: { allowOneParty: true }

# Production — manager approval, no self-approve
- requestor:
    type: group
    id: [e-mail]
    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: [e-mail]
      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:

- requestor:
    type: group
    id: [e-mail]
    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:

- 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.

For a complete reference of policy syntax, filter options, and evaluation logic, see the Access Policies reference.

Next steps

• Add resource-specific filters to fine-tune which AWS, Google Cloud, Azure, or SSH resources users can request.

• Configure PagerDuty or Incident.io for on-call auto-approvals.

• Use the Access Policies API to manage policies programmatically.