Mint a SentinelOne API token
In the SentinelOne management console, go to Settings → Users → API tokens and create a new token with Viewer and Alerts scope. Viewer is enough to read alert metadata; Alerts opens the threat and activity data CipherRun needs to score a workflow run.
If you're on Singularity XDR or higher, the same token can also drive threat.intel.lookup steps — no second key needed. Rotate quarterly; CipherRun treats a 401 as a hard fail and surfaces it on the workflow run page.
Paste the token into /admin/apikeys
Open /admin/apikeys, find the SentinelOne row, and drop the API token in. CipherRun stores it encrypted (pgcrypto, AES) and uses it the next time any workspace workflow fires on alert_triggered. You should see something like:
The row carries an Updated timestamp — if you mint a new token in S1 and forget to paste it in here, that timestamp is the first place to look when a workflow run goes red.
Bind the SentinelOne tenant to your workspace
Paste the SentinelOne Tenant ID — the value that appears in the S1 console URL as accounts/{id} — into the workspace Admin → SentinelOne page at /admin/s1. CipherRun stores the binding on the workspace row and uses it to resolve every inbound alert back to that workspace, so the S1 forwarder doesn't need to know anything about CipherRun routing.
Once bound, CipherRun's playbook engine picks the built-in runbook for the alert classification: ransomware → ransomware-ir-chain, suspicious process → malware-hash-lookup, lateral movement → suspicious-login. The run lands in /app as a queued playbook run, with the S1 tenant and alert id stamped on the lineage row so the audit timeline traces back to the S1 config.
Add Slack and Jira next and you've got a complete handoff — from detection to scored decision to ticket with no human on the loop.