When software fixes vulnerabilities on your servers without a human pressing the button, one question decides whether you can keep using it: can you prove exactly what it did? The AI Operations Log is the answer. Every AI-driven remediation and diagnostic operation the endpoint agent carries out is written as a structured record: the command that ran, whether it succeeded, its captured output, how long it took, and the risk level of the operation. The record is written to disk on the endpoint itself first, then shipped to your own server.
The problem
Automation without a record is a liability. The moment an autonomous system touches production, your team inherits a set of questions it cannot answer from memory:
- A service stopped responding at 03:14. Did the remediation run touch it, or is that a coincidence?
- An auditor asks for evidence that a specific CVE was remediated on a specific host on a specific date. Where does that evidence come from?
- The same fix has failed on the same machine four times this month. Nobody noticed, because each failure was a separate ticket closed by a separate person.
- A change-control board wants to know what commands ran with elevated privileges last quarter. The honest answer is “we would have to reconstruct it”.
Without this record, the alternative is reconstructing history from scattered OS event logs, shell history and half-remembered chat threads: usually during an incident, under time pressure, with the evidence already rotated away.
How it works
- The agent writes the record before it reports anything
The endpoint agent wraps the AI-driven remediation and diagnostic jobs it executes. When the operation finishes, it writes one JSON object to a local JSON Lines file on that machine, before any network call. The record carries a UTC timestamp, the operation type, job ID, vulnerability ID, CVE, the action taken, the command string that was executed, an exit code field, summaries of standard output and standard error, the duration in milliseconds, the status, the risk level, a decision-reason field, and the platform and hostname it ran on. If the network is down, the record still exists.
Two details are worth stating plainly rather than glossing over. The exit code field records the outcome of the operation as a whole, success or failure, while the individual return codes of the commands inside it are preserved in the captured output. The decision-reason field is filled in when the dispatching job supplies a reason, and is always filled in for the suppressed duplicates described below.
Risk level is assigned by operation type, not guessed afterwards
Each class of change carries a fixed risk level defined in the endpoint agent, so a firewall change is never quietly filed alongside a read-only diagnostic:
| Operation type | Risk level |
|---|---|
| Windows firewall rule | CRITICAL |
| Windows registry fix | HIGH |
| Windows / Linux service disable | HIGH |
| Remediation script | HIGH |
| Config fix | MEDIUM |
| Linux package update | MEDIUM |
| Diagnostic script | LOW |
These are the levels defined in the Windows and Linux agents for the operation types each one supports. Any operation type outside this list is recorded at MEDIUM.
- Non-events are recorded too
A log that only records what happened is half a log. When the agent’s idempotency cooldown suppresses a job, the same operation on the same target within the previous two minutes, that suppression is written as its own record, under its own operation type, with a skipped status and the reason. Refusals are recorded as well: when the agent refuses to disable a protected security service, the operation record carries a blocked marker and the refusal reason. You can see what the system chose not to do, which is often the more interesting half.
- Failures produce a written post-mortem
When a remediation fails, the agent additionally writes a Markdown note into a dev_notes folder on the endpoint containing the job ID, the operation type, the exit code and excerpts of standard error and standard output, tagged for later retrieval. The context needed to diagnose the failure is captured at the moment of failure rather than reconstructed days later.
- Upload is authenticated, and the endpoint keeps the first copy
On each agent cycle, roughly ten minutes apart by default, the agent finds log files it has not yet confirmed as delivered and posts them to your server, authenticated with that agent’s own secret. An agent the server does not recognise, or whose secret does not verify, is rejected outright. The server stores each batch under a per-agent, per-day file and stamps every line with the time it was received and the source filename it came from. On the endpoint, files older than 30 days are pruned and a total size ceiling is enforced, but a file that has not been confirmed as uploaded is never deleted, regardless of its age. The endpoint’s own file is written first and remains the first-hand copy, so a server outage costs you nothing but a delay.
What you can do
Follow an AI-driven change back to the vulnerability and job that triggered it, using the vulnerability ID, CVE and job ID carried on the record.
See the command string the agent executed together with the captured output of the run. For script-based operations the record also carries the job payload that defined the script.
Show that a given CVE was acted on, on a given host, at a given time, with a recorded outcome.
Cooldown suppressions are written under their own operation type with a skipped status, and a refusal to touch a protected security service is marked as blocked on the record.
Group records by vulnerability ID or CVE, so the same fix failing repeatedly on the same host becomes visible in the data.
Read the millisecond duration recorded on the operation types that report it.
Feed the records into your existing SIEM, log platform or scripts using your own collector: they are JSON Lines on your own filesystem, one self-describing object per line, with no proprietary format in the way.
The files sit on your server, under your own backup and retention policy.
Who it is for
SOC analysts investigating whether an observed change on a host was the platform or an attacker. System administrators who need to know precisely what ran on their servers overnight. CISOs who have to be able to say, in front of a board, that autonomous remediation is accounted for. Compliance and audit officers who need supporting change evidence for reviews such as ISO 27001, PCI DSS, SOC 2 or BDDK; the module produces raw operation records rather than framework-specific reports. Incident responders building a timeline, who need to rule the platform’s own activity in or out early.
Why it matters
Autonomous remediation is only adoptable if it is accountable. Most organisations that stall on automated remediation stall for a governance reason, not a technical one: nobody will sign off on software making privileged changes it cannot fully account for afterwards. A per-operation record of command, outcome, timing and risk class converts that objection into a reviewable artefact.
The time saving is concrete. Reconstructing “what changed on this host and when” from OS event logs can consume hours of an engineer’s day per incident, and often ends inconclusively because the evidence has already rotated. Here the reconstruction is already written, organised by agent and by day, and it names the vulnerability and the job behind each change, which raw OS logs do not.
Because failures, refusals and suppressed duplicates are all preserved, the log becomes a factual basis for tuning: which operation types genuinely succeed in your environment, which hosts consistently resist a fix, which guardrails fire most often. That is the difference between automation you tolerate and automation you can steadily widen.
Works with
- Autonomous Operations, the engine that decides and dispatches the work this module records.
- Patch Management, the jobs whose execution produces these records; job IDs tie the two together.
- Agent Management: the endpoint agents that generate and upload the records, and the secrets that authenticate them.
- Approval Gates, the controls that decide which high-risk operations reach an endpoint at all.
Frequently asked questions
Which operations appear in this log?
The AI-driven remediation and diagnostic jobs the endpoint agent executes: diagnostic scripts, remediation scripts, configuration fixes, service disables, and registry and firewall changes on Windows, plus package updates on Linux. Snapshot operations and conventional patch installation jobs are tracked through Patch Management rather than through this module.
Does any of this data leave my network?
No. Records are written on the endpoint and uploaded to the SITEY server running in your own infrastructure. Nothing in this module transmits operation data outside your environment. License activation is a separate function of the platform and is the only part that communicates with us.
What happens if the server is unreachable when an operation runs?
The record is written to the endpoint’s local file first, so it exists regardless of connectivity. The agent retries on each subsequent cycle and only marks a file as delivered once the server confirms receipt. Files awaiting delivery are exempt from the endpoint’s age-based cleanup, so a long outage does not silently discard history.
How long is the history kept?
On the endpoint, log files are pruned after 30 days with a total size ceiling, but only once they have been confirmed as uploaded. On your server, the uploaded files are plain files under a directory you control: retention, archival and backup follow your own policy rather than one we impose.
Can I feed these records into my SIEM or log platform?
Yes, using your own collector. Records are stored as JSON Lines, one complete object per line, organised per agent and per day on your server’s filesystem, in a directory you configure. Any collector that can tail a file and parse JSON can consume them, and no export step or intermediate format is required. This module does not ship a prebuilt connector for a specific SIEM product; you point your existing collector at the directory.
Automation you cannot audit is automation you will eventually switch off.
The AI Operations Log is what lets SITEY run unattended and still stand up to a question from an auditor, a board or an incident review. See what a full deployment includes on the pricing page.