Agentic Access Policy
Control what AI agents can execute on a user's behalf with policy-based approvals and enforcement

Overview
The Agentic Access policy governs what an AI agent may execute on a user's behalf once it is running on a monitored endpoint. Where an Agentic AI policy decides whether an agent is permitted to run at all, an Agentic Access policy applies controls to the individual actions a running agent takes — accessing sensitive files, executing privileged or command-line operations, or reaching protected resources.
AI agents — commercial coding assistants such as GitHub Copilot, Cursor, Claude Code, Tabnine, and Codeium, as well as unknown processes that behave like agents — increasingly act with the same privileges as the user who started them. An Agentic Access policy inserts an enforcement layer between the agent and the resource. A matching agent action can be allowed, denied, held for administrator approval, held for end-user (human-in-the-loop) approval, or gated behind MFA or justification — and every action is audited against the policy baseline.
While Agentic Access policies enforce controls actively, they are designed to be introduced in Monitor mode first. Observing how often a policy would match — before it enforces — lets you tune scope and risk thresholds without interrupting legitimate agent activity. See Policy: Phased Rollout Planning for recommended sequencing.
How it Works
Targeting AI agents, not just applications. In addition to the standard User, Machine, and Application collection filters, an Agentic Access policy can be scoped to an Agentic AI Collection — a group of known and flagged AI agent applications. Agents are detected either by signature (Known Agents) or by behavioral heuristics (Possible Agents), and any application can be flagged as Agentic AI from the Applications view so that it appears under the Agentic AI collection.
Risk-score-driven controls. Policy controls can be conditioned on a risk threshold. When a detected agent action exceeds a configured threshold — for example, Likelihood of Being an AI Agent (%) — the policy's response action is triggered. This lets you, for instance, allow low-confidence detections silently while requiring approval for anything scoring above a defined tier.
Human-in-the-loop. The Require User Approval control prompts the end user to approve or deny what the agent is attempting, in real time. This is distinct from administrator approval: it puts the human operating the endpoint in the loop for the agent's action. A Don't ask again for N hours option is available to reduce repeat prompts for the same activity.
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 action proceeds.
Audit baseline. Every governed agent action is recorded, so all AI agent activity can be audited against the policy baseline regardless of the enforcement outcome.
Controls
An Agentic Access policy supports the following controls:
Auto-Approve (Allow) — Permits matching agent actions without further friction. Cannot be combined with other controls.
Auto-Deny (Deny) — Blocks matching agent actions and returns a deny outcome without a user-facing prompt. Cannot be combined with other controls.
Require Approval — The action is held until an assigned approver grants the request.
Require Justification — A written reason must be supplied before the action proceeds.
Require MFA — Identity must be verified (TOTP) before the action proceeds.
Require User Approval — The end user on the endpoint must approve or deny the agent's action (human-in-the-loop).
Managing an Agentic Access Policy
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.
Configure the Policy
Fill in the policy details:
Policy Name — A descriptive name (e.g. Agentic Access – Approval for High-Likelihood Agents)
Policy Type — Select Agentic Access
Status — Select Monitor to observe matches first, or Enforce to apply controls actively

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

Add the control(s) to apply when a matching agent action is detected — 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 or risk score exceeds the configured value.
Stacked Controls — When controls are stacked, all must be satisfied before the action is permitted. Allow and Deny are mutually exclusive and cannot be combined with any other control.

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

Admin Console UI
The Agentic Access policy form exposes the following elements:
Policy Name
Policy Type (Agentic Access selected)
Status
Controls
User Collections
Machine Collections
Application Collections
Agentic AI Collections
Certificate Collections
Product Collections
Policy JSON Example
The following Agentic Access policy runs in Monitor mode and allows matching actions for any application detected as an AI agent with a likelihood score of 90% or higher, evaluating all sub-processes, scoped to all users, all applications, and a single Machine Collection.
Field Reference
PolicyName
Display name of the policy.
PolicyType
Policy type identifier. For this policy type, AgenticAccess.
PolicyId
Unique identifier assigned to the policy.
Status
Policy lifecycle state — monitor, monitor & notify, enforce, or off. Agentic Access policies default to monitor.
Actions.OnSuccess.Controls
The control(s) applied when the policy matches — for example ALLOW, DENY, JUSTIFY, MFA, REQUEST, OPERATORAPPROVAL. Multiple controls are additive (stacked); ALLOW and DENY cannot be combined with other controls.
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.SubProcessCheck
Scopes which sub-processes spawned by the agent the policy evaluates. Accepts a collection of specific applications (for example cmd.exe, powershell.exe) or ["*"] to evaluate all sub-processes.
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.
Last updated
Was this helpful?

