What an on-prem pentest agent actually logs
4 min read
Ask a security team what they want from an automated tester and you will hear about findings, severity, and integrations. Ask what they need and the answer is different: they need to be able to say, months later, exactly what the tool did to their network and why.
That is the audit trail. It is the least visible part of an on-prem pentest agent and the one that earns the right to run unattended. Everything below is written from the operator's side of the console — what you can see, and what you should insist on seeing before you let anything scan your production range.
Every action leaves a line
A scan is not one event. It is thousands: an endpoint probed, a credential attempted, a header read, a path guessed, a finding recorded, a false positive discarded. Each one becomes a record in the trail, and each record carries the same fields.
| Field | What it holds |
|---|---|
ts | When the step ran, in UTC, with the timezone made explicit |
actor | Who started it — a person, a schedule, or a pipeline run |
target | The host, endpoint, or object in scope at that moment |
action | What was done, in the same vocabulary the tool exposes in its API |
result | How it ended, including the negative and the uninteresting outcomes |
evidence | A reference to the request and response pair — a pointer, not a copy |
edition | The scan profile and agent build that produced the event |
The last field matters more than it looks. Two scans of the same host on the same night can disagree, and the question that follows is always which build said what. If the trail cannot answer that, the disagreement cannot be resolved.
The reasoning line is part of the evidence
An automated tester that follows a fixed playbook produces a boring trail: the same sequence, over and over, in the same order. An agent that plans its own path produces something more useful and more fragile — useful because each step depends on what the previous step learned, fragile because a reader cannot reconstruct it from the actions alone.
So the trail records the reasoning in short form: what the agent observed, what it concluded, and why it chose the next step. One paragraph per decision, not a full transcript. Enough that a reviewer six months later can follow the chain from observation to finding without re-running the scan.
{
"ts": "2026-09-22T02:14:03Z",
"actor": "schedule:nightly",
"target": "10.20.4.11:443",
"action": "probe.endpoint",
"result": "finding.candidate",
"evidence_ref": "sha256:9f2c1ab4d0",
"reasoning": "service banner lists an unauthenticated admin route; confirm before reporting",
"edition": "profile=comprehensive agent=local"
}
Illustrative shape, not a schema. Field names follow your own log pipeline.
What the trail deliberately does not hold
This is the part that separates an on-prem agent from a hosted scanner, and it is a design constraint rather than a feature.
The trail does not contain your source. It does not contain credentials the agent used, or the payloads it read from your responses, or the rows a vulnerable endpoint returned. Those stay inside the boundary where they were found. What crosses into the log is a reference — a hash, a path, a record identifier — so that the evidence can be retrieved by someone with access, and never duplicated by someone without.
That choice costs something. An auditor cannot reconstruct the full attack from the log alone; they have to pull the referenced evidence from inside your environment. In exchange, the log itself is safe to ship to a SIEM, safe to hand to a third party during a review, and safe to keep for years. For most teams that trade is obviously correct. It is worth making explicitly rather than discovering later.
What you actually do with it
Three uses, in the order teams discover them.
Triage. When a finding looks wrong, the trail shows what the agent actually did before it concluded. Roughly half of disputed findings resolve here, without a re-run.
Incident forensics. A scan that broke something is an incident. The trail is the timeline: which targets were touched, in what order, with which profile, and what the result of each step was. Without it, you are reconstructing from alert noise.
Compliance evidence. A control that says every testing action is recorded is satisfied by the trail, exported on your schedule into the log platform you already run. The evidence is a byproduct of doing the work, which is the only kind of evidence that stays current.
The test to apply
Before you let any tool scan unattended — ours or anyone's — ask one question. If I asked what this tool did to my network between two in the morning and three, could I answer it in an hour, with evidence, without asking the vendor?
If the answer is yes, you have an audit trail. If it is no, you have a log viewer, and the difference shows up on the day you need it.