AI Liability: Can Companies Reconstruct What Their Agents Did?

Imagine an AI agent managing customer accounts for a software company. It receives a request, retrieves account information and modifies a record through an authorised tool. Days later, a customer alleges that the change caused a financial loss and should never have been permitted.

The company begins investigating. It can confirm that the agent accessed the system, but cannot establish which instructions it received, what information influenced its actions or whether a required approval was bypassed.

This is an illustrative scenario, not a documented insurance claim. Yet it raises an important question for companies deploying autonomous AI: when an agent allegedly causes harm, can the organisation reconstruct what actually happened?

For businesses facing customer disputes, liability allegations or insurance investigations, the answer depends partly on decisions made long before the incident.

AI Liability Is Becoming an Investigation Challenge

In October 2026, the Financial Times reported on emerging insurance liability questions surrounding autonomous AI agents and actions that may exceed their developers' intended controls.

The reporting explored potential exposure across cyber, technology errors and omissions, intellectual property and other insurance arrangements.

These are emerging liability questions, not settled legal precedents. Whether a company is responsible for an agent's actions depends on the circumstances, applicable law, contracts and the relevant insurance policy.

But before responsibility can be evaluated, investigators need to establish the underlying facts.

If an agent discloses confidential information or performs an unintended operation, the outcome could involve model behaviour, application design, permissions, external information or human intervention. Without sufficient records, distinguishing these factors becomes difficult.

What Evidence Is Needed to Reconstruct an AI Incident?

Investigating an autonomous application requires more than confirming that the system was running when an incident occurred.

An organisation may need several categories of evidence:

• Instructions and context: The user's request, applicable system instructions and relevant information retrieved or received by the agent.

• Tool interactions: Which tools were invoked, their parameters, execution sequence and returned responses.

• Actions and outcomes: What the agent changed, disclosed or executed, including relevant downstream effects.

• System configuration: The model, application version, permissions, tools and operating rules active at the time.

• Human involvement: Whether approval was required, requested, granted, rejected or overridden.

These records answer different questions. A tool-call log might establish that an operation occurred, while the preceding instructions and retrieved context help explain the circumstances leading to it.

The OWASP GenAI Security Project's guidance on AI observability highlights the importance of monitoring inputs, outputs and execution traces. For autonomous agents, tool-call sequences are particularly relevant.

However, reconstructing observable actions is not the same as establishing why a model internally selected an action. Internal reasoning may be inaccessible, incomplete or unreliable as an explanation.

A defensible investigation should therefore distinguish recorded events from interpretations about the model's decision-making.

Why Agentic AI Complicates Attribution

Traditional software investigations examine application logs, code changes, configurations and user activity. These techniques remain valuable, but autonomous agents introduce additional complexity.

An agent may combine a user instruction with retrieved documents, external services and multiple tool responses before taking action. A problematic outcome can involve several contributing factors.

For example, an agent might follow a misleading instruction embedded in retrieved content. Alternatively, it might misinterpret a legitimate request because its operating constraints were insufficiently defined.

These possibilities could require different corrective actions.

System changes create another complication. The model, prompts, tools or permissions operating during an investigation may differ from those active when the incident occurred.

Third-party dependencies can also limit visibility. A company may control its application while having incomplete access to records maintained by model providers or integrated services.

Even apparently comprehensive logs may omit relevant external activity. Their completeness, integrity, timestamps and preservation procedures matter as much as their existence.

Consequently, investigators may establish what an agent did without being able to determine every factor that contributed to its behaviour.

Why Evidence Collection Must Begin Before an Incident

The NIST AI Risk Management Framework emphasises monitoring, documentation, incident response and change management throughout the AI lifecycle.

Its Measure Playbook also addresses maintaining relevant histories, audit logs and information that supports investigation of errors and other problems.

For companies operating consequential AI applications, these principles translate into practical preparation.

Organisations need to determine which events should be recorded, how activity across services can be connected, how application versions are identified and how evidence will be preserved when an incident is reported.

They also need to protect those records. Logging sensitive customer information without appropriate controls can introduce additional privacy and security risks.

Retention policies should reflect investigative needs alongside applicable legal, confidentiality and data-protection obligations.

The objective is not to collect everything indefinitely. It is to maintain reliable, appropriately protected records that can support a proportionate investigation.

Once an incident occurs, information that was never captured may be impossible to recover.

Operational Logs and Assessment Evidence Serve Different Purposes

AI documentation often combines two distinct types of evidence.

Operational records describe what occurred during a particular execution. They may include timestamps, instructions, tool calls, outputs, approvals and resulting system changes.

Pre-incident assessment evidence describes what the organisation previously evaluated: identified risks, tested scenarios, observed weaknesses, mitigation measures and control performance.

Consider an agent that makes an inappropriate account modification.

Operational logs might establish the instruction received, the tool invoked and the resulting change. A prior adversarial assessment might show whether the company tested comparable instruction-manipulation scenarios or approval-boundary failures.

Both could contribute to understanding the situation, but they are not interchangeable.

A successful assessment does not prove that an agent behaved correctly during a later incident. Likewise, incident logs do not establish whether the organisation previously recognised and evaluated the relevant risk.

Together, these records can provide a fuller picture of the application's operation and the company's earlier risk-management activities.

What This Means for AI Liability and Insurance

For an AI-deploying technology company, an alleged loss may trigger customer complaints, contractual disputes, internal investigations or notification obligations under relevant insurance arrangements.

A broker, insurer or legal adviser may need to understand the sequence of events, the controls in place and the organisation's response.

The questions will depend on the incident. An unintended financial operation, confidentiality breach and incorrect professional recommendation can raise different issues involving causation, contractual responsibility and coverage.

Documentation can support factual investigation, but it does not independently establish legal liability or determine whether an insurance policy responds.

In September 2026, Michelle Perry's IRMI commentary, Making AI Use in Claims Defensible, examined the importance of documenting AI contributions and human decisions in insurance claims handling.

That analysis concerns insurers using AI to process claims, rather than liability claims against AI developers. Nevertheless, it illustrates a related accountability challenge: distinguishing what technology contributed from what people authorised or decided.

For technology companies, preparation means maintaining operational evidence while also documenting how consequential AI risks were evaluated before deployment and during subsequent changes.

How AetherLab Supports Pre-Incident Risk Documentation

AetherLab helps institutions evaluate AI risk and translate technical assessment findings into structured evidence that risk teams can review.

Its Evidence Pack brings together severity-ranked vulnerabilities, their potential business and financial impact, remediation mapped to controls, and documented assessment decisions. Findings and subsequent reassessments can help show what changed after identified weaknesses were addressed.

For a technology company facing a customer dispute or insurance investigation, documented pre-incident assessments may help establish which risks were recognised, which controls were evaluated and what mitigation work had been completed before the alleged loss.

This information can provide useful context when examining the organisation's previous risk-management activities. It may also support customer assurance reviews, internal governance and discussions with brokers or insurers.

However, Evidence Pack is not an operational logging platform or a substitute for forensic investigation records. It cannot independently reconstruct an incident, establish causation or determine insurance coverage.

Its value lies in organising technical assessment evidence that complements operational records and provides a documented history of how an organisation evaluated and addressed AI risks.

The Evidence Challenge Begins Before the Claim

As autonomous AI applications take on more consequential responsibilities, companies need to prepare for questions that may arise after an unexpected outcome.

What instructions did the agent receive? Which tools did it execute? What controls applied? Which version was operating? What risks had already been identified and tested?

Answering these questions requires operational visibility, reliable record preservation and disciplined assessment documentation.

Even then, uncertainty may remain. The objective is not to guarantee that every incident can be fully explained, but to reduce avoidable gaps in the available evidence.

For AI-deploying companies, this preparation can support incident response, customer accountability and more informed liability and insurance discussions.

When an AI incident becomes a liability question, the evidence available may depend on what was documented months earlier. 

Explore AetherLab's Evidence Pack to understand how structured assessment findings, mitigation records and residual risk evidence can support future accountability and insurance reviews.