> 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/setup/policy-phased-rollout-planning.md).

# Phased Policy Rollout Planning

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

## Phased Policy Rollout Approach

A phased rollout allows administrators to observe real-world policy behavior — what would be blocked, allowed, or flagged — before any controls are enforced, eliminating the risk of accidentally locking users out of legitimate workflows. Starting in Monitor mode also builds a behavioral baseline that makes it far easier to write precise, well-targeted policies rather than guessing at filters and rules upfront. By the time enforcement is enabled, both administrators and end users are informed, prepared, and confident in the outcome.

Before enforcing any policy, use the policy status lifecycle to safely validate behavior without impacting accounts:

* **Monitor** — The policy is evaluated and logged, but no controls are applied. Accounts are unaffected. Use this to establish a behavioral baseline and confirm your filters are matching the right accounts, machines, and applications.
* **Monitor & Notify** — Same as Monitor, but accounts receive an informational notification that the action is being observed. Use this to build awareness and prepare users for upcoming enforcement without disrupting workflows.
* **Enforce** — Controls are actively applied (Allow, Deny, MFA, Justification, Approval). Only switch to Enforce after you've confirmed policy behavior in the prior stages.

***

## Example Phased Rollout Plans

### Agentic AI Policy Phased Rollout Plan

Agentic AI policies control how AI agents and autonomous processes are identified, governed, and audited on the endpoint. Because agentic workloads can spawn dynamically and interact with sensitive resources without direct human initiation, baselining their behavior before enforcement is essential.

{% stepper %}
{% step %}

#### Phase 1 - Monitor

Create an Agentic AI policy targeting all Account, all Machine, and all Agentic AI Collections and set it to Monitor mode. Review audit logs to identify:

* Which AI agents are running, on which machines, and under which user contexts.
* The actions agents are taking — file access, command execution, network calls, and privilege escalation attempts.
* Unmanaged or unexpected agent processes that appear outside sanctioned workflows.
  {% endstep %}

{% step %}

#### Phase 2 - **Monitor & Notify**

Switch to Monitor & Notify. Accounts running agentic workloads will receive a notification that agent activity is being tracked. This is an opportunity to communicate upcoming governance changes to your user base and gauge the volume of agent activity that will require controls when enforced.
{% endstep %}

{% step %}

#### Phase 3+ - **Enforce**

Switch to Enforce and apply appropriate controls:

* **Auto-Approve** for sanctioned agent runtimes and known-good autonomous workflows.
* **Auto-Deny** for unmanaged or unsanctioned agent processes.
* **Justification** for agent actions that are occasionally legitimate but require an audit trail.
* **Admin Approval** for high-risk agent actions, such as agents attempting to elevate, modify system state, or reach sensitive paths.
* **MFA** for agent actions that require step-up authentication of the supervising account before proceeding.
  {% endstep %}
  {% endstepper %}

{% hint style="info" %}
**Note:** Agentic AI policies frequently overlap with Agentic Access and Agentic Privilege Elevation policies. Plan them together so controls are layered consistently rather than applied in isolation.
{% endhint %}

#### **Recommendations**

* Inventory sanctioned AI agents and their expected behavior before writing policies — without that baseline, it is difficult to distinguish managed from unmanaged activity.
* Use collections to scope initial enforcement to accounts and teams running agentic workloads (e.g., engineering, data science) before broader rollout.
* Pair Agentic AI policies with the corresponding Access and Privilege Elevation policies for complete coverage of what agents can reach and do.

***

### Agentic Access Policy Phased Rollout Plan

Agentic Access policies control which resources — files, paths, network endpoints *\*(coming in Keeper EPM v2.2)*, and applications — AI agents are permitted to reach. Because agents may access resources at machine speed and in unexpected combinations, monitoring real access patterns before enforcement is critical.

{% stepper %}
{% step %}

#### Phase 1 - Monitor

Create an Agentic Access policy targeting all Account, all Application, all Machine, and all Agentic AI Collections and set it to Monitor mode. Review audit logs to identify:

* Which resources agents are reaching — sensitive directories, credential stores, config files, and external endpoints.
* Patterns of access that indicate legitimate workflows vs. unexpected or excessive reach.
* Resources that agents access frequently but should not — clear candidates for Deny or Approval controls.
  {% endstep %}

{% step %}

#### Phase 2 - **Monitor & Notify**

Switch to Monitor & Notify. Accounts whose agents are accessing tracked resources will receive an informational notification. Use this phase to communicate upcoming access boundaries and surface any unexpected friction before controls are enforced.
{% endstep %}

{% step %}

#### Phase 3+ - **Enforce**

Switch to Enforce and apply appropriate controls:

* **Auto-Approve** for resources sanctioned for agent access.
* **Auto-Deny** for sensitive paths agents should never reach (credential stores, security tooling, system directories).
* **Justification** for occasional access to resources that require an audit trail.
* **End User Approval** for resource access where the human end user must approve the agent's request before it executes — the agent's attempted access is paused until the end user explicitly authorizes it.
* **Admin Approval** for high-risk resource access that warrants review by a supervisor or security team rather than the supervising account.
* **MFA** for resource access that requires step-up authentication of the supervising account before the agent proceeds.
  {% endstep %}
  {% endstepper %}

{% hint style="info" %}
**Note:** Use [path variables](/en/keeperpam/endpoint-privilege-manager/policies/policy-reference/path-variables.md) such as `{userprofile}`, `{systemroot}`, and `{programfiles}` to write portable, cross-platform Agentic Access policies.
{% endhint %}

#### **Recommendations**

* Define a clear allow-list of resources agents need for sanctioned workflows before applying broad denies.
* Target credential stores, configuration files containing secrets, and security tooling explicitly — these are the highest-value resources to protect from agent reach.
* Use collections to scope enforcement to teams running agentic workloads first, then expand org-wide.

***

### Agentic Privilege Elevation Policy Phased Rollout Plan

Agentic Privilege Elevation policies govern when and how AI agents can run with elevated (administrator) rights. Because elevated agent actions can modify system state at machine speed without direct human oversight, careful baselining before enforcement is critical. We recommend the human in the middle approach by implementing the `End User Approval` control within your Agentic Privilege Elevation Policies.

{% stepper %}
{% step %}

#### Phase 1 - Monitor

Create an Agentic Privilege Elevation policy targeting all Account, all Application, all Machine, and all Agentic AI Collections and set it to Monitor mode. Review audit logs to identify:

* Which agent processes are requesting elevation, and how frequently.
* Which elevated actions agents are performing — installs, configuration changes, service control, registry edits.
* Patterns of elevation that map to legitimate automation vs. anomalous behavior.
  {% endstep %}

{% step %}

#### Phase 2 - **Monitor & Notify**

Switch to Monitor & Notify. Accounts whose agents are requesting elevation will receive a notification that the elevation is being tracked. This is an opportunity to communicate upcoming controls and gauge the volume of elevation requests that will require review when enforced.
{% endstep %}

{% step %}

#### Phase 3+ - **Enforce**

Switch to Enforce and apply controls appropriate to the risk level of each action:

* **Auto-Approve** for known-safe, sanctioned elevated agent workflows (e.g., scheduled patching by a trusted agent).
* **Auto-Deny** for elevated agent actions that are explicitly disallowed.
* **Justification** for infrequent elevation requests that require an audit trail.
* **End User Approval** for elevation requests where the human end user must approve the agent's elevation before it occurs — the agent's attempted elevation is paused until the end user explicitly authorizes it.
* **Admin Approval** for high-risk or unusual elevated agent actions that warrant review by a supervisor or security team rather than the supervising account.
* **MFA** or **Admin Approval + MFA** for agents attempting to perform highly sensitive administrative actions.
  {% endstep %}
  {% endstepper %}

{% hint style="info" %}
**Note:** Agentic Privilege Elevation should be paired with [Least Privilege](https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type) policies so that agents inherit a restricted baseline and must explicitly request elevation rather than running with standing admin rights.
{% endhint %}

#### **Recommendations**

* Treat agent elevation with greater scrutiny than user elevation — agents can act faster and at higher volume than humans, so the blast radius of a misconfigured allow is larger.
* Establish specific Allow policies for well-known, sanctioned agent workflows before applying a broad Deny.
* Pair Agentic Privilege Elevation policies with Agentic Access policies to control both *what* agents can do and *where* they can do it.

***

### Command Line Policy Phased Rollout Plan

Command Line policies control which commands, scripts, and shell operations users can execute. Because command line access is a common attack vector — and also essential for many legitimate workflows — these policies require careful baselining before enforcement.

{% stepper %}
{% step %}

#### Phase 1 - Monitor

Create a Command Line policy targeting all Account, all Application (e.g., `cmd.exe`, `powershell.exe`, `pwsh.exe`, etc.), and all Machine Collections and set it to Monitor mode. Review audit logs to identify:

* Which commands are being run, by whom, and from which machines.
* Commands with high-risk potential such as `format`, `rm -rf`, `net user`, `reg`, or script execution patterns.
  {% endstep %}

{% step %}

#### Phase 2 - Monitor & Notify

Switch to **Enforce** and apply controls. Common configurations include:

* **Deny** for known-dangerous commands (e.g., destructive file operations, user account manipulation, registry edits outside approved workflows).
* **Justification** for commands that are occasionally legitimate but require an audit trail.
* **Approval** for commands that require explicit authorization from a supervisor or security team.
  {% endstep %}

{% step %}

#### Phase 3+ - Enforce

Switch to Enforce and apply controls. Common configurations include:

* **Auto-Approve** for commands explicitly sanctioned for the targeted accounts (e.g., known-safe administrative utilities).
* **Auto-Deny** for known-dangerous commands (e.g., destructive file operations, user account manipulation, registry edits outside approved workflows).
* **Justification** for commands that are occasionally legitimate but require an audit trail.
* **Admin Approval** for commands that require explicit authorization from a supervisor or security team.
* **MFA** or **Admin Approval + MFA** for highly sensitive commands that warrant step-up authentication.

**Understanding Policy Scope**

Before writing Command Line policies, it's important to understand how policy scope is determined:

* A policy with no `Extensions` section is a wildcard elevated-only policy — it acts as a wildcard `sudo` policy and applies to all elevated commands.
* To apply a policy to non-elevated commands, the `Extensions` section must explicitly include `"IsElevated": false`.
* A policy with no `AllowCommands` section in `Extensions` is a wildcard command line policy, meaning it applies to all commands. Once commands are listed in `AllowCommands`, the policy applies only to those specific commands.

Specific policies take precedence over wildcard policies, consistent with standard policy evaluation rules:

* If a command is listed in `AllowCommands` with an **Auto-Approve** control, it will be allowed even if a wildcard policy requires a control such as MFA.
* Conversely, if a specific policy requires **Justification**, that control applies even if a second specific policy for the same command is set to **Auto-Approve**.
  {% endstep %}
  {% endstepper %}

{% hint style="info" %}
**Note:** Command Line policies evaluate against the command being executed, not the parent shell process. A single shell session can be subject to many different policies as the user runs different commands.
{% endhint %}

#### **Recommendations**

* Start with the predefined policies as a baseline, then iterate.
* Start with a targeted Deny list of the highest-risk commands rather than attempting to whitelist everything at once.
* Scope initial Command Line policies to elevated contexts (e.g., `sudo`, `runas`, elevated shells) before applying broader controls.
* Use `AllowCommands` and `DenyCommands` together to define precise combinations within a single shell application.
* Keep policies specific: avoid overly broad wildcards on command patterns, which can produce unexpected matches. Review the Wildcards reference before writing command patterns.

***

### File Access Policy Phased Rollout Plan

File Access policies control which applications can read, write, or execute files and folders. Because these policies can affect a wide range of applications and workflows, a gradual rollout is essential.

{% stepper %}
{% step %}

#### Phase 1 - Monitor

Create a File Access policy targeting all Account, all Application, and all Machine Collections and set it to Monitor mode. Review the audit logs to understand what file access activity is occurring across your environment. Identify any sensitive paths that require protection, and confirm your folder targeting (including variables like `{userprofile}`) is resolving correctly.

Once you have identified which executable files you would like to control access to (such as PowerShell, Command Prompt, DMG, pkg, or applications in Downloads and home folders):

* Use wildcards for any executable not in a protected path.
* Create collections for sensitive areas where additional controls are required.
* Create policies that restrict unmanaged areas such as Downloads and home folders and require Approval. Set these policies to **Monitor & Notify** without acknowledgement (ACK).
  {% endstep %}

{% step %}

#### Phase 2 - **Monitor & Notify**

Switch to **Monitor & Notify** with ACK. Users will begin receiving informational notices that their file activity is being observed and that additional controls will be required in the future to execute. This builds awareness and surfaces any unexpected friction before enforcement begins.
{% endstep %}

{% step %}

#### Phase 3+ - **Enforce**

Switch to Enforce and apply appropriate controls:

* **Auto-Approve** for paths and applications explicitly sanctioned for access.
* **Auto-Deny** for prohibited paths.
* **Justification** for sensitive directories.
* **Admin Approval** for high-risk operations.
* **MFA** for file operations on highly sensitive paths that warrant step-up authentication.

Tune filters based on what you observed during the monitoring phases. Consider starting with Justification or Admin Approval controls before moving to hard Auto-Deny rules.

**Note:** While wildcards are the recommended starting point for policy coverage, some executables may warrant an explicit Auto-Approve or hard Auto-Deny based on your organization's needs. These can be defined in more granular policies as appropriate.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
**Note:** While wildcards are the recommended starting point for policy coverage, some executables may warrant an explicit Allow or hard Deny based on your organization's needs. These can be defined in more granular policies as appropriate.
{% endhint %}

#### **Recommendations**

* Use variables such as `{userprofile}`, `{systemroot}`, and `{programfiles}` to write cross-platform, portable policies.
* Target sensitive directories explicitly (e.g., credential stores, configuration folders) rather than broad-blocking everything.
* Use collections to scope enforcement to groups most likely to access sensitive paths before rolling out org-wide.
* Non-executables should be specifically targeted where they contain sensitive information — for example, configuration files that include keys, passwords, or account names (e.g., `hosts.inf`, `/etc/hosts`).

***

### Least Privilege Policy Phased Rollout Plan

Least Privilege policies remove standing administrator rights from users, reducing the attack surface for lateral movement and privilege abuse. Because this policy type directly changes what users can do on their machines, it carries the highest potential for disruption and requires the most careful planning before rollout.

{% stepper %}
{% step %}

#### Phase 1 - Monitor

Create a Least Privilege policy and set it to Monitor mode. Review audit logs to identify:

* Which users currently hold standing administrator rights, and how often those rights are actually used.
* Which applications and workflows depend on standing admin rights to function.
* Accounts and machines that perform frequent administrative actions — these are the populations most likely to require exception handling or paired Privilege Elevation policies before Least Privilege can be safely enforced.
  {% endstep %}

{% step %}

#### Phase 2 - **Monitor & Notify**

Switch to Monitor & Notify. Accounts whose accounts are flagged for de-elevation will receive an informational notification that standing admin rights are being reviewed and will be removed. Use this phase to communicate the upcoming change clearly, gather feedback on workflows that will be impacted, and identify any final gaps before enforcement.
{% endstep %}

{% step %}

#### Phase 3+ - **Enforce**

Switch to Enforce. Least Privilege does not support per-action controls — once enforced, the policy removes standing administrator rights from the targeted accounts. There are no Auto-Approve, Auto-Deny, Justification, Admin Approval, End User Approval, or MFA controls to configure on a Least Privilege policy itself.

To control specific administrative actions after de-elevation, layer one or more [Privilege Elevation](/en/keeperpam/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md) policies on top. Privilege Elevation policies are where Auto-Approve, Auto-Deny, Justification, Admin Approval, and MFA controls are applied for individual elevation requests.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
**Note:** Least Privilege is most effective when paired with [Privilege Elevation](/en/keeperpam/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md) policies. Removing standing admin rights without a clear elevation path will break legitimate workflows and generate support volume.
{% endhint %}

#### **Recommendations**

* Roll out Least Privilege to lower-risk populations first (standard end users) before targeting power users, developers, or IT staff.
* Pair Least Privilege with Privilege Elevation policies before enforcement so users have a sanctioned path to perform legitimate admin actions.
* Use collections to phase enforcement by department, team, or machine group rather than flipping the entire org at once.
* Communicate the change well in advance — Least Privilege is the policy type users are most likely to notice immediately.

***

### Privilege Elevation Policy Phased Rollout Plan

Privilege Elevation policies govern when and how users or processes can run with elevated (administrator) rights. These policies directly affect users' ability to install software, modify system settings, and run admin tools, so validation before enforcement is critical.

{% stepper %}
{% step %}

#### Phase 1 - Monitor

Create a Privilege Elevation policy targeting all Account, all Application, and all Machine Collections and set it to Monitor mode. Review audit logs to identify:

* Which elevation requests occur most frequently.
* Which applications are being run as elevated.
* Which users or machines are generating the most activity.
  {% endstep %}

{% step %}

#### Phase 2 - Monitor & Notify

Switch to **Monitor & Notify**. Users performing elevation requests will receive a notification that the action is being tracked. This is an opportunity to communicate upcoming changes to your user base and gauge the volume of requests that will require controls when enforced.
{% endstep %}

{% step %}

#### Phase 3+ - Enforce

Switch to Enforce and apply controls appropriate to the risk level of each action. Common starting configurations include:

* **Auto-Approve** for known-safe, business-critical applications.
* **Auto-Deny** for applications that should never be elevated under any circumstance.
* **Justification** for elevation requests that are infrequent or require an audit trail.
* **Admin Approval** for high-risk or unusual elevation scenarios.
* **MFA** or **Admin Approval + MFA** for highly sensitive administrative tools.
  {% endstep %}
  {% endstepper %}

{% hint style="info" %}
**Note:** Privilege Elevation policies evaluate against the application being elevated, not the user's session. The same user may receive different controls depending on which application they are attempting to elevate.
{% endhint %}

#### **Recommendations**

* Use collections to target high-risk user populations (e.g., developers, IT staff) before rolling out broader enforcement.
* Establish specific Allow policies for well-known, sanctioned applications before enforcing a broad Deny. This minimizes disruption to legitimate workflows.
* Pair Privilege Elevation policies with Least Privilege policies for a complete admin control strategy.


---

# 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/setup/policy-phased-rollout-planning.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.