How security work flows through Thread

Security work is a queue problem before it’s an incident problem: the alert, the report, the “is this phishing?” all land as threads in Inbox alongside everything else. Thread’s job is to make the risky ones surface early, give you a read-only investigator that never changes state until you say so, and let you take contained device actions without leaving the ticket. This lesson walks the path a security thread takes and where your controls sit on it.

Where security signals surface

Every thread carries a live sentiment score, and for security that’s a useful early-warning layer: a user who’s been phished or locked out reads as frustrated fast, and Magic Sentiment scores that from the conversation and rolls it up to a company average. Watch the low-scoring threads — they’re often the ones where something is actually wrong. Sentiment is also an escalation trigger. You can configure a low score to fire an automatic escalation and post a recap using a template your team defines, so a souring security thread routes to the right board or person without a human noticing it first.

Sentiment analysis starts only after the customer has sent at least three messages, and the very first message is excluded — early frustration is normal in IT support. Treat the score as a trend signal on a live conversation, not a verdict on the first line.

Configure both the score behavior and the escalation-plus-recap wiring on Configure Magic Sentiment. Set the escalation template so a security thread that crosses your threshold lands where your responders will see it.

Investigate with Super Magic — read is always safe

Super Magic is your investigator in the ticket. It reads freely — tickets, contacts, clients, and knowledge — and looking things up never changes anything, so you can dig without touching state. Open it while viewing a thread and it already has that ticket’s context.

Show me every open ticket for Acme flagged as a security issue
Who is this sender, and have we seen this domain before across our clients?
Pull the recap and the last 10 messages on this thread for my incident notes
What do we know about this contact — devices, recent tickets, prior incidents?
Search the KB for our BEC verification procedure

The one rule that matters for your review: read never mutates. Search, lookups, and summaries are always available to every member and never change your PSA. That’s why you can hand Super Magic to your whole desk for investigation without loosening any control.

Act only with confirmation

When investigation turns into response, Super Magic switches modes — and this is the safety property to put in front of whoever reviews security at your company:

Every write action shows a Confirm action card first. Before anything changes, you see the exact action, a plain-language description, and every detail (which ticket, which status, which contact). Nothing runs until you click Confirm.
Actions record under the individual member, never a faceless service account. When a responder confirms an escalation or note, the ticket history shows that person did it. Accountability holds end to end.
Access is layered and admin-controlled. Write access is set to All members, Admins only, or a custom list, with a per-tool toggle on every action. Intents and Flows are always admin-only.

You configure all of this from the Super Magic admin guide: setup, access & safety — the write-access model, the per-tool toggles, and the confirmation behavior are the controls to document for an assessor.

For irreversible or sensitive response steps — resetting sessions, disabling accounts, releasing a quarantined message — read the Confirm action card line by line before you click. The card exists precisely so a security action is a deliberate decision, not an autocomplete.

Take device action from the ticket — with NinjaOne

When a security thread needs a machine touched — reboot a compromised endpoint, restart a service, flip maintenance mode, reset an alert — NinjaOne connected to Super Magic lets you do it from the chat instead of pivoting to the RMM. Two properties make this safe to allow:

Device actions are writes, so they’re always behind a Confirm action card. Look-ups (device health, active alerts, recent activity, Windows services) are read-only; reboots, service restarts, maintenance mode, alert resets, and device approvals all confirm first.
Each member acts under their own NinjaOne permissions. NinjaOne connects in two layers — an admin configures the workspace connection once, and every technician signs in with their own NinjaOne account. Super Magic can never do more on a device than that member could do signed into NinjaOne directly, so your existing NinjaOne role assignments keep enforcing.

NinjaOne for Super Magic is a limited release. Contact your Thread account team to enable it, then follow the two-layer setup on Connect NinjaOne to Super Magic.

That’s how security work moves through the desk. Next: the data-handling and permissions story you’ll defend to clients and auditors.

How Thread handles your data

Encryption, Magic AI privacy, sub-processors, IP allowlisting, and app permissions.

​Where security signals surface

​Investigate with Super Magic — read is always safe

​Act only with confirmation

​Take device action from the ticket — with NinjaOne

​Next

How Thread handles your data

Where security signals surface

Investigate with Super Magic — read is always safe

Act only with confirmation

Take device action from the ticket — with NinjaOne

Next