Security that doesn’t wait for Monday.

Every ten minutes, Sentinel asks each server which security updates are pending, including those that apt holds back, usually a new kernel.

For the exposure report, Sentinel pulls in three catalogs in full: the actively exploited vulnerabilities listed by the US agency CISA, the Ubuntu Security Notices and EPSS, the exploitation probability from FIRST. The matching runs hourly in the control center, against what is installed and listening on each server. No information about your servers is sent out in the process.

The result is not a list of 400 CVE IDs but one number per vulnerability, built from four questions: whether it affects your server, whether it is being exploited, whether the service is reachable from outside and whether the fix exists, plus the US agency’s deadline and the ransomware flag. Whatever affects you and is being exploited appears in the application as a finding with a button and arrives as a notification. Sentinel keeps “no matches” and “not affected” apart and states with every check what it could not check.

The exposure report includes the end of security updates: when an operating system or a PHP version no longer receives any, Sentinel says so clearly, and it also recognizes Ubuntu Pro with its extended coverage. It starts the move to a new version only with your approval, because that move cannot be rolled back; by default it is switched off.

As a rule, Sentinel installs security updates within an hour, as far as the risk class allows, including at night, on weekends and during blackout periods. The risk class depends on the action, not on the package: installing security updates without restarting a service is class 1 and may run at any time; restarting a service is class 2 and waits for the window, with a backup. Which class Sentinel may carry out without you is determined by the level you choose per server. Anything bigger waits for the maintenance window: other updates, new kernels and reboots, by default 03:00 to 05:00, not on weekends and not on public holidays in North Rhine-Westphalia (NRW).

Every run has the same structure. First Sentinel checks the server and records what is already red beforehand, then the package state, for larger interventions together with a backup of the configuration. After the update the same check runs once more, and only what is newly red in it counts as a failure.

If something goes wrong, Sentinel restarts stopped services; if that is not enough, packages and configuration go back to their previous state. If that fails too, it pauses this server’s automation until you approve it again, and alerts you, even at night; if that happens on a second server within 24 hours, automation stops everywhere. Afterwards every run is in the checksum chain of the audit log, with its time. That is not a certification, but it is proof.

If a serious case file comes up at night, for example a new account, a new sudo rule or a scheduled job that downloads a script from the internet, Sentinel preserves the evidence and notifies you. Then an AI, provided it is switched on and the daily budget is sufficient, reads the filtered extract and writes down what happened, which traces support that, what else is probably affected, what is still missing and which actions from the catalog it recommends, with a confidence level that it justifies.

The evidence goes in as data, never as an instruction. Malware that whispers sentences to the reading AI can distort the assessment, but it can never set a block, delete a file or trigger an intervention: the investigator has no tools, answers only in a fixed schema and may only make read-only follow-up requests. Every recommendation needs your approval.

Without an AI key, the rule’s fixed assessment stands, and a human decides.

How the AI works and what it never does →