Approval Gates is the control layer that decides what SITEY is allowed to do on its own and what has to wait for a person. Automated remediation stops at a defined point, an authorized approver sees the exact job that is about to run on the exact machine, and the decision is written to an audit record with a name, a timestamp and a target.
The problem
The moment you automate remediation, you inherit a governance question: who said this script could run on a production server? In most teams the answer lives somewhere the system cannot see. Approval happens in a chat thread, a reply to an email, or a verbal go-ahead in a stand-up, and the tooling has no idea any of it happened.
That gap produces three recurring failures.
Someone approves a described fix, then the script is edited, regenerated or applied to a wider set of hosts.
If the approve button, the chat command and the API endpoint are each guarded by hand, one of them eventually gets missed, and any account with a session can trigger fleet-wide changes.
When an auditor or an incident review asks who authorized a specific change on a specific host at a specific time, the evidence is a screenshot of a conversation.
The usual reaction is to switch the automation off and go back to manual patching, which trades one risk for a slower one. Approval Gates exists so you can keep the automation and still hold the brake.
How it works
Gate 1 stops the pipeline before anything executes
The autonomous pipeline is allowed to run discovery, false-positive analysis, diagnostics on the endpoint and remediation script generation. It then stops. The work is packaged as a patch batch in state pending approval, and nothing is dispatched to any agent until an authorized account approves that batch. On approval, SITEY first prepares the snapshot chain so the rollback point is created before the change, moves the workflow to the running phase, stores the approver’s identity on the workflow, and writes a Gate 1 approved entry to the autonomy log.
You approve a job, not a summary
The batch view lists every sub-job it contains: the target agent, the operation, its category, and where the script came from, reused from a previously learned script, adapted from one, or newly generated.
Opening a job shows the remediation script itself. Each job can also be approved or rejected individually, or cancelled while the batch has not started, or scheduled into a maintenance window instead of running immediately.
If a job has no remediation script yet, the approve action stays closed and the screen tells you so. You cannot approve an empty promise.
Risky AI actions stop in the conversation
The same principle applies to the AI assistant. Eighteen of its write-capable tools are classified by risk: creating a patch job, running a remediation script on an agent, applying a learned script in bulk, proposing a batch rollback, changing a vulnerability’s status, emailing a vendor. A risky tool is not executed unless it is explicitly approved. Instead the chat renders an approval card showing the tool, its arguments and its risk level, with approve and reject next to it.
Two checks run in order: the server-side role check first, which the browser cannot influence and cannot be disabled, then the user’s approval. Tools that approve or reject patch jobs additionally require the approver role, so a client cannot talk its way into self-approval.
The autonomy level decides how far the pipeline runs unattended
Each autonomy policy carries a level, off, diagnose only, until Gate 1 (the default), or full auto, and is scoped by severity, tags and agent groups. So you can leave low-severity findings on a longer leash while critical changes to domain controllers stop for a human, without running two different processes.
An optional in-loop mode, switched on by a server-side environment setting rather than a panel toggle, goes further and pauses the agent loop itself before it applies a remediation, changes a configuration or schedules a reboot; the pending item appears in the autonomy approval queue with the tool, its arguments and the reason. Approving it consumes a one-time token tied to those exact arguments and resumes the loop; rejecting it closes the workflow as rejected by operator and hands the finding to a person.
Every decision becomes a record
Approvals, rejections and cancellations are written to the autonomy action log with the approver’s user ID and the affected vulnerability, and a structured comment is added to the vulnerability itself. Task-level approval chains keep their own history: chain, step number, who acted, what they did, the comment they left and when. Nothing is reconstructed later from memory.
What you can do
Hold every automated remediation at a named gate until an authorized account approves the batch, with the rollback snapshot prepared before the change is applied.
Read the actual remediation script, the target agent and the operation type before you approve, and see whether the script is newly generated or one your environment has already run successfully.
Approve or reject individual jobs inside a batch, cancel a batch that has not started, or push a job into a maintenance window instead of running it now.
Restrict approval to a single defined role set, administrator out of the box, enforced identically on the API, the panel and the assistant’s chat commands, and failing closed when the role cannot be read.
Require explicit approval for risky AI actions, with the tool name, arguments and risk level shown before anything runs.
Set a different autonomy level per policy, so severity, tags and agent group determine how much stops for a human.
Build multi-step approval chains on tasks, with a named approver list per step; the task moves to pending approval and only reaches approved after the final step.
Work a personal queue of the approvals waiting on you, with priority and step position, and add a reason when you reject.
Produce a per-decision audit trail that names the approver, the action, the comment and the timestamp.
Who it is for
Hold the approver role and carry the operational risk of a change window; they are the people who need to see the script, not a description of it.
Use the pending queue to move confirmed findings forward without needing rights to execute changes themselves.
Decide the policy: which severities may run unattended, which must stop, and who is allowed to release them.
Read the decision log to see who authorized a given change, on which asset, and when.
Use multi-step chains when a fix needs sign-off from more than one owner.
Why it matters
An approval gate is what makes autonomy adoptable. Teams do not refuse automated patching because the scripts are wrong; they refuse it because no one wants to be the person who let an unreviewed change onto a production fleet.
A gate that names the approver, shows the exact payload and records the decision turns that objection into a defined responsibility.
It also removes the slowest part of most remediation cycles. The delay between “we know the fix” and “the fix is applied” is usually spent chasing authorization across channels. When the approval lives on the job, the approver opens one screen, reads the script, and releases it, and the pipeline continues by itself through execution and retest.
Finally, it turns change control into a by-product of doing the work. The record is written as each decision is made rather than reconstructed afterwards: what was going to run, on which asset, who released it, when, and what happened next. It is kept in the operations log and can be filtered by action and time window when someone asks.
Works with
- Patch Management. Where batches and jobs are reviewed, approved, rejected or scheduled.
- Autonomous Operations, sets the autonomy level per policy and exposes the pending approval queue and kill switch.
- User Management & RBAC. Defines which roles may approve, enforced on every path.
- AI Operations Log, the log of gate decisions and autonomous steps, filterable by action and time window.
Frequently asked questions
Can I turn the gates off and run fully automatically?
Yes, within limits. A policy set to full auto can run the pipeline through to verified closure without a human release, but the level is not the only check. Each job is classified into a risk tier first, and operations that touch firewalls, reboots, domain settings or credentials, along with anything the classifier cannot place, fail closed to a human gate even under full auto. Changes that do qualify still have to pass a canary rollout cohort before they widen. Because the level is also set per policy and scoped by severity, tags and agent group, most teams run full auto on a narrow, well-understood class of findings and keep everything else stopping at Gate 1.
Can someone bypass the gate through the AI assistant?
Not by design. The approve and reject operations available in chat run the same role check as the HTTP endpoints, read from a single shared definition, and deny the action when the role cannot be determined. Risky AI tools are blocked until approved, and the role check runs before the approval check, so client-side approval alone is not enough.
What happens to the rollback point after a fix is verified?
After the retest confirms the fix, the workflow enters a closure step that dispatches the snapshot deletion and records who authorized it, alongside a comment on the vulnerability. In the autonomous pipeline this closure completes automatically once verification passes, under both the until Gate 1 and full auto levels, and the deletion is still written to the log with an approver named. A role-gated API endpoint is available if you prefer to confirm the cleanup explicitly instead.
Who can approve, out of the box?
The approver role set is defined in one place and currently contains the administrator role. Widening it, for example to internal penetration testers, is a single change in that definition, and it then applies to the batch endpoints, the job endpoints, the closure step and the chat commands at the same time.
If you are weighing automated remediation and stopping at the governance question, this is the module that answers it: the automation runs, and a named person still decides when it touches production. See pricing for the self-hosted licence. You install SITEY in your own infrastructure, and your vulnerability and approval data never leaves it.