Policy Evaluation
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.
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.
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
The agent observes an event: a launch, an elevation, or an agent child / agent elevation.
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.
It selects enforced policies of the relevant type(s) whose filters match.
If more than one policy matches, specificity and control priority produce a single outcome (see When Policies Conflict).
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).
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 mitigation, elevation control, software allow-lists, or AI containment. Start from a Least Privilege foundation, then stack policies from broad to specific — and use the right policy type for each event.
Security Policy Pyramid
Layer 1 — Least Privilege (Foundation)
Author a Least Privilege Policy 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 (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 for authoring guidance.
Layer 2 — Known Locations (Approval)
Require Approval (optionally with MFA or Justification) for high-risk tools at their normal install paths — for example {system32}\cmd.exe and PowerShell under System32.
Use on File Access — and on Privilege Elevation 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.
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.
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 and Privilege Elevation; on agent paths, baseline Deny still blocks agent-driven use of that binary.
Layer 6 — AI-Specific Controls
Add agentic policies for AI workflows; do not replace baseline layers with them alone.
Agentic AI — Who may launch AI applications, and with what controls.
Agentic AI Access — What those agents may spawn (for example shells, package managers, browsers), via agent + child (subprocess) scope.
Agentic AI Privilege Elevation — 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.
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:
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).
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.
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.
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 — Layers A–D for execution control: path Approval, broad Approval, hash-only Deny, certificate Allow.
Privilege Elevation — Same layered idea for elevation events.
Agentic AI, Agentic AI Access, and Agentic AI Privilege Elevation — 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 — deeper File Access matching, hash-only vs. path+hash, and conflict examples.
Policy Types — overview of every enforced type and its controls.
Policy Controls — Allow, Deny, MFA, Justification, Approval, and Operator Approval.
Policy Status — Enforce, Monitor, and Disabled modes.
Path Variables & Protected Paths and Wildcards — shared building blocks for application scope.
Last updated