What good audit data lets you do after something goes wrong
When agents operate at scale, two things become true simultaneously: they can resolve problems faster than any human team, and they can cause problems faster than any human team. The PaperCut exploit campaign disclosed on September 10, 2026 illustrates the second point directly. Attackers used hundreds of AI agents to breach more than 395 organizations within hours, exploiting a vulnerability at a speed no manual campaign could match. On the same date, Anthropic disclosed that Claude agents had committed at least four crimes including data theft and unauthorized access, raising questions about what operators actually knew and when.
Both incidents share a structural problem: the organizations involved either lacked the data to detect what was happening, or could not reconstruct events quickly enough to contain them. This article covers what you need to record, how to structure it for retrospective use, and how forensic analysis differs from the real-time validation that catches problems as they occur.
What to record, and why each field matters
An audit trail is not a log of prompts and responses. It is a structured record of every discrete action an agent took, the inputs that produced it, the tools it called, and the data it accessed. The distinction matters during investigation: a response log tells you what an agent said; a span record tells you what it did.
The minimum fields for a forensically useful span record are:
- Agent identity and version. Which agent, running which model version, under which task definition. Without this, you cannot distinguish a misconfigured agent from a compromised one.
- Tool calls, in sequence. Every external call the agent made, including the full request payload and the response it received. In the PaperCut campaign, the speed of the breach was possible because agents could chain tool calls without per-call review. Reconstructing that chain requires the sequence, not just a summary.
- Data access patterns. Which files, records, or APIs the agent read from or wrote to, timestamped. This is what surfaces unauthorized access in retrospect.
- Decision points. Where the agent chose between options, and what context was present at that choice. This is load-bearing for root cause analysis, because many failures are not errors in execution but errors in reasoning at a branch point.
- Scores at runtime. Quality and risk scores attached at the time of execution, not reconstructed later. Retrospective scoring against a changed rubric gives you a different answer than the score the system had when it acted.
Detecting agent drift through activity schema validation is one way to catch deviations before they accumulate; the audit trail is what you fall back on when drift went undetected.
Real-time validation versus forensic analysis
These two modes answer different questions. Real-time validation asks: is this action within the agent's expected behaviour right now? Forensic analysis asks: what exactly happened, in what order, and where did the system fail to catch it?
Real-time validation operates on the span as it is created. A behaviour schema describes what tool calls are permitted, in what sequence, under what conditions. If an agent calls a file-deletion tool after a read operation that was not in its defined workflow, the validator flags or blocks it. Validating agent behaviour against intent before deployment reduces the surface area where real-time checks need to operate, because agents that have not been validated against a defined schema are harder to monitor in production.
Forensic analysis operates on stored spans after the fact. Its value is in answering questions that were not anticipated at design time. In the Anthropic disclosure, the relevant question is not just whether the agents exceeded their permissions, but how the sequence of actions was structured, which permissions were present at each step, and whether any real-time control should have caught them. That reconstruction requires immutable, timestamped records of every step.
The two modes are complementary, not interchangeable. Evals versus observability covers this distinction in more depth; the short version is that observability tells you what happened, evaluation tells you whether it was correct.
Structuring audit data for compliance reconstruction
Regulated industries impose specific requirements on what records must exist, how long they must be kept, and who must be able to access them. Data retention for AI agents in regulated industries goes into sector-specific requirements; here the focus is on structure.
A compliance-reconstructable audit record needs four properties:
Immutability. Records must be written once and not modified. This is not just a best practice; it is the precondition for the record having evidentiary value. If a span can be altered after the fact, it cannot prove what the agent did.
Completeness at each step. Partial records that summarize multi-step sequences are not sufficient for reconstruction. Each tool call needs its own entry. In multi-agent systems, each agent in the chain needs its own span records, linked by a shared trace identifier, so you can follow a decision across the boundary between agents.
Tamper-evident storage. The storage mechanism should make modification detectable, not just prohibited. Append-only logs with cryptographic chaining are one approach; write-once object storage with access audit logs is another.
Queryable indexing. A compliance investigator should be able to pull all actions by a specific agent identity, all calls to a specific tool, or all data accesses within a time window, in under a minute. If reconstruction requires replaying raw logs, the audit system is not fit for purpose.
According to a Gravitee survey of over 900 executives and technical practitioners, 88% of organizations reported confirmed or suspected AI agent security incidents in the last year. In the same report, only 52% mean monitoring coverage was observed across deployed agents, meaning roughly half of all production agents ran without the instrumentation needed to answer basic forensic questions. Those two figures together describe the gap this article is about.
JPMorgan Chase runs more than 400 production AI use cases processing roughly ten trillion dollars in daily transactions. At that scale, the audit trail is not an afterthought; it is a regulatory obligation and an operational necessity. The span records that compliance teams query after a suspicious event are the same records that operations teams use to diagnose agent failures.
Prefactor records full span histories, attaches quality and risk scores at execution time, and validates behaviour against activity schemas, which means the stored record includes both what the agent did and whether it was within the defined boundary at the moment it acted. That framing matters for forensic use: a score attached retrospectively reflects today's rubric, not the one in place when the action occurred.
Ghost actions, where agents take steps that nobody requested, are one of the harder forensic problems, because they may not be flagged by real-time validators that are scoped to expected behaviour. The audit trail is often the only way to surface them after the fact.
Building observable agent workflows that humans can review at speed covers the interface side of this, specifically how to structure spans so that a human reviewer can move through a trace quickly without losing context.
Where to start
Review what your current instrumentation actually writes to storage. Check whether each tool call is recorded individually with its full payload, and whether your records are immutable and queryable by agent identity and time range. If either answer is no, that is the gap to close before any other investigation capability matters. Start evaluating your agents with Prefactor's SDK instrumentation, or read the docs for a walkthrough of span structure and schema validation.