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. The available controls differ slightly by Policy Types:
Privilege Elevation and File Access support the full set (Auto-Approve, Auto-Deny, Admin Approval, Justification, MFA);
Command Line supports Admin Approval, Justification, and MFA;
Least Privilege supports Auto-Approve and Auto-Deny.
The three Agentic AI Governance policy types (Agentic AI, Agentic Access, and Agentic Privilege Elevation) 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.
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.
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:
The user triggers a privileged action (for example, running an application as Administrator).
The Keeper agent intercepts the request and presents the user with a pending notification.
The request is sent to the Keeper backend and appears in the Admin Console → Endpoint Privilege Manager → Requests queue.
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.
If approved, the user is notified and can proceed with the action.
Key behaviors and timeouts:
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
Timeout windows are configurable in the Admin Console under Admin → Approvals for each event type.
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.
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.
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:
The user triggers a privileged action.
The Keeper agent displays a prompt asking the user to enter a justification message.
The user types their explanation and submits it.
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:
The user triggers a privileged action.
The Keeper agent prompts the user to enter a valid MFA code from their registered TOTP authenticator app.
The code is validated against the user's Keeper vault MFA configuration.
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:
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).
The Keeper agent displays an approval prompt to the end user on the affected endpoint, showing the action details.
The user approves or denies. The action proceeds only on approval; a denial blocks it.
The decision is recorded in the audit log.
Key behaviors:
The prompt offers a "Don't ask again for N 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.
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.
1
Auto-Deny
If present, the action is blocked immediately and no further controls are evaluated.
2
Admin Approval
The request is routed to an approver and remains pending until granted.
3
MFA
The user is prompted to complete TOTP verification.
4
Justification
The user is prompted to enter a written reason, which is recorded in the audit log.
5
Auto-Approve
If present, the action is permitted without further prompts.
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.
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.
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 "*".
Control Reference Summary
Admin Approval
Yes
No
No (pending until decided)
Yes
Auto-Approve
No
No
No (permits action)
No
Auto-Deny
No
No
Yes
No
Justification
No (offline cached)
No
No
No
MFA
Yes
Yes (with TOTP configured)
No (blocked if offline)
No
Require User Approval
See note below
No
No (pending until user decides)
No (end user decides, not a separate approver)
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.
Last updated
Was this helpful?