AI Remediation Planning is the step where a confirmed finding becomes an executable fix for the specific host it was found on. SITEY classifies the vulnerability, runs a read-only diagnostic on the live machine when that host runs the SITEY agent, and generates an OS-aware remediation plan: with a plain-language description, a risk warning, the affected services and a verification command. That waits in an approval queue until a person releases it.
The problem
A scanner report ends exactly where the real work begins. “Upgrade to the vendor-supplied version” tells an engineer nothing about the machine in front of them: which build is actually installed, whether the service is even running, whether the registry key exists, whether turning it off breaks an application that depends on it.
So somebody opens an RDP or SSH session, checks by hand, writes a PowerShell or bash snippet, tests it somewhere safe if there is time, and then repeats the whole exercise on the next twenty hosts. Commercial products with no published patch fall through the cracks entirely. Someone was supposed to email the supplier, and nobody remembers whether they did. When the same CVE reappears next quarter, the knowledge of how it was fixed lives in one engineer’s head or in a chat thread nobody can find.
The outcome is predictable: critical findings age in the queue not because the fix is difficult, but because writing it, checking it and getting it approved costs hours per host.
How it works
- Classification before anything is generated
Every finding first passes a deterministic classifier that reads the vulnerability name, CVE, description and the scanner’s own solution text. It looks for Windows KB and Microsoft bulletin identifiers, a list of known commercial vendors (Oracle, SAP, VMware, Citrix, Cisco, Fortinet, IBM and others), common OS and open-source components, and hints pointing at configuration, registry, service or firewall changes. Each match produces a category, a confidence score and a written reason you can read.
OracleSAPVMwareCitrixCiscoFortinetIBMThe AI model is only asked for a second opinion when the deterministic result is weak, confidence at or below 65, or “manual review”, and its answer is accepted only if it is more confident. Even then, its category, software type and confidence value are validated against a fixed whitelist before anything downstream uses them.
Category What SITEY does with it Auto-patchable Builds a patch job for the agent on that host, held for approval Configuration change Generates a configuration fix script, held for approval Vendor contact Creates no job; opens a vendor record for supplier name, e-mail and ticket ID Manual review Records the finding and its reasoning for the security team Compensating control Recorded for human handling rather than automated - Diagnosis on the live host
Before a fix is written for a single host, SITEY generates a diagnostic script and sends it to the agent on the affected machine. That script is validated in read-only mode, any write command blocks it, and it must end with an explicit verdict line of TRUE_POSITIVE, FALSE_POSITIVE or INCONCLUSIVE. SITEY waits for the result (90 seconds by default) and carries stdout, stderr and the exit code into the planning step as separately labelled channels, so “the setting is already secure” can be told apart from “that command does not exist on this host”.
LimitationThis step needs an agent registered for that host and an AI provider key configured on your account. If either is missing, or the agent does not answer in time, planning continues without diagnostic evidence, and the recorded status says which of those happened.
- A plan grounded in that host’s reality
Plan generation receives the diagnostic evidence, the agent’s OS profile and its capability limits (an old Windows Server is not handed a modern cmdlet), the machine’s software, service and port inventory, CVE enrichment from NVD, EPSS and the CISA KEV catalogue, category-specific engineering rules for registry, service, firewall, TLS, authentication, SSH and patching work, plus similar past fixes retrieved from your own knowledge base. Text that arrived from scanners or from diagnostic output is sanitized for prompt-injection patterns before it reaches the model.
- Typed plan, deterministic compilation, safety gates
For registry and service changes the model is asked for a typed plan, operations and parameters rather than hand-written shell, which SITEY compiles into PowerShell 5.1 on Windows or bash on Linux itself. Registry changes are the case that is enforced: if the model writes one as freeform script anyway, the request is retried with a plan-only instruction, and a malformed registry path is rejected rather than patched up. Every script then passes a blocklist covering disk formatting, registry key deletion, stopping EDR or event-log services, clearing event logs, reboots, encoded or downloaded code and disabling network adapters, plus a size limit and a shell syntax check. Reboots are forbidden outright; a service restart is the most a plan may do.
- Approval, dispatch and learning
The result becomes a patch job in pending approval. Nothing changes on a server until a user holding the patch-approver role approves it. If an active job already exists for the same host, vulnerability and job type, a duplicate is refused. When the work completes, SITEY records the outcome, writes the lesson into a pattern store keyed on CVE and software, and moves a successfully fixed vulnerability into the retest queue instead of silently marking it closed.
What you can do
Get a categorised, reasoned recommendation for any finding, including a clear “do not automate this” answer for proprietary software.
Run a read-only diagnostic on an agent-based host and read the raw output before deciding anything.
Generate an OS-specific fix script for Windows or Linux with a description, risk warning, estimated downtime, prerequisites, affected services and a verification command.
Dispatch one plan to a list of agents at once, skipping hosts that already have the same job open. The live diagnostic step runs for single-host requests, not for this bulk path.
Override the AI’s category deliberately when you know better, with the override recorded against your name.
Record vendor contact details, e-mail and ticket ID for findings only the supplier can fix.
A rejection is fed back as a negative signal so the same recommendation loses weight.
Review per-host and fleet-wide reports: success rate, category distribution, top hosts by volume and the number of learned patterns.
Track the token cost of every analysis and generation call.
Who it is for
Need to know whether a finding is real on that specific host before escalating it.
Would otherwise write the same PowerShell twice a week and roll it out by hand.
Want the model’s reasoning, the diagnostic evidence and the exact script in front of them before approving a change.
Need remediation to be a measurable process rather than a backlog.
Have to show an auditor who decided what, when and on what grounds.
Why it matters
The expensive part of vulnerability management is rarely the scan, it is the hours between “we know about it” and “it is fixed and verified”.
The expensive part of vulnerability management is rarely the scan; it is the hours between “we know about it” and “it is fixed and verified”. Writing a fix by hand for one host is an afternoon. Doing it across a fleet, with a paper trail of who approved what, is a week. This module compresses that into read-the-plan, check-the-evidence, approve.
It also changes the shape of risk. Every approved change goes through the same blocklist, the same syntax check and the same compiler, instead of depending on which engineer wrote it and how tired they were. Vulnerabilities in third-party products stop disappearing, because “contact the vendor” becomes a record with a ticket ID rather than a good intention. And the system gets cheaper over time: successful fixes become reusable patterns, failures become lessons the next generation attempt is explicitly told not to repeat.
Works with
- AI Triage. Decides whether a finding is real and worth fixing; its analysis is carried into the planning prompt, so the generator works from the same reasoning you read.
- Patch Management, receives the generated job and dispatches it to the agent on the target host.
- Approval Gates, the role-checked gate every changing job must pass before it runs.
- Retest & Closure, takes over once a fix succeeds, so closure is proven rather than assumed.
Frequently asked questions
Does anything run on my servers without approval?
Within this module, only the diagnostic. Diagnostic scripts are dispatched automatically because they are validated as read-only, any write command blocks them from being sent at all. Every script or job that changes a system is created in pending-approval state and requires a user with the patch-approver role to release it.
What happens when there is no patch available?
The classifier routes it to vendor contact instead of inventing a fix. No job is created; you get a record you can fill in with the supplier’s name, contact address, ticket ID and notes, and the finding stays visible as an open item rather than quietly failing an automation attempt.
What happens if a generated fix fails?
The failure is recorded against the vulnerability and the pattern that suggested it, so that recommendation loses confidence. On the next attempt, the exact stderr, exit code and the script that failed are given back to the model with an instruction not to repeat the same command, including the specific case where a command simply does not exist on that host.
Where does my data go?
SITEY runs in your own infrastructure and the findings, hosts, history and knowledge base stay in your database. Two kinds of call reach outside. The first is to the AI provider configured on your account: the classification and planning prompts, which carry the vulnerability details and the host context needed to write the fix, and the short query text sent to that provider’s embeddings API when SITEY looks up similar past fixes in your knowledge base. The second is CVE enrichment lookups against public NVD, EPSS and CISA KEV sources, which fall back to a built-in list when those are unreachable.
If your team is writing remediation scripts by hand today, this is the module that takes the first draft off their hands: with the evidence, the reasoning and the approval trail attached. See pricing to deploy SITEY in your own environment.