Policies

Policies are the authorization rules. Each policy defines who can do what on which resources.

Policy structure

A policy has:

Field	Description
Name	Human-readable identifier
Effect	ALLOW or DENY
Actions	What actions this policy covers (e.g., read, write)
Resources	Which resources or resource types this policy applies to
Priority	Numeric priority (0–100). Higher priority policies are evaluated first. When two policies match, the higher-priority one wins. Default: 50
Application	Scope the policy to a specific application (optional)

Policy assignment

Policies don't do anything on their own — they need to be assigned. You can assign a policy to:

• A role — All subjects with that role get the policy (RBAC)
• A group — All subjects in that group get the policy (group-based)
• A subject directly — Only that specific subject gets the policy (direct access)

DENY policies

DENY policies take precedence over ALLOW policies. If any applicable DENY policy matches, access is denied regardless of ALLOW policies.

Use DENY policies for:

• Revoking access for specific subjects
• Blocking access to sensitive resources
• Temporary access restrictions

ABAC conditions

Policies can include attribute-based conditions that compare subject, resource, or context attributes at evaluation time. This turns a simple RBAC policy into a fine-grained ABAC policy.

See ABAC Conditions for full syntax and examples.

Example: allow read only when the subject's department matches the resource's department:

{
  "conditions": [
    {
      "attribute_path": "subject.attributes.department",
      "operator": "equals",
      "value": {
        "type": "attribute",
        "path": "resource.attributes.department"
      }
    }
  ]
}

Policy modifiers

Modifiers are toggleable guardrails you can enable on any policy without rewriting the policy itself:

Modifier	Effect
Time window	Policy only applies within a start and end time
IP allowlist	Policy only applies when the request originates from an allowed IP range
MFA required	Policy only applies when the subject has completed multi-factor authentication
Approval required	Policy only applies when an explicit approval flag is set in context

Modifiers are additive — enable multiple modifiers on one policy and all must pass.

Configure modifiers from the policy detail page in the console, or via the Management API.

Policy status

Policies have a status lifecycle:

Status	Meaning
Active	Evaluated normally
Inactive	Exists but skipped during evaluation

Use inactive status to temporarily disable a policy without deleting it. Toggle status from the policy list or detail page.

Policy Tester

The Policy Tester (Policies → detail page → Test tab) lets you evaluate a single policy in isolation against a custom input. Provide a subject, resource, action, and optional context — the tester shows whether the policy would allow or deny and which conditions matched.

Use this to verify a policy before activating it, or to debug why a specific policy is producing unexpected results.

Examples

Policy	Effect	Actions	Resource type	Assigned to
editors-can-read-write	ALLOW	read, write	document	editor role
sales-can-manage-contacts	ALLOW	read, write, delete	contact	Sales Team group
block-contractor-delete	DENY	delete	*	Frank (subject)
office-hours-only	ALLOW	write	production-config	deployer role (with time-window modifier)

Related

• ABAC Conditions — Full condition syntax reference.
• Access Paths — How policies are evaluated across direct, role, group, and ABAC paths.
• Decisions — What happens after a policy evaluates.