Skip to main content
You connect SentinelOne once at the MSP level, then turn it on per agent.

​
1. Create a service user in SentinelOne

A service user is an API-only account. It cannot sign in to the console, and its token does not depend on a person’s account.
1

Open Service Users

In the SentinelOne management console, go to Settings > Users > Service Users and create a new service user.
2

Pick the scope

Pick Account scope to cover every client in that account, or Site scope for one client. Neo maps each site to a PSA company, so Account scope is usually right for an MSP.
3

Pick the role

Each API operation needs its own permission (for example Threats.updateAnalystVerdict to set a verdict), and a role grants a set of them. Other MSP tools ask for Viewer to read, and for SOC or IR Team to set verdicts and respond to threats. Whatever you allow in Neo, the role decides what SentinelOne accepts.
4

Set the expiry and copy the token

SentinelOne requires an expiry date for the token. Pick the longest your policy allows, and note the date: when the token expires, agents stop reaching SentinelOne until you save a new one. Copy the token when it is shown.
Do not use the token from My User > API Token Operations. It belongs to your own console account and expires after 30 days by default.

​
2. Add the token in Neo

1

Open Integrations

In the Neo Dashboard, open Integrations and find the SentinelOne card, under Security.
2

Enter the console URL and token

Console URL is the address of your management console, as the browser shows it, for example https://usea1-yourcompany.sentinelone.net. Paste the service user’s token into API Token and click Save.Neo checks both before it saves them. It confirms that the token authenticates and that it can list your sites. A wrong URL, an expired token or a role that cannot view sites is rejected immediately.
Neo accepts SentinelOne cloud consoles (*.sentinelone.net) and US government consoles (*.s1gov.net). On-premises consoles are not supported.

​
3. Turn SentinelOne on per agent

Each agent decides whether it uses SentinelOne and which areas it can touch. Open the agent, go to the Integrations section, and configure the SentinelOne block.

​
Pick an access profile

Read Only

Every area read only. The agent investigates threats and endpoints and reports, but never changes anything.

Helpdesk

Threats & Alerts and Endpoints read and write, everything else read only. The agent can close threats, add notes, scan endpoints and collect logs. Mitigation and isolation still wait on a technician.

IT Admin

Every writable area read and write, with technician approval on every write.

Full Automation

Routine triage writes, scans, log and file collection and tags run with no approval. Mitigation, network isolation, reboot, shutdown, uninstall, exclusions, scripts and site changes still wait on a technician.

​
Or set each area by hand

​
Safety controls

  • Response actions always wait on a technician. This covers mitigation, network isolation, reboot, shutdown, uninstall, exclusions, the blocklist and remote scripts. It holds whatever the agent’s automation level or access profile. It is not a setting you can turn off.
  • Threat, alert and endpoint actions name their targets. SentinelOne applies such an action with an empty filter to every endpoint or threat the token can see. Neo refuses one that does not list the exact threat, alert or endpoint ids.
  • Only the writes Neo needs are allowed. Neo refuses policy changes, site deletion, user and token management, remote shell and other console administration, whatever the agent is set to.
  • Secrets stay in SentinelOne. Neo never reads site registration tokens, agent passphrases or the uninstall password. It also removes registration tokens from every site and group record before an agent sees it.
  • Path safety. Neo rejects suspicious URL paths (anything that contains .., for example) before they reach SentinelOne.

​
If SentinelOne refuses Neo’s requests

Until a 401 or 403 is fixed, agents that use SentinelOne report the failure on the ticket they were working. The rest of Neo keeps running.

​
Disconnecting SentinelOne

1

Open the integration

In the Neo Dashboard, open Integrations and select the SentinelOne card.
2

Disconnect

Click Disconnect and confirm. Neo removes the credentials from Key Vault.
Neo keeps your Organization Mapping, including any mapping you set by hand, so a later reconnect continues from the same state. Agents that use SentinelOne stop working until you connect it again.

​
Security

  • The token is stored in Azure Key Vault, never in plaintext.
  • All traffic to SentinelOne goes over HTTPS, to your own console address only.
  • Write access is opt-in per agent.