Response actions and endpoint isolation
Request approved containment, track target acknowledgement, and release isolation using explicit recovery.
Response actions request an explicit change from an agent, gateway, edge service, or approved integration. They record who authorized it, which targets were selected, and what each executor actually acknowledged.
Request and approve
A Responder opens Incident → Response → Request action, chooses the target and action, and enters a reason. Check Endpoint → Capabilities before selecting an endpoint control, then review the exact target IDs in the request preview.
Set the execution-start deadline in expires_at. It defaults to 15 minutes after creation and must be between 60 seconds and 24 hours after creation. If the action has not started by that deadline, it expires and cannot execute when the device later reconnects.
Disruptive actions can require approval at Organization → Response controls → Approval rules. An authorized second person opens Incident → Response → Action → Review, checks targets, parameters, and deadline, then approves or rejects. Self-approval is rejected when separation is required.
Accepted targets and parameters are immutable. If they need to change, cancel the original request through Incident → Response → Action → Cancel and inspect its final per-target results before submitting replacement work. The replacement requires its own approval; cancellation does not undo an effect that already completed.
Open Incident → Response → Action to follow pending_approval, queued, running, and the final result: succeeded, failed, rejected, canceled, or expired. Success requires executor acknowledgement. For bulk work, inspect each target's result; any required target failure makes the aggregate action fail.
If execution began before the deadline, passing that deadline does not undo its effects. Continue following the action until the executor's outcome is recorded.
Isolate an endpoint
Choose Request action → Isolate endpoint after confirming the capability, management channel, and recovery owner. Isolation blocks the supported network paths while preserving the agent's management and declared recovery channels. It does not promise protection from local console access or every unsupported network interface.
Open Endpoints → Endpoint → Response state and confirm the isolation acknowledgement and time. A 202 response or missing heartbeat does not establish that the device is isolated.
If the agent cannot be reached, record containment as unconfirmed. For a device using Guard-managed access, open Access → Sessions and revoke its sessions; verify gateway acknowledgement for each one. Ask the device's network administrator to block any remaining paths outside Guard. Record which paths remain unconfirmed in the incident timeline.
Release and reconcile
Use Incident → Response → Request action → Release isolation with a reason and any required approval. Verify the agent acknowledged release and the device regained only its permitted connectivity. Policy expiry, incident closure, agent credential revocation, and action cancellation do not automatically release isolation.
If the device cannot reach management, a recovery administrator obtains its device-bound recovery instructions at Endpoint → Maintenance → Recovery authorization and performs them locally. Record the action in the incident timeline. After reconnect, check Endpoint → Response state for the reported release and compare it with the local result before issuing another response action.
Quarantine has its own restoration workflow. See Action API for request contracts and operations for cancellation boundaries.