Deploy Sentinel to devices

Create a deployment

Open Security → Sentinel → Deployments and create a named rollout. Set an enrollment window (1 to 90 days) and a lifetime enrollment limit (1 to 10,000 devices). One deployment can enroll macOS, Windows, and Linux devices within its shared limit.

Choose the operating system, architecture, and package type when you download. The bundle is a ZIP containing the installer, installation and detection scripts, a README for your management tool, and a private enrollment.json.

Each device exchanges the shared enrollment secret for its own credential. The secret can only enroll: it cannot upload telemetry or retrieve policy. No employee tokens or exo login are needed to install.

• Closing enrollment keeps already enrolled devices working.
• Revoking the deployment invalidates every device credential it issued.
• Removed or expired device credentials do not give enrollment quota back.

The deployment list shows lifetime enrollments, devices that currently hold a credential, devices with a heartbeat in the last hour, and devices awaiting their first heartbeat. Your device management tool remains the source for installation failures that happen before enrollment.

macOS

Use Jamf, Kandji, or Intune. Deploy the configuration profile first, scoped to the same devices, then the package. Upload the package as a managed app and provision-macos.sh as a root script; provisioning may run before or after the package. The script contains the enrollment secret and needs the same protection as enrollment.json.

Without the network extension, the guard runs as an explicit proxy. Claude Code is still covered, because the service writes its managed settings. Tools that ignore proxy settings are not. See Network guard.

Package upgrades preserve configuration and identity. The provisioning script refuses a different endpoint instead of silently moving a Mac between organizations.

Windows

For Intune, extract the Windows ZIP privately, run the Microsoft Win32 Content Prep Tool with install-windows.cmd as the setup file, and upload the resulting .intunewin as a Windows app (Win32). Use System install behavior, x64 requirements, the included 64-bit detection script, and exit code 3010 as a soft reboot. Configuration Manager and other tools can run the same scripts as SYSTEM.

The installer verifies the package signature and checksum, writes configuration readable only by SYSTEM and Administrators, and starts the service. The privileged Windows service is pending managed-device qualification; validate installation, upgrade, and removal on real Windows devices first.

Linux

Linux bundles include checksums, an Ansible playbook, and root scripts for provisioning, detection, installation, and removal. Hosts need systemd and Python 3, plus apt-get for DEB or dnf for RPM. Provisioning may run before or after package installation, and upgrades preserve identity.

Restricting AI access to supervised runs needs the nft_socket kernel module, which stock Debian, Ubuntu, and RHEL kernels ship. After installing, confirm the service:

exo-sentinel status --service

Install on a single device

To try Sentinel on one machine, open Security → Agent Sentinel, create a push token, and use the installation pack shown for macOS, Linux, or Windows. This installs the per-user collector, which provides inventory, activity, and add-on policy for that user.

Roll out in rings

1. Set the workspace policy first. Collection interval, capture mode, guard domains and rules, routing, supervision, and hooks. All deployments use the workspace policy and any device overrides.
2. Start with a pilot ring of IT and a few engineers, with policies in monitor mode. Watch device health, the Network tab, and policy decisions.
3. Turn on enforcement and hooks. Hooks fail closed: if the service is stopped or unreachable and a tool call was never evaluated before, the harness refuses it. On macOS, deploy the managed login items payload first so the service cannot be switched off.
4. Widen ring by ring, with one deployment per ring, closing enrollment when each ring is done.

In a pilot, test a harmless denied operation, an approved operation, an approval hold, an offline and restart cycle, and metadata-only collection. Inspect the actual result and the stored telemetry, not only the component health report.

How policy reaches devices

Set the workspace default under Security → Agent Sentinel → Policy and per-device overrides under Policy on a device. Every change takes a new revision. A device's effective revision only ever increases, even when an override is cleared.

Devices receive policy when they renew their credential and also poll for it every 60 seconds. A policy is validated whole and applied atomically. An offline device keeps enforcing the last valid policy it received.

Remove a device

Delete on a device does three things immediately: it blocks that device ID from ever enrolling, renewing, or uploading again; it revokes its upload credentials; and it removes its telemetry and user mappings and marks it as decommissioning.

When the device next contacts the control plane, it stops what it manages, withdraws managed settings, trust, and launcher shims, confirms decommissioning, and wipes its identity. It then idles until it is provisioned again with a new enrollment, which creates a new device.

On macOS you can also remove Sentinel locally as an administrator:

sudo "/Library/Application Support/Adaptive Scale/Exo Sentinel/uninstall.sh"

Before removing a per-user collector that enforces an add-on policy, disable the policy and wait for it to report restoration. See Add-on policy.

Conflicts and silent devices

• Conflict. A validly signed renewal that does not continue the stored sequence means a second copy of the device key exists. The console shows a Conflict status and a warning. The legitimate device is not revoked automatically; investigate, then remove and re-enroll it if needed.
• Silent. A device with no heartbeat for six hours, twice the credential lifetime.

Move from per-user installs

The privileged macOS package disables each user's per-user agent and leaves its state in place. The privileged service enrolls as a new device, so remove the old per-user device in the console with Remove without waiting. On Linux, disable the user units before installing the package:

systemctl --user disable --now exo-sentinel