Why a long-lived server drifts
- Services outlive their purpose: a staging copy, a database opened for a migration, a mail server nobody uses.
- Access accumulates: former staff, contractors, a deploy key nobody can place.
- Patching stops at the package: the new kernel is installed, the old one is still running.
- Configuration is edited by hand, under pressure, and never written down.
- There is no provider firewall in front of the machine unless you built one.
What is exposed, as the internet sees it
The agent reports listening sockets and which of them are reachable from outside, and the posture findings name the exposures that matter on an unmanaged host: a database, cache or mail port open to the internet, a resolver answering recursive queries, a firewall that is installed but inactive. The weekly AI audit ranks them with the evidence. Closing one is a proposed fix that waits for your approval and keeps a copy for undo.
Patched on disk is not patched in memory
SecAI reports pending security updates and, separately, updates that are installed but waiting for a reboot, because a kernel or library fix that has not been loaded is a fix that has not happened. Installed packages are matched against vulnerability data every twelve hours, per server, with the fixed version where the distribution has published one. A package update is proposed and waits for approval; a reboot is yours to schedule.
Who can do what, and what changed
Local accounts, sudo grants, authorised SSH keys with their fingerprints, setuid and capability binaries are inventoried and any change is reported, attributed to the administrator session it happened inside or flagged as having none. Cron entries, systemd units, sudoers and authorised keys are watched with the text before and after a change. On a machine that has been running for years, the first report is often the most useful one: it is the inventory nobody had.
A machine worth keeping alive
A dedicated server usually carries more than one thing that matters, so an exhausted machine is an outage for all of them. The agent is protected from the OOM killer and keeps a per-second record of pressure, memory, forks and sockets when the server is under exhaustion or cannot reach SecAI, so that an outage has a story afterwards. If you set the server to Protect, it may cap or freeze the one process group responsible and undo it when the episode ends; it never touches init, SSH, a database, a web server, a control panel or a login session. Every server starts at record only.
What it does not cover
- The out-of-band management controller (IPMI, iDRAC, iLO). Keep it off the public internet; SecAI does not see it.
- Hardware health: disks are reported by usage, not by SMART attributes or RAID state.
- Volumetric DDoS, which has to be absorbed upstream by the provider or a scrubbing service.