"Contain this person": containment plans
One approval that ends sessions, isolates devices and suspends accounts across Qorionix and Microsoft 365, previewed first, undoable where possible.
When someone else may be using one of your people's accounts, the access rarely sits in one place. It is in their Qorionix sign-ins, in any privileged session they have open, in the vault credentials they checked out, on their laptop and — most often, for a small business — in their Microsoft 365 session. A containment plan puts all of that on one page as a list of steps. You read it, approve it once, and it runs. Each step records whether it worked and whether it can be undone, and the whole plan is written to a tamper-evident receipt.
What a plan is
A plan is about one person. It names them by their Qorionix account, by their Microsoft 365 / Entra ID sign-in name, or by both, and it carries a reason, which is required. It also has a lookback window — seven days unless you change it, and never more than 90 — that decides how far back to look for credentials the person used.
Building the plan reads, without changing anything, which of the person's privileged sessions are live right now and which vault credentials they checked out or used inside the lookback window, and adds one step for each. Devices are never guessed: a device is isolated only if it is named in the plan.
Where a plan gets built
| Where | What the plan is built for | Started by |
|---|---|---|
| Users, the Contain action on a person's row | That person. You can add devices to isolate and choose to suspend the account. | You |
| Endpoints, the Contain action on a device's row | That device, with isolation already filled in. You name the person the plan is about. | You |
| Incidents, Build containment plan under Respond to this alert | The person in a Microsoft 365 / Entra ID sign-in alert, including someone with no Qorionix account. | You |
| Sentinel-Q, Contain this person or Contain this host on a decision | The person or device the decision is about. | You |
| The Something's wrong button on Home | The person, external identity or device you named when you started the guided response. | You |
| A suspected mailbox takeover | A person with a Qorionix account, when a risky sign-in and a mailbox-rule change are both seen for them within six hours. | Qorionix, automatically |
| The privileged-access threat detector | A person whose privileged activity raised a high-severity alert. | Qorionix, automatically |
| An employee's I think I clicked something report | The person who reported, and their devices if you have set up isolation. | Qorionix, automatically |
A plan Qorionix builds on its own is still only a proposal. It waits as Proposed, exactly as if you had built it, and the incident or report that raised it links to it with Review containment plan or Review plan. That link opens the plan's own page, where you approve and then execute it, or reject it; see Deciding on the plan's page. A plan raised by an employee report can also be approved and run in one go from its card on the Overview, with Approve and run. When a mailbox takeover is about someone with no Qorionix account, no plan is built automatically; the incident offers Build containment plan instead, so you can end their Microsoft 365 session from there.
Preview, approve, execute, undo
Preview
Give a reason and fill in anything else the dialog asks, then choose Preview plan. You see every step, what it acts on, and whether it is Reversible or Permanent, before anything happens. If you name a device to isolate, the dialog also asks for the control-plane range: the network the sensor must still reach so the device can be released later. See Isolating a machine.
Approve, or reject
Approve records who approved the plan and when. It is the one human decision a plan needs, and it can only be made while the plan is still proposed. Approving runs nothing, and an approved plan can no longer be rejected. If you decide not to act, Reject it instead, with a reason. A rejected plan can never be approved or run afterwards.
Execute
Execute runs the steps in order, and each one gets its own result: Done, or Failed with the error. If a step fails, the rest still run and the ones that worked stay in place; the plan ends as Failed so you can see exactly which parts landed. A plan runs once. Executing it again is refused rather than repeating anything.
Undo
Open the plan's page (View status in the dialog, or the link from the incident or report). Every step that finished and can be reversed has an Undo button. Undo reverses that one step only; nothing else in the plan changes, and the undo is recorded with who did it and why.
- Proposed
- Built and waiting for a decision. Nothing has run.
- Approved
- A person approved it. Nothing has run yet.
- Executing
- The steps are running now.
- Completed
- Every step ran successfully.
- Failed
- It ran, and at least one step failed. The steps that worked are still in place.
- Rejected
- A person decided not to act. It can never run.
Deciding on the plan's page
Every plan has its own page, however it was built, and every decision can be made there. You reach it from View status in the preview dialog, or from the incident, report or Overview card that links to the plan. While the plan is Proposed, the page shows Approve and Reject. Once it is Approved, the page shows Execute. After it has run, the page shows each step's result and an Undo button on every step that can be reversed.
Approve and Execute each ask you to confirm first, and the confirmation says what will happen. For Approve, that means nothing runs yet and the plan can no longer be rejected. For Execute, it means every step listed on the page runs now against live accounts, sessions and devices, and, if any steps are Permanent, how many of them cannot be undone. A plan with no steps offers only Reject, because it has nothing to approve or run.
Why a person always approves
One plan can sign someone out of everything, cut a laptop off the network and disable an account, across Qorionix and your Microsoft 365 tenant at once. A wrong one stops a person working, and part of it cannot be taken back. So the default is fixed: building a plan never approves it, and the server refuses to execute a plan nobody has approved. It is not just a button the console hides.
The platform does have a path for running a plan without a person. Your plan's autonomy level, your own explicit opt-in for that severity and a platform-wide safety ceiling must all allow it, and anything it ran would be recorded as done by Sentinel-Q, never as a person. That safety ceiling currently holds every containment plan at recommend, so today every containment plan waits for a person, whatever your plan or settings. See What Sentinel-Q is allowed to do.
What each step does
| Step | What it does | Undo |
|---|---|---|
Isolate the device (isolate_endpoint) | Cuts the named device off the network, keeping only the connection the Qorionix sensor needs so it can be released. One step per device. | Reversible. Undo lifts the isolation. |
End Qorionix sessions (revoke_sessions) | Revokes every active Qorionix session and refresh token for the person, and requires step-up MFA when they sign in during the next 24 hours. One step, however many devices they are signed in on. | Permanent. A revoked session cannot be restored; the person signs in again. |
End a privileged session (terminate_pam_session) | Ends one live privileged session, such as SSH or RDP, that the person has open through Privileged access. One step per session found when the plan was built. | Permanent. An ended session cannot be resumed. |
Queue credential rotation (queue_rotation) | Records one vault credential the person checked out or used inside the lookback window as needing rotation. It queues the rotation; it does not change the secret. | Permanent. The queue entry stays. |
Suspend the Qorionix account (suspend_account) | Suspends the person's Qorionix account. Added only when you tick Also suspend the account. | Reversible. Undo reinstates the account. |
End the Microsoft 365 session (revoke_entra_sessions) | Revokes every refresh token Microsoft Entra ID has issued for the person in your own tenant, so they must sign in to Microsoft 365 again. | Permanent. Revoked tokens cannot be restored. |
Disable the Microsoft 365 account (disable_entra_account) | Turns off the person's Entra ID account in your tenant. It is disabled, not deleted, so their sign-in history stays. Added only when you tick Also suspend the account. | Reversible. Undo re-enables the account. |
The Microsoft 365 steps
The two Microsoft 365 steps act on your own Entra ID directory, through your Microsoft 365 connection. They are added only when the plan knows the person's Microsoft 365 sign-in name and your connection is working at the moment the plan is built; otherwise they are left out rather than added to fail later. For an alert raised by a Microsoft 365 sign-in, this is usually where the attacker's session actually lives, and ending only the Qorionix session would contain nothing.
Ending the session and disabling the account are different things. Disabling stops new sign-ins, but tokens Microsoft has already issued stay valid until they expire; revoking them is what ends access already granted. That is why the session step is included whenever Microsoft 365 is connected, and the disable step only when you ask to suspend.
For someone with no Qorionix account, a plan can only contain these two steps. If Microsoft 365 is not connected either, the preview says there is nothing to run, and you need to end their session from the Microsoft 365 admin center instead.
The receipt
Every plan has its own tamper-evident record in the same hash-chained audit log Sentinel-Q uses for its decisions. An entry is added when the plan is built, when it is approved or rejected (with the reason), when execution starts, when it finishes (with the final status), and for every undo (with the step and the reason). Each entry records who acted and whether that was a person or Sentinel-Q, and each entry's hash covers the one before it, so changing or removing any entry breaks the chain at that point.
The receipt records decisions and the start and finish of execution. The result of each step — done or failed, the error, when it ran and when it was undone — is on the plan's own page.
A plan's chain is named containment: followed by the plan's id, which is the last part of the plan page's address. To check that it is intact, use the qorionix__verify_audit_chain tool described in Connecting your own AI client over MCP. The plan's page can also draft the incident story and notices from the plan's own record; see Evidence-bound drafts.
Who can do what
Reading a plan needs response:containment.read. Building, approving, rejecting, executing and undoing all need response:containment.execute, so someone who can see a plan's status cannot approve it just because they can see it. The server enforces both, whatever the console shows.
What to read next
- The "Something's wrong" panic button: preserving evidence before you contain, and the NIS2 clock.
- Isolating a machine: what isolation costs, and how a device gets back on the network.
- Response actions on an endpoint: single-device actions that run outside a plan.
- Evidence-bound drafts: writing the incident story and notices from the plan afterwards.