> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Connecting SentinelOne to Neo

> Create a SentinelOne service user, save its token in Neo, and decide what each agent can do

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.

<Steps>
  <Step title="Open Service Users">
    In the SentinelOne management console, go to **Settings > Users > Service Users** and create a new service user.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Warning>
  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.
</Warning>

## 2. Add the token in Neo

<Steps>
  <Step title="Open Integrations">
    In the Neo Dashboard, open **Integrations** and find the SentinelOne card, under Security.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  Neo accepts SentinelOne cloud consoles (`*.sentinelone.net`) and US government consoles (`*.s1gov.net`). On-premises consoles are not supported.
</Note>

## 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

<CardGroup cols={2}>
  <Card title="Read Only" icon="magnifying-glass">
    Every area read only. The agent investigates threats and endpoints and reports, but never changes anything.
  </Card>

  <Card title="Helpdesk" icon="headset">
    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.
  </Card>

  <Card title="IT Admin" icon="user-gear">
    Every writable area read and write, with technician approval on every write.
  </Card>

  <Card title="Full Automation" icon="bolt">
    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.
  </Card>
</CardGroup>

### Or set each area by hand

| Area                             | Access levels you can pick          | Notes                                                                                                                                                                                         |
| -------------------------------- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Threats & Alerts**             | Disabled, Read Only, Read and Write | Verdict, incident status, notes and the ticket number follow your approval setting. Mitigation, blocklist and exclusion from a threat, and unified-alert changes always wait on a technician. |
| **Endpoints**                    | Disabled, Read Only, Read and Write | Scans, log and file collection and tags follow your approval setting. Isolation, reboot, shutdown, uninstall, disabling the agent and moving it always wait on a technician.                  |
| **Exclusions & Blocklist**       | Disabled, Read Only, Read and Write | Every change waits on a technician.                                                                                                                                                           |
| **Deep Visibility & Activities** | Disabled, Read Only                 | Event searches, the activity log and hash verdicts.                                                                                                                                           |
| **Remote Scripts**               | Disabled, Read Only, Read and Write | Every script run waits on a technician.                                                                                                                                                       |
| **Accounts, Sites & Groups**     | Disabled, Read Only, Read and Write | Creating and renaming groups follows your approval setting. Creating or changing a site and moving endpoints between groups wait on a technician.                                             |
| **Users & Roles**                | Disabled, Read Only                 | Who has console access, with which role.                                                                                                                                                      |

## 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

| What comes back                                            | Cause                                                         | Fix                                                                                        |
| ---------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| `401`                                                      | The token expired or was revoked                              | Generate a new token for the service user in SentinelOne and save it in Neo.               |
| `403`                                                      | The service user's role or scope does not allow the operation | Give the service user a role with the permission that operation needs, or widen its scope. |
| A failed **SentinelOne Company Mapping** row with HTTP 401 | The token expired or was revoked                              | Save a new token. The mapping rebuilds on the next PSA sync.                               |
| A failed **SentinelOne Company Mapping** row with HTTP 403 | The role cannot view sites                                    | Give the service user a role with site view access.                                        |
| `429`                                                      | Too many requests                                             | Wait, then try again. If it repeats, check what else uses the same token.                  |

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

<Steps>
  <Step title="Open the integration">
    In the Neo Dashboard, open **Integrations** and select the SentinelOne card.
  </Step>

  <Step title="Disconnect">
    Click **Disconnect** and confirm. Neo removes the credentials from Key Vault.
  </Step>
</Steps>

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.
