Chain-of-Custody in AI-Mediated Forensics

Forensic chain of custody was designed in an era when evidence meant a physical object — a hard drive, a piece of clothing, a printed document — that could be handled only by specific named individuals, each of whom signed for it. The principle transferred reasonably cleanly to digital forensics: a disk image is produced by a specific tool on a specific machine at a specific time, and the hash of that image is recorded immediately. From that point forward, the integrity of the digital evidence is verifiable. An AI that reads ten thousand log entries, correlates them across six enrichment sources, and produces a two-page investigation narrative has done something that no individual signed for. The inputs it received, the processing it performed, and the sources it weighted most heavily are not in the narrative. They are not in any log unless the infrastructure was designed to put them there. This article is about designing that infrastructure.

What Chain of Custody Means in the Digital Context

Chain of custody in digital forensics has three components: collection integrity (evidence was collected without modification from its source), storage integrity (evidence was not modified between collection and analysis), and access integrity (every instance of access to the evidence is logged with the identity of the accessor and the purpose of access). Casey (2011) identifies these three components as the minimum requirements for evidence to withstand adversarial scrutiny — in a legal proceeding, a regulator's inquiry, or an internal investigation review.

For conventional digital forensics, these components translate directly into technical practices: write-blocking during acquisition prevents modification at collection; cryptographic hashing before and after storage detects modification in transit or at rest; access logs with identity and timestamp record every query. When these practices are followed, the chain of custody is a verifiable record that can be examined by any party with legitimate access.

ISO/IEC 27035-1:2023 extends the chain-of-custody obligation to AI-assisted incident analysis by requiring that all evidence used in an incident investigation be traceable to its source and that the investigation process itself be documented with sufficient detail to support reconstruction and review. This requirement was designed for human-conducted investigations, but its plain meaning applies to AI-conducted ones: if an AI is the investigator, the evidence it used and the process it followed are subject to the same documentation requirement.

NIST SP 800-61 Rev. 2 (2012) specifically requires that organizations maintain a chain of evidence that covers not just the raw artifacts but also the tools and methods used to analyze them. When the tool is an LLM and the method is prompt-based synthesis, this requirement implies that the prompt, the model version, the input artifacts, and the output must all be logged as components of the chain of custody.

Three Custody Gaps in Autonomous SOC Pipelines

Autonomous SOC pipelines introduce three custody gaps that do not exist in conventional human-conducted forensic investigations. Each gap represents a point in the investigation chain where evidence integrity could be compromised without detection.

The context assembly gap occurs between the collection of raw artifacts and the assembly of the LLM's input context. Raw artifacts — event logs, network flows, endpoint telemetry, threat intelligence enrichments — are normalized, filtered, and combined into a structured context window before being submitted to the LLM. This assembly process may drop artifacts (filtering decisions that are not logged), modify artifacts (normalization that changes semantic content), or add artifacts (enrichments that introduce third-party data without provenance tracking). None of these transformations are necessarily improper, but if they are not logged, the chain of custody is broken at the assembly stage: a reviewer cannot determine from the LLM's output which raw artifacts it actually considered.

The synthesis gap occurs at the LLM inference step itself. The LLM receives the assembled context and produces an investigation narrative. This process is, in most deployed systems, a black box from the custody perspective: the specific portions of the context that most influenced the output are not identified, the model's internal processing is not logged, and the relationship between specific artifacts and specific conclusions in the narrative is not traceable. A narrative that says 'the process was launched by a known legitimate updater' cannot be verified post-hoc against the evidence that supported that conclusion, because the synthesis process does not record which artifacts drove each conclusion.

The dissemination gap occurs between the LLM's output and its eventual use in decisions, reports, or legal proceedings. Investigation narratives produced by AI investigators are often sent directly to ticketing systems, incident response coordinators, and management dashboards. At each handoff, the narrative may be excerpted, summarized, or reformatted — and the connection between the final report and the original AI output, let alone the original evidence, is progressively lost. A regulatory inquiry that arrives six months after an incident cannot trace a specific claim in a post-incident report back through the AI's output to the specific log entry that supported it.

Technical Controls: Closing the Context Assembly Gap

Closing the context assembly gap requires that every operation applied to raw artifacts before they reach the LLM context window is logged as a custody event. A custody event record for the assembly stage includes: the artifact identifier (a hash of the original artifact), the operation applied (normalization, filtering, enrichment, deduplication), the reason for the operation (specified in the assembly pipeline configuration), the before and after states if the operation modifies the artifact, and the identity of the assembly process that performed the operation.

When context assembly is pipeline-based — a series of transformation steps applied to a collected artifact set — each step should emit a custody event. The resulting custody log for a single investigation context may contain hundreds of events, one per transformation per artifact. This log is not read directly by humans during normal operations; it is stored alongside the investigation record and retrieved only when the investigation is challenged or reviewed.

Seshia et al. (2018) require that AI systems in high-stakes contexts have formally specified interfaces — defined inputs and outputs that are verifiable against their specifications. The custody log is the implementation of this requirement for the context assembly interface: it records precisely what was submitted to the LLM as its input, in a form that can be verified against the specification of what should have been submitted.

The context assembly custody log enables a specific type of forensic review that is otherwise impossible: an auditor can replay the investigation by re-submitting the logged context to the same model version and verifying that the output matches the recorded narrative. This replayability is the digital forensics equivalent of a chain-of-custody record that allows an examiner to verify that the evidence presented at trial is the same evidence that was collected at the scene.

Technical Controls: Closing the Synthesis Gap

The synthesis gap — the black box at the LLM inference step — is the most technically challenging to close, because LLM inference is inherently non-deterministic and the relationship between input and output is not directly interpretable. Three partial controls address the gap without requiring full interpretability.

Full input logging records the complete context submitted to the LLM at inference time, including the system prompt, the assembled artifact context, and any tool outputs or intermediate results. Combined with the model version and inference configuration (temperature, sampling parameters, any constrained decoding settings), full input logging makes the investigation partially replayable: re-submitting the logged context to the same model version with the same configuration will produce a statistically similar (though not necessarily identical) output. NIST AI 100-1 (2023) requires AI systems in high-stakes contexts to be explainable at the level needed to support audit and accountability; full input logging is the minimum implementation of this requirement for generative AI investigators.

Output anchoring links specific claims in the AI's narrative to specific artifact identifiers. This can be implemented by instructing the LLM (through the system prompt) to cite artifact IDs when making factual claims, similar to how a human investigator cites evidence. The citations create a traceable link between narrative claims and the artifacts that supported them. The citations are not complete provenance — the LLM may have been influenced by artifacts it did not cite — but they provide sufficient traceability for most audit and regulatory purposes.

Model version pinning records the exact model checkpoint used for each investigation inference call. This is required for replayability: a narrative produced by model version A cannot be replicated by model version B, even given identical inputs. Maintaining a registry of model versions used in production investigations, with their deployment dates and retirement dates, allows an organization to demonstrate which model produced a specific historical investigation narrative.

Technical Controls: Closing the Dissemination Gap

The dissemination gap — the progressive loss of traceability as the AI's narrative moves through downstream systems — requires controls at the output boundary of the investigation system. Every downstream recipient of the investigation narrative must receive it in a form that maintains its connection to the full custody record.

The primary control is a unique investigation record identifier (IRID) assigned to each AI-mediated investigation at the moment the inference call is logged. The IRID travels with the narrative through all downstream handoffs — in the ticket, in the incident report, in any management summary derived from the narrative. Any party with legitimate access can present the IRID to the investigation record store and retrieve the full custody record: the collected artifacts, the context assembly log, the inference input and output, and the model version. The IRID is the digital forensics equivalent of the physical evidence tag — a durable identifier that links the final processed evidence back to its original source.

Casey (2011) identifies auditability — the ability to reconstruct the entire investigation from its records — as the defining property of a forensically sound investigation. The IRID plus the full custody record implement auditability for AI-mediated investigations: given the IRID, the custody record can be retrieved and the investigation replayed.

Hadfield-Menell et al. (2017) demonstrate that AI systems operating in consequential contexts should preserve the ability of their principals to review and correct their outputs. The dissemination controls implement this principle: they ensure that the human principals at the top of the principal hierarchy can always retrieve the full evidence record behind any AI investigation narrative, regardless of how many handoffs and summaries have occurred downstream.

Legal and Regulatory Context

The legal and regulatory context for AI-mediated forensics is still evolving, but several existing frameworks establish relevant obligations. ISO/IEC 27035-1:2023 requires that incident evidence be preserved with integrity for the duration of any associated legal or regulatory proceedings — a requirement that explicitly applies to evidence in any form, including AI-processed summaries. NIST SP 800-61 Rev. 2 (2012) requires that organizations maintain a chain of evidence to support potential legal action, specifying that evidence must be properly labeled, protected, and documented from collection through disposition.

NIST AI 100-1 (2023) adds the AI-specific layer: AI systems used in high-stakes decisions must support explainability, accountability, and auditability. An AI investigator whose evidence handling does not meet the controls described in this article meets none of these three requirements for the specific decisions it informs: its evidence handling is not explainable (the context assembly process is not logged), not accountable (there is no signed-for chain of custody), and not auditable (the full evidence cannot be reconstructed from the output).

The practical risk is twofold. First, investigation findings produced without adequate custody controls may be excluded from or challenged in legal proceedings, leaving an organization without the evidentiary support it expected for enforcement or litigation decisions. Second, regulatory inquiries that demand documentation of how an investigation was conducted may find that the AI investigator cannot produce a satisfactory answer — not because the investigation was wrong but because its process was not recorded.

Limitations

The output anchoring control — instructing the LLM to cite artifact IDs — provides traceable links between claims and evidence but does not guarantee completeness. The LLM may have been influenced by artifacts it did not cite, and the absence of a citation for an artifact does not mean that artifact had no influence on the narrative. Organizations should treat output anchoring as sufficient for most audit purposes while acknowledging that it does not provide full provenance of the LLM's reasoning.

Model version pinning enables replayability under the assumption that the same model version will be available for replay at the time of the audit. In practice, model providers may retire versions or modify their serving infrastructure in ways that make exact replication impossible. Organizations should maintain their own copies of the model checkpoints used in production forensic inference, or contract for model version guarantees from their provider, if legal defensibility requires exact replication.

The controls described here address the custody chain for evidence used by the AI investigator. They do not address the accuracy of the AI's conclusions — an investigation that is fully auditable but substantively wrong is still wrong. Custody controls and investigative accuracy are complementary requirements; neither substitutes for the other.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

# Investigation Record Identifier (IRID) — AI Forensic Custody Schema

IRID = generate_uuid()  # assigned at investigation start, before first inference call

custody_record = {
    'irid':               IRID,
    'created_at':         utc_timestamp(),
    'investigator_model': {
        'model_id':       'llm-investigator-prod',
        'checkpoint':     'sha256:abc123...',  # exact model checkpoint hash
        'deployed_at':    '2026-08-01T00:00:00Z',
    },
    'alert_id':           triggering_alert_id,
    'artifacts': [
        {
            'artifact_id': sha256_of_raw_artifact,
            'source':      'edr-sensor-01',
            'collected_at': utc_timestamp(),
            'assembly_ops': [
                {'op': 'normalize', 'field': 'timestamp', 'result': 'UTC-converted'},
                {'op': 'enrich',    'source': 'ti-feed-01', 'added': 'ip_reputation'},
            ],
        },
    ],
    'context_hash':   sha256_of_assembled_context,  # hash of full LLM input
    'output_hash':    sha256_of_raw_llm_output,
    'artifact_citations': [
        {'claim': 'process launched by known updater', 'artifact_ids': ['abc123', 'def456']},
    ],
}

append_only_store.write(IRID, custody_record)  # written before narrative is disseminated

Glossary

Chain of Custody

The documented record establishing that evidence was collected without modification, stored securely, and accessed only by authorized parties — the mechanism that makes forensic evidence legally admissible and investigation findings auditable.

Context Assembly Gap

The custody gap between raw artifact collection and LLM context submission, during which transformations may be applied without being logged, breaking the evidence chain.

Synthesis Gap

The custody gap at the LLM inference step, where the relationship between specific input artifacts and specific output conclusions is not recorded, making the evidence basis for individual narrative claims untraceable.

Dissemination Gap

The custody gap between the AI's investigation output and its eventual use in decisions or reports, during which progressive summaries and handoffs lose traceability to the original evidence.

Investigation Record Identifier (IRID)

A unique identifier assigned to each AI-mediated investigation at the moment of inference logging, which travels with all derivative documents and resolves to the full custody record.

Output Anchoring

The practice of instructing an LLM investigator to cite specific artifact identifiers when making factual claims, creating a traceable link between narrative conclusions and the evidence that supported them.

Model Version Pinning

The practice of recording the exact model checkpoint, deployment configuration, and inference parameters used for each forensic inference call, enabling investigation replay and audit.

References

1. NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide
2. NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
3. NIST SP 800-207: Zero Trust Architecture
4. ISO/IEC 27035-1:2023, Information Security Incident Management — Part 1: Principles
5. OWASP Agentic Security Initiative: Agentic AI Threats and Mitigations (2025)
6. Casey — Handbook of Digital Forensics and Investigation (Elsevier, 2011)
7. Seshia et al. — Formal Specification for Deep Neural Networks (ATVA, 2018)
8. Hadfield-Menell et al. — The Off-Switch Game (IJCAI, 2017)
9. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems