Denied Logo

Policies

Create and manage authorization policies

Policies are the core of Denied. Each policy defines authorization rules written in Rego that evaluate incoming requests and produce allow or deny decisions.

Policy Structure

A policy consists of:

FieldDescription
NameA name for the policy
ReasonA reason that is returned when the policy is triggered
EffectWhether this policy grants access (Allow) or blocks it (Deny)
ContentThe Rego conditions that implement the authorization logic
EnabledWhether the policy is active and included in the OPA bundle

Creating a Policy

  1. Go to Policy StudioPolicies
  2. Click Create Policy

This will open the policy editor where you can start from a templates, write your Rego conditions manually or use the AI-assisted creation.

Multiple Conditions (AND Logic)

You write the conditions that must all be true for the policy to match.

# Allow subject A to perform action B on resource C
input.subject.id == "A"
input.action.name == "B"
input.resource.id == "C"

Each line is a condition. All conditions in a single policy use implicit AND logic.

Multiple Policies (OR Logic)

Create separate policies for OR logic.

The Input Object

The input object contains the authorization request:

input.subject.type          # Subject type (e.g., "user", "agent")
input.subject.id            # Subject identifier
input.subject.properties    # Subject attributes (role, team, etc.)
input.action.name           # Action being performed (e.g., "read", "delete")
input.action.properties     # Action attributes
input.resource.type         # Resource type (e.g., "document", "api")
input.resource.id           # Resource identifier
input.resource.properties   # Resource attributes (owner, visibility, etc.)

Policy Effects

Denied is deny by default: access is not granted unless your policies say otherwise. Define allow policies to explicitly open access when their conditions match.

Allow policies

Each allow policy grants access only when all of its conditions are true. Across policies, any matching allow can grant access — but only if nothing denies the request.

Deny policies

Deny policies explicitly block access when they match. Deny takes precedence: if any deny policy matches, the decision is denied, even when allow policies would otherwise permit it.

Default is deny; allows must be intentional. A matching deny always wins over matching allows.

Managing Policies

Toggling

Enable or disable policies without deleting them using the toggle switch in the policy list. Disabled policies are excluded from the OPA bundle.

Editing

Click Edit on any policy to open the policy in the editor. Changes propagate to your PDP within seconds.

Deleting

Click Delete to permanently remove a policy. Consider disabling instead if you might need it later.

Policy Deployment

When you create or modify a policy:

  1. Changes are saved immediately
  2. The OPA bundle is regenerated
  3. Your PDP pulls the updated bundle (typically every 10-30 seconds)
  4. New authorization requests use the updated policies

On this page