Overview
Policies you define decide which analyzer proposals move forward without waiting for a person. Zenable’s analyzers already score every proposal against a rubric; a policy turns that score into an automated decision — accept proposals at or above a threshold, optionally decline proposals below a floor, and leave everything in between for human triage on Insights. Nothing is auto-approved unless a policy you created says so.
Policies never bypass approval workflows. If an approval flow gates the change, an automated approval files the same request a human would — governance stays the intentional last stop. A policy only replaces the triage click, not the approval.
Global-scope proposals are never policy-accepted or auto-declined, regardless of policy configuration, because their blast radius is too large — a global-scope change applies everywhere. They always route to human review, even when a policy would otherwise match.
What can be policy-accepted
Each policy selects one or more proposal kinds:
| Proposal kind | Produced by | What accepting does |
|---|
| New requirement proposals | Repository analysis of merged PRs | Promotes the proposed requirement to an active (beta) requirement and queues guardrail generation |
| Requirement refinements | Requirement refinement | Promotes the proposed new version to the family’s live version |
| Requirement merges | Requirement evolution analysis | Promotes the merged requirement, records lineage, and deprecates the source requirements |
| Requirement splits | Requirement evolution analysis | Promotes every split result, records lineage, and deprecates the source requirement |
Policies
A policy is the unit of configuration — create as many as you need:
- Accept threshold (0–10) — proposals scoring at or above this are accepted automatically.
- Decline floor (0–10, optional) — proposals scoring below this are declined automatically and move out of the triage queue. Zenable defaults to 6 and allows customization on the Agent Policies page.
- Target selector (optional) — narrow the policy to matching proposals using a reusable target selector, e.g. only proposals for certain scopes or from a specific analysis source.
- Daily cap (optional) — a per-policy limit on automated accepts per day, on top of the tenant-wide daily budget. Proposals over budget simply wait for the next day (or a person).
- Enabled — disabled policies keep their configuration but never act.
When policies overlap
If several enabled policies match the same proposal, the strictest threshold wins — the proposal must satisfy every matching policy’s bar to be accepted. A decline only happens when every floor-bearing policy would decline it and no matching policy would individually accept it; conflicting policies land the proposal on a human instead.
Policies are governed changes
Approval policies decide what moves forward without a person, so changing one is itself gateable: approval flows can target approval_policy_create, approval_policy_update, and approval_policy_delete. A tenant can require a human sign-off on any change to what a policy accepts.
Scoring rubrics
Every proposal kind is scored against a rubric of up to six weighted dimensions. Zenable ships built-in rubrics per kind; each dimension’s description is the verbatim instruction the scoring model follows.
- Customize a rubric under Approvals → Policy evaluation → Scoring Rubrics — the editor seeds from the built-in defaults so you tune rather than start blank.
- Tenant default — mark one rubric per kind as the default; analyzers use it whenever no configuration profile picks a different one.
- Configuration profiles can link specific rubrics, so different repos can be scored against different bars.
Scores are computed when the proposal is created and stored with it — editing a rubric affects future proposals, not the existing queue.
How runs work
The policy evaluation engine runs on Zenable’s analysis scheduler (roughly daily) and compares each open proposal’s stored score against your policies. You can also trigger a run on demand with Run now. Automated accepts show a Policy-accepted badge on Insights, and every accept records which policies set the binding bar.
A tenant-wide daily budget bounds total automated accepts per day, independent of per-policy caps, so a runaway analyzer can never flood your requirement set.
Required Permissions
| Permission | Grants |
|---|
approvals:read | View approval policies |
approvals:manage | Create, edit, and delete approval policies; trigger a run |
settings:read | View scoring rubrics |
settings:manage | Create, edit, and delete scoring rubrics |
API Reference
Approval Policies
| Method | Endpoint | Description | Permission |
|---|
| GET | /api/data/approval-policies | List policies (pass ?include_disabled=true to include disabled) | approvals:read |
| POST | /api/data/approval-policies | Create a policy | approvals:manage |
| PUT | /api/data/approval-policies/{id} | Update a policy | approvals:manage |
| DELETE | /api/data/approval-policies/{id} | Delete a policy | approvals:manage |
| POST | /api/data/approval-policies/run | Schedule a run now | approvals:manage |
Scoring Rubrics
| Method | Endpoint | Description | Permission |
|---|
| GET | /api/data/approval-policy-rubrics | List rubrics (filter with ?assessment_kind=) | settings:read |
| GET | /api/data/approval-policy-rubrics/defaults | Built-in default rubric per proposal kind | settings:read |
| POST | /api/data/approval-policy-rubrics | Create a rubric | settings:manage |
| PUT | /api/data/approval-policy-rubrics/{id} | Update a rubric (new version) | settings:manage |
| DELETE | /api/data/approval-policy-rubrics/{id} | Delete a rubric | settings:manage |
