---

name: "sentinelone-alerts" description: "SentinelOne's read-only unified alert surface: the list/search/get alert tools plus notes and history, severity levels, status values, view types, GraphQL filter syntax, and cursor-based pagination." when_to_use: >- When triaging new alerts, investigating specific alerts, searching by severity or status, reviewing alert timelines, and managing alert workflows across MSP client environments. Use when: sentinelone alert, sentinelone threat, sentinelone detection, sentinelone incident, alert triage, alert investigation, sentinelone severity, sentinelone critical, sentinelone high, alert management, sentinelone notification, or security alert.

SentinelOne Unified Alert Management

All alert tools are read-only — you can view, search, and investigate alerts but cannot modify status, assignments, or take response actions.

For full field definitions, response examples, and error details see REFERENCE.md.

Anti-triggers

• A threat the Huntress SOC found. Both products call their findings alerts or incidents, and both speak of severity, detection, and remediation — the vocabulary overlaps almost completely, the data does not. This skill reads only the SentinelOne console; a Huntress finding appears nowhere in it. Route by which sensor is on the endpoint, not by the word the ticket used — for Huntress use huntress-incidents.
• Acting on an endpoint — isolating a host, killing a process, quarantining a file, or rolling back a remediation. Every SentinelOne tool here is read-only; those actions exist only in the SentinelOne console. On a Huntress-managed endpoint the approve/execute remediation flow is huntress-incidents.
• A CVE finding rather than a detection. Vulnerabilities carry the same severity, status, notes, and history shape as alerts and are easily mistaken for them; use sentinelone-vulnerabilities.
• A cloud or Kubernetes posture finding. Same tool shape again, but the XSPM misconfiguration surface — use sentinelone-misconfigurations.
• A device-health or monitoring condition — RMM and incident platforms call a monitor firing an alert too, and none of them is an EDR detection. Use atera-alerts, superops-alerts, pagerduty-alerts, or rootly-alerts; M365 tenant alerts are cipp-alerts.

MCP Tools

list_alerts — List alerts with filters

Parameters: severity, status, viewType, limit, cursor, sortBy, sortOrder

list_alerts severity=CRITICAL status=NEW sortBy=detectedAt sortOrder=DESC limit=50
list_alerts viewType=CLOUD limit=50

search_alerts — GraphQL filter search

Parameter: filters (array of {fieldId, filterType, values}), limit, cursor

search_alerts filters=[{"fieldId": "endpointName", "filterType": "CONTAINS", "values": ["workstation-01"]}]
search_alerts filters=[{"fieldId": "severity", "filterType": "IN", "values": ["CRITICAL", "HIGH"]}]

Filter types: EQUALS, NOT_EQUALS, CONTAINS, IN, NOT_IN. Add "isNegated": true to invert any filter.

get_alert — Full alert details

get_alert alertId=1234567890

get_alert_notes / get_alert_history

get_alert_notes alertId=1234567890
get_alert_history alertId=1234567890

Key Concepts

Severity: CRITICAL | HIGH | MEDIUM | LOW | INFO | UNKNOWN

Status: NEW | IN_PROGRESS | RESOLVED | FALSE_POSITIVE

View types: ALL (default) | CLOUD | KUBERNETES | IDENTITY | INFRASTRUCTURE_AS_CODE | ADMISSION_CONTROLLER | OFFENSIVE_SECURITY | SECRET_SCANNING

Pagination: Pass limit on the first call, then pass the returned cursor to fetch subsequent pages until no results remain.

Workflows

Triage New Alerts

1. list_alerts with status=NEW, sortBy=severity, sortOrder=DESC, limit=50
2. If results hit the limit, page through with cursor — do not assume 50 covers everything
3. For each CRITICAL/HIGH alert: get_alert for full details, then get_alert_notes for prior context
4. If get_alert returns not-found, the alert may have been merged or resolved — re-query list_alerts to confirm
5. Build triage summary: alert name, severity, client (siteName), endpoint, detection time

Investigate a Specific Alert

1. get_alert with the alertId
   • If not found: verify the ID via list_alerts or search_alerts — alert IDs can change after merge operations
2. get_alert_notes — check for existing analyst notes before duplicating work
3. get_alert_history — review timeline of status changes and assignments
4. Use purple_ai to investigate the threat described in the alert
5. Cross-reference with list_inventory_items for affected asset context

Search Across Clients

1. search_alerts with filters=[{"fieldId": "severity", "filterType": "IN", "values": ["CRITICAL", "HIGH"]}]
2. If results are large, add a time-range filter or narrow by viewType to reduce noise
3. Group by siteName to identify which clients need attention first

Best Practices

1. Triage CRITICAL/HIGH first — always sort by severity descending during triage
2. Check notes before investigating — call get_alert_notes to avoid duplicating prior analyst work
3. Paginate large result sets — never assume a single page contains all matching alerts; always check for a returned cursor
4. Scope by site for client work — use site/account filters or GraphQL siteName filter when investigating a specific client

Related Skills

• Purple AI — Natural language investigation of alert threats
• Threat Hunting — PowerQuery execution for deep analysis
• API Patterns — MCP tools reference and connection info
• Inventory — Asset context for affected endpoints
• Vulnerabilities — Vulnerability context for compromised assets