# Response actions Review and approve the actions agents, playbooks and Brain propose, bind each action to your own security tools, and trace every decision on the audit ledger. Tracix responds to threats through proposals that a person approves. This page explains who may approve what, how approved actions run, and how to connect them to the security tools you already use. ## How a response moves 1. **Proposed.** The SOC agents, playbooks and Brain file proposals. None of them can run a catalog action on its own. Each proposal names the action, its target and the reason. For actions on hosts and network devices, it also pins exactly what the approver will act on. 2. **Approved or rejected.** A person decides on **Security › Response Actions**. The action's tier decides who may approve it. 3. **Executed.** Tracix runs the action itself, through the collector on a host, or through a tool you bind with your own credential. An action with nothing bound becomes a task for a person to complete. 4. **Recorded.** Every proposal, decision and outcome lands on the hash-chained audit ledger. ## The actions and who approves them The catalog has 25 actions in four tiers: **0** observes and notifies, **1** makes reversible changes inside Tracix or reads from a host, **2** contains a threat in a way people notice, and **3** is destructive or broad. Editors and admins approve tiers 0 and 1; only admins approve tiers 2 and 3. | Tier | Actions | Runs through | | ---- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | 0 | Notify the SOC, open a case, attach evidence to a case, add to a watchlist | Tracix | | 0 | Request forensic collection | A task for a person | | 1 | Block or unblock an indicator, remove from a watchlist, enable or disable a detection rule | Tracix | | 1 | Scan host files with YARA | The collector on the host, read-only | | 2 | Contain a host or release it, kill a process | A bound EDR tool | | 2 | End a process on the host, quarantine a file on the host, restore a quarantined file | The collector on the host, where its owner allowed host response | | 2 | Disable a user account, revoke user sessions, force a password reset, disable an API key or token | A bound identity or key provider | | 2 | Block or unblock an IP address at the edge | A bound firewall or edge tool, or edge ACLs on Arista EOS and Nokia SR Linux through configuration management | | 3 | Quarantine mailbox content | A bound mail provider | | 3 | Reimage a host | A task for a person | A YARA scan reads at most 500 files in 20 seconds and never sends file contents; matches land on the host's profile. ## Review proposals Open **Security › Response Actions**. The queue is split into **Proposed**, **In progress**, **Operator tasks**, **Failed**, **Executed**, **Done manually** and **Rejected**. Each proposal shows the action, its tier, how it runs, the target, the linked case, the reason, and the inputs pinned when it was filed, such as a process ID or a file's SHA-256. * Select **Approve**, with an optional note, to run the action. * Select **Reject**, with an optional reason, to close it. * For an operator task, do the work, then select **Mark done** and say what was done. * For a failed action, select **Retry** to approve it again. ## Bind actions to your tools An admin decides how each vendor-dependent action runs. On **Response Actions**, under **Intent bindings**, select **Edit bindings**. For each action, choose a vendor action and the credential it uses, or leave it **Unbound (operator task)**, then select **Save bindings**. Vendor credentials live under **Credentials**. | Action | Tools you can bind, for example | | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Contain or release a host | CrowdStrike Falcon, Microsoft Defender, SentinelOne, Carbon Black EDR, Bitdefender GravityZone, ESET PROTECT, Huntress, Trend Micro Apex One | | Kill a process | Bitdefender GravityZone, ESET PROTECT, Trend Micro Apex One | | Disable a user, revoke sessions, force a password reset | Okta, Microsoft Entra ID, Keycloak, JumpCloud and others; which actions each supports varies | | Block an IP address at the edge | Cloudflare, Fortinet FortiGate, Check Point, F5 BIG-IP, Cisco Secure Firewall Threat Defense, pfSense, OPNsense and others | | Quarantine mailbox content | Microsoft Entra ID, through Microsoft Graph | Any action can instead go to your own automation through the **Generic webhook**. Tracix posts the action, target, reason, proposal, case, approver and time as JSON, and signs the body: the `x-tracix-signature` header carries `sha256=` followed by the HMAC-SHA256 of the body with your signing secret. Verify it before you act on the request. Select **Action library** to browse every vendor action, see the exact call it makes and its inputs, and turn one into a draft workflow. ## Respond on a host Ending a process and quarantining or restoring a file run through the collector on the host, without an EDR. They work only where the host's owner allowed it when installing the collector: * In the console's install flow, tick **Allow host response on this host**. The install command then carries `--enable-response` on Linux and macOS, or `-EnableResponse` on Windows. Run the installer again without it to turn host response off. * Collectors on Docker and Kubernetes never run host response. When a proposal is filed, Tracix asks the collector to pin its target: a process by its ID, start time and program, and a file by its path and SHA-256. At approval, the collector refuses if the ID now names another process or the file's content changed. It never ends itself, the init process, kernel threads or the Windows session and security processes. Quarantined files are kept encrypted in the collector's state directory, and a restore puts the file back with its owner and mode. ## Block an address at the edge with configuration management **Block IP at the edge** can add a deny entry to an ACL on your own Arista EOS or Nokia SR Linux devices instead of calling a firewall vendor. **1. Prepare the devices** Manage the devices in [configuration management](https://tracix.io/docs/network/ncm) over gNMI, with credentials bound and a collector on a release that supports scoped ACL writes. Create the IPv4 and IPv6 ACLs on each device and apply them to the edge interfaces. Tracix never creates, replaces or binds an ACL. An Arista ACL ends with an implicit deny, so give it a final permit entry. **2. Bind the action** Under **Intent bindings**, choose **Edge ACL on managed devices (NCM)** for **Block IP at the edge**. Choose the devices or one device group, name the IPv4 and IPv6 ACLs, choose the traffic to deny (**From the address**, **To the address** or **Both directions**), and give a sequence range Tracix may use. When a block is proposed, Tracix picks free sequence numbers in the range, renders the change for each device and shows each entry with its SHA-256 on the proposal. Approval sends exactly that change. The collector writes an entry only where its slot is free or already identical, reads it back, and restores the slot if it doesn't verify. Each block matches one address or prefix, no wider than /8 for IPv4 or /16 for IPv6. **Unblock IP at the edge** removes only the entries Tracix's blocks added. ## Playbooks Playbooks are workflows that start from security events, such as a new alert, a triage verdict or an opened case. Open **Security › Playbooks** to install ready-made ones as drafts. In a playbook, a vendor action of tier 0 or 1 runs when the playbook does, and an action of tier 2 or 3 files a proposal instead. Activating a playbook that contains tier 2 or 3 actions needs an admin. ## The audit ledger **Security › Audit Ledger** shows every consequential action by the agents and analysts: verdicts, proposals, approvals, executions, cases and evidence. Each entry is chained to the one before it by SHA-256, so tampering with, dropping or reordering an entry breaks verification from that point on. The page shows **chain intact** with the number of entries, or the entry where the chain broke. Host responses, YARA scans and edge changes are written to the ledger before they start, so none of them runs unrecorded. ## Next steps - [Detection rules and shadow mode](https://tracix.io/docs/security/detections): Tune the rules that raise alerts - [Problems and cases](https://tracix.io/docs/alerting/problems-and-cases): Work incidents as cases - [Brain](https://tracix.io/docs/ai/brain): Investigate an alert in plain language