Agent Sentinel
See which AI agents run on your workstations, what they do, and apply supported controls to them with the separate exo-sentinel service.
What Sentinel does
Managed agents run in your connected deployments. Agent Sentinel covers the other place agents run: employee workstations, where people use Claude Code, Codex, Gemini CLI, Cursor, and similar tools directly. It is a separate executable, exo-sentinel, that reports to the control plane. Open Security → Agent Sentinel in the console.
| Capability | What you get | Read more |
|---|---|---|
| Inventory | Installed harnesses, skills, MCP servers, agent add-ons, and IDE plugins on each device. | Inventory & add-on policy |
| Activity | Sessions, prompts (as far as your capture mode allows), token usage, and who is running what. | Activity & alerts |
| Network guard | Capture and rules for traffic to AI vendors, and limits on which applications reach them. | Network controls |
| Gateway routing | Provider calls sent through your LLM gateway with keys bound to the person and process. | Gateway routing |
| Supervision | Agents launched through Sentinel run in a sandbox with credential and network protections. | Supervised runs |
| Policy hooks | Managed harness settings route tool calls through your command policies before they execute. | Resource policies |
To install it across a fleet, see Deploy Sentinel to devices.
Privileged service and per-user collector
Sentinel runs in one of two modes.
- Privileged service. A system service that standard users cannot stop, edit, or uninstall. It owns the device credential, and for each interactive account on the machine it runs a worker as that account to read that user's agent transcripts. Transcript parsing never runs as root, and a worker can read only what its user can. The network guard, gateway routing, and supervision require this mode.
- Per-user collector (
legacy_user). Runs as the signed-in user and covers that user's home directory. It provides inventory, activity, and add-on policy. A user who can modify their own collector, configuration, or state can bypass it.
In privileged mode a small per-user helper reports the user's current exo login, so the service can map a device account to a verified platform user, and shows service status in the macOS menu bar. Stopping the helper stops nothing; the service reports it as missing. Any user can check the service from a terminal:
exo-sentinel status --service
Platform support
| Platform | Privileged service | Per-user collector |
|---|---|---|
| macOS | Supported. Transparent network interception additionally needs a provisioned Network Extension deployed through MDM, which is pending qualification on signed fleet deployments. | Supported |
| Linux | Supported (systemd, DEB and RPM packages for x64 and ARM64). | Supported |
| Windows | Implemented, pending managed-device qualification. Use the per-user package until it is qualified. | Supported (x64) |
Reading protection coverage
The device list's Protection coverage column highlights stale reports, identity conflicts, component errors, unsupervised agents, adopted runs without a sandbox, and missing policy or guard reports. Open a device's Overview → Protection coverage for activity-reader coverage, the applied policy revision, network guard details, and run counts.
Protection checks
Overview → Protections on a device shows per-control results. Where your administrator has enabled them, you can also run on-demand checks that exercise a control with harmless synthetic traffic and record the outcome.
| Check | What a pass shows | Scope |
|---|---|---|
| Check configuration | The device reads back the settings it was sent. | All privileged collectors |
| Test proxy fixture | A launched run's request through the guard's proxy was allowed, and a matching blocked request was stopped. | Running Linux launches, IPv4 or IPv6 |
| Test direct-egress block | A confined run could not connect directly to a host outside the guard. | Confined Linux runs, TCP or UDP |
| Test transparent interception | Proxy-unaware HTTPS from the run was delivered to the guard. | Unconfined Linux runs |
| Test gateway routing | The run's traffic reached the configured LLM gateway, which accepted a run-bound key. | Linux launches, operator-managed gateways |
| Test content capture | The device handled a synthetic prompt and exchange as its capture mode requires. | Privileged collectors on every platform |
| Test hook fixture | An installed Claude Code, Codex, or Gemini CLI honored allow and deny decisions from a synthetic hook. | macOS, per OS account |
| Check a rule (dry run) | What your command policies would decide for one command, path, or host. Nothing executes. | Any device account mapped to a platform user |
Each check covers only the route, address family, and run it tested. A hook fixture uses synthetic settings, so it shows how the harness integrates, not that your own rules are enforced. In those fixtures the tested harnesses still ran the action when the hook timed out or was missing, so protect the service from being stopped before relying on hooks.
Permissions
| Permission | Allows |
|---|---|
sentinel:read | View devices, inventory, activity, people, and recorded check results. |
sentinel:write | Manage devices, policies, push tokens, add-on controls, plugin classifications, and request checks. |
alerts:read | View Security → Alerts. |
Assign these through roles. Browser Sentinel extensions are proposed and not available. Existing Web Agents and managed browser add-ons are separate features.