SentinelOne Singularity

At a glance

Vendor	SentinelOne Singularity Platform
Source type	edr
Vendor ID (slug)	sentinelone
Base URL	Per-tenant — https://<your-console>.sentinelone.net. The hostname is whatever URL you sign into the Management Console with.
Auth method	api-key — Authorization: ApiToken <token> (note: not Bearer). The connector overrides the dispatcher's default prefix for SentinelOne.
Schedule default	daily — override to hourly for tighter response on ransomware and detection-only KRIs.
Licensing	Any Singularity SKU — Core, Control, or Complete. All KRIs use the v2.1 /agents and /threats endpoints which are available on every Singularity tier. Specific filters (ransomware classification, MITRE tactics) surface meaningful data only on Control or Complete tiers.
Availability	New in 2026.04.

Required scopes & roles

SentinelOne API tokens inherit the role of the user who mints them. For least privilege, create a dedicated service user with the built-in Viewer role and mint the token as that user:

• Viewer (built-in read-only role) — reads agents, threats, storylines, policies, and activities. Cannot remediate, rollback, mitigate, or mutate any state. This is the correct role for the Draxis connector.
• If your org uses custom roles, grant Read on: Endpoints, Threats, Policies, Deep Visibility Events, and System Info. Do not grant any Write, Manage, or Respond permissions.

Do not mint the token under your personal Admin or Global Admin account. SentinelOne API tokens inherit the creator's role at mint time and never change; if the Draxis token leaks, a token minted from a Global Admin account grants full remediation + config-change reach across every endpoint in your org.

Setup steps

1. Create a dedicated service user. In the S1 console, go to Settings → USERS → Users → Actions → Create New User. Name it draxis-connector, use a role-mailbox email your security team monitors (e.g. draxis-api@your-domain.com), and pick Role = Viewer. Set Scope = Global unless you want to restrict Draxis to a specific Site / Account scope (valid, but reduces the KRI's coverage accordingly).
2. Set a long random password and enable MFA. This is a service user; you want it locked down. Store the credentials in your password manager — you may need them once more at token-rotation time.
3. Sign in as the service user, then generate the API token. Log out of your admin account, sign in as the service user, go to My User → Options → Generate API Token. Copy the token value immediately — it's shown only once. SentinelOne tokens are typically valid for 6 months before rotation is required.
   This sign-out / sign-in dance matters: tokens inherit the role of the user who clicks "Generate", not the scope on the user record. Generating the token while logged in as a Global Admin gives the token Global Admin reach regardless of which service user you assigned it to later.
4. Note your console URL. The URL you sign in at (e.g. https://acme.sentinelone.net) is your API Base URL. Draxis adds /web/api/v2.1/... paths itself. Strip any trailing slash or path.
5. (Optional) IP-restrict the service user. Settings → USERS → Users → draxis-connector → Actions → IP Restrictions. Allowlist the Draxis egress IP range. Skip this on first setup; add it once the connector is confirmed working.

Wire it into Draxis

1. Open Settings → Integrations in your tenant.
2. Click Add integration and pick Endpoint Detection & Response as the source type.
3. Pick SentinelOne Singularity from the vendor dropdown. Draxis pre-fills the auth method (API Key) and daily schedule.
4. In API Base URL, paste your SentinelOne console URL from step 4 (e.g. https://acme.sentinelone.net). No trailing slash or path.
5. In API Key / Token, paste the API token value from step 3. Draxis encrypts it server-side with encryption.key before storage.
6. Click Test. Green means Draxis reached /web/api/v2.1/system/info and the token authenticated successfully. The message includes your tenant's deployment mode and scope level.
7. Under KRIs to import, tick the KRIs you want Draxis to manage. All six s1_* KRIs are checked by default; uncheck any you don’t need. Selected rows are created on save with the seeded thresholds. Unchecking a previously-imported KRI deletes it on save.
8. Save. The connector runs daily by default; use Run now from run history to trigger the first sync immediately.

KRIs produced

Slug	Meaning	Derivation
s1_agents_offline_48h	Non-decommissioned agents idle for more than 48h	GET /web/api/v2.1/agents?lastActiveDate__lt=<now-48h>&isDecommissioned=false&isPendingUninstall=false&limit=1, read pagination.totalItems.
s1_threats_detection_only	Unresolved threats where mitigationMode is "detect" (S1 saw but didn't block)	GET /web/api/v2.1/threats?mitigationStatuses=not_mitigated&mitigationModes=detect&resolved=false&limit=1
s1_storylines_critical_mitre_7d	Unresolved threats in last 7d tagged with critical MITRE tactics	GET /web/api/v2.1/threats?createdAt__gte=<now-7d>&resolved=false&tactics=Credential Access,Lateral Movement,Impact&limit=1. MITRE tactic names in the query must match S1's exact strings.
s1_devices_not_protected	Agents whose operational state is less than fully_protected	GET /web/api/v2.1/agents?operationalStates=partially_protected,not_protected,disabled,error&limit=1
s1_ransomware_detections_7d	Threats classified as Ransomware in the last 7 days	GET /web/api/v2.1/threats?createdAt__gte=<now-7d>&classifications=Ransomware&limit=1. Counts both static-AI and behavioral engine classifications.
s1_threats_pending_rollback	Active threats where rollbackStatus is "pending"	GET /web/api/v2.1/threats?rollbackStatuses=pending&resolved=false&limit=1

Each row is a slug the connector writes to. Draxis creates the matching kri rows automatically when you check them in the KRIs to import section of the integration form — no manual API call or seed script needed. Thresholds shown in the table are the seeded defaults; you can edit them freely in the KRIs tab afterwards.

Vendor quirks

• Authorization header is ApiToken, not Bearer. SentinelOne's convention predates Bearer. The connector overrides Draxis's default api-key header on every request; no configuration needed.
• API tokens inherit the minting user's role at generation time, permanently. If you mint while logged in as a Global Admin, the token is Global Admin forever, regardless of the scope on the user record. Always log out, log in as the service user, then click Generate.
• Tokens rotate on a fixed schedule. SentinelOne expires API tokens every 6 months (organization-configurable). The S1 console does not notify on rotation — the connector starts failing with 401 one day. Either calendar the rotation or subscribe to S1's token-expiry admin alerts.
• "Storylines with critical MITRE" is a threats filter, not a true storyline API. Deep Visibility storylines aren't directly queryable as discrete objects; we approximate by counting unresolved threats in 7d tagged with MITRE tactic names for the three critical categories (Credential Access, Lateral Movement, Impact). If your org cares about a different subset (e.g. Initial Access + Execution), open a feature request — the tactics list is a one-line change in the connector.
• "Devices not fully protected" is an operational-state count, not a policy-exclusion count. The KRI counts agents whose operationalState is anything other than fully_protected — includes policy exclusions but also includes sensor errors, degraded states, and partial rollouts. That's the operationally meaningful signal. A strict "policy-exclusion-only" count would require iterating every policy's exclusion rules — on the roadmap.
• Ransomware detection KRI counts both engines. SentinelOne's classification is assigned by whichever engine fires first — Static AI or Behavioral AI. The KRI's derivation treats all "Ransomware" classifications as ransomware detections regardless of engine. If you need to split behavioral vs static, open a support request.
• Scope limits the KRI's coverage. If you assigned the service user to a specific Site or Account scope (step 1 of setup), every query is implicitly bounded to that scope. That's usually what you want (a Site-level admin cares about their own Site), but it means the KRI values reflect that scope, not the whole org.
• Rate limits are generous. S1's default API rate limit is 1200 req/min per token. The connector makes ~7 calls per run (probe + 6 KRIs), so this is essentially free even at hourly schedule.
• Console URL is the API host. Unlike CrowdStrike (which has separate api.* and falcon.* hostnames), SentinelOne's management UI and API share the same hostname. Whatever you sign in at is the API base.
• Timestamp filters want ISO 8601 with milliseconds. S1 accepts 2026-04-19T13:00:00.000Z as well as plain 2026-04-19T13:00:00Z. The connector sends the latter; both work.

Troubleshooting

• HTTP 401 on Test with Authentication Failed — the API token is wrong, expired (6-month rotation), or the service user was disabled. Sign in as the service user and regenerate the token.
• HTTP 403 on specific endpoints — the service user's role is too narrow. Confirm it's on the Viewer built-in role (or a custom role with read on Endpoints, Threats, Policies, Deep Visibility Events, System Info).
• HTTP 429 — you've hit the S1 rate limit. Drop the schedule to daily or less, or split the integration across multiple tokens (rare — most orgs run one Draxis connector per S1 tenant).
• s1_storylines_critical_mitre_7d is always 0 — either your tenant has no MITRE-tagged threats in the last 7 days (common for well-protected orgs), or your tactic-name strings don't match S1's exact enum. S1's tactic names are English and case-sensitive: "Credential Access", "Lateral Movement", "Impact". Custom MITRE tactic names in your tenant (rare) won't match.
• s1_devices_not_protected is high but the console shows everyone as green — S1's operationalState enum includes transient states like updating and reboot_required that the console doesn't surface as "not protected" but the connector does. A spike is usually a bulk update rollout; wait a day for it to settle.
• rowsSkipped > 0 and rowsWritten = 0 — your tenant hasn't imported any KRIs for this integration yet. Open the integration in Settings → Integrations, tick the KRIs under KRIs to import, and save.
• Still stuck? Open a support ticket with the run ID (from Run history) and we'll dig in.