> ## 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.
# SentinelOne API
> Triage SentinelOne threats and alerts, investigate endpoints, and respond with technician sign-off — mitigation, isolation, exclusions and remote scripts always require approval
The SentinelOne API tool gives Neo agents direct access to the SentinelOne Management API (v2.1). An agent can read the threat behind a ticket, check the endpoint and its timeline, record the verdict, and close the threat in the console. With a technician's approval, it can also mitigate the threat or isolate the endpoint.
Automatically enabled when you configure SentinelOne permissions in your agent workflow. No manual toggle needed.
Agents load the SentinelOne API skill first. The skill carries the site scoping rule, the `filter` and `data` body shape, and the endpoint tables for threats, alerts, endpoints and response actions.
## What It Does
* Read the threat behind a SentinelOne ticket: classification, confidence, file, hashes, storyline, and whether it is already mitigated
* Read its timeline, notes and storyline events, and the endpoint's current status
* Set the analyst verdict and incident status, add notes, and write the PSA ticket number on the threat
* Read and update STAR alerts, and read unified alerts through Unified Alert Management
* Find endpoints by name, user, IP or status; run and stop scans; collect logs and files; tag endpoints
* Mitigate threats, isolate or reconnect endpoints, reboot or shut down, with technician approval
* Read and change exclusions and the hash blocklist, with technician approval
* Run Deep Visibility and PowerQuery event searches, and read the console activity log
* Run a library script on named endpoints, with technician approval
## Permission Groups
| Permission Group | What It Covers |
| -------------------------------- | ---------------------------------------------------------------------------------------------------- |
| **Threats & Alerts** | Threats, STAR alerts and unified alerts: verdicts, incident status, notes, ticket number, mitigation |
| **Endpoints** | Agents, installed applications and vulnerabilities, scans, log and file collection, endpoint actions |
| **Exclusions & Blocklist** | Exclusions, the hash blocklist, threat-intelligence IOCs |
| **Deep Visibility & Activities** | Event searches, the activity log, hash verdicts: **read-only** |
| **Remote Scripts** | The script library, script runs and results |
| **Accounts, Sites & Groups** | The client hierarchy every other call scopes to |
| **Users & Roles** | Console users, service users and roles: **read-only** |
Each group has an access level: **Disabled**, **Read Only**, or **Read/Write**.
## Access Profiles
All groups Read Only. The agent investigates any threat or endpoint and reports, but never changes anything.
Threats & Alerts and Endpoints at Read/Write, everything else Read Only. The agent can close threats, scan endpoints and collect logs. Mitigation and isolation still require technician approval.
Every writable group at Read/Write, with technician approval on every write.
Routine triage writes, scans, log and file collection and tags run autonomously. Mitigation, network isolation, reboot, shutdown, uninstall, exclusions, remote scripts and site changes still always require technician approval.
## Safety Controls
| Control | Behavior |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Technician-in-the-Loop** | Require human approval for writes, configurable per group |
| **Response actions** | Mitigation (kill, quarantine, remediate, rollback), adding a threat to the blocklist or exclusions, network isolation and reconnection, reboot, shutdown, broadcast, uninstall, decommission, disabling or moving an agent, and agent software updates always require technician approval |
| **Exclusions and scripts** | Every exclusion, blocklist or IOC change and every remote script run always requires technician approval |
| **Unified alert changes** | Every Unified Alert Management GraphQL mutation always requires technician approval |
| **Named targets only** | A threat, alert or endpoint action must list the ids it acts on; an empty filter, which SentinelOne applies to everything in scope, is refused |
| **Write allowlist** | Every write must match Neo's explicit list of supported SentinelOne writes, and any other is refused. Policy changes, site deletion, user and token management, remote shell and other console administration are not on the list |
| **Secrets** | Registration tokens, agent passphrases and the uninstall password are never read, and registration tokens are removed from site and group records |
Network isolation is asynchronous. After the call, the endpoint shows `disconnecting` and then `disconnected`. The agent is instructed to report an endpoint as isolated only after SentinelOne confirms it.
## How to Configure
Save your console URL and a service-user API token in the Neo Dashboard under the **Security** integrations category. See [Connecting SentinelOne to Neo](/integrations/sentinelone/connecting-to-neo).
The service user's role limits what any agent can do: each API operation needs its own permission. Other MSP tools ask for **Viewer** to read, and for **SOC** or **IR Team** to set verdicts and respond to threats.
In your agent workflow's **Integrations** tab, choose an access profile or customize each permission group.
Response actions always require technician approval. Decide whether verdicts, status changes and scans should require approval too.
Start with **Read Only** or **Helpdesk**. Both give the agent the threat context for a ticket without any response action.