Introduction
This article covers initial setup of the SentinelOne Singularity Operations Center console, including switching to the latest console version, managing users, configuring policy, and installing agents.
Splashtop x SentinelOne Integration info can be found here: SentinelOne Integration
For Splashtop customers, the console URL is below:
https://usea1-splashtop.sentinelone.net/
An active SentinelOne account is required to access the console and the documentation referenced in this article. Replace the base domain above if using SentinelOne purchased from another provider.
Confirm the SentinelOne console being used is the Singularity Operations Center. Integrations and future updates are built for this version.
- If "Incidents" appears in the left navigation menu, the account is on the legacy console. Another indicator: hovering over the browser window/tab name shows "SentinelOne - Management Console" instead of "Singularity Operations Center."
- To switch: click the account name in the top-right corner → My User, then toggle on "Singularity Operations Center."
SentinelOne's scope hierarchy determines where policies, products, and features can be applied, and who can access what.
- Global - Sits above the Account level and is managed by Splashtop.
- Account - Every Splashtop customer is provisioned at the Account level. Accounts inherit policy from Splashtop's default unless that inheritance is broken.
- Site - Accounts can create multiple Sites. Different products, features, and policies can be set per Site, making this useful for separating clients (common for MSPs) or departments/branches (common for IT teams). If there's no need to separate feature or license allocations, a single Site is sufficient. Sites inherit policy from the Account unless that inheritance is broken.
- Group - Sites can contain Groups, which allow for further organization within a Site (e.g., by department, device type, or location). Groups can have their own policy, but cannot have separate license or feature allocations - those are set at the Site level. Groups inherit policy from the Site unless that inheritance is broken.
Example: An MSP might create a separate Site for each client, while an internal IT team might use a single Site with Groups for each department.
Note on license allocation: A license/seat count set per Account or Site is informational rather than a hard limit - it's meant to help track and plan usage. It's still possible to install the agent on more endpoints than the allocation reflects, since SentinelOne does not block installs once that number is reached. Installing beyond the allocated count may result in overage charges, so it's worth monitoring usage against the assigned allocation.
Go to Policies & Settings → User Management → Console Users to add additional users.
Assign a scope for each user:
| Scope | Access |
|---|---|
| Account level | All sites under the account |
| Site level | Only the specific site(s) assigned |
Assign a role. Built-in roles are provided by SentinelOne, and custom roles can also be created under the Role tab.
| Role | Permissions | Notes |
|---|---|---|
| Viewer | View console features and activity | Cannot run actions |
| C-Level | Create, edit, delete, and run reports | Cannot run other actions |
| IT | Edit exclusions and blocklist items; configure Notifications, Device Control, Firewall rules | |
| SOC | Mitigate/remediate threats, isolate endpoints | |
| IR Team | Investigate breaches and IoCs via Event Search; create incident response and root cause reports | |
| Admin | Full access to all console features within the assigned scope | Recommended for the primary console owner |
Related documentation:
By default, the account inherits a recommended baseline Global policy managed by Splashtop. This can be overridden at the account level or per site - sites inherit the account-level policy unless that inheritance is broken.
Path: Policies & Settings → Endpoint Security and Cloud Workload Security → Policy
Before making changes, review SentinelOne's Default & Recommended Policy Settings article - it covers the baseline configuration recommended for most environments and is a good starting point before adjusting any of the settings below.
Protection Modes
- Suspicious - lower confidence; more prone to false positives
- Malicious - high confidence true positive
Response Actions
- Detect - generates an alert only (some automatic protections still apply, such as protecting snapshots, blocking memory scraping, and enforcing anti-tampering)
- Protect, which includes:
- Kill/Quarantine - stops the process and quarantines it for investigation
- Remediate - removes altered artifacts/files (e.g., registry keys)
- Rollback - restores files modified by malware to the last snapshot (Windows only)
Defaults:
- Suspicious detections default to Detect mode, requiring manual review to confirm true/false positive before closing. This can be switched to a Protect action, though doing so risks acting on false positives.
- Malicious detections default to Kill/Quarantine. This can be tightened to Remediate, but remediation actions are difficult to reverse once applied.
Detection Engines
Default settings are recommended in most cases unless performance or bandwidth issues arise. Hover over each engine in the console for a full description.
Pre-execution:
- Reputation - checks files against SentinelOne's cloud threat intelligence (known malware by hash); cannot be disabled
- Static AI - analyzes file content directly and assigns a maliciousness score
- (Suspicious-level pre-execution detection can be disabled if it generates excessive false positives)
Post-execution:
- Behavioral AI - monitors the full "storyline" of a process
- Docs & Scripts - detects malicious documents and scripts
- Lateral Movement - flags device-to-device network movement
- Anti-Exploit - detects malicious web activity and fileless malware/memory injection
- PUA (Potentially Unwanted Applications) - flags apps that likely don't belong on a business network
- App Control / Drift Detection - flags apps not part of the original container image
- Detect Interactive Threats - monitors for malicious CLI use by authorized users (can generate false positives)
On-write/on-execute behavior can also be adjusted via the gear icon - useful for lower-powered hardware like thin clients. Toggling these settings may require a reboot.
Agent Security Settings
- Snapshot (Windows only) - required for the Rollback function
- Anti-Tamper - prevents the agent from being uninstalled, deleted, or disabled
- Scan New Agents - runs a full disk scan after install (optional, since the AI engines monitor continuously regardless)
- Logging - collects data for troubleshooting; can be disabled for specific groups to save space
- Drive Blocking (Windows only) - prevents suspicious/malicious drivers from loading
Event Collection
Controls what data is sent from endpoints to the SentinelOne cloud. For organizations with compliance requirements (GDPR, HIPAA, etc.), these settings should be reviewed carefully. Otherwise, keeping logging enabled is recommended - reducing data collection also reduces visibility for troubleshooting and threat hunting.
- Data Masking - anonymizes details like file names, though this can limit hunting capability
- Focused File Monitoring - reduces bandwidth usage, though this can also limit visibility
Remote Shell
Enables remote command execution on an endpoint - useful during incident response.
Decommissioning
Taking an agent offline and marking it "decommissioned" frees up its license. If the machine comes back online later, it will consume a license again.
Related documentation:
Path: Policies & Settings → Endpoint Security and Cloud Workload Security → [Blocklist / Exclusions]
Blocklist - A list of blocked file hashes, applied in addition to the Reputation engine. Entries come from three sources: manually added, added from SentinelOne's cloud, and added automatically from threat alerts. Blocklist entries apply cumulatively across whatever scope they're set at.
Exclusions - Exclusions should be applied at the smallest scope possible - for example, to a specific group of endpoints rather than an entire site or account - to avoid unnecessarily widening the attack surface.
Related documentation:
Installation From Splashtop
Sentinel Agent installation can be streamlined directly from the Splashtop console integration. Install the agent on-demand, or assign an endpoint policy to install and enforce installation automatically.
See the SentinelOne Integration article for steps on installing from Splashtop.
Installation Outside of Splashtop
- In the SentinelOne console, go to Agent Management → Packages and download the installer for the target OS.
- A site or group token is required to complete installation. Find that in the Site/Group's Scope Information:
-
Manual Installation (Windows & macOS)
- Run the installer package on the computer.
- Enter the Scope Token copied from step 2 to finish the installation.
- For macOS: Authorize Full Disk Access and Network Extension permissions for the SentinelOne Agent in the System Preferences.
-
Silent Installation (Windows & macOS)
-
For Windows, run the below command in CMD or a 3rd party deployment tool:
SentinelOneInstaller.exe [-a installer_arguments] -t {token}Installer arguments are optional and can be found in SentinelOne documentation linked below.
-
For macOS, save the Site Token or Group Token in a plain text file in a folder named /tmp with the Installer package. Name the Token file:
com.sentinelone.registration-token. Change the ownership of the file to root withsudo chown root. Run this command:$ sudo /usr/sbin/installer -pkg {Path}/tmp/SentinelXXXX.pkg -target /Authorize Full Disk Access and Network Extension permissions in System Preferences.
The scope token and macOS permissions can be further automated if you have an MDM.
-
- After installation, confirm the agent appears under Agent Management or Inventory. Agent Management is used for managing agents and taking action on them. Inventory provides a broader asset-management view across all endpoints.
Related documentation:
- SentinelOne - Installing Agents (includes silent install parameters and additional install options)
- SentinelOne - Installing on macOS with JAMF
Each alert reflects a detection at either the Suspicious or Malicious confidence level, along with the response action taken (or pending, if in Detect mode). Reviewing an alert typically involves checking:
- What triggered the detection (which engine)
- The process storyline/timeline
- Whether the associated action (Detect/Kill/Quarantine/Remediate/Rollback) was applied or requires manual triage
Related documentation:
Additional SentinelOne Resources
Beyond this article, SentinelOne provides additional resources for deeper learning and reference.
Knowledgebase Documentation
From within the Singularity Operations Center console, click Help → Documentation in the top-right corner to access SentinelOne's full knowledgebase.
SentinelOne University
Splashtop customers are eligible for free access to SentinelOne University, which offers official training and onboarding courses, including certifications. To request access, contact the Splashtop Support team.