> 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/setup/policies.md). # Policies

This section goes deeper into **policy types**, **status**, **controls**, and **filters** so you can design policies that match your security and compliance goals. ## Policy Types Each policy has a **type** that determines what kind of action it controls.

Type	What it controls	Typical use
Agentic AI	What an AI agent (autonomous assistant, MCP-connected tool, or other non-human identity) is allowed to do on the endpoint.	Govern agent-initiated actions; require approval or deny high-risk agent behavior.
Agentic Access	The child processes an AI agent launches (e.g., an IDE agent spawning `git` or `where`).	Allow trusted subprocesses of an agent without prompting on every spawn; require approval or deny others.
Agentic Privilege Elevation	When an AI agent can run with elevated (administrator/root) privileges.	Require approval or deny agent-initiated elevation; allow specific elevated actions for trusted agents.
Command Line	Execution of commands (e.g., PowerShell, shell, scripts).	Block dangerous commands; require approval for sensitive scripts.
File Access	Access to files and folders.	Block or allow access to sensitive paths; require justification or approval for certain files.
Least Privilege	Whether a user keeps or loses local administrator rights.	Remove standing admin from most users; allow exceptions for specific roles or machines.
Privilege Elevation	When users can run as administrator (or elevate privileges).	Require MFA, approval, or justification before elevation; allow or block specific apps.
Advanced Mode: Keeper Updates	Which version of KEPM each endpoint should run.	Keep endpoints on the latest release automatically, or pin a specific version for validation or change windows.
Advanced Mode: Update Jobs	Deploying or updating job definitions on the agent.	Deploy automation and enforcement jobs from a central place.
Advanced Mode: Update Settings	Pushing configuration to the agent (e.g., plugin or global settings).	Roll out settings from the dashboard without touching each endpoint.

When a user, process, or agent triggers an action, the agent figures out the **event type** (e.g., privilege elevation, file access) and evaluates only the policies of that type. So a Privilege Elevation policy never blocks file access; a File Access policy never blocks elevation. You can combine multiple policy types to get full coverage. {% hint style="danger" %} **Sequencing:** When deploying multiple policy types, order matters. Privilege Elevation policies should be configured and tested before Least Privilege is enforced, so users retain a governed path to elevation after standing admin rights are removed. See [Policy: Phased Rollout Planning](/keeperpam/endpoint-privilege-manager/policies/policy-phased-rollout-planning.md) for the recommended approach. {% endhint %} ### File Access Approval Duration When approval is required under a file access policy, the requester is granted a four-hour window to access the approved file once authorization is provided. During the four-hour window, the requestor may open, edit, save, and close the file that they have been granted access to. ### MFA Access Duration After an MFA challenge has been issued and successfully completed, the requester is granted a five-minute window to use the authorized privilege. If the privilege is not exercised within this time frame, a new MFA request must be submitted. **Reference:** [Configuring the Approval Duration](/keeperpam/endpoint-privilege-manager/user-guides/configuring-the-approval-duration.md) ## Policy Status Each policy has a **status** that controls whether it actually enforces or only observes.

Status	Evaluated?	Enforced?	What happens
Off	No	No	Policy is ignored. Use this to disable a policy without deleting it.
Enforce	Yes	Yes	Policy is evaluated and controls are applied.
Monitor	Yes	No	Policy is evaluated and logged, but no control is applied—actions are allowed. Use to see impact before enforcing.
Monitor & Notify	Yes	No	Same as Monitor, but users or admins can be notified when the policy would have matched. Good for training and gradual rollout.

Start with **Monitor** or **Monitor & Notify** for new policies, confirm behavior in reports and logs, then switch to **Enforce** when you’re ready. ## Policy Controls **Controls** define what happens when a policy **matches** a request. A control either lets the action proceed, blocks it, or requires the user to complete an additional step first. You can combine controls so that higher-risk actions get multiple checks.

Control	Meaning
Admin Approval	Requires an authorized approver to review and approve the request before the action can proceed. Best for higher-risk actions that should have human oversight.
Auto-Approve	Automatically approves the request without prompting the user or an approver, while still logging the action. Best for low-risk actions you want to permit silently but retain a record of.
Auto-Deny	Automatically denies the request without prompting the user or an approver, while still logging the attempt. Best for actions that should never be permitted but that you want visibility into when they are attempted.
End User Approval	Allows the user to approve their own request to proceed, without requiring a separate authorized approver. Best for lower-risk actions where you want the user to confirm intent and create an audit record, but full approver oversight is unnecessary.
Justification	Requires the user to provide a written reason for why they need the action. Creates accountability and improves auditability.
MFA	Requires the user to complete multi-factor authentication to confirm their identity before proceeding. Helps prevent misuse if a password is compromised.

You can combine controls (e.g., MFA **and** Admin Approval) so that high-risk actions get multiple checks. The product applies precedence rules so the final outcome is clear—a deny outcome overrides an allow. ## Advanced Mode & Filters **Filters** define **who** and **what** a policy applies to. Typically all of the following must match for the policy to apply: * **Accounts:** Which users or User Collections. * **Agentic AIs:** Which AI agents, identified by an Agentic AI Collection, for agent-initiated actions. * **Applications:** Which executables, paths, or patterns (often with variables and wildcards). * **Machines:** Which endpoints or Machine Collections. * **Optional:** Time of day, day of week, or date range. More **specific** filters (e.g., a single app and a single Collection) usually take precedence over **broad** ones (e.g., “all users” and “all machines”). So you can have a default policy for everyone and override it with a more specific policy for a subset. **Advanced Mode** options may include: * **Keeper Updates:** Declare the desired KEPM version for targeted endpoints—either the latest release or a pinned version—so machines converge automatically without manual reinstalls. See [Keeper Updates](/keeperpam/endpoint-privilege-manager/policies/policy-types/advanced-policy-types/keeper-updates.md). * **Custom rules:** Extra conditions (e.g., risk score, location) if your deployment supports them. * **Extension / AllowCommands:** In some setups, an explicit list of allowed commands (e.g., for time sync or specific admin tools). If a command isn’t in the list, it may be denied when using an allow-list model. Design policies so that the most specific cases are defined first, then use broader policies for defaults. Use [Reference: Variables & Wildcards](/keeperpam/endpoint-privilege-manager/policies/policy-examples/advanced-examples/variables-and-wildcards.md) to keep filters manageable with variables and wildcards. --- # 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://docs.keeper.io/keeperpam/endpoint-privilege-manager/setup/policies.md?ask=&goal= ``` `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.