Active Response

Active response is LinuxGuard's automated containment capability: when a monitored identity exhibits behaviour matching a configured trigger condition, the platform can execute targeted containment actions on that identity across the affected servers — without waiting for manual intervention. What distinguishes active response from simple alerting is its safety model: the system is designed so that automated action is structurally impossible unless every layer of the configuration has been explicitly set up to allow it.

Safety Model

The safety model establishes the conditions under which automated response can occur. Understanding these conditions before configuring any playbook provides the confidence that response commands execute precisely where intended — and cannot fire outside that boundary.

Triple Opt-In

Active response requires three independent conditions to be satisfied simultaneously. Each layer represents a deliberate architectural decision that prevents a specific class of accidental execution:

Layer 1 — Playbook enabled with trigger conditions configured. A playbook must be explicitly enabled and must have at least one trigger condition (a signal type, severity threshold, and identity type match) set before any response can fire. This ensures that tenants which have not deliberately activated automated response are never affected, even if signals matching the playbook's pattern are observed.

Layer 2 — Server group membership. A playbook's scope is defined at configuration time by one or more server groups. At runtime, the playbook can only act on servers that belong to those groups. The scope boundary is fixed — it cannot be extended by a signal, an operator action, or any runtime condition. A playbook scoped to a staging server group cannot act on production servers, regardless of what signals fire.

Layer 3 — Agent-level response flag. Each agent has an individual response_enabled flag. Even when Layer 1 and Layer 2 conditions are fully satisfied, a command issued to an agent with this flag disabled will sit in QUEUED state until it times out. No action is taken on that host. This allows operators to opt individual hosts in or out of automated response independently of their group membership.

Exclusion list. At the playbook level, specific identities can be excluded from automated response entirely regardless of what signals they generate. Common exclusions include service accounts performing scheduled tasks, break-glass emergency accounts, and monitoring infrastructure agents. An excluded identity matching a trigger condition generates the alert signal but receives no containment command.

Audit trail. Every response command is recorded with the full context of why it fired: the identity that was acted upon, the action taken, the triggering signal, the timestamp, and the pre-action state of the affected resource. The audit trail uses a chain hash to ensure integrity — records cannot be altered after the fact.

Note: Before enabling response at scale, you can configure a playbook scoped to a single non-critical test account. Observe the trigger behaviour and response execution in the Active Responses page before expanding scope.

Blast Radius

A playbook's scope — the server groups it can act on — is set at configuration time. This is a design property of how playbooks work, not a runtime safety net: a playbook simply has no mechanism to act outside its configured scope.

In addition to scope, the system enforces built-in execution limits as system properties. These are not configurable console settings:

• Maximum 10 commands per server per hour — prevents a single host from receiving a high volume of commands in a short window

• Maximum 50 distinct servers per playbook execution window — bounds the number of hosts a single playbook execution can affect

• Maximum 5 concurrent tenant-wide commands (commands in QUEUED, DISPATCHED, or EXECUTING state combined) — limits overall response activity across the tenant at any moment

A circuit breaker provides an additional safeguard: if a playbook's failure rate exceeds 20% across five or more commands within a 15-minute window, the playbook is automatically disabled. This prevents a misconfigured or partially failing playbook from continuing to issue commands when the success rate indicates a systemic problem.

Rollback

Most containment actions are temporary by design. Two rollback mechanisms ensure that containment state does not persist beyond its useful window.

Automatic timeout-based rollback. The system polls completed commands on a five-minute cycle and automatically reverses eligible actions when their configured rollback window expires. The system default is four hours from command completion. Eligible actions are: lock account, disable SSH key, and revoke sudo. Automatic rollback is recorded in the audit trail with the initiator identity system:auto_rollback.

Kill sessions does not support automatic rollback. Terminated sessions cannot be restored — there is no session state to recover.

Manual console rollback. An operator can trigger rollback for any completed, eligible action directly from the Active Responses page. Manual rollback is available once per original action — a second rollback of the same command is not permitted. The rollback is linked to the original command in the audit trail with the operator's identity as initiator.

Playbooks

A playbook is a named, scoped policy that connects a trigger condition to one or more containment actions. Its configuration elements are:

• Trigger conditions — a combination of signal type, severity threshold, and identity type that causes the playbook to fire

• Server group scope — the set of server groups the playbook can act on (fixed at configuration time)

• Containment actions — one or more of the four available actions, optionally including notifications

• Exclusion list — identities that are never acted on by this playbook

• Auto-rollback timeout — the window after which eligible containment actions are automatically reversed (system default: four hours)

Playbooks are created and configured in the Zero Trust Enforcement section of the console. In addition to containment actions, playbooks can also trigger notifications — alerting a security operations channel without taking containment action, or in combination with containment. See Notification Rules for setup instructions.

Containment Actions

Four containment actions are available. Each is a targeted operation on a specific identity on a specific set of servers within the playbook's server group scope.

Lock Account

What it does: Disables the account's password authentication by locking the account (usermod -L). The account continues to exist but cannot authenticate using a password. Existing sessions are not affected — only new password-based authentication attempts are blocked.

Rollback: The action is reversed automatically at the rollback timeout, or manually from the console. Reversal restores the account to its pre-action state. If the account was already locked before the response fired, the rollback does not unlock it — the pre-action state was locked, and that state is preserved.

Scope: Acts on the named account on each server within the playbook's server group scope.

Kill Sessions

What it does: Terminates all active sessions for the identity on every server in scope — not only the session that triggered the signal. The operation uses loginctl terminate-user with a pkill fallback for robustness across distributions.

Rollback: There is no rollback for kill sessions. Terminated sessions cannot be restored. Kill sessions is not eligible for automatic or manual rollback.

Scope note: Because kill sessions acts across all servers in scope rather than just the triggering server, it has a higher default severity threshold than other containment actions. This reflects the broader reach of the operation.

Disable SSH Key

What it does: Disables the specific SSH public key that triggered the signal in the identity's authorized_keys file. The key entry is marked as disabled rather than deleted, preserving the original file state for accurate rollback.

Rollback: Automatic rollback at the timeout restores the original authorized_keys contents. Manual rollback is also available from the console. Reversal restores the exact pre-action state of the file.

Scope: Acts on the named SSH key for the named identity on each server in the playbook's server group scope.

Revoke Sudo

What it does: Installs a deny rule in sudoers.d that prevents the identity from using sudo. The deny file passes a visudo syntax check before being installed atomically, ensuring no partial or malformed sudoers state is left on the host.

Rollback: Automatic or manual rollback removes the deny file. Reversal only removes the file that was installed by this action — if the identity had no sudo access before the response fired, the state after rollback is unchanged.

Important: Revoke sudo is only available when a sudo policy is configured for the identity. If no sudo policy exists for the identity, this action has no effect.

Active Responses Page

The Active Responses page in the Zero Trust Enforcement section of the console provides a real-time view of all response commands — past and present — across the tenant.

In-flight commands. A command is in-flight when it is in QUEUED, DISPATCHED, or EXECUTING state:

• QUEUED — the command has been issued by the platform and is waiting to be picked up by the agent. If the agent's response_enabled flag is off, the command remains QUEUED until it times out.

• DISPATCHED — the agent has acknowledged the command and is preparing to execute.

• EXECUTING — the operation is actively running on the host.

Pending rollback window. COMPLETED commands for actions with an active auto-rollback window also appear as active in the page. These commands have completed their containment action but have not yet been automatically reversed — they will be rolled back when the configured timeout expires.

History. All commands — completed, failed, timed out, and rolled back — appear in the history view with their full lifecycle timestamps, the initiator identity, the signal that triggered the playbook, and any linked rollback commands.

Status tracking. Each entry shows the full lifecycle state (QUEUED → DISPATCHED → EXECUTING → COMPLETED, FAILED, or TIMED_OUT), the identity acted upon, the target server, the action type, and the linked rollback command if one exists.

---

Related: Security Architecture | Zero Trust Enforcement