Estimated time: 10-15 minutes. You will need Site Admin (or higher) access in SentinelOne, plus access to the Clarion workspace where you want to connect SentinelOne.
What you’ll configure
Connecting SentinelOne takes three things:| What | Purpose |
|---|---|
| Clarion webhook URL + secret | SentinelOne posts threats to this URL. The secret, sent as the x-webhook-secret header, authenticates them. Both are generated when you click Connect. |
| SentinelOne API token | A Service User token with the SOC role that lets Clarion enrich each alert with the full threat details and run response actions (mitigate, isolate, set verdict/status). Without it, alerts are sparse. |
| Console URL | Your tenant URL, used for the “View in SentinelOne console” deep link on alerts. |
Prerequisites
- A SentinelOne console with at least one Linux, macOS, or Windows agent enrolled
- An admin role on the SentinelOne account or site you want to forward
- Access to the Clarion workspace where you want to configure the integration
Step 1 — Connect SentinelOne in Clarion
- Open Clarion and go to Integrations → SentinelOne.
- Click Connect. Clarion generates the webhook URL and a webhook secret for this workspace.
- Copy the webhook URL and secret immediately. The secret is shown only once; if you lose it you’ll have to disconnect and reconnect to generate a new one.
Step 2 — Create a SentinelOne Service User (SOC role)
You can use a personal API token (tied to your user) for testing, but for the actual integration we recommend a dedicated Service User so the token survives if the original creator’s account changes.- In the SentinelOne console: Policies and settings → User management → Service Users.
- Click + New Service User.
- Fill in:
- Name:
clarion-integration - Description:
Used by Clarion to enrich and action threats. - Scope: prefer Site (the specific site you’re forwarding from) over Account — least privilege.
- Role: SOC. This grants both read and edit access on Threats, so Clarion can enrich alerts and run response actions (mitigate, isolate, set verdict/status). A custom role with equivalent Threats read/edit access also works. A read-only role (e.g. Viewer) only enriches alerts and cannot action threats.
- Expiration: set to 1 year; rotate annually.
- Name:
- Save → the console shows the API Token once. Copy it immediately.
Step 3 — Paste console URL and API token into Clarion
Back on Clarion’s SentinelOne configure page, fill in Console details:- Console URL — your tenant URL, e.g.
https://your-tenant.sentinelone.net. No trailing slash. - Site ID / Account ID — optional; populated automatically once the first real threat lands but you can pre-fill them if you have them.
- API token — paste the token from step 2.
API token (stored — leave blank to keep) next to the field on subsequent visits, confirming the token is set.
Step 4 — Configure the SentinelOne side
SentinelOne sends webhooks via the Singularity Webhook marketplace app. The built-in Notifications channels (SMTP, Syslog) don’t support arbitrary headers, so the marketplace app is required for auth to work.4a. Install Singularity Webhook
- SentinelOne console → Marketplace.
- Search for Singularity Webhook.
- Install (or Add Configuration if already installed). Scope to the site you want to forward from.
4b. Configure Threat Response Action 1
In the configuration screen:- Toggle Make Response Actions available as Manual Response Actions from Threats to on (so you can also fire the webhook manually from a threat in the SentinelOne console).
- Under Advanced, leave Auto-Disable on Unauthorized Error on.
- Expand Threat Response Action 1:
- Name:
Clarion - Description:
Forward threats to Clarion - Automation Trigger Options:
All Threats - URL: paste the Clarion webhook URL from step 1.
- Action:
POST - Webhook Request Body: switch to Custom (the presets ship without custom headers, so they can’t authenticate).
- Name:
4c. Custom Body
The webhook body only needs the threat ID — Clarion fills in the rest. Paste this as Define custom message body:Use the
${activity.…} placeholder syntax (braces, not $(…) parentheses). ${activity.threatInfo.threatId} and ${activity.id} both resolve to the threat ID and work equally well.4d. Headers
Set Headers to:- Var1 — Secret variable description:
Clarion webhook secret - Var1 — Secret variable value: paste the Clarion webhook secret from step 1.
4e. Test the connection
In the Threat Response Action 1 view, click Test Connection. SentinelOne should reportStatus 200 (or 201) — and you should see a corresponding webhook accepted: alert created log line in your Clarion environment.
SentinelOne’s “Test Connection” sends the template with
${activity.…} placeholders unsubstituted (because there’s no threat in scope during the test). A test alert will be created in Clarion with literal-string placeholder values in the payload — that’s expected. A real threat detection produces the resolved payload.Step 5 — Verify with EICAR
The cleanest end-to-end test is the EICAR test file. On any enrolled endpoint:[SentinelOne] eicar.com — <hostname> in Triage → Alerts, with full description (file path, SHA256, mitigation status, endpoint IP, site name, deep link back to the console).
How severity is mapped
SentinelOne’s payload doesn’t include aseverity field — only confidenceLevel: "malicious" | "suspicious" | …. Clarion maps it like this:
SentinelOne confidenceLevel | Clarion severity |
|---|---|
malicious | high |
suspicious | medium |
| anything else | medium (default) |
severity field with Critical/High/Medium/Low/Informational, Clarion uses that directly and ignores the confidence fallback.
Troubleshooting
webhook rejected: missing authentication header in Clarion logs
The x-webhook-secret header isn’t reaching Clarion. Most common causes:
- You switched the Singularity Webhook body mode from Custom to a preset; presets drop custom headers.
- The
Var1value field is blank, while the headers JSON references${Var1}. - The headers JSON has a syntax error and SentinelOne is silently sending no headers.
webhook rejected: invalid authentication token
The x-webhook-secret value doesn’t match what’s stored on the Clarion integration. You probably rotated the secret in Clarion (disconnect + reconnect) and forgot to update Var1 in SentinelOne, or vice versa. Reconnect in Clarion and re-paste the new secret into Var1.
Alerts are created but with empty fields
The API token is missing, expired, or scoped to the wrong account/site, so Clarion can’t pull the threat details. Regenerate the token in SentinelOne and re-paste it into Clarion’s API token field.${activity.…} placeholders showing as literal text in the alert payload
You’re most likely seeing a Test Connection alert, where placeholders don’t substitute by design — see step 4e. If a real detection also shows the literal ${activity.threatInfo.threatId} string, re-paste the minimal template exactly as shown in step 4c (braces, not $(…) parentheses).
Authentication issue occurred while running automated_response_actions. (1) Invalid json value for Body field
SentinelOne validates the Custom Body as JSON at save time, before any substitution. A bare ${activity} or $(activity) is not valid JSON. Only string-position placeholders ("threatId": "${activity.threatInfo.threatId}") work.