What runs on its own, exactly
Each server runs in one of two modes that you choose when you enrol it and can change at any time. In Awaiting Approval, every action waits for a person, including blocking an address. In Automatic, which every paid plan includes, the platform adds exactly one thing: blocking an address identified as attacking the server, without asking. For SSH that means an address seen failing logins in three separate reports within thirty minutes, so one mistyped password never blocks anyone; a source the agent identifies as scanning for vulnerabilities, abusing WordPress logins or flooding the server is blocked on that finding. Nothing else is added by Automatic mode. The list of actions that may run unattended is a single entry in the code, and widening it is a release decision, not a setting.
A block is scoped so it cannot become an outage. Your own address and any address you mark as trusted are exempt, the edges of a CDN in front of the server are protected so a proxied site cannot be blocked by its own traffic, and every automatic block expires on its own after 6 hours, longer for an address that keeps coming back, never more than 7 days. If a block ever catches you, the "Let me in" link in the alert lifts it, and lifting a block never needs approval, so the way back in works even while everything else is paused.
How a block is enforced
SecAI does not install a firewall. It uses the tool the server already runs: fail2ban, CrowdSec, CSF, firewalld or iptables, whichever it finds, and records what it did. The block is visible in the dashboard with the evidence behind it, and it is listed in the tool that holds it, so an administrator who prefers the command line sees the same rule there. A block is scoped to what was attacked: an SSH attacker is dropped on the SSH ports only, a web attacker on ports 80 and 443 only, and a flooding source everywhere, but only after a rule keeping every SSH port open is in place. Where fail2ban, CrowdSec, CSF or firewalld holds the rule, that tool's own timer may end the block sooner than SecAI's expiry; the longer blocks for an address that keeps coming back hold in full only where the agent wrote the rule itself.
The decision is made from the agent's own authentication telemetry and the platform's sighting counter, not from a shared blocklist. A distributed attack that spreads one attempt across many addresses does not trip a per-address threshold, and SecAI says so rather than pretending otherwise; the flood detector on the host, and an upstream provider for anything volumetric, are the answers to that shape of attack.
What waits for approval, and what you see
Everything with a wider blast radius waits for a person in both modes: hardening fixes to service configuration, package updates, enabling or disabling an account, and quarantining a suspected web shell. Quarantine waits for a person even when a person asked for it, because the page that shows a flagged file shows two hundred bytes of it, which is enough to recognise something and not enough to prove it.
A proposal reaches you with the action itself, the reason SecAI proposed it, the server and resource it affects, the effect in plain words, and, where one exists, how it is undone. Approving it in the dashboard is the approval; a fix you click yourself is not queued for you to approve a second time. Proposals arrive in the Approvals queue and in the alert email, so nothing waits silently. A proposal nobody answers within 7 days expires as declined, and you are told.
Self-healing fixes: apply, verify, undo
A configuration change goes through one path on the server: a copy of each file is written to disk first, the change is applied, the configuration is validated before any reload, the service is reloaded, and then the service and SecAI's own control channel are verified. A failure at any step restores the copy, reloads again if something was reloaded, and reports what happened. The copy stays on your server under /var/lib/securityemployee/snapshots and is uploaded nowhere.
Every applied change has an Undo in the dashboard by its own id, and Undo refuses if the file has changed since SecAI wrote it, because a later edit is somebody's work. When a change is rolled back, that kind of change on that server goes back to waiting for approval until you say otherwise, and three rollbacks across your servers within an hour switch on safe mode for all of them and email you what was attempted and what broke.
The switches above every mode
Two controls sit above the per-server mode. A pause stops all automation while the undo actions, lifting a block, removing a hardening fix and restoring a quarantined file, keep working. Safe mode, which the platform switches on by itself when rollbacks spike, rejects everything except those same undo actions until a person turns it off.
Controls resolve from the narrowest scope outward: a setting on one server wins over the organisation's, which wins over a category's, which wins over the global switch. An action the platform does not recognise, or a category that has not been through its canary period, defaults to waiting for approval.
The audit trail
Every security action is explainable after the fact. The activity feed and the daily digest tell the story per server: what was detected, what ran on its own, what waited for you and what you decided, and what was rolled back. Each item names its outcome, whether SecAI handled it, you handled it, it is being watched, or it needs an expert, so a quiet day reads as quiet and a busy one reads in order.
What automated response is not
- Not a web application firewall. SecAI blocks addresses at the host firewall and watches web roots; it does not inspect or rewrite HTTP requests.
- Not volumetric DDoS protection. The host can detect a flood and drop a source; traffic that saturates the link has to be stopped upstream.
- Not automatic patching. A package update is proposed with the vulnerability behind it and waits for approval, because an update that restarts a service is a change to production.
- Not automatic account lockout. Enabling or disabling an account always waits for a person.