EDR Platform Configuration Guide: Securing SentinelOne Singularity Roles, Tokens and Policies

A SentinelOne Singularity console can isolate, remediate and run shell sessions on every protected endpoint, so the settings that decide who and what can use it matter as much as the agent policy. Most of the work sits in four places: the scope hierarchy and the roles granted at each level, the service users and API tokens that feed SIEM, SOAR, deployment and AI tooling, the agent policy (Detect or Protect, anti-tamper, exclusions), and the activity data you send out for monitoring. This guide covers those settings from the customer side, for endpoint engineers, SOC leads and identity teams who run or audit a Singularity tenant. It assumes the agent is already deployed and focuses on configuration and governance rather than detection content.

This is an independent guide from NHI Mgmt Group, based on SentinelOne's public documentation as of November 2026. It is not sponsored or reviewed by SentinelOne. Product features change, so confirm settings against SentinelOne's current documentation.

Key takeaways

• Scope is part of every permission. A role means nothing until it is attached at a Global, Account, Site or Group scope, so access reviews must read role and scope together.
• Service users are non-human identities with expiry dates. Each integration should have its own service user, its own custom role and the narrowest scope that works; the API token is shown once and must go straight into a secrets store.
• Protect mode and anti-tamper are the baseline. Run Protect with anti-tamper on, keep the Suspicious threshold under review, and turn on Snapshot where you want Rollback on Windows.
• Exclusions are the quietest way to blind the agent. Use the Suppress Alerts mode by default, the smallest scope possible, and an owner and review date for every entry; reserve Interoperability and Performance Focus for proven conflicts.
• Console activity belongs in your SIEM. Forward activity and threat events (for example as CEF over syslog or through an API connector) and alert on role, token, policy and exclusion changes.

How identity and access work in SentinelOne Singularity

Singularity has three identity planes, and each needs its own review. Mixing them up is the usual reason a token with account-wide rights survives an access review that only looked at console users.

The scope hierarchy

Partner and MSP documentation describes four levels. Policies, exclusions, roles and tokens are all set at one of them.

• Global: above every account. In an MSP model the provider holds this level; in a direct deployment only the smallest possible group of administrators should.
• Account: the customer tenant. Most integrations should live here or lower.
• Site: separates products, features and policies, for example by business unit, region or client.
• Group: organises endpoints within a Site, for example by department, server tier or location. Pilot rings and server policies are usually Groups.

Two practical consequences follow. First, an agent's Site or Group token decides where a new endpoint lands and therefore which policy it gets on day one, so treat those tokens as deployment secrets. Second, a role granted at Account scope reaches every Site and Group beneath it; grant at Site or Group scope wherever the job allows.

Single sign-on

SSO is configured under Settings, Integrations, Types, SSO with the Enable SSO toggle. The SentinelOne side takes the identity provider's issuer ID, redirect URL and public certificate, and gives you the Assertion Consumer Service URL and SP Entity ID to register at the identity provider. Two settings deserve attention:

• Default role: the role given to users who arrive through SSO without a mapping. Set it to Viewer, not to an operational role.
• Auto Provisioning: creates console users on first sign-in. If you enable it, map roles from identity provider groups (identity provider guides describe a role attribute for built-in roles and a role_id attribute for custom roles) so access follows group membership and leaver processes.

Enforce phishing-resistant MFA at the identity provider for every console user, and keep any remaining local accounts to a documented break-glass set. See the SAML Security Guide.

Admin roles and privileged access

SentinelOne ships six predefined roles that cannot be edited or deleted: Viewer, C-Level, IT, SOC, IR Team and Admin. Custom roles are created under Settings, Users, Roles, Actions, New Role after selecting a scope, by choosing individual permissions. Existing roles can be duplicated and adjusted, and deleting a role forces you to pick a replacement role for its users (Reassign and Delete), which is a useful prompt to check who held it.

• Separate duties: keep the ability to change roles and create service users apart from day-to-day analyst roles. One partner integration guide asks for Service Users Create inside an integration role: question any such request and create the service user yourself instead.
• Prefer Site and Group scope: grant Account scope only to people who administer the whole tenant, and Global scope to as few accounts as possible.
• Review on a schedule: export users, service users and their roles quarterly; look for built-in Admin assignments, roles with Remote Shell or uninstall rights, and users who have not signed in.

The wider pattern of protecting a security tool's own control plane is covered in Securing the EDR and XDR platform itself. See also the Privileged Access Management Guide.

Integrations, API tokens and service users

Service users are created under the console's user management area (labelled Settings, Users, Service Users or Policies and Settings, User Management, Service Users depending on console version). The creation flow asks for a name, description and Expiration Date, then a Select Scope of Access step with an Access Level and a role, and finally shows the API token once with a Copy API Token button. If the token is lost, you generate a new one and update the integration.

• One integration, one service user: never share a token between tools. Name the service user after the integration and owner so activity logs are readable.
• Short but workable expiry: partner docs note the trade-off: shorter expirations are more secure but mean regenerating tokens more often. Set an expiry that matches a rotation process you will actually run, and alert well before it lapses.
• Store tokens as secrets: put the token in a vault or CI secret store, never in playbooks, inventory files or scripts. SentinelOne's own detection-as-code reference notes that anyone who can read the token or push to the main branch can change what runs in the console, so protect the repository as well as the token.
• AI and MCP access: the Purple AI MCP server reads alerts, PowerQuery event data, inventory, vulnerabilities and misconfigurations with a console token. It has no built-in authentication of its own, so network-exposed deployments need a reverse proxy or load balancer in front, and SentinelOne advises pinning to a specific commit for production use. See the MCP Security Guide.
• Deployment secrets: Site and Group tokens used by installers, and agent passphrases retrieved by tooling, are credentials too. Keep them out of shared images and logs.

For the general discipline see the API Key Management Guide and the Service Account Security Guide.

Logging and detection

The console records administrative activity (logins, role and user changes, policy and exclusion edits, response actions such as threat resolution or fetching files from an agent) alongside threat events. Send both to the SIEM so that console changes can be correlated with endpoint and identity data. SIEM vendor documentation shows SentinelOne events arriving as CEF over syslog (messages beginning CEF:0|SentinelOne|), and many SIEM and SOAR products pull the same data through the management API with a read-only service user.

Retain console activity for at least as long as your incident investigation window. See the EDR Telemetry Guide for using the endpoint data itself.

Hardening baseline

Agent policy

• Policy mode: Detect only alerts (some automatic protections still apply); Protect enables mitigation. Partner documentation describes the common default of Malicious detections set to Kill and Quarantine while Suspicious detections stay in Detect for manual review. Move the fleet to Protect once a pilot shows acceptable false positive rates, and decide deliberately whether Suspicious should also mitigate on high-value servers.
• Mitigation actions: Kill and Quarantine stops and isolates the process; Remediate removes changed artefacts such as registry keys and is hard to reverse; Rollback restores files to the last snapshot on Windows and needs Snapshot enabled.
• Anti-Tamper: keep it on everywhere. It stops the agent being uninstalled, deleted or disabled locally.
• Snapshot and driver blocking: turn on Snapshot on Windows where Rollback is part of your ransomware response, and use the driver blocking option to stop suspicious or malicious drivers loading. See Bring Your Own Vulnerable Driver and EDR Killers Guide.
• Blocklist: hash blocklist entries add to the reputation engine; keep them scoped and documented like exclusions.

Exclusions

From management version S-24.2.1, partner documentation notes that broad Windows system variables such as %SystemRoot% are flagged as Not Recommended. For a false positive or interoperability problem, a support case is safer than a broad exclusion. The process side is covered in the EDR Tuning and Exclusions Management Guide.

Upgrades and lifecycle

• Ring the upgrades: upgrade a pilot Group first, then wider Groups, rather than the whole Account at once.
• Use signed packages: on RPM-based Linux, GPG-signed packages can be requested and verified (the Ansible collection imports the SentinelOne GPG key).
• Track platform support: the SentinelOne Ansible collection notes that Agent 26.2 dropped Windows 8.1, Server 2012 R2 and early Windows 10 builds, pinning those hosts to 26.1.2.177. Plan replacements for hosts on a version ceiling.
• Decommission cleanly: decommissioning frees a licence; agents that come back online consume one again, so investigate unexpected returns.
• Apply updates: apply vendor security updates promptly and follow SentinelOne's security advisories.

How to implement

1. Map the scope tree: document Accounts, Sites and Groups, which policy each uses and which Site or Group tokens are in installers.
2. Fix console identity: enable SSO with a Viewer default role, map roles from identity provider groups, and reduce local accounts to break-glass.
3. Rebuild roles: create custom roles for analysts, IR, endpoint engineering and auditors; move people off the built-in Admin role where a narrower role fits.
4. Re-issue integration tokens: one service user per integration with a custom role, minimum scope and an expiry; move tokens into a vault; delete the old shared users.
5. Pilot Protect mode: apply Protect, anti-tamper and Snapshot to a pilot Group for two to four weeks, measure false positives, then widen by Group. Roll back by moving the Group back to its previous policy, not by disabling the agent.
6. Clean up exclusions: export every exclusion, assign owners, remove broad entries and convert to Suppress Alerts where possible.
7. Turn on monitoring: forward activity and threat events to the SIEM and build the alerts in the table above.
8. Review quarterly: users, service users, token expiry, exclusions and policy drift.

Detection and measurement

• Protect coverage: percentage of active agents in Protect mode with anti-tamper on (target close to 100 percent outside documented exceptions).
• Privileged console identities: number of users and service users holding Admin, Remote Shell or uninstall rights, trending down.
• Token hygiene: percentage of service users with a named owner, a custom role and an expiry within your rotation policy.
• Exclusion health: count of exclusions without an owner or review date, and count of exclusions at Account or Global scope.
• Silent agents: agents not reporting for longer than your threshold, and time to resolve.
• Change alerting: percentage of role, policy and exclusion changes that matched an approved change.

Framework mapping

Common misconfigurations

• Shared integration tokens: one service user feeding several tools, with a role far broader than any of them needs and no expiry tracking.
• Account or Global scope by default: roles and service users granted at Account scope when a Site or Group would do.
• SSO default role set too high: new SSO users arriving as SOC or Admin because the default role was never changed from a test value.
• Policies left in Detect after rollout: pilot Groups that never moved to Protect, or servers excluded "temporarily" years ago.
• Broad exclusions: folder wildcards, whole-publisher signer exclusions or Interoperability mode used to fix a single application.
• Tokens and passphrases in automation code: API tokens or agent passphrases committed to playbooks or written to job logs.

Practitioner checklist

• Scope tree documented, with the policy and token for every Site and Group.
• SSO enabled, default role Viewer, roles mapped from identity provider groups, MFA enforced.
• Built-in Admin limited to a small named group; custom roles for other functions.
• Remote Shell, passphrase and uninstall rights in separate, reviewed roles.
• One service user per integration, custom role, minimum scope, expiry and owner recorded.
• All API tokens and Site or Group tokens stored in a secrets manager.
• Protect mode, anti-tamper and (on Windows) Snapshot on across production Groups.
• Exclusions use Suppress Alerts, smallest scope, owner and review date.
• Activity and threat events forwarded to the SIEM with alerts on role, token, policy and exclusion changes.
• Quarterly review of users, service users, exclusions and agent version support.

Standards and references

• SentinelOne: Feature Spotlight, Fully Custom Role-Based Access Control
• SentinelOne: Ansible Collection s1agents (required permissions and agent lifecycle)
• SentinelOne: Detection as Code reference implementation
• SentinelOne: Purple AI MCP Server
• Cisco Duo: SentinelOne Single Sign-On
• Palo Alto Networks: Set Up SentinelOne Singularity Endpoint for Integration
• Guardz: SentinelOne Exclusions
• Splashtop: SentinelOne Console Quickstart Guide

Related NHI Mgmt Group resources: EDR Guide, Securing the EDR and XDR platform itself, EDR and XDR platform health check, Service Account Security Guide.