AI Audit Log Chain of Custody: Forensic Integrity at the Request Boundary

At 09:42, a clinician's application sends a prompt to an LLM. Six months later, an investigator asks for the record, the identity behind the request, the policy that permitted it, and proof that nobody altered the response after it was written. A log line alone cannot answer that request. The organization needs a chain of custody for the record.

NIST SP 800-92 treats log management from collection through disposal. For AI decisions, I would add a fifth operational test: can an independent reviewer verify the exact request record presented in an inquiry against the record written at the decision boundary?

TL;DR

Capture the request record at the decision boundary, protect its write path, retain access history, and give an independent reviewer a repeatable verification process. The evidence must show who initiated the routed AI request, how the record reached durable storage, and which protected signing material validates the presented event.

The record that enters custody

Chain of custody begins at capture. The per-decision record should identify the authenticated user or agent and the application route. It should retain the timestamp, endpoint, policy version, data classification, outcome, and correlation identifier. Content handling must follow the organization's privacy and retention policy, which may mean retaining a protected reference or digest instead of full prompt text.

The AI audit log format guide details the field set. The essential point is provenance: a later reviewer must distinguish the person who asked for the decision from the service credential that transported it. That policy version records the rule that applied.

Capture has to occur where the decision path is visible. Application logs can describe a workflow step, while provider logs can describe API activity. Neither record automatically contains the complete identity and policy context. A request-boundary record brings those facts together before the application receives the model result.

A custody chain with evidence at each handoff

The chain has five checkpoints, each with a record that an auditor can inspect.

• Capture: The gateway or application component records the request context and creates an immutable event identifier.
• Write: A signing service or protected key signs the canonical event representation, recording the key identifier and timestamp used.
• Transfer: The event is transmitted over an authenticated channel, with a receipt or delivery acknowledgement linked to the event identifier.
• Storage: An append-only store enforces retention, records read access, and prevents ordinary application writers from changing historical events.
• Verification: A separate process retrieves the event, validates the signature and any chain checkpoint, and records the result.

This pattern replaces a vague claim of "tamper proof" with artifacts a reviewer can request. An inquiry team should be able to retrieve the event and signature result. It also needs the storage-access history and retention rule. The system description must explain who could write or read each component.

Cryptographic integrity and operational independence

Digital signatures can show that an event representation validates against public verification material. Hash chains or periodic Merkle-tree checkpoints can expose deletion or reordering within a window. Their value depends on protected signing material, trusted time, canonical record formatting, and verification outside the store that holds the event.

A writer that can replace an event, re-sign it with accessible signing material, and alter the verification history leaves the reviewer with an assertion rather than independent evidence. Separate the signing authority from log-store administration. Give the verification role separate access.

Custody designs also need a protected and auditable time source. Record the application timestamp and the storage receipt time. Include the signature or checkpoint time where the implementation has one. A single client-supplied timestamp provides weak evidence when a dispute turns on event order.

Retention and deletion evidence

Retention is a custody requirement as well as a privacy requirement. The current text of the EU AI Act requires providers to keep automatically generated logs for at least six months under Article 19, while Article 26(6) places the corresponding deployer retention duty on deployers of high-risk systems under their control. Other regimes and contracts can impose longer periods.

Create a retention schedule per record class, then preserve two proofs: the policy that selected the retention period and the log-store event showing the record remained available until that period ended. When deletion is required, retain the deletion evidence permitted by the applicable privacy and security policy. Retention without retrieval testing is paperwork. Run a sample retrieval before a regulator's deadline turns it into an incident.

The inquiry package

A useful inquiry package contains the decision record, signature or hash-chain verification output, storage-access trail, applicable policy version, model endpoint record, and an explanation of the custody architecture. The AI audit log immutability guide covers storage and retention choices, while the EU AI Act Article 12 logging guide explains why traceability has to connect back to the system's operating context.

The package should be reproducible by someone outside the operating team. Give the reviewer a documented verification command or process, the public verification material, and the event identifiers needed to repeat the result. A PDF exported from a dashboard can support a narrative, but it cannot replace the underlying evidence trail.

DeepInspect

DeepInspect can observe HTTP AI traffic that passes between authenticated users or agents and LLM endpoints. At that boundary, it can bind the routed request to identity and policy context and create a per-decision audit record for the traffic it inspects.

Chain-of-custody integrity also requires the organization's signing and log-storage controls. Retention and verification need their own tested procedures. Local application execution and offline data handling need separate evidence paths because they do not necessarily traverse the LLM HTTP request boundary. Tool calls need a route-specific evidence design.

Let's talk today.