What an AI agent audit trail should contain
An AI agent audit trail should let a sceptical reader reconstruct a material action after the fact: which agent acted, under which declared configuration, with what authority, toward what outcome, and with what supporting signals. It is a reconstruction aid for due diligence, not a blanket statement about good behaviour. The trail should be complete enough to attribute actions, honest enough to label what each record actually supports, and lean enough to avoid storing raw customer payloads.
Identity and scope
Record a stable agent identity, the use case or task passport in force, and the named accountable human where one exists. Without identity and scope, later events cannot be attributed to the right actor or judged against the right boundary.
Scope should be declared in plain language: what the agent is for in this use case, which actions are allowed, which are prohibited, and who oversees what. Declared scope makes gaps visible. If an allowed action never produces a receipt, that is structural information about coverage, not proof that the action never occurred off the record.
The action itself
For each material step, capture at least:
- When it occurred (UTC timestamp)
- What happened, via a stable event type that survives exports and audits
- A short human-readable summary for readers who will not parse metadata
- Who acted: agent, system, or operator, as an explicit actor string
Prefer structured event types over free prose alone. "output_generated" plus metadata beats a paragraph that cannot be aggregated or compared across runs.
Materiality rules should be consistent. Either the operator classifies which actions are material, or the recording platform applies stable server-side rules. Ad hoc logging produces trails that look complete until a buyer asks for a specific action class and finds silence.
Authority and oversight
Note whether the step was autonomous, queued for human review, forbidden, or blocked. If an operator decided, record who resolved it and when. Authority without a trail is theatre; a trail without authority context is incomplete.
High-impact actions benefit from explicit gates: queue before send, threshold checks, or dual control. The trail should show whether the gate was used, not merely that the outcome occurred.
Configuration fingerprint
Bind each material event to a configuration fingerprint: model or runtime identity, tool allowlist hash, playbook version, decision-rights version, and deployment identifiers where available. Otherwise you cannot show which version of the agent took the action when behaviour changes between Monday and Thursday.
Configuration changes should emit their own events with old and new fingerprints. Silent edits destroy the value of every subsequent receipt.
Evidence level
Declare how each record was produced using exactly three levels: self_reported (self-reported), system_confirmed (system-confirmed), and operator_confirmed (operator-confirmed). The label tells readers who vouched for the line. Mixing levels without labelling them invites over-reading.
Self-reported entries are claims from the agent stack. System-confirmed entries carry an independent reference check. Operator-confirmed entries carry a named human acceptance for that step. None of these levels, alone or together, settles questions the trail was never designed to answer.
Integrity signals
Prefer append-only storage with tamper-evident linking so a missing or altered event is detectable. Hash chains, sequence numbers, and signed exports each help third parties check structural integrity without trusting a single database administrator.
Exportable Action Receipts help a reviewer validate a single claim offline: event type, authority status, evidence level, timestamp, chain position, configuration fingerprint, and signature when signing is enabled.
Integrity of storage does not imply completeness of submission. A perfect chain of three events does not show that a fourth event was never logged.
What to leave out
Do not store raw prompts, documents, secrets, or customer payloads in the trail unless you have an explicit retention regime and access control model for that data. Proof without payload: summarise and reference, do not dump.
Free-text that might appear on a public proof room should pass human review before publication. Structural fields can be public; narrative content often should not be.
Retention, erasure, and jurisdiction still apply to whatever you keep outside the trail. The audit record is not a substitute for data protection design.
What a complete trail still cannot show
Even a well-instrumented trail cannot, by itself, prove that unrecorded actions never happened, that scope was wisely drawn, or that outcomes were fair. Publish declared instrumentation and honest limits beside any buyer-facing export. See What an AI agent audit trail cannot tell you.
How Proofroom approaches this
Proofroom implements this model as hash-chained Action Receipts scoped to one agent doing one use case. Use case passports carry scope, allowed and prohibited actions, oversight, decay windows, and optional critical actions. Events stream in via HTTP or MCP; material actions receive receipts with evidence level, authority status, configuration fingerprint, and mandatory limitation notes.
The live proof room exposes structural fields publicly: event types, timestamps, chain integrity, coverage score, declared scope, configuration component names, and fingerprints. Reviewer tier adds full component values. Owner tier adds operational detail for signed-in operators.
Recording is fire-and-forget by default so evidence never blocks the agent's task path. Operators who need a durable write acknowledgement for specific steps can use require_ack on those actions. Completeness remains the operator's instrumentation responsibility.
Chain heads publish daily to a public anchors repository. Individual receipts can be checked with Ed25519 signatures. Walkthrough: /verify.
Proofroom's own internal agents use the same tables and controls as customer agents. Their trails are public examples of the same structural fields described on this page.