To reconstruct what an agent did, collect records from every layer, tie them together with a shared identifier, and order them on one clock. Start with the agent's identity, then tool calls, then approvals, then the downstream systems that actually changed. Do not rely on the agent's own account.
Why the agent's summary is not evidence
An agent can describe its own work inaccurately, or have been steered to describe it wrongly. Treat its explanation as a lead, not a record. The reliable sources are the systems it called, which keep their own logs.
Sources to pull, in order
| Source | What it shows |
|---|---|
| Identity provider or agent registry | Which identity, credentials, sponsor, scope |
| Tool or MCP server logs | Which tools were called, arguments, results |
| Approval records | Who approved what, and when |
| Downstream systems | What changed in databases, repos, cloud, email |
| Network and egress logs | Where data went |
| Model or application traces | What the agent was told and read |
OWASP's logging guidance says each record should capture when, where, who and what. If your sources do not include those four, note the gap before you start so you do not draw false conclusions.
Steps
- Fix the window. Start at the earliest suspicious event and move backward until activity looks normal.
- Pull the identity first. Everything else is filtered by it. If two agents shared an identity, say so, because this weakens every later conclusion.
- Normalize time. Convert all records to one time standard and note clock drift between systems.
- Join records with a correlation ID. If you have none, join by identity, target and time, and mark those joins as less certain.
- Build the timeline: time, actor, action, target, result, source. One row per event.
- Separate fact from inference. Mark each row as observed in a log or inferred from context.
- Find the trigger. Look at what the agent read just before the first odd action: a document, an email, a web page or a tool description. That is often where the instruction came from.
- Check downstream effects independently. A tool log may say a delete was sent, and the database log says whether it ran.
- Record unknowns. A list of what you could not determine is as valuable as the timeline.
Common gaps
Tool arguments were not logged. Logs rotated away before anyone looked. Several agents shared one account. Clocks disagreed by minutes. Logs sit on the same host the agent could write to, which raises doubt about integrity. Each of these is a lesson for the next version of your logging, so write them down.
Preserve before you analyze
Copy the relevant logs and configuration to a safe, read only location first. Analysis tools and cleanup steps can change evidence. Keep a note of who accessed the copy.
Use the timeline
A good timeline answers four questions. What did the agent access? What did it change or send? How did it start? Is it contained? It also feeds your breach assessment, since counts of affected records usually come from these downstream rows.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how events are recorded over time, and think about which fields you would need to replay them.
Safeguard offers asset discovery and compliance and evidence automation that support keeping these records in order. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Can I trust the agent's own summary?
Use it as a lead only. Confirm every claim in the logs of the systems it called.
What if there is no correlation ID?
Join by identity, target and time, and label those joins as lower confidence.
Sources
Last reviewed: 19 October 2026.
