AI Agent Insurance Products: The New Wave, and How to Launch One | Openkoda

In February 2024 a British Columbia tribunal ordered Air Canada to pay a passenger CA$812. The airline’s website chatbot had told Jake Moffatt he could book a flight and claim a bereavement discount retroactively. He couldn’t. Air Canada argued that the chatbot was, in effect, responsible for its own answers. The tribunal did not accept that, and pointed out the obvious: the bot was part of the airline’s website, so the airline owned what it said.

The money was trivial. The principle was not. Moffatt v. Air Canada settled, cheaply and early, the question every business now has to answer at much larger scale: if your AI gets it wrong, you pay.

And that was a chatbot answering a question. The systems being deployed in 2026 do things. They issue refunds, place orders, move money, change records, write and ship code, and make decisions inside workflows where nobody reads every step. The failure modes are bigger, faster and harder to spot. Insurers worked this out well before most of their customers did, and they have responded in two directions at once: writing AI out of the policies businesses already hold, and building a new market to sell back.

Standard policies are being closed to AI on purpose

The clearest signal came from Verisk, whose ISO policy forms sit underneath a very large share of the world’s property and casualty business. Verisk filed a family of generative AI exclusion endorsements that carriers could start attaching to commercial general liability renewals from 1 January 2026:

• CG 40 47. Excludes bodily injury, property damage and personal and advertising injury arising out of generative AI, under both Coverage A and Coverage B.
• CG 40 48. The narrower version, Coverage B only, aimed at advertising and personal injury claims from AI-generated content.
• CG 35 08. Applies the same exclusion to products and completed operations.

They are optional forms. Carriers choose whether to attach them, and plenty have chosen to. Separately, the Financial Times reported that AIG, Great American and WR Berkley were seeking regulatory approval to exclude AI-related liabilities from corporate policies, with units of Berkshire Hathaway, Travelers and Chubb moving in the same direction.

Technology errors and omissions, the line closest to the risk, is not the safety net people assume either. Tech E&O was written for deterministic software and human-delivered services. Where AI is addressed at all, it is often addressed by sublimit. Armilla has pointed to general technology policies that carry a $25,000 sublimit for AI-related liabilities inside cover that otherwise runs to $5m.

Even the model developers feel it. OpenAI has reportedly arranged roughly $300m of cover for emerging AI risks through the broker Aon, against litigation claiming multiples of that figure. When insurers will not comfortably cover the companies building the technology, the message to everyone deploying it is not subtle.

The reasoning is straightforward. Insurers price from loss history, and there isn’t one. The losses that do exist are correlated in an unpleasant way: if a widely used foundation model degrades or gets jailbroken, thousands of policyholders can have a bad day simultaneously. That is a hard risk to model and an easy one to exclude.

Excluding it, though, leaves a gap that businesses very much want filled. Deloitte’s Center for Financial Services expects AI-specific insurance premiums to grow at roughly 80% a year and reach about $4.8bn globally by 2032. Testudo, one of the new specialist underwriters, says generative AI litigation is up 137% year over year. The exclusions and the new products are the same story told from two ends.

Five shapes the new products take

Almost everything on the market today is a variation on one of five designs. They differ in what triggers a payout, how the risk is assessed, and who actually buys the policy.

1. Affirmative AI liability

Armilla is a managing general agent and Lloyd’s coverholder set up specifically for AI risk. Working with Chaucer and other Lloyd’s underwriters, it launched a standalone AI liability policy in spring 2025 that says out loud what standard policies now exclude: hallucinations, model drift, inaccurate outputs, data leakage, and claims tied to defamation, confidentiality breaches and regulatory violations. Limits reach $25m per organisation.

What makes it interesting is the trigger. Rather than waiting purely for a lawsuit, Armilla underwrites the model’s expected performance and responds when it degrades from that baseline. Chief executive Karthik Ramakrishnan has described it plainly: “We assess the AI model, get comfortable with its probability of degradation, and then compensate if the models degrade.” A chatbot that was right 95% of the time at bind and drops to 85% is a covered event, not a support ticket. Armilla has noted that a policy of this shape could have responded to the Air Canada loss.

It is not a blank cheque. Tom Graham of Chaucer put the underwriting stance simply: “We will be selective, like any other insurance company.”

2. A performance guarantee that pays on a measurement

Munich Re’s aiSure takes the idea further and turns the model itself into the rated object. Munich Re runs technical due diligence on the AI, quantifies how likely and how severe underperformance is, and prices the premium off that robustness assessment. The cover indemnifies consequential financial loss: lost revenue, business interruption costs, legal damages.

Claims settle on measurable performance data rather than through conventional loss adjustment, which makes it behave much more like parametric insurance than like a liability policy. It is model-agnostic, so generative systems are in scope alongside classical machine learning. Munich Re has also put the product into other people’s hands, partnering with Mosaic to reach AI vendors.

3. Certify first, insure second

A third group treats the audit as the product and the policy as what you get afterwards.

The Artificial Intelligence Underwriting Company (AIUC) launched in July 2025 with a $15m seed round led by Nat Friedman’s NFDG, alongside Emergence Capital and Terrain. Its AIUC-1 standard is pitched as SOC 2 for AI agents: a security and risk framework covering the technical, legal and operational safeguards enterprise buyers ask about. Vendors certify to get through procurement, then buy insurance that protects their customers if the agent fails. The certificate opens the door; the policy is what makes the promise credible.

Klaimee, out of Y Combinator’s spring 2026 batch, raised $5.5m in July 2026 to do the same thing for autonomous agents specifically. Every agent submitted for cover goes through automated pre-bind testing: adversarial attacks, penetration testing, behavioural analysis, permission validation and operational stress testing. The output is an insurability score and a remediation report, and then an insurance-backed performance warranty. Klaimee’s argument for existing is that tech E&O and cyber were “designed around deterministic software, data breaches and services delivered by humans”, which is not what an autonomous agent is.

4. An add-on that rides an existing small business policy

The other four designs mostly serve AI vendors and large deployers. HSB, the specialty insurer inside Munich Re Group, went after the long tail instead. On 18 March 2026 it launched AI Liability Insurance for small and mid-sized businesses, covering defence, settlement and judgment costs for third-party claims of bodily injury, property damage, or personal and advertising injury arising from the business’s own AI use. The examples HSB gives are deliberately mundane: an AI-controlled HVAC system that creates a slip hazard, a chatbot that generates faulty appliance installation instructions, AI-written marketing copy that draws a copyright or defamation claim.

HSB’s own survey of 1,000 businesses with 1 to 500 employees found 74% already using AI and 91% planning to. “All types of businesses are using AI to do things more quickly and efficiently,” said Timothy Zeilman, the company’s Global Head of Product Ownership. “At the same time, the AI transformation brings new legal and financial exposures.”

The distribution choice matters as much as the wording. HSB does not sell direct. The coverage attaches to the business policies of its carrier partners, which is a much faster route to a million small businesses than building a brand from scratch.

5. A specialist MGA with Lloyd’s capacity

Testudo launched as an MGA in January 2026 focused on generative AI liability for both vendors and deployers, covering third-party claims from AI outputs including hallucinations and model drift, plus legal costs and damages. By March 2026 it had expanded its programme to $9.25m per insured with Apollo, Atrium and QBE behind it. Peta Kilian, senior innovation underwriter at QBE, framed the appeal for capacity providers as the tooling rather than the wording: helping clients with “AI risk scoring and reporting tools”.

What the five have in common

Look past the differences and the same five product decisions keep reappearing:

• Underwriting is a technical test, not a questionnaire. The rating inputs are eval results, red-team findings, permission scopes and observed accuracy, not headcount and industry code.
• The trigger is a number, not just a lawsuit. Several of these products pay when a measured metric crosses a threshold, which is closer to parametric cover than to traditional liability.
• Certification is part of the product. The audit is a revenue line and a sales tool, not an internal step. Buyers want the certificate as much as the cover.
• Distribution sits next to the thing being insured. HSB rides carrier policies. AIUC and Klaimee attach to a vendor’s enterprise sales cycle. Nobody is waiting for someone to search for AI insurance.
• Data keeps flowing after bind. Audit logs, telemetry and model version changes are policy conditions, because a model that was underwritten in March is a different risk in September.

Why this is awkward on a traditional core system

Every one of those five decisions cuts against the grain of a legacy policy administration system.

Rating engines in most cores are built around a stable set of rating factors, keyed to things like industry classification, revenue and headcount. An AI liability product wants to rate on an insurability score, an accuracy baseline, a model identifier and a permission scope, and it wants to add a new factor next quarter when the market works out what actually predicts loss. Claims modules assume a loss event and an adjuster. A parametric performance trigger wants to open, evaluate and pay from a measured data feed. And the product itself will change repeatedly in its first two years, because nobody knows yet what the right wording is.

That last point is the real constraint. Product change cycles of three to six months are normal in this industry, and they are fatal in a market where a competitor launched in January, expanded capacity in March and doubled its limits by summer. Meanwhile the capacity partner behind you still wants clean, conventional bordereaux every month, in the format their actuaries already use.

How to launch one on Openkoda

Openkoda is a configurable insurance platform rather than a fixed set of products, which is what this kind of launch needs. The path looks like this.

• 1. Describe the product in plain English. The AI Product Builder turns a written brief into a proposed change-set: coverages, limits, rating structure, underwriting rules and workflow. You see a before-and-after diff, approve it, and it applies transactionally with a version history. Business people write the product; nobody waits for a release.
• 2. Rate on the factors this risk actually has. The rating engine takes whatever factors you define, including technical ones like an insurability score, an accuracy baseline or a model family. Rates live in editable tables with effective dating, so you can test a change and schedule it rather than filing a ticket.
• 3. Underwrite from test results, not a proposal form. Feed certification and eval outputs in through the API, auto-accept what clears your rules, and route the rest to a queue. The underwriting workbench shows referred cases with the evidence attached, and document generation produces the certificate and policy pack from live data.
• 4. Sell it where the agent is bought. This cover is almost always bought alongside something else: an AI vendor’s contract, a broker’s package, a carrier’s SME policy. Openkoda exposes the same product as a branded form, a partner-embedded checkout and an API, which is the standard embedded insurance pattern applied to a new class of risk. If that model is new to you, start with what embedded insurance is.
• 5. Handle the parametric part properly. A performance trigger needs a claim that can open itself. The workflow engine can accept a monitoring feed, evaluate it against the policy threshold, open a claim in claims, apply reserves and route approvals, with a human in the loop wherever you want one.
• 6. Report to capacity and to yourself. Bordereaux go out in the formats carriers accept. Reporting lets your team ask about accumulation and loss ratio in plain English against the live book, which matters when your exposure is concentrated in a handful of foundation models.

Underneath all of it, tenant isolation, role-based access and a full audit trail are part of the platform rather than an add-on, and you can run it in your own environment or on managed cloud. For a product where the regulator and your capacity provider will both ask who changed what and when, the audit trail is not a nice-to-have.

A worked example

This one is illustrative rather than a live account, but the shape is realistic.

A coverholder wants to offer an agent performance warranty to companies selling AI customer-service agents. The vendor buys it; the vendor’s enterprise customers are the ones it reassures. Cover pays when the agent’s measured resolution accuracy falls more than ten points below the level certified at bind, and when a third party brings a claim over an agent’s output.

Week one and two: the product is written as a brief and built with the Product Builder, then hand-tuned. Rating starts simple, on certified accuracy band, agent permission scope and annual interaction volume. Week three: the certification partner’s test output is wired in over the API, straight-through rules are set for clean scores, and everything else goes to the underwriting queue. Week four: the quote and bind journey is published as a branded form and as an embedded API the vendor drops into its own contracting flow. Week five: the monitoring webhook is connected, and a workflow opens a claim automatically when the accuracy feed breaches the threshold, with a two-person approval before any payment. Week six: bordereaux templates are agreed with the capacity provider, dashboards go live, and the first binder goes out.

Six weeks is not a stretch when nothing in that list requires a code release. It is out of reach when every one of those steps is a change request. That gap is the whole argument for configuring products rather than developing them, and it is why most of the interesting activity here is coming from MGAs and coverholders rather than large carriers.

Five things to get right before you launch

• Define the failure precisely. “The AI made a mistake” is not a trigger. “Measured accuracy on the agreed test set falls below X for Y consecutive days” is. Everything downstream, from pricing to claims, depends on that sentence being tight.
• Take accumulation seriously. If four hundred of your insureds are running on the same foundation model, a single bad release is one loss event wearing four hundred hats. Track model family as an exposure dimension from day one, not after the first surprise.
• Re-underwrite on model change. A version upgrade can undo the assessment you priced from. Make notification a condition and build the re-test into the workflow.
• Check your own book for silent AI. While you are writing a new AI product, your existing liability and E&O portfolio may already be covering AI losses without pricing for them. Decide that deliberately.
• Follow the regulation as it lands. A majority of US states have adopted the NAIC model bulletin on insurers’ use of AI or guidance close to it, and the EU AI Act is phasing in. It governs how you use AI as well as what you cover, so governance and audit need to be real, not documented.

Closing thoughts

Two years ago insuring AI agents was a conference topic. Today there are affirmative liability policies at Lloyd’s with $25m limits, parametric performance guarantees from the world’s largest reinsurer, certification standards with insurance attached, and an SME add-on distributed through carrier partners. At the same time, the standard policies that quietly covered some of this are being closed off, form by form. Both trends push in the same direction: if you want this risk covered, someone has to build a product for it.

The teams that win here will not be the ones with the best wording at launch. Nobody has that yet. They will be the ones who can rewrite the wording, the rating and the triggers four times in two years without a migration project each time. That is a platform question more than an underwriting one, and it is what Openkoda is built for: products, rules, rating and workflow as configuration you own, on published flat pricing with no percentage of your premium attached.

If you are scoping an AI liability product, book a demo and bring the wording you are working on. It is a more useful conversation than a feature list.