How to build endpoint alert containment

What matters here

• Write the rule down: which detections isolate on their own, and which devices always wait for a person.
• Attach the device and the user before deciding. Who owns it and what it runs changes the answer.
• Contain the account too. A cut-off laptop with a working session elsewhere has only moved the problem.
• Tell the user straight away, on a channel that still works. An isolated laptop with no explanation becomes a service desk call.
• Release on purpose, with a check. A device let back on the network without one is a second incident waiting.

Who this is for

You run security operations. Your endpoint tool raises serious detections at all hours, and the team has argued for a year about which ones should isolate on their own.

How it works in practice

From a serious detection on a device to that device being back in use.

1. 1

   A serious detection arrives from the endpoint tool

   Through its connector or its API, with the device, the process and the detection detail.

2. 2

   The device and the user are attached

   Owner, role, whether they are on call, what the device runs, its compliance state in Intune, and recent sign-ins.

3. 3

   The rule decides, or a person does

   Clear detections on ordinary laptops isolate straight away. Servers, executives and on-call engineers go to an approver.

4. 4

   The device is isolated and the account contained

   Network isolation through the endpoint tool, and the user's sessions revoked if the detection points at credentials.

5. 5

   The user is told, and a case is opened

   What happened, what to do next, and how to get a loan device, on their phone or a manager's message.

6. 6

   Release is a decision with a check

   The device is cleaned or rebuilt, checked compliant, and released, with the approver recorded.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then attach the device and the user

   The right action depends on whose device it is and what it runs.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are our endpoint detection
   tool, Microsoft Intune, Azure Active Directory or Okta, ServiceNow,
   Slack, Jira and Snowflake, or whatever we run in those seats. Before
   you plan anything, tell me which of them are already authenticated in
   the workspace, because I do not want a connector stubbed that I have
   not authenticated. If the endpoint tool has no connector, reach it
   through its API with a credential held in the workspace.
   
   On every high or critical detection, attach: the device's owner, their
   role and manager, whether they are on call right now, what the device
   runs (laptop, server, kiosk), its compliance state in Intune, and the
   owner's sign-ins in the last 24 hours.

2. 2

   Write the containment rule as data

   Which detections isolate on their own is a decision, not a default.

   Headless skills build-workflow

   Copy

   Use build-workflow. Build the rule as a table the security team can
   edit, not as logic in the workflow:
   
     Detections that isolate straight away on an ordinary laptop: for
     example ransomware behaviour, credential theft tools, known malware
     Devices that always need a person: servers, executives' devices,
     anyone on call, shared kiosks
     How long an approver has before the request goes to the next
     person on call, per detection
   
   For anything that needs a person, post to the on-call analyst in
   Slack with the detection, the device and the user, and buttons to
   isolate or hold. Record who decided and when.

   Agree the table with IT and the business before you build it. Most arguments about containment are about this table, and they are easier to have before 2am.

3. 3

   Isolate the device, and contain the account

   A cut-off laptop with a working session elsewhere has only moved the problem.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then on a decision to contain:
   
     Isolate the device from the network through the endpoint tool,
     keeping its connection to the endpoint tool itself open
     If the detection involves credentials, revoke the owner's sessions
     in the identity provider and reset their sign-in methods
     Mark the device in Intune so it can't reach company apps until
     released
   
   Then open a Jira case with the detection, the context, the decision
   and every action, and a ServiceNow request for a loan device if the
   user will be without one for more than a few hours.

4. 4

   Tell the user on a channel that still works

   An isolated laptop with no explanation becomes a service desk call.

   Copy

   The user's laptop is offline, so message them on Slack or Teams on
   their phone, and copy their manager. Say what happened in plain words,
   that it is not their fault, what they should not do (sign in somewhere
   else with the same password), and how to get a loan device.
   
   Keep the message short. The case has the detail.

5. 5

   Release on purpose, with a check

   A device let back on without a check is a second incident.

   Copy

   Release only when an analyst marks the case resolved. Before release
   confirm: the device was cleaned or rebuilt, the endpoint tool shows no
   active detections, and Intune shows it compliant.
   
   Then lift the isolation, clear the Intune mark, tell the user, and
   close the ServiceNow loan request. Record who released it.
   
   Report: detections, share contained on the rule, time from detection
   to isolation, time an approver took, and devices held more than two
   days.

6. 6

   Validate it, then hand the rule to security ops

   Because the rule will need changing the first week it runs.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run it for a fortnight with every isolation going
   to an approver, and compare what the rule would have done with what
   the analyst chose.
   
   Then open the same workflow in Tray Build so security operations can
   change the containment table, the approver timeouts and the user
   message in the visual canvas.

What it connects to

The detection comes from the endpoint tool. The device, the account and the user each live somewhere else.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides