Does AI insurance cover a systemic model failure across many clients at once?

Most AI liability underwriting so far has priced the risk of an individual deployer's own configuration or oversight failure: one operator, one agent, one bad outcome. A different and structurally harder problem sits underneath that pricing assumption. A large share of AI agents in production today are built on a small number of foundation models. A defect, a training data issue, or an extended outage in one of those models is a single root cause capable of producing correlated claims from thousands of unrelated businesses at the same time. This article explains why that scenario, aggregation risk, is different from an isolated agent failure, what the cyber insurance market's earlier experience with systemic risk suggests about where AI cover is heading, and what to actually check in your own policy wording.

Why a shared foundation model changes the risk shape

Traditional liability pricing assumes losses across a book of policyholders are largely independent: one business's professional error does not make another, unrelated business more likely to make the same error at the same time. AI agent liability breaks that assumption in a specific, structural way. A large share of production AI agents, across sectors and across unrelated businesses, are built on a small number of foundation models supplied by a handful of providers. If one of those models develops a systematic defect, degrades in a specific way after an update, or experiences an extended outage, every business whose agent depends on that model can be affected by the same root cause at effectively the same time.

This is a different failure mode from the scenarios most AI liability coverage was designed around. An individual agent's erroneous execution, discussed in our earlier analysis of the autonomous action coverage gap, is an isolated event traceable to one operator's configuration, scope, or oversight choices. A foundation-model-level defect is not isolated in this way. It is a single cause with the technical potential to generate simultaneous claims from a large number of a carrier's unrelated policyholders, all citing the same underlying event.

What the cyber insurance market already learned about this problem

The cyber insurance market faced a structurally similar problem earlier and has already built a market-standard response worth understanding by analogy. State-backed and broadly propagating cyberattacks, most notably the NotPetya incident, demonstrated that a single attack could generate correlated claims across many policyholders simultaneously, in ways that broke the independence assumption cyber pricing had relied on. In response, the Lloyd's market adopted a standard requirement that syndicates writing standalone cyber cover either exclude, or set an explicit and quantified limit on, their exposure to state-backed catastrophic cyberattacks.^[1]

No equivalent, market-standard clause addressing systemic AI model risk specifically has been published by AIUC, Munich Re, Armilla, Lloyd's, or any other carrier active in this space as of mid-2026. This is worth stating plainly rather than implying otherwise: the AI liability insurance market is at an earlier stage of this specific problem than the cyber market was when its state-backed cyber exclusions were introduced, and it would be inaccurate to describe systemic AI exclusions as an established market feature. What can be said with confidence is that the underlying actuarial concern, a single, shared technology dependency capable of producing correlated loss across an insurer's book, is the same class of problem the cyber market already had to solve, and AI carriers with reinsurance-scale capacity, Munich Re foremost among them given its dual role as a reinsurer and a direct AI insurer through aiSure, are the most likely to address it first as written policy volume grows.

Why this matters more for agentic systems than for standard AI outputs

Aggregation risk is not unique to agentic AI, but agentic deployment sharpens it. A standard AI output failure, a single hallucinated answer, typically causes a discrete, bounded loss to one customer of one deployer. An agentic system that autonomously executes actions, discussed at length in our companion piece on the autonomous action coverage gap, can compound a model-level defect into a larger number of executed, consequential actions before anyone notices the underlying cause. If the same foundation-model defect that produces a wrong answer in a chat interface instead produces a wrong autonomous transaction, a wrong autonomous booking, or a wrong autonomous communication across every deployer relying on that model at that moment, the aggregate loss a single root cause can generate scales with the number and consequence of the actions agents were authorised to take, not merely with the number of affected conversations.

How this shows up in your policy wording, whether you have noticed or not

The mechanism through which aggregation risk actually affects what you can recover is the policy's definition of an occurrence, combined with its per-occurrence and aggregate limits. Most liability policies cap what the insurer pays for a single occurrence, and separately cap total payouts across the policy period through an aggregate limit. Whether a correlated, foundation-model-level event that affects several of your own AI-enabled products or business units at once is treated as one occurrence, subject to a single per-occurrence limit shared across all the resulting claims, or as multiple separate occurrences, each potentially attracting its own limit, is a question most current AI liability policies do not answer with the clarity this scenario deserves, because the policy language was largely drafted before this specific failure mode was a live underwriting consideration.

This is not a hypothetical drafting nuance. If your business runs three separate AI-enabled products, each built on the same underlying foundation model, and a defect in that model causes correlated failures across all three simultaneously, an occurrence definition that treats this as a single event could leave you facing an aggregate loss well in excess of what a single per-occurrence limit was sized to absorb, even though your total policy limit looks adequate on the declarations page for what appears to be an isolated incident.

What insurers are doing about it today

In the absence of a published, standard systemic AI exclusion, carriers currently manage this exposure primarily through the structural tools already available to them: conservative per-occurrence and aggregate limits sized with correlated loss in mind, and reinsurance treaties that spread a primary insurer's exposure to a large, correlated event across multiple reinsurance partners. Munich Re's position as both a reinsurer and a direct AI insurer through its aiSure product gives it visibility into aggregation exposure that a smaller, primary-only carrier does not have to the same degree.^[2] Armilla's coverage, structured through Lloyd's, similarly benefits from Lloyd's market-wide capacity and risk-spreading mechanisms, though this is a general feature of the Lloyd's market structure rather than an AI-specific systemic risk product.^[3]

What underwriters are increasingly asking for, consistent with the evidence-gathering trend described in our analysis of whether AI insurance covers third-party tool and plugin failures, is visibility into which foundation models and providers an applicant's AI systems actually depend on, and whether that dependency is concentrated in a single provider or diversified. An applicant that can show model diversification, or at minimum a documented fallback plan if a primary foundation model degrades or becomes unavailable, is providing exactly the kind of evidence that supports more precise aggregation-aware pricing rather than a conservative default applied because the underwriter cannot see the dependency at all.

What to check in your own policy now

Three checks are proportionate for any enterprise carrying meaningful AI liability exposure across more than one product or business unit. First, ask your broker directly how the policy defines an occurrence, and specifically whether a correlated failure across multiple of your AI-enabled products, traced to the same underlying foundation model issue, would be treated as one occurrence or several. Second, request the exact wording of any aggregation clause, systemic risk exclusion, or catastrophe-style carve-out in the policy, and have it reviewed against a scenario where your primary foundation model provider experiences a defect or extended outage. Third, confirm your aggregate limit was sized with a correlated, multi-product failure scenario in mind, not only the isolated single-agent failure that most current underwriting conversations still default to discussing. For the regulatory dimension of concentration risk in AI supply chains, see the GPAI model deployer exposure guide on agentliability.eu, and for how a certification assessment documents multi-agent and multi-model dependencies as underwriting evidence, see certifying multi-agent systems on agentcertified.eu.