> 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-reference/policy-evaluation.md).

# Policy Evaluation

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FaANJ7QU0N7YM7nfTZvuh%2Fimage.png?alt=media&amp;token=b8035847-8e08-4eab-8319-bb112d9afdb3" alt=""><figcaption></figcaption></figure>

## How Policy Evaluation Works

Keeper EPM uses one evaluation model for every enforced policy type. This page explains that model at a high level, how the main policy types fit together, and the **layered** approach recommended so controls remain effective when paths change, tools are copied, or AI agents spawn child processes.

{% hint style="info" %}
For deeper File Access matching semantics — including hash-only vs. path-plus-hash members and worked conflict examples — see the [File Access Policy Evaluation Guide](/keeperpam/endpoint-privilege-manager/policies/policy-reference/policy-evaluation/file-access-policy-evaluation-guide.md). For authoring workflows, see [Policy Types](/keeperpam/endpoint-privilege-manager/policies/policy-types.md), [Policy Controls](/keeperpam/endpoint-privilege-manager/policies/policy-controls.md), and [Policy Status](/keeperpam/endpoint-privilege-manager/policies/policy-status.md).
{% endhint %}

## Policy Types at a Glance

Every enforced policy type shares the same filter model (users, machines, applications, certificates, schedules, controls) and the same conflict rules. They differ in **which event** they attach to and **what "application" means** for that event — the launched app, the elevation target, the originating agent, or the child process.

| Policy Type                     | When It Is Evaluated                    | What It Governs                                                        |
| ------------------------------- | --------------------------------------- | ---------------------------------------------------------------------- |
| **File Access**                 | Process launch                          | Whether the user may run this application (baseline execution control) |
| **Privilege Elevation**         | Elevation request                       | Whether the user may run this application elevated                     |
| **Agentic AI**                  | Process launch of an AI or agent app    | Whether the user may **directly launch** that AI application           |
| **Agentic Access**              | Child process from an AI agent          | What an AI agent may **spawn or access** as a subprocess               |
| **Agentic Privilege Elevation** | Elevation from an AI-attributed process | What an AI-attributed process may **elevate**                          |

### What Happens During Evaluation

1. The agent observes an event: a **launch**, an **elevation**, or an **agent child / agent elevation**.
2. It resolves **who** (user), **where** (machine), and **what** (path, and when needed file hash or publisher certificate). For agent events it also resolves the **originating AI agent** when applicable.
3. It selects enforced policies of the relevant type(s) whose filters match.
4. If more than one policy matches, **specificity** and **control priority** produce a single outcome (see [When Policies Conflict](#when-policies-conflict)).
5. On AI-related paths, a **baseline Deny** from File Access or Privilege Elevation still wins over a more permissive agent policy (see [Authority Ceiling for AI Paths](#authority-ceiling-for-ai-paths)).

Monitor-mode policies may audit; they do not override an enforced decision.

### What a Policy Matches

A policy applies only when its scope matches the **current event**:

* **Users or groups** and **machines** (or "all")
* **Applications**, by path, filename pattern, content hash, and/or publisher certificate. For Agentic Access and Agentic Privilege Elevation, application scope often splits between the **agent** and the **child or elevation target**.
* Optional **schedules** and policy **rules**
* For agentic types, an optional **AI likelihood** gate so policies apply only when the app is recognized as AI with sufficient confidence

**Path-based** application entries match the path of the process (or target) being evaluated. Copying a binary to another folder is a different path, so a System32-only policy will not match that copy. That behavior is expected for path collections. Durable designs use **layers** (below) — broader application scope, hash identity, and certificates — not a single path list alone.

The same matching ideas apply whether the policy type is File Access, Privilege Elevation, or an agentic type: specific paths, wildcards / all applications, hashes, and certificates are shared building blocks.

## Recommended Layered Approach

Do not rely on one narrow policy for [LOTL](/keeperpam/endpoint-privilege-manager/policies/policy-examples/policy-living-off-the-land-file-access-justification.md) mitigation, elevation control, software allow-lists, or AI containment. Start from a [**Least Privilege foundation**](/keeperpam/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type.md), then stack policies from broad to specific — and use the right **policy type** for each event.

<h4 align="center">Security Policy Pyramid</h4>

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FTzMzVhnVPicwF9llAQkj%2Fimage.png?alt=media&amp;token=6e987bdd-c0f3-4e85-959a-bd428890d39a" alt=""><figcaption></figcaption></figure>

{% stepper %}
{% step %}

### **Layer 1 — Least Privilege (Foundation)**

Author a [Least Privilege Policy](/keeperpam/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type.md) so standard users do not hold local administrator rights on the endpoint by default. **Every layer above assumes this baseline.**

* Removes standing local admin from users who should not have it, so elevation must be **requested** through Privilege Elevation policies — not exercised silently through pre-existing rights.
* Applies before any launch or elevation event is evaluated; it shapes **what the user starts with**, not what they may run.
* Without this foundation, Layers 1-4 still gate launches and elevation requests, but a user who already holds local admin can bypass many controls that assume standard-user context (registry writes, service installs, driver loads, and similar).
* Pair with [**Privilege Elevation**](/keeperpam/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md) (Layers 1, 2, and 3 on elevation events) so approved administrative work still has a supported path after rights are removed.
* See [Least Privilege Policy](/keeperpam/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type.md) for authoring guidance.
  {% endstep %}

{% step %}

### Layer 2 — Known Locations (Approval)

[Require **Approval** (optionally with MFA or Justification)](/keeperpam/endpoint-privilege-manager/policies/policy-controls.md) for high-risk tools at their normal install paths — for example `{system32}\cmd.exe` and PowerShell under System32.

* Use on [**File Access**](/keeperpam/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md) — and on [**Privilege Elevation**](/keeperpam/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md) when those tools should not elevate without review.
* Gates casual use of the real path; still allows legitimate use after approval.
* Alone, does **not** stop a copy launched from another folder.
  {% endstep %}

{% step %}

### Layer 3 — Broad Posture (All Applications)

Author an **all-applications** (`*`) **Approval** policy as the backstop, then **Allow** business-approved apps (and trusted publishers) that should not need a ticket.

* Catches relocated, renamed, and unexpected launches or elevation targets that miss Layer A.
* Prefer Approval when unknown software should be reviewable; use hard Deny only when unknown must be refused with no approval path.
* Apply the same idea on **Privilege Elevation** when elevation should be gated by default.
  {% endstep %}

{% step %}

### Layer 4 — Known-Bad Content (Hash Deny)

For a specific bad binary that must be stopped **everywhere**, use a **hash-only** Deny (SHA256 with no path bound to it).

* Matches **contents**, so rename and relocate still Deny.
* Path + hash members require **both** to match — that is not a global content block. Prefer hash-only for "block these bytes anywhere."
* Applies on [**File Access**](/keeperpam/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md) and [**Privilege Elevation**](/keeperpam/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md); on agent paths, baseline Deny still blocks agent-driven use of that binary.
  {% endstep %}

{% step %}

### Layer 5 — Trusted Publishers (Certificate Allow)

Use **publisher certificates** on **Allow** policies for vendors and products you trust.

* Best for allow-listing signed software.
* Pair with Layer B so everything else still requires Approval (or is Denied).
  {% endstep %}

{% step %}

### Layer 6 — AI-Specific Controls

Add agentic policies for AI workflows; do not replace baseline layers with them alone.

* [**Agentic AI**](/keeperpam/endpoint-privilege-manager/policies/policy-types/agentic-ai-policy.md) — Who may launch AI applications, and with what controls.
* [**Agentic AI Access**](/keeperpam/endpoint-privilege-manager/policies/policy-types/agentic-access-policy.md) — What those agents may spawn (for example shells, package managers, browsers), via agent + child (subprocess) scope.
* [**Agentic AI Privilege Elevation**](/keeperpam/endpoint-privilege-manager/policies/policy-types/agentic-privilege-elevation-policy.md) — What an AI-attributed process may elevate.

Keep Layers 1-4 in place so a user or agent cannot bypass baseline Deny by launching or elevating a copied tool. Agentic policies add AI-specific gates; they do not remove the need for broad File Access and Privilege Elevation posture.
{% endstep %}
{% endstepper %}

## How the Layers Work Together

* User runs System32 PowerShell → Layer A File Access Approval can apply.
* User runs a copy under their profile → Layer A misses; Layer B still requires Approval (or Denies).
* Known-bad hash → Layer C Denies on launch or elevation wherever the bytes appear.
* Trusted vendor app → Layer D Allows; unknown software stays gated by Layer B.
* AI agent tries to spawn `cmd.exe` → Agentic Access may require Operator Approval; a baseline File Access **Deny** on that child still blocks it.
* AI agent tries to elevate a tool → Agentic Privilege Elevation applies; a baseline Privilege Elevation **Deny** still wins.

## When Policies Conflict

Across policy types, when multiple **enforced** policies of the same evaluation set match:

1. **More specific wins over broader** — user- or group-specific over "all users"; application-specific over "all applications" (and similar specificity for certificates, commands, and subprocess lists).
2. **Within that set, controls rank as:** **Deny → Approval → MFA / Justification / Operator Approval → Allow**.

A specific Allow for an approved app can win over an all-applications Approval for that app, while unknown paths still hit the broad layer. A Deny in the winning set blocks the action.

{% hint style="warning" %}
Deny holds the highest control priority within any winning set. Specificity resolves conflicts **across** scopes (specific vs. wildcard) — not within a set that already contains a Deny.
{% endhint %}

## Authority Ceiling for AI Paths

On AI-attributed launches and elevations:

* **Baseline Deny** (File Access or Privilege Elevation) **always wins** over a more permissive Agentic AI, Agentic Access, or Agentic Privilege Elevation outcome.
* An AI agent cannot obtain Allow where the user's baseline policy would Deny the same resource.
* Baseline MFA and Justification on agent paths are handled under agentic rules (Deny-focused carve-out); agentic policies own the AI-specific Approval and operator flows.

**Design implication:** keep strong baseline Deny and Approval layers even when investing heavily in Agentic Access policies.

## Outcomes

* **Allow** — Action proceeds.
* **Approval / MFA / Justification / Operator Approval** — Action waits until controls succeed.
* **Deny** — Action is blocked.
* **No Matching Enforced Policy** — That policy family does not intervene; OS defaults apply for that event. Other policy types may still apply.

Keeper EPM does not imply default-deny by itself. To gate or refuse unknown software or elevation, author all-applications Approval or Deny policies (Layer B), then Allow what you trust.

## Design Checklist

* [**File Access**](/keeperpam/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md) — Layers A–D for execution control: path Approval, broad Approval, hash-only Deny, certificate Allow.
* [**Privilege Elevation**](/keeperpam/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md) — Same layered idea for elevation events.
* [**Agentic AI**](/keeperpam/endpoint-privilege-manager/policies/policy-types/agentic-ai-policy.md)**,** [**Agentic AI Access**](/keeperpam/endpoint-privilege-manager/policies/policy-types/agentic-access-policy.md)**, and** [**Agentic AI Privilege Elevation**](/keeperpam/endpoint-privilege-manager/policies/policy-types/agentic-privilege-elevation-policy.md) — Explicit policies for AI launch, spawn, and elevation.
* **Baseline Coverage** — Confirm baseline Deny still covers tools that users and agents should never run.
* **Content Identity** — Prefer hash-only members for "block this binary everywhere."
* **Validation** — Test real install paths, relocated copies, and (where relevant) agent-spawned children.

## Related Reading

* [File Access Policy Evaluation Guide ](/keeperpam/endpoint-privilege-manager/policies/policy-reference/policy-evaluation/file-access-policy-evaluation-guide.md)— deeper File Access matching, hash-only vs. path+hash, and conflict examples.
* [Policy Types](/keeperpam/endpoint-privilege-manager/policies/policy-types.md) — overview of every enforced type and its controls.
* [Policy Controls](/keeperpam/endpoint-privilege-manager/policies/policy-controls.md) — Allow, Deny, MFA, Justification, Approval, and Operator Approval.
* [Policy Status](/keeperpam/endpoint-privilege-manager/policies/policy-status.md) — Enforce, Monitor, and Disabled modes.
* [Path Variables & Protected Paths](/keeperpam/endpoint-privilege-manager/policies/policy-reference/path-variables.md) and [Wildcards](/keeperpam/endpoint-privilege-manager/policies/policy-reference/wildcards.md) — shared building blocks for application scope.


---

# 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/policies/policy-reference/policy-evaluation.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.