Policy Management in the Console
The Policies page is your operational view of authorization policy across every system in the tenant. Use it to understand coverage, find errors, and open the Git-backed editor when you need to change Rego.
Open it at console.enforceauth.com/policies (or .dev in non-prod tenants).
What you see on the Policies page
The page header summarizes the scope: Manage and analyze authorization policies across all systems.
Two tabs organize the work:
| Tab | Purpose |
|---|---|
| Statistics Overview | Fleet-wide counts, top triggered policies, usage trends |
| Policies | Searchable list of every policy file with status and coverage |
Statistics Overview
The Policy Statistics section shows card counts for Active, Error, Draft, Disabled, and Total Policies, plus Coverage (percentage of policies that have appeared in decision logs).
Each card links to a filtered view on the Policies tab — for example View errors jumps straight to policies in an error state.
Time ranges: 24 hours, 7 days, or 30 days. The 24-hour view adds a day picker for finer-grained investigation.
Below the cards:
- Top 10 Triggered Policies — policy name, usage frequency, success/error percentages, and owning system
- Policy Usage Over Time — hourly (24h) or daily (7d/30d) series for active, error, and draft policies
Use this tab when answering: Are policies healthy? Which rules fire most? Are we flying blind on unevaluated policies?
Policies list
The Policies tab is the working list. Search by file name, then filter by:
- Status — Active, Error, Draft, Disabled (or all)
- Coverage — Evaluated vs never evaluated
- Environment — when your tenant has configured environments
Columns include File Name, Status, System, Inherited By, Imposed On, Coverage, Created, Last Edited, and Last Invoked.
Click a row to open detail. Policies with a pending pull request route to the draft editor (/policies/drafts/:id); deployed policies open the detail view (/policies/:id).
Policy lifecycle states
Status is derived from deployment and evaluation state:
| Status | Meaning |
|---|---|
| ACTIVE | Deployed and available to PDPs via the current bundle |
| ERROR | Deployment or evaluation problem — investigate before promoting |
| DRAFT | Change in flight (typically an open PR) not yet live |
| DISABLED | Intentionally not enforced |
Additional list badges:
- Not deployed — indexed in Git but not yet part of a successful deployment
- Pending PR — open pull request awaiting review or merge
Treat ERROR and never evaluated coverage as operational signals, not just labels.
Creating a policy
Users with policy:create permission and the policy-create feature flag see Create Policy on the Policies page.
The create flow (/policies/new) asks for:
- Entity — which system (or org) owns the policy file
- Policy name — becomes the file name in the Git policy source
- Code — Rego in the Monaco editor (Builder, Flow, and Bundle Index views for supported layouts)
Save Policy opens a pull request in your connected Git repository, then redirects to the draft editor.
If your Git token lacks write access, the editor is read-only and surfaces: Read-only — your Git token doesn't have write permissions to this repository.
Editing deployed policies
From policy detail, Save as Draft creates a PR with your changes (requires policy-edit and Git write permission). The hint text states: Saving will create a pull request with your changes.
The editor supports:
- Policy Files sidebar — browse the connected repo tree
- Code, Builder, Flow, and Bundle Index tabs (Builder/Flow/Index hidden for non-policy data files)
- Rego, JSON, and YAML syntax highlighting
Draft editor and pull requests
The draft page (/policies/drafts/:id) shows Edit Draft: plus the policy file name, with a status banner that polls Git every 60 seconds:
| Banner state | Meaning |
|---|---|
| Under review | PR open, awaiting reviewers |
| Ready for approval | Checks passed, ready to merge |
| Issues found | CI or review blockers |
| Approved | Approved, not yet merged |
| Live | Merged and deployed |
| Closed | PR closed without going live |
Save Changes pushes a new commit to the PR branch. After merge or close, the editor becomes read-only; use Create New Policy to start fresh.
View on GitHub opens the PR when a URL is available.
Decision coverage on a single policy
Policy detail includes a Decision Coverage card:
- Status — Evaluated vs no decisions
- Evaluations — count in the selected window
- Last Evaluated — timestamp, or Never
A policy can be ACTIVE in Git but show no coverage until PDPs evaluate it against real traffic.
Permissions and feature flags
| Capability | Requirement |
|---|---|
| View policies | Standard console access |
| Create policy | policy:create + policy-create flag |
| Edit / Save as Draft | policy-edit flag + Git write on the policy source repo |
Verify success
- Statistics show expected active count after a deployment
- New or edited policy appears with correct System and status
- After merge, draft banner reaches Live and detail shows Evaluated once traffic hits the rule
- Error count trends down after fixing Rego or deployment issues
Related guides
- Entity model — where policies attach (org vs system)
- Deployments — how Git changes become live bundles
- Rego essentials
- Policy authoring best practices
- API Reference