Phased Policy Rollout Planning
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.
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.
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.
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.
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.
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.
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.
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.
Note: Use path variables such as {userprofile}, {systemroot}, and {programfiles} to write portable, cross-platform Agentic Access policies.
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.
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.
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.
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.
Note: Agentic Privilege Elevation should be paired with Least Privilege policies so that agents inherit a restricted baseline and must explicitly request elevation rather than running with standing admin rights.
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.
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.
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.
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
Extensionssection is a wildcard elevated-only policy — it acts as a wildcardsudopolicy and applies to all elevated commands.To apply a policy to non-elevated commands, the
Extensionssection must explicitly include"IsElevated": false.A policy with no
AllowCommandssection inExtensionsis a wildcard command line policy, meaning it applies to all commands. Once commands are listed inAllowCommands, 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
AllowCommandswith 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.
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.
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
AllowCommandsandDenyCommandstogether 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.
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).
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.
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.
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.
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.
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.
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.
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 policies on top. Privilege Elevation policies are where Auto-Approve, Auto-Deny, Justification, Admin Approval, and MFA controls are applied for individual elevation requests.
Note: Least Privilege is most effective when paired with Privilege Elevation policies. Removing standing admin rights without a clear elevation path will break legitimate workflows and generate support volume.
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.
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.
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.
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.
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.
Last updated