Autonomous Operations

Autonomous Operations is the control room for SITEY’s self-driving remediation engine. It is where you declare how much the platform may do without asking you: which machines are in scope, which severities qualify, how far a fix may proceed before a person signs off, and what must never be touched automatically. Every diagnosis, script, snapshot, patch, retest and rollback the engine then performs lands back here as a visible, auditable record.

The problem

Remediation is where vulnerability programmes stall. Scanning is cheap; fixing is not. A single finding costs an analyst a remote session, a handful of exploratory commands, a script written from memory, an apply, a re-check, and a ticket update. Multiply that by a few hundred open findings and the backlog only grows. The oldest criticals are still open months later, not because nobody knows the fix, but because nobody had the hours.

Teams that do automate usually swing to the other extreme: a scheduled script pushed fleet-wide, with no idea which host it touched, no snapshot to fall back on, and no independent proof the vulnerability actually closed. When it breaks a production database at 3am, automation gets switched off permanently and the team goes back to doing everything by hand.

What is missing between those extremes is a place to say precisely how much autonomy you are granting, to whom, and under what conditions, and a record that shows exactly what the machine did with that permission.

How it works

1. You write policies, not scripts

   A policy scopes autonomy by agent group, severity level and tag, and assigns one of four levels: off, diagnose only (investigate and report, and close a finding as a false positive when its confidence passes the threshold you set, but never change a host), until Gate 1 (diagnose, build a remediation plan, then stop and wait for human approval), or full auto (carry the fix through to verified closure). New policies default to “until Gate 1” on critical and high findings with snapshots required: the conservative setting, not the aggressive one. Several policies can coexist; when more than one matches a finding, the engine applies the policy that covers the highest severity tier.

2. A safety classifier caps what any policy can ask for

   Policy level is a ceiling request, not a guarantee. Before anything runs, each finding is classified against its host: an agent marked exempt drops the workflow to off entirely; a host marked critical is capped at diagnose-only; database and web findings are held at Gate 1 for a human by default, regardless of what the policy says. The reason for the cap is shown next to the finding, so nobody has to guess why the engine stopped.

3. A phase machine drives each finding, with watchdogs behind it

   Every autonomous finding becomes a workflow that moves through explicit phases: diagnosis proposed, diagnosis running, analysing, remediation proposed, remediation running, verification running, pending cleanup, closed. With only legal transitions permitted. A leader-elected orchestrator advances these on a timer, holding a database advisory lock so two servers can never drive the same finding at once. Separate watchdogs reclaim jobs an agent never picked up, park workflows whose host went offline and resume them when it returns, track hosts waiting on a reboot, and write a console alert when a human gate has been waiting past its SLA.

4. Every state-changing action passes an eligibility gate

   Read-only steps run freely. A mutating step is admitted only after it clears the effective autonomy level, the operation’s risk tier, the global kill switch, the host’s circuit breaker, canary wave membership, a blast-radius cap on concurrent changes, and the snapshot requirement, which the policy can either enforce strictly or allow to be waived when a snapshot cannot be taken. High-risk operation classes stay blocked unless you explicitly allowlist them on the policy. If a canary wave produces failures, the rollout halts itself and resumes only after a cooldown.

5. Verification decides the ending

   After a fix is applied, the engine re-tests independently rather than trusting the script’s exit code. Confirmed fixes close as verified. If verification shows the vulnerability still open, the engine can automatically raise a rollback job against the snapshot it took beforehand and hand the finding back to a human. If the fix failed for a fixable reason, a bounded self-heal retry produces a revised script; when the budget runs out, the workflow escalates to a human with its full reasoning trace attached.

What you can do

Who it is for

Why it matters

The cost of an open vulnerability is time. Autonomous Operations removes the human from the parts of remediation that do not need judgement, the investigation, the script, the apply, the retest, while keeping the human firmly in the parts that do: which systems are too important to touch, which change classes need a signature, and how wide a blast radius is acceptable. Because policy is declared in advance rather than negotiated per ticket, the same decision does not get re-litigated a hundred times.

Works with

• Approval Gates, the human checkpoints where an “until Gate 1” policy hands the decision back to you
• AI Remediation, generates the fix plan and script that the autonomous engine executes
• Patch Management, the job pipeline that dispatches every diagnostic, snapshot and remediation to the endpoint
• Retest & Closure, the independent verification that decides whether a finding closes or rolls back

Frequently asked questions

Can it change my servers without asking?

Only if you configure it to. New policies default to “until Gate 1”, which means the engine diagnoses and prepares the fix but stops for human approval before changing anything. Full autonomy is a deliberate setting, and even then the safety classifier keeps exempt agents, critical hosts, and, by default, database and web findings out of it.

What happens if an automated fix breaks something?

Destructive changes can be gated behind a snapshot, taken on the host before the change and retained for a configurable period; the policy decides whether a change may still proceed when that snapshot cannot be taken. If independent verification shows the vulnerability still open after the fix, the engine can automatically create a rollback job against that snapshot and hand the finding to a human, and a follow-up check records whether the rollback job actually completed and raises a visible alert if it did not. Concurrency caps and canary waves limit how many hosts can be affected before a failure halts the rollout.

Can I try it on a few machines before trusting it fleet-wide?

Yes. Scope a policy to a single agent group, nominate specific canary hosts to receive changes first, and cap concurrent changes to one. There is also an environment gate, switched on in server configuration, that restricts autonomy to hosts carrying the environment labels you list, such as test and staging. Untagged hosts are treated as production and stay out of scope.

How do I stop it immediately?

The dashboard has a global kill switch that halts autonomy, and a mutation-only pause that stops all changes while diagnosis and monitoring continue. The mutation pause can additionally be limited to specific agent groups. Both take effect on the next orchestrator cycle, and the watchdogs keep running so nothing is left silently stranded.

Autonomous Operations is included in SITEY and runs on infrastructure you own: the platform, its database, the action log and the agents all stay inside your network.

See pricing to get started, or begin at the most conservative setting, diagnose only, and widen the policy once you have seen the engine work on your own estate.