Prove SentinelOne is working — first tool + proof field

1. Why “is the agent working?” is five questions

Operators collapse five failures into one sentence. The agent never checked in. The host is decommissioned or already disconnected. The Group policy is Detect, so the agent alerted and did not kill. The Storyline still has a Run key after mitigation = Kill. Remote Shell cannot start because Last Reported is fourteen hours ago. Those are five first clicks.

This page is the night-shift desk for proof. The factory taught Storyline, Kill vs Remediate, and Disconnect from Network. Here you learn the five console surfaces you actually open, in order, when someone asks you to prove SentinelOne is working — or to explain why it did not block.

Hero · five tiles, one ticket

2. Mental model — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you Disconnect a DC at 02:00 or flip the whole Site to Detect.

3. Decision flow — ticket → first tool

Flowchart first. Do not open Policy or start Remote Shell until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to the Singularity console. If you cannot recite the proof field, you are not ready to Disconnect or change Detect to Protect.

5. Runbook Side A → B → C

Side A proves the agent is on the wire. Side B proves what Singularity saw and whether policy was allowed to mitigate. Side C proves live response. On a messy Sev-2, do them in this order until a field lights up.

Side A — Sentinels (agent health)

1. Open Sentinels, not Incidents

   Path: Sentinels. Search hostname. If two rows appear, sort by Last Reported and work the live one — the stale row is often a leftover or a pending-decommission record. Source: SentinelOne FAQ (Management console manages agents); Customer Portal knowledge base for Sentinels filters including Decommissioned.

2. Read the four agent columns that close “is the agent working?”

   Last Reported — most recent console check-in (UTC). Agent Version. Network Status — Connected or Disconnected (after Disconnect from Network). Decommissioned filter — offline agents drop out of the default view (commonly after 21 days unless your Site changed the aging). Source: Sentinels inventory columns; FAQ on remote agent management.

3. If Last Reported is hours, stop. This is an agent ticket

   Do not start Remote Shell. Do not Fetch File and call it collected. Do not call it a miss. Check connectivity to the management console, install token / Site, pending uninstall, and whether you opened a decommissioned row. Then come back.

4. If Network Status is already Disconnected, say that out loud

   Disconnect from Network cuts inbound and outbound except the management console. That is containment, not “agent down.” Quote Network Status before anyone “fixes S1” by reconnecting a live malicious host.

Side B — Threat Center, Storyline, Policy Detect vs Protect

1. Open the threat, not Slack’s filename

   Path: Incidents → the threat (older chrome: Threats). You land in Threat Center. Official status bar: Threat Status (mitigated by policy or not), AI Confidence Level (Suspicious or Malicious), Analyst Verdict and Incident Status. Source: Feature Spotlight — Introducing the New Threat Center.

2. Read Threat Status, AI Confidence, Analyst Verdict

   Those three close “what did the agent think this was, and what did a human mark?” A Malicious / Undefined / Not mitigated threat is not a hash debate. Set Analyst Verdict (True Positive, False Positive, Suspicious). Do not leave it Undefined while you argue update.exe.

3. Open Explore (Storyline) before you type Remote Shell

   Threat Center → Explore. Official: the entire attack Storyline — processes, files, registry, network, DNS — in Process Tree or the table. Quote Storyline ID and persistence. Explore is historical telemetry. Remote Shell is live. Do not skip the plot to go collect a file the tree already named.

4. If the ticket is “why didn’t it block?”, open the assigned Group policy

   Path: endpoint card → Policy, or Policy on that Group. Read Detect vs Protect for the engine that convicted (Static AI / Behavioral AI). Official: the choice between Detect or Protect is governed by policies the customer controls; Protect takes the mitigation actions defined in the policy. Detect means the product did what that Group is configured to do. Promote to Protect under change control — do not call it a miss and do not flip the Site.

Path:            Incidents → threat → Threat Center
Quote:           Threat Status + AI Confidence Level + Analyst Verdict
Then:            Explore  (Storyline ID · process tree · persistence)
If “no block”:   Sentinels → endpoint → assigned Policy
Quote:           policy name + Detect vs Protect for that engine
If empty queue:  Sentinels Last Reported / decommissioned first

Side C — Remote Shell / Fetch File + Disconnect from Network

1. Contain a live malicious workstation before you collect souvenirs

   Official action: Disconnect from Network (network isolation). The host keeps a path to the management console. That is the right 01:40 move on a finance laptop with a live Malicious Storyline. It is the wrong reflex on a DC / DNS / DHCP — those wait for change-control. Source: SentinelOne FAQ (network isolation); Singularity Complete (block incoming and outgoing network activity).

2. Fetch File or start Remote Shell only after Last Reported is seconds

   Threat Center can fetch the threat file from the same view. Endpoint Actions → Remote Shell opens PowerShell on Windows and Bash on macOS and Linux, securely from the Management Console. A dark Last Reported does not give you a shell tonight — that is not evidence.

3. Use the documented action that answers the ticket

   Fetch the file the Storyline already named. Use Remote Shell to confirm the process or persistence the Explore tab showed. Quote the action and the output. Remote Shell is change-control — you need the role and, in most shops, a change number before you delete or run unconstrained commands.

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

S1-ED-01 — Prove the agent (Sentinels)

01:42 · P2. Priya on a hotel network. Phone photo of a SentinelOne tray icon. L1 already drafted “S1 missed the malware.” Incidents for her hostname are empty.

First tool: Sentinels. Search ENDPOINT-LAB-41.

If Last Reported is hours / the only row is decommissioned: quote that pair. Empty Incidents is expected. Next check is the agent — console connectivity, install token, Site, leftover row — not a new STAR rule.

If Last Reported is seconds and Network Status is Connected: the agent is talking. Now you are allowed to open Incidents for that endpoint and UTC window. A tray icon is not Last Reported.

S1-ED-02 — Prove why it did not block (Policy Detect vs Protect)

02:05 · P2. A threat fired. The process is still running. Someone typed “S1 failed” in the channel and wants Protect off for Finance so they can work.

First tool: endpoint card → assigned Policy, or Policy on Group FIN-WS. Confirm the Group that assigned it.

Proof field: policy name (lab: FIN-WS-Detect) and Behavioral AI / Static AI set to Detect. That is the ticket. The agent did what that Group is configured to do. Set Analyst Verdict. Disconnect if the Storyline is real. Promote the engine to Protect under change control. Do not flip the Site to Detect.

S1-ED-03 — Prove the conviction and the plot (Threat Center + Storyline)

02:20 · P1. THR-1042. User still in Outlook. L1 wants to close because mitigation = Kill.

First tool: Incidents → THR-1042 → Threat Center, then Explore.

Proof field: Threat Status = Mitigated (Kill), AI Confidence Level = Malicious, Analyst Verdict still Undefined; Explore shows Storyline SL-88 with a Run key under finance.user. Last Reported 16s, Network Status = Connected. Kill stopped a process. It did not finish the plot. Disconnect this workstation. Remediate the Storyline. Set the verdict. Filename later.

S1-ED-04 — Prove the live host (Fetch File / Remote Shell)

02:40 · P2. IR wants the sample on disk. Someone already opened Remote Shell against the 12-day row.

First tool: Sentinels Last Reported on the row you will session, then Threat Center Fetch File or Actions → Remote Shell.

Proof field: fetch complete for the path on Explore, or a PowerShell/Bash session showing the Run key / process the Storyline already named. If Last Reported is hours, you will not collect — that is not evidence in the ticket tonight.

S1-ED-05 — Prove the block was policy (Protect mode)

03:00 · P3. Red team says SentinelOne broke the demo. Group policy on that host is Protect. L1 wants Detect for the Site until Monday.

First tool: Policy for the demo Group.

Proof field: policy name + Protect mode that matched the demo tool. A blocked demo can be policy success. Scope a time-boxed exclusion or move that one host to a Detect Group with an owner and an end time. Keep Protect on for everyone else.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• SentinelOne Customer Portal / Knowledge Base (official console paths: Sentinels, Incidents / Threat Center, Policy, Remote Shell, Fetch File, Decommissioned filter — confirm labels on your generation)
• SentinelOne FAQ (Management console manages agents; kill, quarantine, remediate, rollback, network isolation; Remote Shell — PowerShell on Windows, Bash on macOS and Linux; AI Confidence Level on incidents)
• SentinelOne — Feature Spotlight: Introducing the New Threat Center (Threat Status, AI Confidence Level, Analyst Verdict, Incident Status; Overview / Explore / Timeline; Fetch File; Remote Shell; endpoint online / quarantined snapshot)
• SentinelOne — Singularity Complete (Storyline context; automated and manual remediation including 1-click rollback; block incoming and outgoing network; Full Remote Shell)
• SentinelOne — Singularity Endpoint
• SentinelOne — ActiveEDR feature spotlight (on-agent correlation that becomes the Storyline)
• SentinelOne — Deep Visibility (hunt from Threat Center network history / Storyline ID)
• SentinelOne — Detect or Protect is governed by customer-controlled policies (Protect takes the mitigation actions defined in the policy)
• SentinelOne — Storyline Active Response (STAR)
• SentinelOne — Threat hunting + auto-mitigate / network quarantine
• SentinelOne — What is EDR? + Storyline correlation
• SentinelOne Status (platform-wide console health — not a substitute for one host’s Last Reported)

Related: Blog 1 · Storyline is the S1 word — kill is not remediate · SentinelOne dashboard · Dummy lab · Storyline, Ranger & Rollback