> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-controls.md).
# Policy: Controls
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 (Agentic AI Access, Agentic Access, Agentic Privilege Elevation, Command Line, File Access, Least Privilege, & Privilege Elevation). 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
**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 Require Approval is selected, the user is always prompted to provide a reason for the request, even if Require Justification is not separately enabled.
{% endhint %}
#### Auto-Approve (Advanced)
**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.
**JSON representation:**
```json
"Controls": ["ALLOW"]
```
#### Auto-Deny (Advanced)
**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.
**JSON representation:**
```json
"Controls": ["DENY"]
```
### End User Approval
**What it does:** Pauses an action and routes it to the **end user** at the affected endpoint for an allow-or-deny decision in real time — a human-in-the-loop gate. It is a primary control for governing **Agentic AI** activity: when an AI agent attempts an action a policy scopes, the action is held until the user present at the machine explicitly approves or denies it.
**How it works:**
1. A scoped action is attempted — most commonly by a detected AI agent acting on the user's behalf.
2. The Keeper agent suspends the action and presents the user with an approve/deny prompt describing what is being requested, by which agent, and against which resource.
3. If the user approves, the action proceeds. If the user denies, the action is blocked.
4. The decision, the requesting identity, and the resource are recorded in the audit log.
**Key behaviors:**
* This control places the decision with the **end user at the endpoint**, distinct from **Admin Approval**, which routes to a designated approver team in the Admin Console.
* When attached to an Agentic policy, the underlying control value is `OPERATORAPPROVAL`.
* On **timeout**, the configured fail-mode is applied.
{% hint style="info" %}
**Agentic AI context:** End User Approval is typically paired with a risk threshold (see **Risk-Driven Controls** below), so the prompt is raised only when an agent's action crosses the configured AI-likelihood or risk level — routine, low-risk agent activity proceeds without interrupting the user.
{% endhint %}
### 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 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.
### Risk-Driven Controls (Agentic AI)
Agentic policies can gate a control on a **risk threshold** rather than firing on every matched action. Instead of acting on every agent action in scope, the policy evaluates the action and applies its control only when a configured threshold is crossed.
* **`minAiLikelihoodPercent`** — set on the policy's `Extension` object; the minimum confidence (0–100) that the process is an AI agent before the policy applies.
When a threshold is exceeded, the policy's configured response is triggered — for example, an **End User Approval** prompt, **Admin Approval**, or a deny.
**JSON representation (monitor-mode Agentic Access policy, AI likelihood ≥ 90%):**
```json
"Status": "monitor",
"Actions": {
"OnSuccess": { "Controls": ["ALLOW"] },
"OnFailure": { "Command": "" }
},
"Extension": {
"SubProcessCheck": ["*"],
"minAiLikelihoodPercent": 90
}
```
`SubProcessCheck` scopes the policy to the agent's spawned subprocesses (`"*"` matches all).
### 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 — if any one is denied, fails, or times out, the action is blocked.
Layering lets you tune a single policy to the risk of the action it governs. A routine self-service action might require only Justification, while a high-risk action — such as unrestricted elevation across a fleet of endpoints — might layer Admin Approval with MFA to combine human oversight with identity assurance. Any controls that produce a verification step can be combined; the determination controls (Auto-Approve and Auto-Deny) cannot, since each resolves the outcome on its own.
**Order of evaluation:** When multiple controls are configured, KEPM presents them to the user in precedence order (see the control precedence order below), not in the order they were added to the policy. For example, when Admin Approval and MFA are combined, the request is routed for approval first, and the user is prompted for MFA only after the request is granted. When MFA and Justification are combined, MFA is completed before the justification prompt is shown.
**Network and timeout behavior:** A combined policy inherits the most restrictive requirement of its controls. If any included control requires a network connection (Admin Approval, End User Approval, or MFA), the action cannot proceed offline. Likewise, the action is bound by the timeout windows of every control in the layer — for example, adding MFA to an approval workflow extends the total interaction time, since the user must complete MFA after the approver grants the request.
**Friction considerations:** Layering controls increases assurance but also increases user friction and, for approval-based layers, approver queue volume. When applying a layered policy broadly (for example, to all elevation attempts across all endpoints), consider scoping it by application, User Collection, Machine Collection, or time window to keep verification proportional to risk.
**JSON representation:** Controls are combined by listing each control token in the `Controls` array. The array order does not affect evaluation order — precedence is applied automatically.
```json
"Controls": ["APPROVAL", "MFA"]
```
{% hint style="info" %}
**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
| Control | Requires Network | Requires Keeper Vault Account | Blocks Action Immediately | Requires Human Approver |
| ----------------------- | ------------------- | ----------------------------- | -------------------------- | ----------------------- |
| Admin Approval | Yes | No | No (pending until decided) | Yes |
| End User Approval | Yes | No | No (pending until decided) | No (end user decides) |
| MFA | Yes | Yes (with TOTP configured) | No (blocked if offline) | No |
| Justification | No (offline cached) | No | No | No |
| Auto-Approve (Advanced) | No | No | No (permits action) | No |
| Auto-Deny (Advanced) | No | No | Yes | No |
## 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:** The user cannot initiate an approval request. The action is blocked.
* **Auto-Approve / Auto-Deny:** Evaluated locally with no network dependency.
* **End User Approval:** Requires the end user to be present at the endpoint to respond. If the prompt cannot be presented or times out, the configured fail-mode applies.
* **Justification:** The action is permitted. The justification is cached and sent to the server when the agent reconnects.
* **MFA:** The user cannot complete MFA verification. The action is blocked.
* **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:
```
GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-controls.md?ask=
```
The question should be specific, self-contained, and written in natural language.
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.