Response actions

Response actions are discrete containment operations that Sentinel executes autonomously or that you trigger via the API. Every action is audited; reversible actions retain an enforcement receipt that the rollback path uses.

Available actions

Name	Type	Required	Description
isolate_device	action	No	Cut device network access. Management channel remains active. Dispatched to the endpoint agent — see the note below.
deisolate_device	action	No	Restore full network access to an isolated device. Dispatched to the endpoint agent.
terminate_connections	action	No	Close established non-management flows after isolation. Requires a capable endpoint/network integration.
kill_process	action	No	Terminate a specific process by PID or name on a device. Dispatched to the endpoint agent.
suspend_process / resume_process	action	No	Pause or resume a PID only after executable, hash, and process-start identity verification. Dispatched to the endpoint agent.
quarantine_file	action	No	Move a file to quarantine storage on the device. Dispatched to the endpoint agent.
restore_file	action	No	Restore a previously quarantined file. Dispatched to the endpoint agent.
run_scan	action	No	Trigger a scan on a device. Dispatched to the endpoint agent.
collect_forensics	action	No	Collect forensic evidence from a device. Dispatched to the endpoint agent.
disable_local_account / enable_local_account	action	No	Lock or restore a local endpoint account. Distinct from the tenant directory identity.
terminate_local_sessions	action	No	Evict active local endpoint sessions. Irreversible and always approval-gated.
disable_persistence / enable_persistence	action	No	Disable or restore a launchd, Windows service, or Windows scheduled-task persistence item.
block_hash / unblock_hash	action	No	Add or remove a SHA-256 execution deny through a configured endpoint control integration.
block_certificate / unblock_certificate	action	No	Add or remove a signer-certificate execution deny.
block_path / unblock_path	action	No	Add or remove a path-based execution deny.
disable_account	action	No	Disable a user account through your tenant’s connected identity provider. Completes synchronously.
enable_account	action	No	Re-enable a directory account through Entra, Okta, or Supabase Auth.
revoke_sessions	action	No	Invalidate all active sessions for a user. Completes synchronously.
force_mfa	action	No	Attempt to require MFA re-challenge — provider support varies, see the identity actions page. Completes synchronously.
block_ip	action	No	Block an IP at the Cloudflare layer. Completes synchronously.
unblock_ip	action	No	Remove an IP block. Completes synchronously.
block_domain	action	No	Block a domain at the Cloudflare layer. Completes synchronously.
unblock_domain	action	No	Remove a domain block. Completes synchronously.
quarantine_message / purge_message / block_sender	action	No	Contain malicious mail through a configured mail-security integration.
remove_forwarding_rule / revoke_mailbox_delegation	action	No	Remove mailbox persistence and unauthorized delegated access.
revoke_api_key / rotate_secret	action	No	Invalidate compromised non-human credentials. Irreversible and approval-gated.
disable_oauth_app / disable_service_principal	action	No	Disable compromised application identities through a configured cloud provider.
remove_public_link / lock_bucket / isolate_workload	action	No	Contain cloud data exposure or a compromised workload.
freeze_share / restrict_transfer / disable_removable_media	action	No	Apply temporary data-loss containment controls.
run_playbook	action	No	Execute a playbook — see the playbooks page.
notify_analyst	action	No	Durably enqueue analyst delivery with retry, poisoning, acknowledgement, and an idempotency key.

Warning:Endpoint-agent actions do not complete synchronously: the response means a signed command was queued, not that execution finished. Identity and network actions complete synchronously after provider verification. Mail, cloud, SaaS, execution-control, and data-loss actions require a tenant integration advertising that exact capability and fail closed when it is absent. See status in the action object below.

Trigger a response action

bash

POST /v1/sentinel/actions

bash

curl -X POST https://api.hldgroup.org/v1/sentinel/actions \
  -H "Authorization: Bearer hld_live_xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "isolate_device",
    "target_type": "device",
    "target_id": "dev_01hxyz",
    "incident_id": "inc_01hxyz",
    "reason": "Suspicious outbound traffic, isolating pending investigation."
  }'

The action object

The response to the isolate_device call above — an endpoint-agent action, so the immediate response is queued, not completed:

json

{
  "id": "act_01hxyz",
  "action": "isolate_device",
  "status": "queued",
  "target_type": "device",
  "target_id": "dev_01hxyz",
  "incident_id": "inc_01hxyz",
  "triggered_by": "api",
  "reason": "Suspicious outbound traffic, isolating pending investigation.",
  "created_at": "2025-06-01T03:14:09Z",
  "completed_at": null,
  "reversible": true,
  "reversed_at": null
}

Poll GET /v1/sentinel/actions/:id or list actions for the incident (below) to see status transition to completed/failed once the device's agent reports back. For the synchronous identity/network actions, status is already completed (or a failure) in the initial response.

Reverse an action

Actions marked reversible can be undone through their endpoint, identity, network, or provider integration. The reversal is audited and tied to the same incident; irreversible actions never expose this operation.

bash

POST /v1/sentinel/actions/:id/reverse

{
  "reason": "Investigation complete, device cleared. Restoring access."
}

Tip:Always provide a reason when triggering or reversing actions. It becomes part of the permanent incident timeline and is included in audit reports.

List actions for an incident

bash

GET /v1/sentinel/incidents/:incident_id/actions

Webhooks Rate limits