How it works

Remediation flow

Every change goes through the same steps. None of them can be skipped from the console.

plan ──▶ dry run ──▶ approval ──▶ signed job ──▶ checks on the host ──▶ change ──▶ verification ──▶ result
                                                                                        │
                                                                                        └─▶ rollback if needed

#1. Plan

A plan says what should change on which hosts: for example "upgrade openssl to the latest security version on these 12 hosts". It is created by Fix, Fix selected, Fix all, an attack-path breaker, an autopilot rule, or by hand. Only operators, admins and owners can create plans.

Each job uses one typed action with checked parameters: package.upgrade, service.restart, firewall.restrict, os.update_kb, and so on (the full list is in Local policy). There is no action that runs a command or script of your choice.

#2. Dry run

Each host checks the plan without changing anything: is the package available, which version would be installed, which dependencies come along, is the service there, would the local policy allow it, can a snapshot be made. The plan shows the result per host. A plan cannot be approved while a dry run is still running.

#3. Approval (four eyes)

A second person approves the plan, by default with a security key. The requester can never approve their own plan. The approval is bound to a fingerprint of the exact plan (the plan hash): any later change makes it lapse. See Approvals.

#4. Signing

The signing service is a separate component of SEK Systems that holds the signing key of your environment. It only signs a job when:

• a valid approval for exactly this plan exists;
• the kill switch of your environment is off;
• the job fits the pace limit: at most 10% of your active agents per hour and 25% per day.

SEK Systems sends the jobs when the maintenance window of the plan opens (or right away for "now").

Each job is signed for one host and has a validity window (24 hours by default) and a sequence number.

Large plans run in waves: a small canary group first, then the rest, with a stop when the failure rate crosses the threshold of your environment.

#5. Checks on the host

The agent accepts the job only if all of these hold:

• the signature is valid and comes from the key of your environment;
• the job is addressed to this host;
• it is not expired, not replayed (the agent remembers what it has seen), and the host clock is within 5 minutes;
• the kill switch is off;
• the local policy allows the action, the package or service, the time (local windows) and the hourly limit.

A job that fails a check is refused, with the reason, and nothing changes.

#6. Change, with health checks and snapshots

1. Baseline: the agent runs the host's health checks (HTTP, TCP, service) and records the result.
2. Snapshot: where possible and allowed (allow_snapshots), a snapshot of the root volume: LVM, ZFS, btrfs or Windows VSS. Not when free space is below snapshot_min_free_pct.
3. Change: the action itself, with the system's own tools (apt, dnf, zypper, apk, pacman, Windows Update, winget, msiexec, systemctl). A running package installation is never interrupted halfway, also not by a cancel or the kill switch.
4. Verification: the health checks again, and a check that the intended state was reached (for example the package is at the expected version).

#7. Result and rollback

If verification fails and the plan uses automatic rollback, the agent restores the previous state where it can. The agent signs its result, sends a new inventory, and the finding is updated.

#Rollback

What can be rolled back automatically, and what not:

The job result rolled_back means the previous state is back; rollback_failed means the host needs your attention.

#Autopilot

For routine updates you can let SEK Systems create plans by itself, with autopilot rules (Settings → Autopilot). The guardrails are fixed:

• each rule is approved by two admins with their security key, and the approval is valid for 90 days;
• only package.upgrade and Windows updates;
• always in a maintenance window, with health checks, automatic rollback and snapshots where possible;
• one canary host first, then a waiting time before the next wave, and a pause at the first failure;
• limits per plan and per day.

Autopilot plans still go through the signing service and the local policy of every host.