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

1. get_alert_notes — check for existing analyst notes before duplicating work
2. get_alert_history — review timeline of status changes and assignments
3. Use purple_ai to investigate the threat described in the alert
4. 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