Problem it solves
After an agent run completes, users and operators have no way to verify what actually happened, what data was accessed, or whether all actions were authorized.
When to use
After every agent run that touched external systems, accessed non-public data, or executed actions on behalf of a user.
When not to use
This pattern is always required when the execution pattern is used. There is no scenario where post-run audit can be omitted for agentic runs.
Governing principle
The audit trail is not a log. It is a governance record. It must be immutable, exportable, and tied to specific consent events — not just a list of API calls.
Required Components
Interaction Flow
Run completes or terminates
Whether the run succeeded, failed, or was aborted, the audit record is written.
Audit trail composed
Every action, consent event, tool call, and state change is assembled into the audit record in chronological order.
Impact assessment finalized
The Impact Assessment updates with the actual footprint of the run: what data was accessed, what systems were touched, what regulatory exposure was created.
Environmental impact logged
Compute cost, energy usage, and model calls are recorded in the Environmental Impact section.
Record available for inspection
The audit trail is accessible to the user and (depending on configuration) to operators and compliance systems.
Export available
The full record can be exported in a structured format for compliance, incident review, or archival.
Governance requirements
Audit records must be immutable after composition — they cannot be edited, filtered, or selectively deleted. Records must be retained per applicable regulatory requirements.
Accessibility notes
The audit trail interface must support keyboard navigation through individual events. Time-based filtering controls must be labeled. Export functions must not require mouse-only interactions.