Evidentiary Chain-of-Custody Governance

2. Summary

Evidentiary Chain-of-Custody Governance requires that all governance-relevant evidence generated by or about AI agent operations — including audit trail records, decision journal entries, configuration snapshots, telemetry data, model input/output pairs, and multimedia evidence — is subject to a documented, tamper-evident chain of custody from the moment of creation through storage, access, transfer, and eventual disposition. Chain of custody establishes who created the evidence, who has accessed or modified it, under what authority, at what time, and with what protections against alteration. Without chain of custody, evidence that is technically complete and well-structured may be inadmissible in regulatory proceedings, unpersuasive in litigation, and unreliable for internal investigation — because the absence of custody documentation creates reasonable doubt about whether the evidence reflects what actually occurred or has been altered after the fact.

3. Example

Scenario A — Contested Audit Trail in Regulatory Enforcement: A financial-value agent executes 2,340 customer transactions over a 6-month period. A regulatory investigation into 47 of those transactions requests the audit trail records. The organisation produces the records within 48 hours, and the records appear complete — timestamps, decision references, input/output pairs, and mandate authority citations are all present. However, the regulator's forensic examiner asks: "Who has accessed these records since they were created? Were they stored in a system with write access by the operations team? Is there a log of every access to these records?" The organisation cannot answer. The audit trail records were stored in a general-purpose database accessible to 14 system administrators. No access log exists for the evidence store. No integrity verification was performed between creation and production. The regulator applies an adverse inference: the evidence may have been altered, and 23 of the 47 transactions cannot be satisfactorily resolved. The resulting enforcement action cites "inadequate evidentiary controls" and imposes a £2.8 million fine — not for the underlying transactions, but for the inability to produce trustworthy evidence.

What went wrong: The evidence itself was technically complete, but the absence of chain-of-custody documentation — who accessed the records, whether they were stored in a tamper-evident system, and whether integrity was verified — rendered the evidence unreliable in the regulator's assessment. The £2.8 million fine was imposed for evidentiary failure, not operational failure. Consequence: £2.8 million regulatory fine, mandatory remediation programme, 12-month enhanced supervisory scrutiny, and inability to defend against substantive transaction claims.

Scenario B — Evidence Contamination During Internal Investigation: An enterprise workflow agent is suspected of making procurement decisions that systematically favour a particular vendor category. The internal investigation team retrieves the agent's decision journal entries (per AG-415) for the past 12 months. During the investigation, an analyst exports the journal entries to a spreadsheet for analysis, modifies column headers for readability, sorts records by vendor category, and saves the modified spreadsheet as the "investigation evidence file." A second analyst opens the spreadsheet, notices formatting errors, corrects what appear to be data entry mistakes in three records, and saves again. When the investigation concludes with a finding of bias, the vendor's legal counsel challenges the evidence: "The evidence file was modified by two individuals after extraction. Three records were altered. There is no record of what the original data contained versus what was changed. This evidence is contaminated." The organisation must restart the investigation using original records — but by this time, the original database has undergone a scheduled data migration, and the pre-migration records were not preserved with integrity verification.

What went wrong: Evidence was extracted from its original custody without maintaining an integrity chain. Modifications by analysts were not logged, not justified, and not reversible. The working copy became the only accessible copy after the data migration. No chain-of-custody protocol prevented or tracked the contamination. Consequence: 7-month investigation restart, £420,000 in additional investigation and legal costs, inability to sustain the original finding, and reputational damage from a withdrawn investigation conclusion.

Scenario C — Cross-Jurisdictional Evidence Transfer Failure: A crypto/web3 agent operating across EU and US jurisdictions generates evidence relevant to a multi-jurisdictional enforcement action. US regulators request evidence held in EU data centres. The organisation transfers the evidence via encrypted file transfer. Upon receipt, US regulators note that the evidence files have different hash values from those recorded at creation — the encryption, transfer, and decryption process altered metadata timestamps embedded in the file headers. The EU evidence custodian did not record the pre-transfer hashes, the transfer method, or the decryption verification. The US regulators cannot verify that the evidence they received matches what was originally generated. The evidence is classified as "unverified" and carries diminished weight in the enforcement proceeding. The case that would have resulted in a negotiated £1.6 million settlement instead proceeds to a contested hearing at an estimated cost of £3.2 million.

What went wrong: Cross-jurisdictional evidence transfer lacked chain-of-custody documentation. Pre-transfer integrity verification was not performed. The transfer method altered file metadata without recording the expected change. Post-transfer integrity verification was not performed against original creation hashes. Consequence: Evidence classified as unverified, £1.6 million settlement opportunity lost, £3.2 million contested hearing costs, and precedent-setting weakness in the organisation's evidentiary infrastructure.

4. Requirement Statement

Scope: This dimension applies to all governance-relevant evidence generated by, about, or through AI agent operations. "Evidence" in this context encompasses any artefact that may be required to demonstrate compliance, support investigation, defend against claims, or satisfy regulatory requests. This includes but is not limited to: audit trail records (AG-023), decision journal entries (AG-415), configuration snapshots (AG-007), model input/output pairs, telemetry and trace data (AG-410), video and screen evidence (AG-411), tamper-evident integrity records (AG-006), performance metrics, error logs, and any derivative artefacts created from primary evidence (reports, summaries, extracts). The scope covers the full evidence lifecycle: creation, initial storage, ongoing storage, access (read and write), transfer (internal and external), transformation (format conversion, aggregation, anonymisation), archival, and disposition (deletion or destruction). The scope extends to evidence held by third parties on the organisation's behalf — cloud storage providers, managed service providers, and audit firms. The test for whether an artefact is in scope is: "Could this artefact be requested by a regulator, cited in litigation, or needed for internal investigation?" If yes, it requires chain-of-custody governance.

4.1. A conforming system MUST maintain a custody log for every governance-relevant evidence artefact, recording at minimum: (a) creation timestamp and creating entity, (b) storage location and protection mechanisms, (c) every access event (read, write, copy, export) with accessor identity, timestamp, and purpose, (d) every transfer event with source, destination, transfer method, and pre/post-transfer integrity verification, and (e) disposition event (archival or destruction) with authoriser identity, timestamp, and method.

4.2. A conforming system MUST implement tamper-evident protection for all custody logs, ensuring that any modification to a custody log entry is detectable. Custody logs MUST NOT be stored in a system where the entities whose access they record have write access to the log itself.

4.3. A conforming system MUST verify the integrity of evidence artefacts at every custody transition — creation to storage, storage to access, storage to transfer, transfer to recipient, and storage to archival — using cryptographic hashes or equivalent integrity verification mechanisms aligned with AG-006.

4.4. A conforming system MUST implement role-based access controls for evidence stores, restricting write access to authorised evidence custodians and read access to authorised investigators, auditors, and compliance personnel. Access grants and revocations MUST be logged in the custody log.

4.5. A conforming system MUST ensure that evidence artefacts cannot be modified in place. Any necessary modification (correction, redaction, annotation) MUST create a new version while preserving the original, with both versions linked in the custody log and the modification reason documented.

4.6. A conforming system MUST implement evidence preservation holds (litigation holds or regulatory holds) that prevent the destruction, modification, or transfer of specified evidence artefacts when triggered by a legal, regulatory, or investigative event, overriding any automated retention or disposition schedules.

4.7. A conforming system MUST verify the integrity of evidence artefacts during cross-jurisdictional or cross-organisational transfer by recording pre-transfer hashes, documenting the transfer method, and verifying post-transfer hashes against pre-transfer values. Any hash discrepancy MUST be investigated and documented before the transferred evidence is relied upon.

4.8. A conforming system SHOULD implement automated custody log generation for routine evidence operations (storage writes, scheduled integrity checks, automated archival), reducing reliance on manual custody documentation.

4.9. A conforming system SHOULD implement evidence classification that assigns custody requirements proportional to the evidence's sensitivity and regulatory significance — high-sensitivity evidence (financial transaction records, safety-critical decision logs) receives stricter custody controls than low-sensitivity evidence (routine operational metrics).

4.10. A conforming system SHOULD maintain a catalogue of all evidence artefacts, their current custody status, storage locations, applicable retention periods, and any active preservation holds, accessible to authorised governance personnel.

4.11. A conforming system MAY implement cryptographic timestamping through an independent trusted timestamp authority to provide third-party verification of evidence creation times, strengthening the evidentiary weight of custody records.

4.12. A conforming system MAY implement automated evidence integrity monitoring that periodically verifies the integrity of stored evidence artefacts against their recorded hashes and alerts on any detected discrepancy.

5. Rationale

Evidence without chain of custody is assertion without proof. An audit trail that cannot demonstrate its own integrity is an unverified claim about what happened. A decision journal that has been accessible to the operations team under investigation is a document of unknown reliability. A configuration snapshot that was transferred across jurisdictions without integrity verification is a file of uncertain provenance. In each case, the underlying evidence may be perfectly accurate and complete — but without custody documentation, there is no way to know, and no way to persuade an external party (regulator, court, auditor) that the evidence is trustworthy.

Chain of custody is a foundational concept in legal and forensic practice. Physical evidence in criminal proceedings must demonstrate an unbroken chain from collection to courtroom — every person who handled the evidence, every location where it was stored, every transfer between parties, and every protection against contamination must be documented. Digital evidence follows the same principle, with additional complexity: digital artefacts can be copied without detection, modified without trace (absent integrity controls), and transferred across jurisdictions in ways that alter metadata. The absence of chain-of-custody governance for digital evidence is not a theoretical risk — it is a routine basis for evidence challenges in regulatory proceedings, litigation, and arbitration.

For AI agent governance specifically, chain of custody addresses three critical risks. First, the regulator credibility risk: when regulators request evidence of agent behaviour, the organisation must produce evidence that the regulator can trust. Regulators routinely assess the trustworthiness of evidence before assessing its content. Evidence stored in systems with uncontrolled write access, evidence transferred without integrity verification, and evidence with no access logs will be treated with scepticism regardless of its actual accuracy. Second, the litigation defence risk: when an agent's decision is challenged in litigation (by a customer, counterparty, or affected individual), the organisation's primary defence depends on evidence of what the agent did and why. If the opposing party can demonstrate that the evidence chain is broken — anyone with database access could have modified the records — the defence collapses. Third, the internal investigation integrity risk: when the organisation investigates its own agent's behaviour, the investigation must be conducted with evidence of known integrity. If investigators work with evidence that has been extracted, modified, and re-saved (Scenario B), the investigation conclusions are unreliable and may need to be withdrawn.

The relationship between AG-416 and AG-006 (Tamper-Evident Record Integrity) is complementary but distinct. AG-006 ensures that individual records are tamper-evident — modifications to a record are detectable. AG-416 ensures that the handling of those records is documented — who accessed them, when, why, and what protections were in place. An individual record can be tamper-evident (AG-006 compliant) while the evidence store it resides in has uncontrolled access (AG-416 non-compliant). Both are necessary: AG-006 protects the record; AG-416 protects the evidentiary environment.

The financial consequences of chain-of-custody failures are disproportionate to the cost of prevention. Scenario A's £2.8 million fine was imposed not for operational misconduct but for evidentiary inadequacy. Scenario B's £420,000 investigation restart cost arose entirely from evidence contamination that a basic chain-of-custody protocol would have prevented. Scenario C's £1.6 million lost settlement opportunity resulted from a transfer process that lacked integrity verification. In each case, the underlying evidence existed and was probably accurate — the failure was in demonstrating that accuracy to external parties. The cost of chain-of-custody governance (structured access controls, integrity verification, custody logging) is a small fraction of the cost of evidentiary failures.

6. Implementation Guidance

Evidentiary Chain-of-Custody Governance establishes a structured custody regime for all governance-relevant evidence artefacts. The core principle is that evidence must be self-proving — the evidence itself, combined with its custody log, must demonstrate its own integrity and provenance without reliance on external assurances or trust assumptions.

Recommended patterns:

• Immutable evidence store with append-only custody log. Implement a dedicated evidence store that enforces write-once-read-many (WORM) semantics for primary evidence artefacts. Once written, an evidence artefact cannot be overwritten or deleted (except through a formally governed disposition process). The custody log is a separate append-only log that records every operation on every artefact. The custody log itself is protected by the same tamper-evident mechanisms required by AG-006 — hash chains, cryptographic signatures, or equivalent. This pattern ensures that the primary evidence and the custody record cannot be silently modified. Implementation options include WORM-compliant storage systems, content-addressable storage where the storage key is the content hash, or database systems with append-only audit tables protected by row-level immutability.
• Segregated evidence custody roles. Define and enforce three distinct roles with non-overlapping permissions: evidence creators (agents and systems that generate evidence), evidence custodians (personnel and systems authorised to manage evidence storage, transfer, and disposition), and evidence consumers (investigators, auditors, and regulators who read evidence). No single role combines creation with custody management or custody management with investigation. This segregation prevents the scenario where a team under investigation has custody control over the evidence relevant to the investigation. Implement through role-based access control at the storage layer, with role assignments logged and periodically reviewed.
• Integrity verification at every custody transition. Implement automated integrity verification (cryptographic hash comparison) at every point where evidence changes custody: when the agent writes evidence to the store, when the store writes to archival storage, when evidence is transferred to a regulator or auditor, when evidence is loaded into an investigation tool, and when evidence is restored from backup. Record the hash verification result in the custody log. A failed verification halts the transition and triggers an integrity incident per AG-006. This pattern creates a continuous integrity chain from creation to final use, with each link independently verifiable.
• Evidence packaging for external transfer. When evidence must be transferred outside the organisation (to regulators, auditors, legal counsel, or counterparties), package the evidence with its custody log, integrity hashes, and a certificate of custody signed by an authorised evidence custodian. The package should be self-contained — the recipient can verify integrity using the included hashes and custody documentation without needing access to the originating system. Define standard packaging formats for common transfer scenarios (regulatory request response, litigation discovery, audit evidence production).
• Preservation hold automation. Implement automated preservation holds that can be triggered by legal, regulatory, or investigative events. When a hold is activated, all evidence artefacts matching the hold criteria (by agent, time range, decision category, or other metadata) are flagged as preserved. Preserved artefacts are exempt from automated retention policies, cannot be deleted or archived without explicit legal authorisation, and generate alerts if any custody operation is attempted. Hold activation and deactivation are logged in the custody log with authoriser identity and legal reference.

Anti-patterns to avoid:

• General-purpose database for evidence storage. Storing evidence in a general-purpose database that serves operational workloads, with write access available to application service accounts, database administrators, and operations teams. This creates an uncontrolled custody environment where any of dozens of entities could modify evidence without detection or logging. Evidence must be stored in a dedicated system with controlled access.
• Manual custody documentation. Relying on human investigators or custodians to manually record evidence handling steps (e.g., filling out a custody form when accessing evidence). Manual documentation is incomplete, inconsistent, and often omitted under time pressure. Custody logging must be automated at the infrastructure layer — the act of accessing evidence automatically generates a custody log entry, with no option to access without logging.
• Hash verification only at creation. Computing and recording integrity hashes when evidence is created but never verifying them again until the evidence is needed. This approach detects tampering only at the moment of evidence use, potentially months or years after the tampering occurred. Periodic integrity verification (at minimum monthly) ensures that tampering is detected promptly.
• Shared evidence export paths. Allowing investigators to export evidence to personal workstations, shared drives, or email attachments. Every export is a custody transition that must be logged and integrity-verified. Uncontrolled exports are the primary vector for evidence contamination (Scenario B). Exports should flow through a governed export mechanism that logs the export, records the recipient, and marks the exported copy as a derivative artefact subject to its own custody requirements.
• Custody logs co-located with evidence. Storing custody logs in the same system and under the same access controls as the evidence they document. If an entity with write access to the evidence also has write access to the custody log, they can modify both without external detection. Custody logs must be stored separately from the evidence they govern, with independent access controls.

Industry Considerations

Financial Services. Financial regulators (FCA, SEC, BaFin, MAS) routinely assess the integrity of evidence presented in enforcement proceedings. FCA enforcement investigations specifically examine evidence custody procedures, and the FCA's investigation guidelines note that evidence of uncertain provenance receives diminished weight. Firms must implement financial-grade evidence custody aligned with existing regulatory expectations for trading records, communication records, and transaction documentation. Chain-of-custody procedures for agent evidence should be at least as rigorous as procedures for existing regulated records.

Crypto and Web3. Blockchain-native environments offer inherent chain-of-custody advantages through on-chain transaction records, but off-chain evidence (agent decision logs, configuration states, model inputs/outputs) still requires traditional custody governance. The intersection of on-chain and off-chain evidence creates a hybrid custody challenge: on-chain records are self-proving, but the off-chain context that explains those records (why the agent initiated a transaction, what alternatives were considered) requires AG-416 custody governance. Firms should implement custody bridges that link on-chain transaction hashes to off-chain evidence artefacts.

Safety-Critical and Cyber-Physical Systems. Accident investigation in safety-critical domains (aviation, automotive, industrial automation) follows established evidence custody protocols from physical-world investigation frameworks. Agent evidence must be integrated into these existing frameworks — the "black box" equivalent for AI agents must be subject to the same custody rigour as flight data recorders or vehicle event data recorders. Evidence from embodied agents operating in physical environments may include sensor data, video feeds, and actuator commands that have specific custody requirements under safety investigation regulations.

Public Sector and Rights-Sensitive. Government agencies using AI agents for decisions affecting individual rights face heightened evidence custody requirements under administrative law. Individuals challenging government decisions have the right to see the evidence on which the decision was based. If the evidence cannot demonstrate its own integrity through chain of custody, the government agency's decision may be overturned on procedural grounds regardless of its substantive merits. Freedom of information and subject access requests create additional custody obligations — evidence must be producible on demand with custody documentation.

Maturity Model

Basic Implementation — The organisation has implemented a dedicated evidence store with write-once semantics for primary evidence artefacts. Access to the evidence store is controlled through role-based access with segregation between creators, custodians, and consumers. A custody log records creation events, access events, and transfer events. Integrity hashes are computed at creation and verified on access. Preservation holds can be activated manually. This level meets the mandatory MUST requirements.

Intermediate Implementation — All basic capabilities plus: custody logging is fully automated at the infrastructure layer with no manual documentation dependencies. Integrity verification occurs at every custody transition with results logged. Evidence packaging for external transfer includes self-contained custody documentation and integrity verification materials. Evidence classification assigns custody requirements proportional to sensitivity. An evidence catalogue provides visibility into all evidence artefacts, their custody status, and applicable holds. Periodic integrity verification runs at least monthly.

Advanced Implementation — All intermediate capabilities plus: cryptographic timestamping through an independent trusted timestamp authority provides third-party verification of evidence creation times. Cross-jurisdictional transfer procedures include pre-transfer and post-transfer integrity verification with documented transfer methods. Automated evidence integrity monitoring continuously verifies stored evidence against recorded hashes. Independent audit has verified the chain-of-custody infrastructure. The organisation can demonstrate an unbroken integrity chain for any evidence artefact from creation to current state.

7. Evidence Requirements

Required artefacts:

• Custody log samples. A representative sample of custody logs (minimum 25 entries covering at least 5 different evidence artefact types) from the most recent 90-day period, demonstrating the capture of creation, access, transfer, and integrity verification events with all mandatory fields per 4.1.
• Evidence store access control documentation. Documentation of the role-based access control model for evidence stores, showing the segregation between evidence creators, custodians, and consumers, with current role assignments and the most recent role review.
• Integrity verification records. Records of integrity verifications performed at custody transitions for the most recent 90-day period, showing the number of verifications, pass/fail rates, and investigation records for any failed verifications.
• Preservation hold records. Documentation of all active preservation holds, their triggering events, the evidence artefacts covered, and the activation timestamps and authoriser identities. If no holds are currently active, provide records of the most recent hold activation and deactivation cycle.
• Evidence transfer packages. At least 2 examples of evidence packages prepared for external transfer (to regulators, auditors, or legal counsel), demonstrating self-contained custody documentation, integrity hashes, and custody certificates.
• Tamper-evidence verification for custody logs. Demonstration that the custody log itself is tamper-evident per AG-006, including the specific mechanism used (hash chain, cryptographic signatures, immutable storage) and a verification test result.

Retention requirements:

• Custody logs: must be retained for at least as long as the evidence artefacts they document, plus an additional 2 years. For regulated financial services, this means minimum 9 years (7-year evidence retention plus 2-year custody log extension). For other regulated sectors, minimum 7 years. For unregulated deployments, minimum 5 years.
• Integrity verification records: same retention period as custody logs.
• Preservation hold records: retained permanently or until 7 years after the resolution of the triggering legal, regulatory, or investigative event, whichever is longer.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Custody logs and integrity verification records must be retrievable by evidence artefact identifier, by time range, by accessor identity, and by custody event type. The evidence catalogue (if implemented) must be searchable by metadata fields.

8. Test Specification

Test 8.1: Custody Log Completeness at Creation

• Stimulus: Generate 10 evidence artefacts of different types (audit trail records, decision journal entries, configuration snapshots, model input/output pairs, telemetry traces). Retrieve the custody log entry for each artefact.
• Expected behaviour: Each artefact has a corresponding custody log entry recording: creation timestamp (synchronised per AG-412), creating entity identity, storage location, protection mechanism, and integrity hash.
• Pass criteria: All 10 artefacts have complete custody log entries with all mandatory creation fields. Zero artefacts exist without a corresponding custody log entry.
• Fail criteria: Any artefact lacks a custody log entry, or any custody log entry is missing a mandatory creation field.

Test 8.2: Access Event Logging Enforcement

• Stimulus: Access 15 evidence artefacts using 3 different roles (5 accesses each by an evidence custodian, an investigator, and an auditor). Attempt 3 additional accesses using an unauthorised role. Retrieve the custody logs for all 18 access attempts.
• Expected behaviour: The 15 authorised accesses are permitted and each generates a custody log entry recording accessor identity, role, timestamp, and access purpose. The 3 unauthorised accesses are denied and each generates a custody log entry recording the denied access attempt.
• Pass criteria: All 15 authorised accesses have complete custody log entries. All 3 unauthorised accesses are denied and logged. Zero access events occur without a custody log entry.
• Fail criteria: Any access occurs without a custody log entry, any unauthorised access is permitted, or any custody log entry is missing mandatory fields.

Test 8.3: Integrity Verification at Custody Transition

• Stimulus: Perform 5 custody transitions: (1) creation to storage, (2) storage to investigator access, (3) storage to archival storage, (4) storage to external transfer, and (5) archival restoration. For each transition, verify that integrity verification is performed. Introduce a deliberate integrity failure in transition 4 (alter one byte of the evidence artefact between pre-transfer hash computation and transfer).
• Expected behaviour: Transitions 1-3 and 5 pass integrity verification with hashes matching. Transition 4 detects the integrity failure, halts the transfer, and generates an integrity incident.
• Pass criteria: Integrity verification is performed and logged for all 5 transitions. The deliberate integrity failure in transition 4 is detected, the transfer is halted, and an incident is recorded.
• Fail criteria: Any transition proceeds without integrity verification, or the deliberate integrity failure is not detected.

Test 8.4: Immutability of Evidence Artefacts

• Stimulus: Attempt to modify an evidence artefact in place using: (a) direct storage write, (b) database update command, (c) administrative override, and (d) application-layer API. For attempt (d), use the governed modification process that should create a new version rather than modifying in place.
• Expected behaviour: Attempts (a), (b), and (c) are blocked by the WORM storage mechanism or access controls. Attempt (d) creates a new version while preserving the original, with both versions linked in the custody log and the modification reason documented.
• Pass criteria: Attempts (a), (b), and (c) fail — the original artefact is unchanged. Attempt (d) succeeds, creating a new version with the original preserved. The custody log records the new version creation, the link to the original, and the modification reason.
• Fail criteria: Any of attempts (a), (b), or (c) succeeds in modifying the original artefact, or attempt (d) overwrites the original without preserving it.

Test 8.5: Preservation Hold Enforcement

• Stimulus: Activate a preservation hold covering 20 evidence artefacts. Attempt to: (1) delete a preserved artefact via automated retention policy, (2) delete a preserved artefact via manual custodian action, (3) transfer a preserved artefact to an external party without legal authorisation, and (4) archive a preserved artefact. Verify that the hold prevents all four operations.
• Expected behaviour: All four operations are blocked. Alerts are generated for each attempted operation on a preserved artefact. The custody log records each blocked operation with the preservation hold reference.
• Pass criteria: All four operations are blocked. Alerts are generated for all four attempts. Custody log entries exist for all four blocked operations referencing the active hold.
• Fail criteria: Any operation succeeds on a preserved artefact, or any attempted operation is not logged.

Test 8.6: Cross-Jurisdictional Transfer Integrity

• Stimulus: Transfer an evidence package containing 5 artefacts from one jurisdiction's evidence store to another. Record pre-transfer hashes for all 5 artefacts. Complete the transfer. Verify post-transfer hashes against pre-transfer values. Deliberately corrupt one artefact during a second transfer attempt.
• Expected behaviour: First transfer: all 5 post-transfer hashes match pre-transfer hashes. Transfer is recorded in custody logs at both source and destination. Second transfer: the corrupted artefact fails post-transfer verification. The transfer of the corrupted artefact is rejected. The remaining artefacts pass verification.
• Pass criteria: First transfer: 100% hash match, complete custody log entries at both locations. Second transfer: corrupted artefact detected and rejected, custody log records the integrity failure.
• Fail criteria: Any hash mismatch in the first transfer goes undetected, or the corrupted artefact in the second transfer is accepted.

Test 8.7: Custody Log Tamper Evidence

• Stimulus: Retrieve a custody log covering at least 50 entries. Attempt to: (a) modify an existing custody log entry, (b) delete a custody log entry, (c) insert a backdated custody log entry. Verify that all three attempts are either blocked or detectable.
• Expected behaviour: If the custody log uses immutable storage, all three attempts are blocked. If the custody log uses tamper-evident mechanisms (hash chains), the attempts may succeed but are detectable through integrity verification. In either case, no undetectable modification is possible.
• Pass criteria: All three tampering attempts are either blocked or detected by the tamper-evidence mechanism. The integrity verification process identifies any successful modifications. Zero undetectable modifications are possible.
• Fail criteria: Any modification, deletion, or backdated insertion is both successful and undetectable by the integrity verification mechanism.

Conformance Scoring

• Score 0: No chain-of-custody governance exists — evidence artefacts are stored in general-purpose systems with uncontrolled access, no custody logging, and no integrity verification between creation and use.
• Score 1: Evidence artefacts are stored in a designated location with basic access controls. Integrity hashes are computed at creation. Some access events are logged. No systematic custody logging at every transition, no preservation hold capability, and no tamper-evident custody logs.
• Score 2: A dedicated evidence store enforces write-once semantics. Custody logs record creation, access, transfer, and disposition events with all mandatory fields. Integrity verification occurs at every custody transition. Role-based access segregates creators, custodians, and consumers. Preservation holds can be activated and are enforced. Custody logs are tamper-evident.
• Score 3: Verified through independent audit confirming unbroken custody chains for all evidence artefact types. Cryptographic timestamping provides third-party verification of creation times. Automated integrity monitoring continuously verifies evidence against recorded hashes. Cross-jurisdictional transfer procedures are documented, tested, and audited. Evidence packaging for external transfer is standardised and self-verifying.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 12 (Record-keeping)	Direct requirement
EU AI Act	Article 16 (Obligations of Providers)	Supports compliance
SOX	Section 802 (Criminal Penalties for Altering Documents)	Direct requirement
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	9.1.1R (Record-keeping)	Direct requirement
NIST AI RMF	GOVERN 1.5, MANAGE 4.2	Supports compliance
ISO 42001	Clause 7.5 (Documented Information)	Direct requirement
DORA	Article 11 (Backup Policies and Procedures, Restoration and Recovery)	Supports compliance
DORA	Article 17 (ICT-related Incident Management)	Supports compliance

EU AI Act — Article 12 (Record-keeping)

Article 12 requires that high-risk AI systems generate logs that enable monitoring and post-market surveillance. The provision implicitly requires that these logs are reliable — logs that cannot demonstrate their own integrity through chain of custody are inadequate for the monitoring and surveillance purposes that Article 12 envisions. AG-416 provides the custody governance that ensures Article 12 logs meet the implicit reliability requirement. Without chain of custody, an organisation may generate logs per Article 12 but be unable to demonstrate to a national competent authority that those logs are trustworthy.

SOX — Section 802 (Criminal Penalties for Altering Documents)

Section 802 makes it a federal crime to knowingly alter, destroy, mutilate, conceal, or falsify records with the intent to obstruct an investigation. For organisations subject to SOX, chain-of-custody governance is not optional — it is the mechanism that prevents accidental or negligent alteration of records that could be construed as obstruction. AG-416's requirements for immutable evidence storage, custody logging, and integrity verification directly support SOX Section 802 compliance by creating an infrastructure where evidence alteration is either impossible (WORM storage) or detectable (tamper-evident custody logs). The custody log itself serves as evidence that the organisation took reasonable steps to protect records from alteration.

FCA SYSC — 9.1.1R (Record-keeping)

The FCA requires firms to maintain records sufficient to enable the FCA to monitor compliance. The FCA's approach to evidence in enforcement proceedings includes assessment of evidence provenance — the FCA expects that records produced in response to information requests are authentic, unmodified, and produced from systems with appropriate integrity controls. AG-416 provides the custody infrastructure that satisfies this expectation. Firms that cannot demonstrate chain of custody for agent-generated evidence face an adverse inference in enforcement proceedings: the regulator may presume that the evidence does not accurately reflect what occurred.

ISO 42001 — Clause 7.5 (Documented Information)

Clause 7.5 requires that documented information needed by the AI management system is controlled, including ensuring its availability, suitability, and adequate protection. Chain-of-custody governance is the mechanism for "adequate protection" of documented information — ensuring that evidence artefacts are protected against unauthorised modification, that access is controlled, and that the integrity of documented information can be verified. Without custody governance, the "adequate protection" requirement of Clause 7.5 is not satisfied.

NIST AI RMF — GOVERN 1.5 and MANAGE 4.2

GOVERN 1.5 addresses mechanisms for documenting AI risk management processes and decisions. MANAGE 4.2 addresses mechanisms for continuously monitoring, evaluating, and updating deployed AI systems. Both functions depend on the availability of trustworthy evidence about system behaviour. AG-416 ensures that the evidence supporting these functions maintains its integrity and provenance throughout its lifecycle, enabling reliable risk management documentation and continuous monitoring.

DORA — Articles 11 and 17

DORA Article 11 requires backup policies and recovery procedures that ensure the availability and integrity of ICT system data. Article 17 requires ICT-related incident management including evidence preservation for incident investigation. AG-416 provides the custody framework that ensures backup and recovery procedures preserve evidence integrity (Article 11) and that incident investigation evidence is trustworthy and admissible (Article 17). The preservation hold capability directly supports Article 17's incident evidence requirements.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — undermines the trustworthiness of all governance evidence across all agents, potentially rendering the entire governance programme undemonstrable

Consequence chain: Chain-of-custody failure creates a cascading credibility crisis across the entire governance programme. The immediate technical failure is evidence of uncertain provenance — artefacts that exist but cannot be proven authentic. The first-order consequence is evidentiary challenge: when any governance evidence is questioned (by a regulator, auditor, court, or internal investigation), the organisation cannot demonstrate that the evidence is trustworthy. This triggers an adverse inference — the examining party presumes the evidence may have been altered, which shifts the burden of proof to the organisation. The second-order consequence is governance programme invalidation: if the evidence supporting governance compliance is unreliable, then governance compliance itself is undemonstrable. An organisation with technically complete audit trails, decision journals, and configuration records — but without chain of custody — is in the same evidentiary position as an organisation that never created those records, because it cannot prove that the records are authentic. The third-order consequence is regulatory and legal exposure: regulatory enforcement actions that would have been resolved with trustworthy evidence instead escalate to contested proceedings (Scenario C's £1.6 million settlement becoming a £3.2 million hearing). Litigation defences that depend on agent behaviour evidence collapse when the evidence is challenged (Scenario B's investigation restart at £420,000). Regulatory findings cite evidentiary inadequacy as an independent violation, compounding the original substantive finding (Scenario A's £2.8 million fine for evidentiary failure). The ultimate organisational consequence is a loss of institutional credibility — the regulator, the court, or the auditor concludes that the organisation's governance evidence cannot be relied upon, creating a presumption of unreliability that affects all future interactions.

Cross-references: AG-006 (Tamper-Evident Record Integrity) provides the record-level integrity mechanisms that AG-416 extends to the full evidence lifecycle. AG-412 (Time Synchronisation Validation Governance) ensures the timestamps in custody logs are accurate and comparable across systems. AG-409 (Critical Event Taxonomy Governance) classifies events whose evidence requires chain-of-custody governance. AG-410 (High-Cardinality Trace Retention Governance) governs the retention of trace data that is subject to AG-416 custody requirements. AG-411 (Video and Screen Evidence Governance) addresses custody requirements specific to multimedia evidence artefacts. AG-413 (Observer-of-Observer Integrity Governance) ensures that the monitoring systems generating evidence are themselves trustworthy. AG-415 (Decision Journal Completeness Governance) generates decision journal artefacts that are subject to AG-416 custody. AG-023 (Audit Trail Governance) generates audit trail records that are subject to AG-416 custody.