> For the complete documentation index, see [llms.txt](https://newdocs.keeper.io/en/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://newdocs.keeper.io/en/keeperpam/endpoint-privilege-manager/policies/policy-controls.md).

# Policy Controls

<figure><img src="/files/emQoXyiqKjpSwL5h4vpC" alt=""><figcaption></figcaption></figure>

When a policy is set to **Enforce** status, every action that matches the policy's scope must satisfy one or more **controls** before it is allowed to proceed. Controls define exactly what the user must do — or what Keeper will do automatically — in response to a privileged action.

Controls are configured per-policy and apply consistently across all supported policy types. The available controls differ slightly by [Policy Types](/en/keeperpam/endpoint-privilege-manager/policies/policy-types.md):

* [**Privilege Elevation**](/en/keeperpam/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md) and [**File Access**](/en/keeperpam/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md) support the full set (Auto-Approve, Auto-Deny, Admin Approval, Justification, MFA);
* [**Command Line**](/en/keeperpam/endpoint-privilege-manager/policies/policy-types/command-line-policy-type.md) supports Admin Approval, Justification, and MFA;
* [**Least Privilege**](/en/keeperpam/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type.md) supports Auto-Approve and Auto-Deny.
* The three Agentic AI Governance policy types ([**Agentic AI**](/en/keeperpam/endpoint-privilege-manager/policies/policy-types/agentic-ai-policy.md), [**Agentic Access**](/en/keeperpam/endpoint-privilege-manager/policies/policy-types/agentic-access-policy.md), and [**Agentic Privilege Elevation**](/en/keeperpam/endpoint-privilege-manager/policies/policy-types/agentic-privilege-elevation-policy.md)) support Auto-Approve, Auto-Deny, Admin Approval, Justification, MFA, and Require User Approval. Multiple controls can be combined on a single policy to create layered verification requirements.

{% hint style="info" %}
**Conflict resolution:** When multiple policies apply to the same user, machine, or application simultaneously, Keeper enforces all applicable policies and automatically applies the most restrictive outcome where conflicts exist.
{% endhint %}

## Available Controls

The following controls are available when creating or editing a policy in Enforce mode.

* [Admin Approval](#admin-approval)
* [Auto-Approve](#auto-approve)
* [Auto-Deny](#auto-deny)
* [Justification](#justification)
* [MFA](#mfa)
* [Require User Approval](#require-user-approval)

### Admin Approval

**What it does:** The user's action is paused and routed to a designated approver team. The action is blocked until an approver explicitly grants or denies the request.

**How it works:**

1. The user triggers a privileged action (for example, running an application as Administrator).
2. The Keeper agent intercepts the request and presents the user with a pending notification.
3. The request is sent to the Keeper backend and appears in the **Admin Console → Endpoint Privilege Manager → Requests** queue.
4. The assigned approver reviews the request details — including the requesting user, machine, application, command-line arguments, and any justification provided — and either approves or denies it.
5. If approved, the user is notified and can proceed with the action.

**Key behaviors and timeouts:**

| Event                                        | Default Timeout         |
| -------------------------------------------- | ----------------------- |
| Initial approval request expires             | 30 minutes              |
| Request auto-escalates to secondary approver | After 30 minutes        |
| Escalated request expires                    | 4 hours from escalation |
| Approved request available for use           | 24 hours from approval  |

{% hint style="info" %}
Timeout windows are configurable in the Admin Console under **Admin → Approvals** for each event type.
{% endhint %}

**Approver configuration:** Approval rules, approver assignments, escalation behavior, and time windows are managed centrally in **Admin → Approvals** in the Keeper Admin Console — not within individual policies. Keeper Administrators always retain full approval rights. Review activity is tracked under **Endpoint Privilege Manager → Requests**.

**Offline behavior:** Approval requests require an active network connection. Users cannot initiate an approval request while offline.

{% hint style="info" %}
**Note:** Approvals always require a justification. When Admin Approval is selected, the user is always prompted to provide a reason for the request, even if Justification is not separately enabled.
{% endhint %}

### Auto-Approve

**What it does:** Explicitly permits a matched action to proceed without requiring any additional user verification. The action passes through silently.

**When to use it:** Use Auto-Approve when you want to create a permissive exception for a specific application, command, or file path within a broader restrictive policy. For example, you may want to permit a trusted IT tool to elevate without interruption while all other elevation attempts require approval.

**Key behaviors:**

* Auto-Approve overrides default-deny behavior for the matched scope.
* No notification, MFA prompt, justification dialog, or approval workflow is triggered.
* The event is still recorded in the audit log when the policy status is set to Monitor or Monitor & Notify.
* Auto-Approve and Auto-Deny controls can coexist in different policies. When multiple policies apply, Keeper enforces the most restrictive applicable outcome.
* Auto-Approve cannot be combined with any other control. Selecting it deactivates all other controls on the policy, and a confirmation prompt appears when it is selected or cleared. Defining scope requires at minimum one User or Machine collection and one Application or Agentic AI collection.

### Auto-Deny

**What it does:** Explicitly blocks a matched action and prevents it from proceeding under any circumstances, without presenting any verification pathway to the user.

**When to use it:** Use Auto-Deny to implement a hard block on specific applications, commands, or file paths — for example, as part of a default-deny strategy or to block known risky executables. Auto-Deny is the appropriate control when there is no valid business reason to permit the action.

**Key behaviors:**

* The action is terminated immediately upon match. No approval, MFA, or justification prompt is shown.
* The block is recorded in the audit log.
* When building a "Deny Everything" model, Keeper's protected-path logic is applied automatically to prevent unintended disruption of critical operating system components.
* Auto-Deny policies are evaluated with the highest enforcement priority when multiple policies conflict.
* Auto-Deny cannot be combined with any other control. Selecting it deactivates all other controls on the policy, and a confirmation prompt appears when it is selected or cleared. Returns a deny response immediately with no user-facing prompt. Defining scope requires at minimum one User or Machine collection and one Application or Agentic AI collection.

### Justification

**What it does:** The user must type a written explanation of why they need to perform the requested action before it is allowed to proceed.

**How it works:**

1. The user triggers a privileged action.
2. The Keeper agent displays a prompt asking the user to enter a justification message.
3. The user types their explanation and submits it.
4. The action is permitted and the justification text is recorded in the audit log.

**Key behaviors:**

* No approver review is required when Justification is used alone. The action proceeds immediately after the user submits a justification.
* The justification message is captured and associated with the audit event for compliance and review purposes.
* **Offline behavior:** If a policy requires only justification (and not MFA or Admin Approval), execution is permitted offline. The justification message is cached on the device and sent to the server once the agent reconnects.

### MFA

**What it does:** The user must prove their identity using a time-based one-time password (TOTP) before the action is permitted.

**How it works:**

1. The user triggers a privileged action.
2. The Keeper agent prompts the user to enter a valid MFA code from their registered TOTP authenticator app.
3. The code is validated against the user's Keeper vault MFA configuration.
4. If the code is valid and within the session window, the action proceeds. If the code is invalid or expired, the action is blocked.

**Key behaviors:**

* Users must have an active Keeper vault account within the tenant and must have configured a TOTP-based two-factor authentication method.
* Any valid Keeper email and 2FA combination is accepted as long as the account belongs to the tenant.
* MFA sessions are valid for **5 minutes**. Within that window, the user will not be re-prompted for the same type of action.
* MFA verification requires an active network connection. If the device is offline, MFA-gated actions are blocked.

### Require User Approval

**What it does:** Prompts the signed-in end user on the endpoint to approve or deny an action in real time. Unlike Admin Approval — which routes the decision to a separate approver team — Require User Approval places the decision with the person at the keyboard. This is the "human-in-the-middle" gate used most often for AI agent governance, where an AI agent attempts an action that a policy filters and the user must confirm it.

**How it works:**

1. A monitored action matches a policy with Require User Approval (for example, an AI agent attempting to access a sensitive file or run a privileged command).
2. The Keeper agent displays an approval prompt to the end user on the affected endpoint, showing the action details.
3. The user approves or denies. The action proceeds only on approval; a denial blocks it.
4. The decision is recorded in the audit log.

**Key behaviors:**

* The prompt offers a **"Don't ask again for&#x20;*****N*****&#x20;hours"** option, which suppresses repeat prompts for the same action scope for the configured window.
* Require User Approval can be combined with a risk-score threshold so the prompt is shown only when an action's risk score exceeds the configured limit.
* The decision is attributed in the audit log to the end user who responded.

***

## Combining Controls

KEPM supports combining multiple controls on a single policy to enforce layered verification requirements. When controls are combined, **all** configured controls must be satisfied before the action is permitted. Controls are always presented to the user in a fixed order regardless of the order in which they were added to the policy.

Show Image

Auto-Approve and Auto-Deny are terminal controls: they resolve the action on their own and cannot be combined with any other control. The remaining controls — Admin Approval, MFA, and Justification — can be combined with one another. Require User Approval is an independent end-user gate and is not combined with the administrator-side controls.

#### Allowed Combinations

The table below shows which controls can be combined on a single policy.

| Control            | Admin Approval | MFA | Justification | Auto-Approve | Auto-Deny |
| ------------------ | -------------- | --- | ------------- | ------------ | --------- |
| **Admin Approval** | —              | Yes | Yes           | No           | No        |
| **MFA**            | Yes            | —   | Yes           | No           | No        |
| **Justification**  | Yes            | Yes | —             | No           | No        |
| **Auto-Approve**   | No             | No  | No            | —            | No        |
| **Auto-Deny**      | No             | No  | No            | No           | —         |

#### Order of Evaluation

When multiple controls are combined on a policy, they are processed in a fixed sequence. The action proceeds only if every control is satisfied in turn; if any control is failed, cancelled, or denied, the action is blocked and no subsequent control is presented.

<table><thead><tr><th width="89.5333251953125">Order</th><th width="151.933349609375">Control</th><th>What the user encounters</th></tr></thead><tbody><tr><td>1</td><td>Auto-Deny</td><td>If present, the action is blocked immediately and no further controls are evaluated.</td></tr><tr><td>2</td><td>Admin Approval</td><td>The request is routed to an approver and remains pending until granted.</td></tr><tr><td>3</td><td>MFA</td><td>The user is prompted to complete TOTP verification.</td></tr><tr><td>4</td><td>Justification</td><td>The user is prompted to enter a written reason, which is recorded in the audit log.</td></tr><tr><td>5</td><td>Auto-Approve</td><td>If present, the action is permitted without further prompts.</td></tr></tbody></table>

{% hint style="info" %}
**Control precedence order (highest to lowest):** `DENY` → `APPROVAL` → `MFA` → `JUSTIFY` → `ALLOW`. This same order determines the outcome when conflicting controls apply to a single action.
{% endhint %}

#### Policy Specificity and Precedence

Policies follow specific-versus-wildcard precedence rules across all KEPM policy types. When multiple policies match a request, the engine separates them into **specific** and **wildcard** policies and evaluates only the more targeted group.

A policy is considered **specific** if its `UserCheck`, `ApplicationCheck`, or `MachineCheck` contains one or more non-wildcard values (i.e., it targets named users, named applications, or named machines rather than `"*"`). A policy is considered **wildcard** if all three of those filters are set to `"*"` or are empty.

The precedence rule is:

* If any specific policies match the request, **only** those specific policies are evaluated; all wildcard policies are ignored for that request.
* If no specific policies match, wildcard policies are evaluated.
* When multiple specific policies match the same request, their controls combine additively and are evaluated in the fixed order shown above.

{% hint style="warning" %}
**Important:** Specificity is determined by `UserCheck`, `ApplicationCheck`, and `MachineCheck` — **not** by whether `AllowCommands` is present. A policy with `AllowCommands` but `ApplicationCheck: ["*"]` is still treated as a wildcard policy and will not take automatic precedence over another wildcard policy. To achieve specific-policy precedence, ensure the policy's `ApplicationCheck` (or `UserCheck` / `MachineCheck`) targets a named application or collection rather than `"*"`.
{% endhint %}

### Control Reference Summary

<table><thead><tr><th width="134.06671142578125">Control</th><th width="171.6666259765625">Requires Network</th><th width="141.13330078125">Requires Keeper Vault Account</th><th width="144">Blocks Action Immediately</th><th>Requires Human Approver</th></tr></thead><tbody><tr><td>Admin Approval</td><td>Yes</td><td>No</td><td>No (pending until decided)</td><td>Yes</td></tr><tr><td>Auto-Approve</td><td>No</td><td>No</td><td>No (permits action)</td><td>No</td></tr><tr><td>Auto-Deny</td><td>No</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Justification</td><td>No (offline cached)</td><td>No</td><td>No</td><td>No</td></tr><tr><td>MFA</td><td>Yes</td><td>Yes (with TOTP configured)</td><td>No (blocked if offline)</td><td>No</td></tr><tr><td>Require User Approval</td><td>See note below</td><td>No</td><td>No (pending until user decides)</td><td>No (end user decides, not a separate approver)</td></tr></tbody></table>

### Offline Behavior Summary

Policies are pushed to endpoints and evaluated locally on the device. The following rules apply when the device is offline:

* **Admin Approval required:** The user cannot initiate an approval request. The action is blocked.
* **MFA required:** The user cannot complete MFA verification. The action is blocked.
* **Justification only:** The action is permitted. The justification is cached and sent to the server when the agent reconnects.
* **User approval required:** See the confirmation note below — offline behavior depends on whether the endpoint prompt can be served and the decision cached locally.
* **Auto-Approve / Auto-Deny:** Evaluated locally with no network dependency.
* **Audit events:** Cached locally and sent to the server once the agent comes back online.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://newdocs.keeper.io/en/keeperpam/endpoint-privilege-manager/policies/policy-controls.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.