Response Actions is the durable, audited containment and one-shot remediation log. An operator selects a device and an action from a fixed catalog; UEC persists the action first, dispatches a typed command, tracks the result, and guarantees an inverse for every reversible containment.

---

Action catalog

Action	Kind	Inverse	Windows	macOS	Linux
Isolate	Containment	Unisolate	✅	✅	✅
BlockDomain	Containment	UnblockDomain	✅	✅	✅
BlockUsbStorage	Containment	UnblockUsbStorage	✅	—	✅
BluetoothDisable	Containment	BluetoothEnable	✅	—	—
CertDeploy	One-shot	none	✅	—	—
DefenderScan	One-shot	none	✅	—	—
RemoveThreat	One-shot	none	✅	—	—
BitLockerEncrypt	One-shot	none	✅	—	—
BitLockerDecrypt	One-shot	none	✅	—	—
DefenderHarden	One-shot	none	✅	—	—

Unsupported actions are not offered for a target platform. A one-shot is directly runnable but has no inverse, no auto-revert deadline and does not enter the desired-containment feed.

BitLockerDecrypt is not the undo of BitLockerEncrypt. They are independent one-shot actions. Treating decrypt as an inverse could silently decrypt a disk when an action expired.

---

Safety invariants

1. The server sends an action name and typed envelope, never a command line, script or path.
2. Isolation always preserves management access: loopback, DNS, DHCP and the agent’s configured server endpoint.
3. An action row is persisted before dispatch.
4. Only one live action exists for the same tenant/device/type/target.
5. Every reversible action has a working, idempotent inverse.
6. Every create, dispatch, result, undo and expiry is audited.
7. Actions have an expiry unless SuperAdmin explicitly marks them indefinite.
8. Tenant settings provide a master kill switch, automatic-response opt-in, allowed actions and an hourly cap.
9. Heartbeat convergence reverts orphaned containment; endpoint state cannot outlive its record.

---

Manual containment workflow

1. Open the target device or Response Actions.
2. Select the action.
3. Provide a reason and expiry.
4. Confirm. UEC creates the row, then dispatches it.
5. Watch state: Pending → Dispatched → Succeeded/Failed/TimedOut.
6. Verify the result and the device’s last endpoint confirmation.
7. Undo with the explicit inverse or allow expiry.

If the device is offline, the row remains pending and the dispatch worker retries when it reconnects. A pending action already beyond expiry is cancelled rather than dispatched.

---

States

State	Meaning
Pending	Persisted, not yet delivered
PendingApproval	Waiting for configured approval
Dispatched	Transport accepted delivery
Succeeded	Endpoint reported success
Failed / TimedOut	Executor failed or acknowledgement window elapsed
Expired / Reverted	Containment ended by expiry or inverse

---

Automatic response

Alert rules can bind response actions, but automatic response is:

• opt-in per tenant;
• limited to allowed action types;
• capped hourly;
• still subject to dedup/rate limits in the alert pipeline;
• audited with source alert and rule IDs.

Start with low-risk actions and a short default undo interval. Do not enable automatic isolate on a production-critical ring without approval and rollback rehearsals.

---

Read the action log

For each row, inspect target, reason, origin, source alert/rule, actor, dispatch/result times, expiry, endpoint confirmation, failure reason and message. The reason is mandatory because this log is both an operational and audit record.

---

Rule-triggered flow

1. Alert survives deduplication and rule rate limits.
2. Active-response hook reads rule bindings.
3. Tenant settings and hourly cap are enforced.
4. Action is created with Origin = Rule and source IDs.
5. Dispatch follows the same state machine as a manual action.

There is no separate unguarded “run script” path.