Your AI agent just modified a production file. No one opened the application. No shortcut was created. No recent documents entry exists. The registry is silent.

A forensic examiner arrives. They find nothing. They conclude nothing happened or worse, they find the file and blame the wrong person.

This is not hypothetical and has been demonstrated by Ovie Carroll, SANS Institute principal instructor and director of the US Justice Department’s cybercrime lab. Carroll demonstrated exactly this scenario in a controlled experiment in July 2026. He instructed an AI agent to open a Word document in OneDrive, add a paragraph and save it. The agent complied through a programming library inside an invisible PowerShell session. Every forensic artefact that an examiner would normally reach for was never created.

Carroll calls this the SAIDI defence: “Some Artificial Intelligence Did It.” The successor to SODDI (“Some Other Dude Did It”) that has been a courtroom staple for two decades.

The truth was recoverable as the NTFS change journal recorded the rewrite. The event log captured the silent process. The agent’s session log preserved the instruction verbatim. But traditional forensic methods would have missed it entirely.

Here is the complication most commentary misses, the SAIDI defence plays differently depending on which courtroom you are standing in.

Three Jurisdictions, One Architectural Problem

In England and Wales, the Crown Prosecution Service must demonstrate the integrity of computer generated evidence under PACE 1984. The prosecution bears the burden. Without forensic architecture, SAIDI becomes a credible defence.

In EU member states, civil law traditions place different burdens. Courts take a more active role in evidence evaluation. The AI Act now mandates the evidence infrastructure itself, regardless of whether an incident has occurred.

In US federal courts, the Daubert standard governs expert testimony reliability. Proposed Federal Rule of Evidence 707 would extend that standard to machine generated evidence. Without reconstruction capability, the prosecution cannot demonstrate that the forensic methodology is testable.

Three legal traditions. One architectural requirement. If you operate across borders ( as most enterprises do) your forensic readiness architecture must satisfy all three simultaneously.

“Traditional incident response playbooks were not built for AI. They do not account for prompt injection exploits, poisoned training data, hijacked autonomous agents or the regulatory reporting obligations that the EU AI Act introduces.” Source: BeyondScale, “AI Incident Response Playbook for LLM and GenAI Breaches” (2026)

Why Traditional DFIR Fails

Digital Forensics and Incident Response (DFIR) was built for a world where humans performed actions at human speed, left predictable artefacts in predictable locations and operated within static infrastructure. However none of these assumptions hold for AI-native systems.

AI agents operate at machine speed, across system boundaries, through tool invocations spanning multiple services, with reasoning chains that exist only in ephemeral memory.

When something goes wrong (such as a hallucination triggering a financial transaction, a prompt injection exfiltrating data, an agent escalating its own privileges ) the evidence landscape is fundamentally different.

Dimension	Traditional DFIR	AI System DFIR
Evidence location	Filesystem, registry, logs	Prompt traces, embeddings, tool call chains
Artefact predictability	Actions leave known traces	Agents may leave no traditional artefacts
Infrastructure state	Static between incidents	Models update, prompts change, corpora evolve
System boundary	Single	Multi-agent delegation across trust boundaries
Speed	Human	Machine speed cascading decisions
Attribution	User → action	User → agent → tool → outcome
Persistence	Evidence persists by default	Ephemeral* context windows, streaming responses

( * lasting for a very short time or short-lived)

The jurisdictional dimension compounds this. DFIR frameworks were built around common law evidence standards. EU civil law traditions operate differently. The AI Act prescribes what evidence infrastructure must exist regardless of whether an incident has occurred.

“Forensic readiness for AI native systems is still immature in most organisations. Traditional playbooks rarely define what to preserve from agent memory, retrieval context, prompt chains, model telemetry, MCP integration traces, or tool calling chains across internal services.” Source: Andrea Fortuna, “When the AI Lies to Its Own Logs” (2026)

The gap is architectural. If you have not designed for forensic readiness from the start, you cannot retrofit it after an incident. The evidence is already gone and if you have designed only for one jurisdiction’s requirements, you have designed for non-compliance in the others.

The AI Evidence Taxonomy

Forensic readiness requires defining (in advance) what constitutes evidence, where it lives, how long it is retained and who can access it.

This is an architecture decision, not an operations decision. As such the decisions should also be recorded in your ADR/ADL (Architecture Decisions Record / Architecture Decisions Log).

Each regulatory regime emphasises different layers. The architecture must capture all of them.

Layer 1: Identity and Context

• Who initiated the interaction?
• Which agent processed it?
• What model was active?
• What policies were in effect.

• UK GDPR Article 5(2) requires demonstrable proof of who authorised what.
• EU AI Act Article 14 mandates traceability back to a responsible natural person.
• Colorado AI Act requires disclosure of AI involvement in consequential decisions.

Layer 2: Input Chain

• Original user prompt, verbatim and timestamped
• System prompt active at execution
• Retrieved context with relevance scores
• Prior conversation history
• Injected context from upstream agents

• EU AI Act Article 12 explicitly requires logging of input data “to the extent such data is relevant.”
• UK ICO guidance requires explaining what data influenced an automated decision.
• NIST AI RMF’s Map function expects documentation of data inputs.

Layer 3: Reasoning and Decision 

• Full model response
• Confidence signals
• Policy engine evaluation
• Tool selection reasoning
• Chain of thought content

• UK GDPR Article 22 and the Data Protection Act 2018 give individuals the right to meaningful information about the logic of automated decisions.
• EU AI Act Article 13 requires transparency sufficient for users to interpret outputs.
• Proposed FRE 707 would require demonstrating the reliability of the reasoning process.

Layer 4: Action and Outcome

• Tool invocations with parameters and responses
• External system interactions
• Downstream agent delegations
• Final output
• Side effects

All three jurisdictions converge here. The ICO, the AI Act Article 12 and US litigation discovery all demand records of what the system actually did.

Layer 5: Governance Metadata

• Circuit breaker state
• Trust level
• Approval gates triggered or bypassed
• Anomaly scores
• Cost and token consumption

• EU AI Act Article 9 requires documented mitigation measures.
• UK AI Safety Institute’s reporting expectations covers governance failures.
• SEC guidance on AI risk disclosure requires governance documentation for public companies.

“An AI platform may need to replay the exact context window that fed a model, correlate it with tool calls, compare it with moderation decisions, and preserve enough history for governance review.” — AutoMQ, ” Source: AI Incident Forensics Starts with Durable Event History” (2026)

Evidence Preserving Containment

When an AI incident is detected, the instinct is to shut everything down. This is a wrong approach as shutting down destroys evidence.

The correct response is evidence preserving containment. Stopping the harm while preserving the forensic record.

The Containment Hierarchy

Level 1: Pause the Agent

• Suspend the execution loop without terminating the session
• Freeze the context window
• Maintain tool connections in read only mode
• Continue logging all attempted actions, even blocked ones

Level 2: Isolate the Session

• Revoke credentials for external systems
• Block outbound network calls
• Prevent delegation to downstream agents
• Preserve session state as a forensic snapshot

Level 3: Quarantine the Environment

• Isolate compute from production
• Snapshot all associated storage
• Preserve the exact model version and configuration
• Lock the policy engine state

Level 4: Preserve the Supply Chain

• Hash and sign all model artefacts, prompts and configurations
• Lock the retrieval corpus version
• Preserve dependency manifests
• Record the exact infrastructure state

The Critical Principle

Revoke without destroying. The most common forensic failure in AI incidents is credential revocation that also destroys session state.

When you revoke an agent’s API keys, ensure the revocation does not trigger session cleanup, does not purge cached responses, does not cascade to dependent agents in a way that destroys their state and is itself logged as a containment action.

Cross Border Containment

When an incident spans jurisdictions, containment must account for conflicting timelines and obligations:

• UK: ICO breach notification within 72 hours of awareness. Evidence preservation begins at detection, not confirmation.
• EU: AI Act Article 72 requires notification to market surveillance authorities “without undue delay.” Post market monitoring obligations continue during containment.
• US: State breach notification laws vary from 30 to 90 days. Litigation hold obligations may trigger immediately if legal action is foreseeable.
• Data residency: Evidence captured in the EU cannot necessarily be transferred to a US forensic team without Standard Contractual Clauses, adequacy decisions or derogations.

Replayable Reconstruction

The gold standard for AI forensics is replayable reconstruction, recreating the exact conditions that produced the incident and demonstrating that the same inputs produce the same outputs.

AI systems are non-deterministic by design. But forensic reconstruction does not require perfect reproduction. It requires sufficient reproduction to establish:

• What the agent was instructed to do
• What information it had access to
• What decisions it made
• What actions it took
• What the outcome was

What Makes Reconstruction Possible

Configuration snapshots

• Model version and parameters
• System prompt as exact text, not a template reference
• Policy engine rules, versioned with effective date
• Tool definitions and permissions

Signed artefacts

• Retrieval corpus state as a hash of the embedding index
• Plugin and tool versions as exact commit hashes
• Infrastructure configuration as container image digests.

Dependency records

• Which upstream systems provided data.
• Which downstream systems received actions.
• What other agents were involved.
• What human approvals were given and when.

The Reconstruction Test

If a regulator asked you to demonstrate exactly what happened during an incident, could you recreate the environment, feed in the same inputs and show the same outputs?

The answer must be yes regardless of which regulator is asking:

• UK ICO: Under the accountability principle, you must demonstrate compliance, not just assert it.
• EU AI Act: Article 12 requires logs “sufficient to enable the tracing of the AI system’s operation” throughout its lifetime. This is explicitly a reconstruction requirement.
• US Courts: Proposed FRE 707 would hold machine generated evidence to the same reliability standard as expert testimony. The Daubert standard requires demonstrating that the methodology is testable and has been tested.

The hardest scenarios involve multi-jurisdictional architectures.

Model hosted in the US, data in the EU, user in the UK, which jurisdiction’s reconstruction standards apply? All of them. Design for the most demanding.

Chain-of-Custody

Evidence is only useful if it is admissible. Admissibility requires chain of custody, an unbroken record of who had access to the evidence, when, and what they did with it.

For AI systems, this is complicated by ephemeral compute, shared infrastructure, distributed state, model provider opacity and temporal sensitivity.

Architecture Requirements

Immutable logging

Write-once, append-only stores. Cryptographic hashing where each entry references the hash of the previous. Tamper evident storage. Separation of log storage from the systems being logged.

Access control

• Forensic evidence accessible only to designated incident response roles.
• All access logged and auditable.
• No single individual can both create and modify evidence records.
• Legal hold capability that prevents automated retention from destroying evidence.

Retention policy

• Minimum periods aligned with regulatory requirements
• Graduated retention, full detail for recent events, summarised for older
• Clear destruction procedures
• Exception handling for evidence under legal hold

Cross-provider evidence

• Contractual requirements for model providers to preserve and produce logs
• API-level logging of what was sent to and received from external AI services
• Timestamp synchronisation
• Defined handoff procedures for evidence spanning organisational boundaries

Admissibility by Jurisdiction

Jurisdiction	Standard	Key Requirements
England & Wales	PACE 1984, CPS Digital Evidence Guidelines	Continuity of evidence, integrity of digital exhibits, witness statements for each handler
EU Member States	eIDAS Regulation, national procedural codes, AI Act	Electronic evidence integrity, qualified electronic signatures, tamper resistant logging
US Federal	FRE 901/902, Daubert standard	Authentication, reliability demonstration, chain of custody documentation
US State	Varies (Daubert or Frye)	State specific authentication, varying digital evidence standards

The practical implication: your architecture must produce evidence packages satisfying the most demanding standard.

This means cryptographic integrity proofs, human-readable audit trails, machine readable structured logs, and witness-ready documentation, simultaneously.

The Regulatory Landscape

This is not optional. All three jurisdictions are making forensic readiness a compliance requirement, through different mechanisms, at different speeds, converging on the same architectural outcome.

United Kingdom: Principles-Based, Sector Enforced

The UK has deliberately chosen not to replicate the EU’s prescriptive approach. Instead, existing sector regulators apply AI specific guidance within their domains.

This does not mean less demanding. It means distributed:

• ICO: Accountability principle creates an implicit forensic readiness requirement. You must prove compliance, not just assert it.
• AI Safety Institute: Increasing expectations for safety testing documentation and incident reporting.
• FCA: Senior Managers and Certification Regime means named individuals are personally accountable for AI governance failures.
• DPA 2018, Section 14: Automated decision-making provisions require preserving the logic involved.

The UK patchwork is, in some ways, more demanding than a single regulation, because each sector regulator interprets “adequate records” differently.

European Union: Prescriptive, Risk Tiered

The AI Act’s forensic readiness requirements are explicit:

• Article 12: Automatic, tamper resistant event logging over the system’s entire lifetime.
• Article 9: Documented risk management system with mitigation measures.
• Article 14: Human oversight requiring the ability to understand system capacities and limitations.
• Article 72: Post-market monitoring with serious incident reporting
• GDPR Article 22: Ability to explain individual automated decisions.

The EU demands provable records across the AI lifecycle:

• Event logs
• Conformity documentation
• Training data provenance
• Marked AI outputs.

United States: Fragmented, Sector-Specific, Evolving

No single federal AI regulation exists. Forensic readiness requirements emerge from multiple sources:

• NIST AI RMF: Govern, Map, Measure, Manage functions expect documentation. Voluntary but increasingly referenced in procurement and litigation.
• Proposed FRE 707: Machine generated evidence held to expert testimony standard. Pulled back for further study but the direction is clear.
• Colorado AI Act: Risk management, impact assessments, consumer notification for high-risk systems. Effective February 2026.
• SEC AI Risk Disclosure: Public companies must disclose material AI-related risks.
• State breach notification: All 50 states, varying timelines and definitions.

The fragmentation means tracking multiple overlapping requirements. The practical effect: satisfy the most demanding applicable standard.

Compliance Summary

Regulation	Jurisdiction	Requirement	Status
AI Act, Article 12	EU	Tamper-resistant event logging for system lifetime	August 2026
AI Act, Article 9	EU	Risk management with documented mitigation	August 2026
AI Act, Article 72	EU	Post-market monitoring, incident reporting	August 2026
UK GDPR, Article 5(2)	UK	Demonstrable accountability	Active
DPA 2018	UK	Meaningful information about decision logic	Active
ICO AI Guidance	UK	Records sufficient to explain decisions	Active
FCA / SM&CR	UK	Audit trails, personal accountability	Active
AI Safety Institute	UK	Safety testing, incident reporting	Evolving
NIST AI RMF	US	Documentation across Govern/Map/Measure/Manage	Active (voluntary)
Proposed FRE 707	US	Expert testimony standard for machine evidence	Under review
Colorado AI Act	US	Risk management, impact assessments	February 2026
SEC AI Disclosure	US	Material AI risk documentation	Active
ISO/IEC 42001	International	AI management system with incident management	Active

“The EU AI Act requires that high-risk AI systems automatically generate tamper-resistant logs capable of ensuring traceability throughout the system’s lifetime.” Source: IETF Draft, EU AI Act Operational Model Profile (2026)

Architecture Principles for Forensic Readiness

Six principles can be applied against the three jurisdiction requirement.

1. Log by Default, Redact by Policy

Every AI interaction logged in full by default. Redaction is a deliberate policy decision. What you do not log, you can never investigate.

The tension: UK and EU data minimisation principles appear to conflict with comprehensive logging. The resolution is purpose limitation, logging for forensic readiness, security, and compliance is a legitimate purpose. The logs themselves must be protected and access controlled proportionately.

2. Separate the Evidence Plane from the Execution Plane

The systems that generate evidence must not control the systems that store evidence. An agent that can delete its own logs is an agent that can cover its tracks.

3. Design for Reconstruction, Not Just Recording

Recording what happened is necessary but insufficient. The architecture must support recreating the conditions that produced the incident , model state, data state, policy state, infrastructure state.

4. Attribution Must Be Architectural

Do not rely on forensic analysis to determine who did what. Build attribution into the execution path. Every action carries its provenance, the human who initiated, the agent who executed, the policy that permitted and the tool that performed.

5. Forensic Readiness Degrades Gracefully

When systems fail, evidence capture should be the last thing to stop. Design evidence pipelines with independent failure domains. If the agent crashes, the evidence of the crash survives.

6. Design for Jurisdictional Portability

Evidence architecture must satisfy the most demanding jurisdiction while respecting data sovereignty. Evidence formats admissible across common law and civil law systems.

Storage compliant with data residency. Retention satisfying the longest applicable period. Documentation serving both prescriptive regimes and principles-based regimes simultaneously.

The practical test

Can you produce an evidence package from a single incident that satisfies a UK ICO investigation, an EU market surveillance authority conformity assessment and a US federal court discovery request , without violating any jurisdiction’s data protection requirements?

If the answer is no, your architecture has a jurisdictional gap.

The Forensic Readiness Checklist

Score each item as:

• Implemented
• Partial
• Missing

Evidence Capture

•  All agent interactions logged with full input/output chains
•  Model version, configuration, and parameters recorded per interaction
•  Tool invocations captured with parameters and responses
•  Policy engine decisions logged with reasoning
•  Human identity linked to every agent session
•  Agent-to-agent delegations recorded with authority chain
•  Retrieval context preserved per interaction

Evidence Integrity

•  Write-once, append-only storage
•  Cryptographic hashing ensures tamper evidence
•  Log storage separated from production systems
•  Timestamp synchronisation across all sources
•  No single role can both generate and modify evidence

Containment Capability

•  Agents pausable without destroying session state
•  Credential revocation does not trigger evidence cleanup
•  Session snapshots available at any point
•  Blast radius containment isolates without evidence loss
•  Containment actions themselves logged

Reconstruction Capability

•  Configuration snapshots at regular intervals
•  Model artefacts versioned and signed
•  Retrieval corpus state hashable at any point
•  Dependency manifests maintained and versioned
•  Reconstruction test performed quarterly

Jurisdictional Compliance

•  UK: ICO accountability principle satisfied
•  UK: DPA 2018 automated decision explanations preservable
•  UK: Sector-specific requirements mapped
•  EU: Article 12 tamper-resistant logging implemented
•  EU: Article 72 incident reporting procedures defined
•  EU: GDPR Article 22 decision explanation maintained
•  US: NIST AI RMF alignment documented
•  US: State-specific requirements mapped
•  US: Litigation hold covers AI evidence stores
•  Cross-border: Data transfer mechanisms in place
•  Cross-border: Evidence packages satisfy most demanding standard

What Comes Next

Forensic readiness is the foundation that makes all other AI governance meaningful. Without it, your policies are unenforceable, your incidents are uninvestigable, and your compliance is undemonstrable, in any jurisdiction.

The convergence trajectory is clear:

• The EU prescribes the infrastructure, Article 12 logging, Article 9 risk management
• The UK demands the outcome, accountability, explainability, sector-specific assurance
• The US is building the evidentiary standard, proposed FRE 707, NIST AI RMF, state laws

All three paths lead to the same place. You must design AI systems that produce trustworthy, admissible evidence from day one.

Govern AI agent sprawl before it becomes your next compliance incident. Because you cannot investigate agents you do not know exist.

For now, the action is clear. Take one AI agent in your organisation. Run it through the checklist above. Count the “missing” marks in the checklist.

That count is your forensic debt. And unlike technical debt, forensic debt only becomes visible when something goes wrong, at which point it is too late to fix.

“By the time the team arrives, the attacker has been in the network for weeks, logs are partially overwritten, and half the evidence is gone. That model worked reasonably well when attackers moved at human speed and infrastructure was mostly static. In 2026, neither of those conditions holds anymore.” Source: Andrea Fortuna, “DFIR from Break Glass to Always-On” (2026)

References

1. “SAIDI: Some Artificial Intelligence Did It.” Carroll, O. (2026) via Forbes
2. “AI Incident Response Playbook for LLM and GenAI Breaches.” BeyondScale (2026)
3. “When the AI Lies to Its Own Logs.” Fortuna, A. (2026)
4. “DFIR from Break Glass to Always-On.” Fortuna, A. (2026)
5. “AI Incident Forensics Starts with Durable Event History.”AutoMQ (2026) 
6. “EU AI Act Operational Model Profile.” IETF (2026) 
7. Regulation (EU) 2024/1689. EU AI Act (2024)
8. “Guidance on AI and Data Protection.” UK ICO (2024) 
9. UK Data Protection Act 2018
10. “Approach to Safety Evaluation.” UK AI Safety Institute (2024) 
11. “A Pro-Innovation Approach to AI Regulation.” DSIT (2024)
12. “AI and Machine Learning in Financial Services.” FCA (2024) 
13. “Digital Evidence Guidelines.” CPS (2024)
14. PACE 1984
15. “AI Risk Management Framework 1.0.” NIST (2023) 
16. “AI in the Courtroom: How Proposed Rule 707 Could Shape Evidence Standards.” Steptoe (2026) 
17. Colorado AI Act, SB 24-205
18. eIDAS Regulation (EU) No 910/2014
19. ISO/IEC 42001:2023. “Artificial Intelligence Management System.”
20. “AI Transparency Requires Logging Infrastructure.” Airia (2026)
21. “EU AI Act Compliance for SOC Automation.” D3 Security (2026)
22. “Forensic Readiness Framework.” Security Alliance (2026) 
23. “State of AI in the Cloud 2026.” Wiz (2026)
24. “AI-Generated Evidence Is a Threat to Public Trust in the Courts.” NCSC (2026) 

The Agent Registry Problem: Why You Cannot Govern What You Cannot See