> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zenable.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Policy-Based Auto-Approvals

> Turn analyzer quality scores into automated approvals with policies you define

## 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](/insights). Nothing is auto-approved unless a policy you created says so.

Policies never bypass [approval workflows](/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.

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

Configure policies under **Approvals → Approval Policies**.

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

Merges and splits apply atomically: nothing changes until the whole operation (and any approval gating it) completes.

## 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](/approval-workflows#target-types), 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                  |

See [Roles and Permissions](/permissions) for which roles include these permissions.

## 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` |