Forensics on agent logs: reconstructing what an agent did
After an incident, someone must answer a simple question: what did the agent do? The agent is gone — its session ended, its context was discarded, and the model will not remember. What remains is the log trail: audit entries, shell history, proxy logs, and tool output. Forensic reconstruction of agent activity is the discipline of turning that trail into a timeline. It is harder than reconstructing a human session, because agent activity is bursty, parallel, and driven by a context you can no longer inspect.
Start with a timeline, not a theory
Collect every timestamped source first: the audit log, the shell history of the session, tool server logs, and network egress logs. Build a unified timeline sorted by timestamp, with each source’s entries in its own column. Discrepancies between columns are where the interesting findings live: a command that ran with no corresponding credential resolution, or a network connection with no corresponding command. Work outward from the timeline; do not start from a hypothesis about what the attacker wanted, or you will only find what supports it.
Follow the credentials
The central question in agent forensics is which secrets the agent held. If a credential broker or secret manager logged resolutions, you can reconstruct this precisely: every resolution event names the secret and the requesting session. Correlate those events with the commands that followed. A credential resolved and never used is a near miss; a credential resolved and used is the core of the report. When resolution logging is missing, you are left guessing from shell history and environment snapshots — which is why log design matters more than forensic technique.
Distinguish the model from the tool
An agent did not decide to run a command the way a human does; its context — including prompt injection and tool output — shaped the call. Forensics cannot read the model’s context after the fact, but the logs can record its inputs: the prompt, the tool outputs fed back, the exact command strings. Logs that capture the command and its result let you state facts: this tool was invoked, with these arguments, at this time. Separating what the agent did from why it did it keeps the report honest.
Beware the gaps
Agent logs have characteristic gaps. Output may be truncated or redacted, concurrent tool calls interleave, subshells escape the session boundary, and log rotation can silently drop events. When a gap matters, say so in the report. A reconstruction that flags its missing pieces is more credible than one that papers over them.
Evidence worth defending
The forensic value of a log is decided long before the incident. Append-only storage, timestamps, actor identifiers that separate agent from human, and a rule that secret values never enter the log: those properties are what make reconstruction possible. A credential broker designed for agents, such as trustless (https://github.com/ikkun1222/trustless), writes the audit events forensics needs — resolution, injection, denial — as append-only JSONL entries that never contain token values, so the “what did the agent do” question has an answer grounded in data.
Write the report for the reader
Close with a timeline, the credentials exposed, and the commands executed, each tied to evidence. Leave speculation in a clearly marked section — or leave it out entirely.
If you had to reconstruct your last agent session from logs alone, which events would you find, and which would be missing?