Block access while retaining user privileges

A workflow for AI Agent Security

An AI coding agent runs with the privileges of the person who launched it, presenting the same credentials on the same machine. Credential-based controls cannot tell the two apart, so a developer who is allowed to read a production configuration file hands that same access to any agent they run. This workflow shows you how to block an agent from an action while the person keeps it.

Scope of this guide

This workflow covers writing a policy whose subject is an AI agent rather than the user, testing it in audit, and confirming the block applies to the agent only. It does not cover deploying the agent or building multi-rule policies.

Prerequisites

You have administrator access to the tenant.
The AI Agent Security agent is installed and enrolled on the test endpoint.
An AI coding agent is installed on that endpoint and signed in.
You have identified the resource to protect, such as a file path or a command.

Steps

Step 1: Describe the policy

Go to Protection > Policies.
Select New policy.
Enter a Policy name that names the resource, such as Block agent reads of production config.
Enter a description under Describe the policy. The description is where a policy's intent is recorded, so write it for whoever inherits it.
Select Build the rules.

Step 2: Build the rule

Under Enforcement mode, choose Audit. Running the policy at audit first shows you what it would catch without blocking anything.
Select the subject in the rule sentence and choose Any AI agent.

Do not choose Anyone. It matches every process on the endpoint, including the person's own, so a rule meant to stop an agent also stops the user, your backup software, and your installers.
Select the action in the rule sentence and choose reads a file for a file path, or runs a process for a command.
Select the target and enter the file path or process you are protecting.
Leave Kill the process on deny off. It terminates the process that attempted the action, which can end work the user did not expect to lose.

Step 3: Test and save the policy

Select Review & test.
On the Test & save step, replay recorded activity from a past time window and check what the policy would have matched. Nothing on this step affects live traffic.
Select Save policy. The policy is saved as a draft, and it does not affect anyone until you publish it.
Select Publish policy.

Step 4: Attach the policy to the test endpoint

On the Policies page, select the policy to open its details panel.
Select the Attachments tab.
Select Attach to endpoints and choose the test endpoint.

A published policy reaches only the endpoints and tags it is attached to, so an unattached policy applies to nothing.

Step 5: Test, then enforce

On the endpoint, have the user perform the action themselves. Then have the AI agent attempt the same action.
Go to Intelligence > Events and confirm the agent's attempt is recorded as audited, and the user's is not.
Open the policy's details panel, select Block, and confirm with Use Block.
Repeat the test. The agent is now blocked and the user is not.

Verify the results

Confirm that the person keeps access to the resource and the agent is blocked from it, on the same machine and with the same credentials. Confirm the policy shows Block in the Status column on the Policies page. A policy at Audit records without blocking, whatever its name says.

Next steps

Extend the same rule to other resources the agent should not reach, such as SSH keys and .env files.
Tell your users how to request an exception, so a legitimate blocked action has a route other than turning the policy off.
Attach the policy to a tag rather than to single endpoints once it is proven, so endpoints that join the tag are covered automatically.