Agentic AI Policy

Control which users and endpoints can run AI agents

Overview

The Agentic AI policy governs whether an AI agent is permitted to run at all on a monitored endpoint, and which agents are recognized, enrolled, and governed across the fleet. Where an Agentic Access policy controls what an already-running agent may do, and an Agentic Privilege Elevation policy handles an agent's elevation requests, an Agentic AI policy is the gate that sits in front of both: it determines which agent processes are allowed to execute, which are denied, and which are held for review before they ever take an action.

AI agents — commercial coding assistants such as GitHub Copilot, Cursor, Claude Code, Tabnine, and Codeium, containerized agents, and unknown processes that behave like agents — increasingly launch and run with the same privileges as the user who started them. An Agentic AI policy lets you decide, per User Collection and Machine Collection, which of those agents are sanctioned, which are blocked, and which require approval before they are permitted to operate.

Agents are recognized in one of two ways. Known Agents are identified by signature — process name and path, publisher or certificate, binary hash, and network fingerprint. Possible Agents are flagged by a behavioral heuristic engine that scores unknown processes 0–100 on how closely they behave like an AI agent. Any application can also be flagged as Agentic AI from the Applications view, after which it appears under the Agentic AI collection and becomes available for policy targeting.

While Agentic AI policies enforce controls actively, they are designed to be introduced in Monitor mode first. Observing which agents would be matched — before the policy enforces — lets you validate scope and confidence thresholds without interrupting legitimate agent activity. See Policy: Phased Rollout Planning for recommended sequencing.

How it Works

Recognizing agents. An Agentic AI policy is scoped to an Agentic AI Collection — a group of known and flagged AI agent applications. Known Agents are matched by signature; Possible Agents are surfaced by behavioral heuristics and scored for confidence. Use the All Agentic AI collection to target every recognized agent, or define a narrower collection (for example, "Approved Coding Assistants") to govern a specific set.

Allowing or denying the agent itself. The policy decides whether a matching agent process is permitted to run. An Auto-Approve (Allow) outcome lets a sanctioned agent operate without friction; an Auto-Deny (Deny) outcome blocks the agent outright. Between those extremes, the agent can be held for administrator approval, end-user approval, MFA, or justification before it is permitted to run.

Confidence-driven controls. Because Possible Agents carry a detection confidence score, policy controls can be conditioned on a threshold — Likelihood of Being an AI Agent (%). This lets you, for example, allow low-confidence detections silently while requiring approval for any process scoring above a defined tier, so unknown agent-like processes are reviewed before they are trusted.

Human-in-the-loop. The Require User Approval control prompts the end user on the endpoint to approve or deny a recognized agent in real time. This is distinct from administrator approval: it puts the person operating the endpoint in the loop for the decision to let the agent run. A Don't ask again for N hours option is available to reduce repeat prompts.

Stacked controls. As with Privilege Elevation and File Access, controls are additive. When more than one applicable control is set (for example MFA and approval), all enforced requirements must be satisfied before the agent is permitted to run.

Audit baseline. Every governed agent — allowed, denied, or held — is recorded, so all AI agent activity can be audited against the policy baseline regardless of the enforcement outcome.

Controls

An Agentic AI policy supports the following controls:

Auto-Approve (Allow) — Permits a matching agent to run without further friction. Cannot be combined with other controls.

Auto-Deny (Deny) — Blocks a matching agent and returns a deny outcome without a user-facing prompt. Cannot be combined with other controls.

Require Approval — The agent is held until an assigned approver grants the request.

Require Justification — A written reason must be supplied before the agent is permitted to run.

Require MFA — Identity must be verified (TOTP) before the agent is permitted to run.

Require User Approval — The end user on the endpoint must approve or deny the agent (human-in-the-loop).

Managing an Agentic AI Policy

1

Define an Agentic AI Collection

Before creating the policy, unless you plan to use the "All Agentic AI" collection, you will need to organize the Agentic AI Agents you want to govern into an Agentic AI Collection. Navigate to Collections → Agentic AI and create a new collection. Add known agents directly, or flag detected applications as Agentic AI from the Applications view — flagged applications then appear under the Agentic AI collection and become available for policy targeting.

Give the collection a descriptive name that reflects its purpose — for example, "Approved Coding Assistants" or "Flagged Possible Agents" — to make it easy to identify when assigning it to a policy.

2

Open the Policy Form

From the Admin Console, navigate to Endpoint Privilege Manager → Policies and click the Create Policy button.

3

Configure the Policy

Fill in the policy details:

• Policy Name — A descriptive name (e.g. Agentic AI – Approval for High-Likelihood Agents)
• Policy Type — Select Agentic AI
• Status — Select Monitor to observe matches first, or Enforce to apply controls actively

Agentic AI policies default to Monitor mode and support the full Monitor / Monitor & Notify / Enforce / Off lifecycle. Start in Monitor to validate scope before enforcing.

4

Select Controls

Add the control(s) to apply when a matching agent is recognized — Require Approval, Require Justification, Require MFA, or Require User Approval. Optionally configure a Risk Score threshold so that controls only trigger when the agent's likelihood score exceeds the configured value.

Stacked Controls — When controls are stacked, all must be satisfied before the agent is permitted to run. Allow and Deny are mutually exclusive and cannot be combined with any other control.

5

Set Policy Filters

Define the scope of the policy:

• User Collections — Target specific User Collections, or select all users
• Machine Collections — Target specific Machine Collections, or select all enrolled endpoints
• Application Collections — Optionally scope to specific applications
• Agentic AI Collections — Select the Agentic AI Collection created in Step 1

6

Save and Deploy

Click Save. The policy is pushed to in-scope endpoints within approximately 30 minutes, or immediately via the Refresh Policies option in the Keeper agent.

Admin Console UI

The Agentic AI policy form exposes the following elements:

• Policy Name
• Policy Type (Agentic AI selected)
• Status
• Controls
• User Collections
• Machine Collections
• Application Collections
• Agentic AI Collections

Policy JSON Example

The following Agentic AI policy runs in Monitor mode and requires justification for any application detected as an AI agent with a likelihood score of 90% or higher, scoped to all users, all applications, and a single Machine Collection.

json

{
  "PolicyName": "-->  3-AgenticAI",
  "PolicyType": "AgenticAi",
  "PolicyId": "YVKYlhLqNdLuK54bRxAQvA",
  "Status": "monitor",
  "Actions": {
    "OnSuccess": { "Controls": ["JUSTIFY"] },
    "OnFailure": { "Command": "" }
  },
  "NotificationMessage": "A policy has been set to monitor mode.  When this policy is enabled, [mfa, justification, request] will be required to run this process as an administrator.",
  "NotificationRequiresAcknowledge": false,
  "RiskLevel": 50,
  "Operator": "And",
  "Rules": [
    {
      "RuleName": "UserCheck",
      "ErrorMessage": "This user is not included in this policy",
      "RuleExpressionType": "BuiltInAction",
      "Expression": "CheckUser()"
    },
    {
      "RuleName": "MachineCheck",
      "ErrorMessage": "This Machine is not included in this policy",
      "RuleExpressionType": "BuiltInAction",
      "Expression": "CheckMachine()"
    },
    {
      "RuleName": "ApplicationCheck",
      "ErrorMessage": "This application is not included in this policy",
      "RuleExpressionType": "BuiltInAction",
      "Expression": "CheckFile(false)"
    },
    {
      "RuleName": "DateCheck",
      "ErrorMessage": "Current date is not covered by this policy",
      "RuleExpressionType": "BuiltInAction",
      "Expression": "CheckDate()"
    },
    {
      "RuleName": "TimeCheck",
      "ErrorMessage": "Current time is not covered by this policy",
      "RuleExpressionType": "BuiltInAction",
      "Expression": "CheckTime()"
    },
    {
      "RuleName": "DayCheck",
      "ErrorMessage": "Today is not included in this policy",
      "RuleExpressionType": "BuiltInAction",
      "Expression": "CheckDay()"
    },
    {
      "RuleName": "CertificateCheck",
      "ErrorMessage": "Certificate hash is not included in this policy",
      "RuleExpressionType": "BuiltInAction",
      "Expression": "CheckCertificate()"
    }
  ],
  "UserCheck": ["*"],
  "MachineCheck": ["aDdMC3y_isged8ODDSnvRg"],
  "ApplicationCheck": ["*"],
  "DayCheck": [],
  "DateCheck": [],
  "TimeCheck": [],
  "CertificationCheck": [],
  "Extension": {
    "minAiLikelihoodPercent": 90
  }
}

Field Reference

Field	Description
PolicyName	Display name of the policy.
PolicyType	Policy type identifier. For this policy type, AgenticAi.
PolicyId	Unique identifier assigned to the policy.
Status	Policy lifecycle state — monitor, monitor & notify, enforce, or off. Agentic AI policies default to monitor.
Actions.OnSuccess.Controls	The control(s) applied when the policy matches — for example JUSTIFY, MFA, REQUEST, OPERATORAPPROVAL. Multiple controls are additive (stacked).
Actions.OnFailure.Command	The action taken when a rule check fails. Empty ("") in Monitor contexts, where the policy observes without enforcing a deny.
NotificationMessage	Message surfaced to the end user when the policy applies.
NotificationRequiresAcknowledge	Whether the end user must acknowledge the notification before proceeding.
Operator	Logical operator combining the rule checks. And requires all rules to pass.
Rules	The ordered set of built-in rule checks evaluated for a match (user, machine, application, date, time, day, certificate).
Rules[].RuleName	Identifier of the individual rule check.
Rules[].ErrorMessage	Message recorded when the rule check does not pass.
Rules[].RuleExpressionType	Type of the rule expression. BuiltInAction for the standard checks.
Rules[].Expression	The built-in function evaluated for the rule (e.g. CheckUser(), CheckMachine(), CheckFile(false)).
UserCheck	User Collection scope. ["*"] targets all users.
MachineCheck	Machine Collection scope. A collection identifier targets specific enrolled endpoints; ["*"] targets all.
ApplicationCheck	Application Collection scope. ["*"] targets all applications.
DayCheck / DateCheck / TimeCheck	Optional day-, date-, and time-of-day constraints on when the policy applies. Empty arrays apply no constraint.
Extension.minAiLikelihoodPercent	The minimum AI-likelihood detection score (0–100) a process must reach for the policy to apply. In the example, the policy applies only to processes scoring 90% or higher.