Agent audit trails must answer: who acted, for whom, with what authority

When an agent in a regulated environment closes an account, files a report, or moves money, the question that eventually arrives is never just "what happened?" It is three questions fused together: who acted, on whose behalf, and under what delegated authority. "The agent did it" answers none of them. If your architecture can't produce that accountability chain on demand, you don't have an audit trail — you have logs.

The gap starts with identity. Every agent action carries a dual identity — the agent's own identity and the human principal's delegated identity — and most systems collapse the two into a single service account. That collapse is precisely the accountability gap: when the agent's token is the app's token, you can prove the system acted but not who authorised it. The emerging fixes are explicit about the chain: OAuth identity chaining with nested act claims for multi-hop delegation, and Human Delegation Provenance's Delegation Provenance Tokens — cryptographically signed, scope-bounded, time-limited authorisation records that accompany every action. When an orchestrator delegates to a sub-agent, the token passes with reduced scope, producing an auditable delegation tree instead of an unattributable fan-out.

Evidence, not just events

The second half of the chain is evidence quality. A legally sufficient agent audit trail has four properties: completeness (every consequential action captured), integrity (tamper-evidence via hash chaining, Merkle trees, or WORM storage), temporal accuracy (timestamps from a verifiable source), and reconstructability (the log supports full replay of the decision sequence). This is no longer optional posture: EU AI Act Article 12 mandates automatic logging for high-risk systems, with Annex III enforcement from August 2026 and penalties reaching €15M or 3% of turnover. Ordinary application logs — mutable, co-mingled, retention-by-accident — fail all four properties.

Here is the part teams learn the hard way: this chain cannot be reconstructed after the incident. Three structural reasons. Tool call opacity — standard API logs record that a tool was called, not the semantic intent or the data it touched. The memory audit challenge — a multi-session agent accumulates state across interactions, and per-session logs fragment the causal chain. And versioned operational state — liability reconstruction needs the model version, tool set, and configuration as they were at execution time, which nobody snapshots retroactively. If provenance wasn't attached to the action when it happened, no amount of forensic effort recovers it. The same logic that makes event sourcing worth its complexity when replay is the feature applies: here, replay is legally mandated.

The honest tension is that maximal capture collides with other obligations. GDPR's right to erasure sits awkwardly against seven-year retention floors — crypto-shredding is the usual reconciliation, and it takes real engineering. Chain-of-thought traces raise a genuinely unsettled question about legal discoverability; logging every reasoning token may create liability rather than reduce it. So "record everything forever" is not the thesis. The thesis is narrower: for every consequential action, the principal, the delegation, the agent identity, and the immutable evidence must exist by construction. The AEPD's Rule of 2 gives a workable trigger for the strictest treatment — untrusted external input, plus sensitive personal data, plus an individual-affecting decision means a human signs before execution, and the signature enters the chain.

Design the accountability chain the way you design the schema: first, because everything downstream depends on it. Retrofit projects here don't produce audit trails. They produce expensive apologies.