Learned Scripts is the memory behind SITEY’s automated patching. When the platform runs a script on an endpoint, the job finishes cleanly and the result passes the learning checks, that script is saved together with the vulnerability pattern it fixed and a running record of how often it has worked since. The next time a matching finding appears, the platform reuses proven code instead of asking a language model to write the fix again.
The problem
An AI remediation pipeline without memory is amnesiac.
The same registry hardening, the same service restart, the same package upgrade gets regenerated from scratch on every host, slightly differently each time. Three things go wrong: you pay for a model call on work you have already done, the output varies between runs so a script that was safe on Monday can come back subtly different on Thursday, and nothing in the system can tell you which fixes have a track record and which ones have quietly failed twice already.
Without a learned library
- Scripts live in a shared folder of PowerShell and Bash files, curated by whoever has time
- No success rate attached to any file
- No record of which vulnerability each script was written for
- No mechanism to pull a script out of rotation once it starts breaking machines
- The knowledge lives in one engineer’s head, and it leaves when they do
With Learned Scripts
- Every script is saved together with the vulnerability signature it fixed
- Success rate, failure count and usage history are tracked on every entry
- A script that starts failing is quarantined and stops being offered automatically
- Institutional memory that survives staff turnover
How it works
Search the library before calling a model
When the autonomy worker needs a diagnostic, remediation or verification script, it queries the learned library first. Candidates are matched against the target vulnerability using a weighted signature: CVE identifiers carry the most weight, followed by name keywords, port, service and source scanner. CVE comparison is anchored, so a script learned for CVE-2024-2119 cannot match CVE-2024-21193 as a substring. Results are ranked by a composite of similarity, success rate and usage history, and quarantined scripts are excluded from the query entirely.
Decide: reuse, adapt or generate
The match produces one of three outcomes, on fixed thresholds rather than model judgement:
| Decision | Condition | What happens |
|---|---|---|
| Reuse | Similarity 0.85 or above, success rate 0.80 or above, zero negative feedback | The stored script is used as written, no model call at all |
| Adapt | Similarity 0.60 or above, success rate 0.50 or above | The stored script is handed to the AI as context and edited for this host |
| Generate | No usable match, or the best match is quarantined | A new script is written from scratch |
Reuse carries extra gates before it is allowed: the script must not be quarantined, must have no recorded negative feedback, must match the agent’s operating system family, must pass the script safety validator again at execution time, and must have been used recently, within the last 180 days by default. A stale or untrusted entry falls through to adapt or generate rather than being trusted by default.
Learn only from clean successes
Not every successful job becomes a learned script. A curator sits in front of the write path and rejects results that succeeded for the wrong reasons: await timeouts, stalled executions, missing results, stale agents, and jobs flagged as network catastrophes. Firewall operations that ran without an explicit local port are refused outright, as are script bodies containing adapter-disabling or stack-resetting commands. Only diagnose, remediate and verify operations are eligible. Identical script bodies are deduplicated by SHA-256 hash, so repeat runs increment the counters on one record instead of flooding the library with copies.
Demote automatically when a script goes bad
Learning runs in both directions. When a job linked to a learned script fails, that script’s failure count rises and its success rate is recalculated, once the success rate drops below 0.35 with at least three failures, the script is quarantined and stops being offered. Separately, an operator can file explicit negative feedback against a script, which is stored with the free-text note and marks the script’s last outcome as reverted. The security assistant can also raise that report by itself when an operator complains about a recent job in conversation, using a built-in phrase list. Three negative reports quarantine the script.
Keep the lineage
An adapted script is stored as a new version pointing back at its parent rather than overwriting it. You keep the original, the derivative, and the success rate of each. So you can see whether the adaptation actually improved on what came before.
What you can do
The library is exposed through the platform’s learned scripts management API, which every operation below runs against:
List every script the platform has learned, with paging and filters for operation category (diagnose, remediate, verify), operating system, and active or quarantined status.
Retrieve the full script body of any entry before deciding whether to trust it.
View the exact vulnerability signature a script was learned against: CVEs, name keywords, port, service, scanner.
Success count, failure count, negative feedback count, computed success rate, total usage and last execution outcome on every entry.
Pull a script you do not trust out of all future matching, and bring it back later if it was pulled in error.
Log explicit positive or negative feedback against a script, with free-text notes attached to the originating job. Negative reports count against its standing, positive reports are kept as a record.
Read the last twenty feedback entries and every derived version in a single detail response.
Remove a script so it can never run again, although quarantine is usually the safer way to retire one.
Follow a script back to the job that produced it through its source job reference.
Who it is for
Get a reviewable record of the code the automation is running on their fleet, and a direct way to pull any of it out of rotation.
Stop re-deriving the same containment steps for findings they have already handled once.
Get a visible measure of which remediations actually hold and which keep coming back.
Get institutional memory that survives staff turnover.
Why it matters
Reuse is the cheapest and most predictable path the platform has. On a confident match it skips the model call entirely and executes code that has already succeeded on your infrastructure, which removes both the token cost and the generation latency from the critical path. Predictability matters more than the savings: the same vulnerability on the fiftieth host gets the same tested treatment as on the first, instead of a fresh variation.
The demotion path matters just as much. A remediation library that only grows becomes a liability, old scripts rot as your estate changes. Because failures and operator complaints feed back into the same success rate the matcher reads, a script that stops working stops being offered, without anyone having to remember to clean it up.
Works with
Learned Scripts is fed and consumed by the automation around it. AI Remediation queries the library before generating any fix. Patch Management executes the resulting jobs and reports the outcomes that raise or lower each script’s score. Autonomous Operations uses learned reuse as a step in its fallback ladder ahead of the primary model. Security Assistant is the path by which an operator’s complaint about a bad fix becomes recorded negative feedback, under the conditions described above.
Frequently asked questions
Could a script learned for one CVE be reused on an unrelated vulnerability?
CVE matching is anchored to whole identifiers and both sides of the comparison are tokenised before matching, specifically so that a shorter CVE string cannot match a longer one as a substring. Findings carrying multiple CVEs are handled as a token set rather than a single string.
What stops a destructive script from being learned?
Several checks run before anything is written. The result is rejected if the job succeeded under timeout or stall conditions, if a firewall operation ran without an explicit port, or if the script body fails the safety validator or contains adapter-disabling and network-reset commands. Reuse revalidates the script again at execution time, so a body that was learned before a validator rule tightened will not run under the new rule.
Can we stop a specific script from ever running again?
Yes. Quarantine removes it from matching immediately and the decision logic falls back to generating a fresh script instead. Quarantine is reversible and is usually the right choice, deletion removes the record itself and is not reversible.
Are learned scripts applied to machines without approval?
Reuse decides which script body is proposed, not whether it is allowed to run. A reused script is dispatched through the same patch job pipeline, and handled the same way, as a script the AI had just written for that host. Bulk application of a learned script across multiple agents is registered as a high-risk action that returns a proposal for a human decision rather than dispatching on its own.
Learned Scripts is included in SITEY and runs entirely inside your own infrastructure, the library of scripts your environment produces stays on your servers. See pricing for what a full deployment includes.