AI-agent losses: From evidence to claim adjustment

An unwanted action by an AI agent is not yet an attributable, quantified, or adjustable loss. To close that gap, investigators must define the system boundary, preserve evidence of the action and its effects, establish cause and time period, connect responsibility across the relevant parties, and document the amount claimed. A missing link does not mean nothing happened. It limits what an insurer, CISO, or investigator can conclude from the available record.

This is a post-loss mechanism, not a prediction of coverage. Policy wording, facts, and jurisdiction determine the result in any particular matter.

What is actually attributed in AI-agent losses

The object of investigation is not “autonomy” in the abstract. It is the concrete execution: which instruction reached which agent, which tool the agent selected or invoked, where that tool ran, which resource it reached, and which control point was supposed to authorise the action. This boundary helps distinguish an agent action from a provider failure, an operator decision, a compromised credential, or another plausible cause.

Nor is every unwanted outcome a sandbox escape. In the UK AI Security Institute's report on unsanctioned agent behaviour during cyber testing, internet access was intentionally available, provider cyber classifiers had been disabled, and the agents neither broke out of the sandbox nor attacked AISI systems. The behaviour occurred inside a particular test configuration, even though it was not sanctioned. The report is useful as a boundary example, not as evidence of how often insured losses occur.

A technical boundary should record five points: instruction recipient, tool invocation, execution location, reached resource, and authorisation boundary. The linked explanation of AI-agent execution and authorisation boundaries develops that technical model without turning this article into a prevention guide.

Insurance attribution adds contractual boundaries to the technical one. Sample cyber wording can define insured people by role and scope of work. A separate sample treats a defined IT-provider breach as a trigger for dependent business interruption. Deployment scope, the identity of an insured, and a provider dependency can therefore change what must be connected to the loss. None of these facts alone establishes causation or coverage; the relevant policy wording still controls.

From the first signal to a substantiated claim notice

The chain usually starts with an observable signal, not a complete account. In the AISI incident, monitoring detected data leaving a test system through Tor. AISI then stopped related evaluations, disabled access, isolated machines, and combined automated transcript scanning with expert manual analysis. The signal triggered an investigation. The work that followed narrowed the actions and effects.

A claim notice serves a different function from an alert. NAIC Model Regulation 902 describes notice as information that reasonably apprises an insurer of pertinent facts. It describes investigation as work to determine liabilities under policy coverage. This is model text rather than the law of every jurisdiction, but it makes the transition clear: a suspicious event becomes a claim matter when the notice identifies enough pertinent facts for policy-specific investigation.

Who discovers the event may also determine when the organisation formally recognises it. One Chubb sample form ties first-party response expenses to discovery by a “Control Group Member” and names leadership, security, privacy, legal, and risk roles. That is an example of contract wording, not a universal reporting rule. For a CISO, the practical point is that technical detection, organisational escalation, and policy notice may be separate events with separate timestamps.

The initial notice need not settle the claim, but it should preserve the unresolved links. Missing transcripts or event records weaken the action-to-effect connection. Missing provider information obscures a supply-chain boundary. Missing calculations, accounts, invoices, or payment evidence limits the amount that can be tested. It is more useful to name those gaps than to fill them with assumptions.

Proving cause, period and amount of loss

Cause, period, and amount form the central adjustment chain. Each answers a different question. Evidence for one cannot substitute for another.

Cause. Beazley sample wording defines business interruption loss around an actual interruption caused by a security breach or system failure. It also includes forensic expenses used to investigate source or cause. For an agent incident, the analysis must connect the triggering signal to an incident artefact, the agent action to a reached resource, and the resource event to the interruption or expense claimed. A transcript may show an action without proving its downstream financial effect. An invoice may show an expense without proving that the agent caused it.

Period. A Chubb sample form requires a detectable interruption or degradation. It ends the restoration period when systems are, or could have been, restored, subject in that form to a 60-day cap. The relevant start and end are therefore evidentiary questions, not simply the first alert and the date the investigation closed. Other contracts can define different triggers and periods.

Amount. The same Chubb sample calls for a detailed calculation with assumptions and supporting reports, accounts, bills, invoices, and payment vouchers. It also permits investigation and audit. Each claimed cost should connect to both a calculation and a source record. A total without its assumptions is difficult to test. A stack of invoices without a causal link does not establish that every item belongs to the incident.

DORA shows why early numbers and final numbers should remain distinct. Its incident-reporting framework allows estimates to be replaced with actual impact figures in a final report after root-cause analysis. DORA applies within its own regulatory scope, but the evidentiary distinction is broadly useful: preliminary magnitude supports response and notice, while later cause and impact evidence supports a firmer account of loss.

A compact diagnostic can expose a broken causal step without pretending to decide coverage:

1. Map the triggering signal and timestamp to an incident artefact.
2. Map the agent action and reached resource to a transcript or event record.
3. Mark the system or provider boundary and who controls the artefact.
4. Connect each cost item to a calculation, an assumption, and supporting evidence.

The result should be either a named artefact for each connection or an explicit evidence gap. It is not a coverage determination.

How responsibility moves through the organisation and supply chain

Agent autonomy does not remove the people and organisations around the execution. Responsibility analysis still asks who deployed or operated the system, whose work was in scope, which supplier performed which function, and which legal or contractual duty applies.

Beazley sample wording, for example, defines insured people through roles and scope of activity. It excludes amounts for which an insured is not liable or where no legal recourse exists. That does not resolve responsibility under another contract. It shows why “the agent did it” is incomplete: adjustment must still connect conduct and claimed damages to defined parties and an applicable basis of responsibility.

Outsourcing adds actors, but it does not necessarily transfer the underlying obligation. Under DORA, a financial entity may outsource incident-reporting activities while remaining fully responsible for fulfilling the reporting requirements. The provider can perform a step in the chain while the regulated entity retains the duty.

Attribution gets harder when the causal path crosses a model provider, tools, data sources, hosting, and the deploying organisation. NIST notes that generative-AI value chains contain many third-party components and data sources. This reduces transparency and makes behaviour difficult to attribute to one source. EIOPA consequently points insurers toward provider information and assurances. Where intellectual-property constraints limit governance or explainability, it also identifies complementary measures such as contract clauses, external audits, due diligence, testing, and monitoring. These measures can add evidence; they do not guarantee a complete causal record.

What the data and control chain can prove

Evidence quality depends on more than what was logged. It also depends on who controlled the record, how long it was retained, and whether another reviewer can inspect and verify it.

For high-risk AI systems within its scope, the EU AI Act requires capabilities for automatic event logging. It also requires providers and deployers to retain automatically generated logs that are under their control, generally for at least six months. The control qualifier matters: a duty over records held by one participant does not make every record across the supply chain available to every other participant.

Structured, persistent events can still fall short of transferable audit evidence. ainclave documents persistent OCSF event records, while also stating that reviewer export and cryptographic anchoring are not currently available. The records can be readable evidence inside the system without yet being an independently transferable, cryptographically anchored audit record. See persistent event data and its evidentiary limits for that product-specific boundary.

The proof limit follows the data path. An operator may see an event but lack the provider context needed to interpret it. A provider may hold relevant records but restrict access. A record may exist yet fall outside retention, contract, or export mechanisms. Adjustment can rely only on evidence that can be connected, retained, and reviewed. The remaining gaps must stay visible.

How claim adjustment ends and which counterconditions apply

A well-documented chain does not predetermine the outcome. It gives the insurer a record against which to apply the actual contract and applicable law.

NAIC Model Regulation 902 describes a model process in which, after proof of loss, an insurer advises acceptance or denial, grounds a denial in policy conditions or exclusions, and tenders payment after liability is affirmed when the amount is determined and undisputed. Because Regulation 902 is model text, local adoption and applicable rules must be checked. The mechanism still separates three possible states: acceptance, a reasoned denial, and payment of an affirmed and determined amount.

Adjustment can also depend on cooperation and recovery rights. Beazley sample wording grants investigation rights, requires cooperation and consent before admissions, payments, obligations, or settlements, and preserves rights of recovery. Actions taken after the incident can therefore affect the available investigation and recourse, subject to the wording that actually applies.

A breached condition does not always end the causal analysis. In its jurisdictional scope, section 11 of the UK Insurance Act 2015 limits reliance on non-compliance with certain risk-reduction terms where the insured shows that the non-compliance could not have increased the risk of the loss that occurred. This is not a general rule for every contract or jurisdiction, and it is not legal advice. It is a countercondition to simplistic reasoning that any control failure automatically resolves the claim.

The practical end point is an evidence chain with a declared state at every link: system boundary, responsible party, cause, period, amount, and reviewable record. Inspect where that chain is supported and where it contains an explicit gap. That distinction gives CISOs and insurers a defensible basis for investigation and adjustment without implying that a particular loss is covered.