Secure agents that run on a user's device

How-to guide

Desktop assistants, coding agents, and browser agents act with their user's access, so limit what that access exposes

  • Last validated: Oct 16, 2026
  • 12 minutes to read
  • Contributors

Overview

Desktop assistants, coding agents, and browser agents run on an employee’s device and act on that person’s behalf. They have no Cloud Secure Edge (CSE) identity of their own, which makes them a different problem from an autonomous agent with a Service Account.

What an on-device agent can reach follows from its user:

  • With the CSE desktop app connected, an agent on the device reaches whatever the user’s Service Tunnel and infrastructure service policies allow.
  • An agent that drives the user’s browser reaches the Hosted Websites the user can open.
  • CSE records the activity under the user and the device. It cannot tell the agent’s requests apart from the person’s.

You cannot scope the agent, so scope what its user can reach. The steps below find what agent users can reach, narrow it, and add the controls that limit an agent when its user is not watching.

Step 1: Find what agent users can reach today

An agent inherits every permission its user has, so a broad Role becomes broad agent access. Before you narrow anything, list what the users who run agents can reach. See Manage Roles.

1.1 List the users who run agents, and the Roles they belong to. If your identity provider has a group for them, such as agent-users, use it, because it also gives you the user list for Step 6.

1.2 In the Command Center, navigate from Directory > Roles, and open each of those Roles.

1.3 Open the Linked Policies tab, and write down every policy listed. Together these policies are everything an agent on those users’ devices can reach. Steps 2 and 4 narrow them.

1.4 If a Role covers far more people than the ones who need its access, split it. Create a narrower Role for the users who need the access, and attach the policy to that Role instead.

Step 2: Limit what the Service Tunnel carries

A Tunnel Policy decides which networks, ports, and protocols a device can reach through the Service Tunnel. An agent can reach all of it, so allow only what the job needs. See Network-level (Layer-4) Policies.

2.1 Navigate from Private Access > Access Policies, and open a Tunnel Policy from your list in Step 1.3. Edit the Access Group for each Role the agent users belong to.

2.2 Keep only the destinations the Role needs. Prefer specific FQDNs or small CIDR ranges, such as the subnet of one application, over a whole data center range like 10.0.0.0/8.

2.3 In the Allow List, select only the Protocols and Ports those destinations use, for example TCP 443 for an internal web app. Avoid ALL, because it opens every port.

2.4 Add an Exception List for sensitive hosts that sit inside an allowed range, such as domain controllers, database servers, or backup systems. An Exception List denies those destinations even though the Allow List covers their range.

2.5 Save the policy. Repeat for each Tunnel Policy on your list.

Step 3: Require a High Trust Level for sensitive resources

Device trust is the one control that applies to an on-device agent and not to a Service Account, because a real device sits behind every request. Requiring High trust means an agent can act only from a device that passes every factor in its Trust Profile. See Trust Profiles and Trust Calculation.

3.1 In each Access Group from Step 2 that reaches sensitive resources, set Trust Level to High.

3.2 Navigate from Trust > Profiles, and open the Trust Profile assigned to these users’ devices. Confirm that it includes at least Disk Encryption, Firewall, and Auto Update. Those factors confirm that the device is encrypted, protected, and patched before an agent on it can reach anything.

3.3 On a test device, turn off the firewall, and confirm that the device drops below High and loses access. With desktop app 4.7.0 or later on Windows or macOS, this takes seconds. See Real-Time Trust Factor Evaluation.

Step 4: Block sensitive paths on Hosted Websites

A browser agent can open any Hosted Website its user can open, and do anything on it. A Web Policy can allow the site while denying specific paths, such as admin pages or APIs that delete data. See API-level (Layer-7) Policies for Hosted Websites.

4.1 Navigate from Private Access > Access Policies, and open the Web Policy for a Hosted Website from your list in Step 1.3.

4.2 In the Access Group for each Role the agent users belong to, list the paths to deny in Resources with a ! prefix, for example !/admin* or !/api/v1/delete*. A ! rule overrides any rule that allows the same path.

4.3 Where the agent should only read, set Actions to READ instead of ALL, so it cannot create, update, or delete anything through the site.

4.4 Save the policy.

Step 5: End sessions when the user walks away

An agent can keep working on a device nobody is using. Session idle timeout ends the Service Tunnel and infrastructure connections after a set time with no keyboard, mouse, or touch input. See Control Remote Access Sessions.

5.1 Navigate from Settings > Configuration > Advanced, and set the session idle timeout to 15 minutes. That value meets most compliance frameworks, including PCI DSS. The field accepts 5 to 480 minutes, and 0 turns it off.

5.2 In your identity provider, require interactive sign-in for CSE. If auto-login can complete sign-in on its own, connections resume after the timeout without the user.

5.3 For Hosted Websites that agents use, turn on Secure CORS Requests, and make sure devices enforce the CSE HTTP proxy. Without both, ending the session does not end the browser’s access to the website.

The setting applies to each user at their next login or app restart.

Step 6: Watch for unusual agent activity

CSE records an agent’s requests under its user, so you find an agent misbehaving by watching for activity its user would not produce. See Export and Retain Events and Event Properties and Definitions.

6.1 Export CSE Events to your SIEM. Choose the method that matches your tooling on the export page, and create a read-only API key for it under Settings > API Keys.

6.2 Alert on these patterns for the users from Step 1.1:

  • A spike in Access events, which can mean an agent is crawling a site or scanning a network.
  • Access events with the Unauthorized action, which mean the agent is trying paths or destinations that Steps 2 and 4 deny.
  • Activity outside working hours, when the user is unlikely to be at the device.

Give recurring work its own identity

When an agent’s task becomes scheduled or unattended, move it off the user’s access. Give it a Service Account, so it has its own credentials, its own scope, and its own audit trail. See Secure Private Access for AI Agents.

What’s next

Was this page helpful?