macOS - Security - Install SentinelOne Agent

What the SentinelOne deployment Worklet does

This Automox Worklet™ deploys the SentinelOne EDR agent to macOS endpoints. The evaluation phase looks for the sentinelctl binary at /usr/local/bin/sentinelctl and asks it for a status string. If the agent is missing, or sentinelctl exits non-zero, the endpoint is flagged for remediation. If the agent is already running and registered, the Worklet exits 0 and leaves the endpoint untouched.

Remediation reads two policy variables: the installer package filename (for example SentinelAgent_macos_v21_5_3_5411.pkg) staged in the Worklet's working directory, and the site token from your SentinelOne Packages page. The script writes the token to /tmp/com.sentinelone.registration-token, copies the PKG to /tmp, then runs /usr/sbin/installer with /Library/ as the target. SentinelOne reads the token on first launch, registers the endpoint to the correct tenant and site group, and the Worklet removes both the temporary PKG copy and the token file when the install completes.

Agent files land under /Library/Sentinel and /Library/Extensions; the command-line tool installs to /usr/local/bin/sentinelctl. On macOS 11 and later, the agent loads as a system extension under the Apple Endpoint Security framework, and on macOS 10.15 it falls back to a signed kernel extension. Either way, Full Disk Access and the system extension load both require an MDM-pushed PPPC profile so the agent comes online with no user prompts.

Why deploy SentinelOne to every macOS endpoint

A Mac without the SentinelOne agent is missing from EDR coverage. macOS endpoints without the agent do not report process telemetry, behavioral detection never triggers, and the Singularity console shows a coverage map that does not match reality. New hires, re-imaged laptops, and lab Macs can sit outside policy until someone notices a stale heartbeat. Manual PKG runs leave the site token in shell history and miss endpoints that the admin cannot reach interactively. The resulting EDR gaps typically surface only during an incident.

Apply this Worklet to the macOS device group covered by your SentinelOne site token; the script pushes the PKG and the registration-token file to every targeted endpoint, registers each Mac to the correct tenant on first launch, and re-runs on the policy schedule. A re-imaged laptop is back under EDR by the next agent check-in.

How the SentinelOne PKG install runs

1. Evaluation phase: The Worklet runs /usr/local/bin/sentinelctl status and inspects the exit code. A zero exit code means the agent binary is present and the daemon responded, so the endpoint is reported compliant and remediation is skipped. A missing binary or a non-zero exit code from sentinelctl flags the endpoint as out of policy and queues remediation.

2. Remediation phase: The script writes the site token to /tmp/com.sentinelone.registration-token, copies the staged PKG into /tmp, then runs /usr/sbin/installer -pkg /tmp/SentinelAgent_macos_*.pkg -target /Library/. SentinelOne lays its bundle into /Library/Sentinel and /Library/Extensions, registers the system extension or kext, and reads the registration token on first launch. The Worklet removes the temporary PKG copy and token file, then re-runs sentinelctl status: a zero exit code returns success, a non-zero exit code returns failure.

SentinelOne deployment requirements

• macOS 10.15 (Catalina) or later. Apple Silicon and Intel are both supported by the universal SentinelOne PKG.

• Root execution context. The Automox agent already runs as root on macOS, so no further elevation is needed.

• SentinelOne installer PKG (.pkg) pre-staged on the endpoint at the path referenced by the policy variable, or downloaded inline by an upstream Worklet.

• Valid site token from the SentinelOne Singularity console under Sentinels → Packages → Site Token.

• MDM-pushed PPPC profile granting Full Disk Access to com.sentinelone.sentinel-agent and pre-approving the SentinelOne system extension or kernel extension. Without the profile, the user sees a TCC prompt and the system extension stays unloaded.

• Outbound HTTPS from the endpoint to your SentinelOne management console (typically usea1-*.sentinelone.net or your tenant’s region-specific host) on TCP 443.

Expected state after SentinelOne deployment

On a successful run, /usr/local/bin/sentinelctl is in place, the SentinelOne agent bundle is under /Library/Sentinel, and launchd shows the com.sentinelone.sentineld jobs as loaded. The agent registers with your tenant on first launch and the endpoint appears in the Singularity console under the site that owns the token. The temporary token file at /tmp/com.sentinelone.registration-token is removed by the script before exit, so the token does not linger on disk.

Verification: Run sentinelctl status on the endpoint to confirm the agent reports Loaded, Enabled, and the management URL points at your tenant. Run systemextensionsctl list (macOS 11+) and look for com.sentinelone.network-extension and com.sentinelone.endpoint-security-extension in the activated enabled state. On macOS 10.15, use kextstat | grep -i sentinel instead. In the SentinelOne console, the endpoint should show as Protected with the correct site assignment, and the EICAR test file should be quarantined within seconds of being written to disk.

If the agent installs but the system extension stays in the activated waiting for user state, the PPPC profile is missing or scoped wrong. Push the profile from your MDM, then re-run the Worklet; the evaluation phase will report the endpoint compliant once sentinelctl status returns a loaded daemon. Re-running this Worklet on a recurring policy keeps coverage in place across re-images and OS upgrades, so a returned-from-IT laptop is back under EDR within one Automox cycle.