How to Create an AI Insurance Agent Product in Openkoda PAS

Can You Insure an AI Agent?

An AI agent is not a building, a vehicle or a cargo. It is software that acts: it calls tools, spends money, writes things that go out under your customer’s name, and does all of it faster than anyone can watch. Insurers are being asked to cover exactly that, and the first instinct is usually that it needs a new system.

It does not. What it needs is an answer to the only question a policy administration system really asks about a new line of business: can you describe the thing you are insuring as a list of attributes? If you can, everything downstream - the submission form, the rating, the underwriting rules, the documents - follows from that description, because none of those components know or care whether the attributes describe a roof or a language model.

For an agent, the list turns out to be short and uncomfortably specific:

Who made the model, and which version is pinned. An agent whose model changes underneath you is a different risk next month.
How much autonomy it has, from drafting a suggestion for a person to acting unsupervised.
How much money it can commit in one action.
How many tools and interfaces it can reach, and what class of data it touches.
Whether guardrails are in place, and what it scored on a certified baseline evaluation.

That is an underwriting submission. The rest of this article is what a product built on it looks like, and how to add to it. For the market context behind the cover itself, there is a separate piece on AI agent insurance products.

The whole thing is on video as well, if you would rather watch someone do it than read the steps. It covers the same nine steps in one pass; the written version below is the one to keep open in another window while you build your own.

How to Build an AI Agent Insurance Product

Before you start, you will need: a policy administration system with a product builder, and an account that can reach it. The product here is an existing AI liability product; the walkthrough reads it, then adds a referral rule of its own.

Step 1 - Find It in the Catalogue

The first thing worth noticing is where this product lives: in the same list as motor, home, travel, marine and cyber, with the same status, the same version and the same Open button.

The product catalogue listing aviation, bicycle, property, cyber, marine, motor, household, travel and pet products, with AI Liability among them — The book of products - motor, home, travel, cyber, marine - and AI Liability sitting among them as an ordinary row.

It is not a special case bolted onto the side of the system. It was built with the same AI Product Builder that built everything else on that list, which is the whole claim this walkthrough is testing.

Step 2 - Read the Shape of the Product

Open it, and the overview is the usual six boxes: what it insures, its plans and options, its forms, its rating, its underwriting rules, its workflows.

The AI Liability product overview: one risk type with eight coverages, one plan, one form, rating active, five underwriting rules — One insured thing, eight coverages, one form, rating active, five underwriting rules. The same six boxes every product on that list has.

Worth reading the rating box closely rather than skimming it: Active · 0 factor tables · 2 fee/tax. This product prices with formulas rather than with lookup tables, a legitimate choice for a line with no credible loss history to build a table from, and one that matters when you get to Step 8.

Step 3 - Describe the Agent as a Thing You Can Insure

This is the step the whole product rests on. The risk item is an Insured AI Agent, and its attributes are the ones that decide the risk.

The Insured AI Agent risk item with its attributes: agent name, model provider, pinned model version, autonomy level L0-L4, monetary authority per action, tools and APIs it can call, data classification, guardrails in place, certifications held and certified baseline eval score — The whole argument in one table: an agent described the way a building or a vehicle is - provider, pinned version, autonomy level, spending authority, tool reach, data class, guardrails, eval score.

Three columns are worth deliberate thought when you write your own:

Type. Monetary authority is a currency, tool reach and the eval score are numbers, guardrails is a boolean. Getting these right is what later lets a rule say greater than 100,000 rather than comparing text.
Required. The five that decide whether you will write the risk at all - provider, pinned version, autonomy, authority, data class - are mandatory. Certifications are not.
Used in rating. Nothing is ticked here, which is consistent with the formula-based pricing from Step 2: this column marks fields used as dimensions of a lookup table, and this product has none.

Pinned model version deserves its own note, because it is the attribute a general-purpose configuration screen would never suggest and an underwriter would insist on. Without it you have insured a moving target.

Step 4 - Write Cover That Matches the Risk

Underneath the attributes sit the coverages, and they are as specific to an agent as the attributes are.

The coverages: performance and E&O liability, unauthorised autonomous action, bias and discrimination, privacy breach via agent, prompt injection and security, output IP infringement, regulatory defence and remediation costs, each with a limit — And cover written for what this thing actually does wrong: acting without authority, discriminating, being prompt-injected, infringing somebody's IP.

Read that list as a loss taxonomy rather than as configuration: unauthorised autonomous action, bias, privacy breach, prompt injection, IP infringement, regulatory defence, remediation. Each is a way an agent hurts somebody, and each carries its own limit. Only performance and E&O is mandatory; the rest are selectable, which is how a product covers a range of buyers without becoming several products.

Step 5 - The Questions Come From the Attributes

Because the agent is described as structured attributes rather than in prose, the submission form is generated from them.

The product's Forms tab listing one public, active New Business / Submission form — Because the attributes are structured, the submission form is generated from them - one form, public, live, and the same questions whether a person fills it in or another system posts it.

The form is public and active, and it is the same set of questions whether a broker fills it in or another system posts the submission in. That is the practical pay-off of Step 3: answers arrive as data that rules can read, not as a paragraph in an email that somebody has to re-key.

Step 6 - Read the Underwriting Rules

Rules come in three groups - decline, refer, auto-approve - and every one of them is written against an attribute from Step 3.

Underwriting rules in three groups: decline an unguarded agent on regulated PII or a fully autonomous agent without guardrails, refer high monetary authority or a low eval score, auto-approve a guarded agent with low authority — Three groups - decline, refer, auto-approve - written against the agent's own attributes. Ordinary underwriting judgements about a new kind of thing.

They read like underwriting, not like software: decline an unguarded agent that touches regulated personal data; decline a fully autonomous agent with no guardrails; refer anything that can commit 100,000 in a single action; refer an agent whose certified baseline score is under 70; let a guarded agent with low spending authority straight through. It is the same automated underwriting machinery every other product on the catalogue uses.

Note that the declines combine two conditions with AND. Neither fully autonomous nor no guardrails is a decline on its own. It is the pair that is uninsurable, and that is an appetite decision somebody made deliberately.

Step 7 - Add a Rule of Your Own

Appetite changes faster than anything else on a new line, so this is the part you will do most often. A rule is four fields: the attribute, the comparison, the value, and the reason.

The inline rule editor with the attribute, the comparison, the value and the reason an underwriter will see filled in — A rule is four fields: the attribute, the comparison, the value, and the reason an underwriter will read. There is no name field - the reason is the rule's identity.

There is no name field, and that is worth knowing rather than working around: the reason is the rule’s identity. Write it as the sentence an underwriter should read when the referral lands in their queue. “Wide tool access - refer for scope review” tells them what to do; “tool rule 3” does not. A rule saved with no condition at all is silently dropped, so fill the condition before you save.

The saved referral rules now including tools and APIs greater than 10, with a confirmation that six rules were saved — Saved, and live from that moment: the new referral sits with the two that were already there, and the product now carries six rules.

From that moment every submission for this product is measured against it. There is no release to schedule.

Step 8 - Make the Product Check Itself

Before any of this goes live, validate it. The check reads the whole configuration and then prices a test quote with the real rating engine.

The launch readiness panel reporting ready to launch with no blocking problems, a test quote price, and three non-blocking warnings about minimum premium, payment plan and carrier program — Validate reads the whole configuration and prices a test quote with the real engine - then separates what would stop a launch from what is merely worth a look.

The distinction it draws is the useful part: blocking problems versus worth checking. The three warnings here are all real and none of them stops a launch - no minimum premium, so a low-exposure risk could price near zero; no payment plan, so invoices cannot be scheduled; no carrier program, so policies issue direct with no bordereaux. On a brand-new line the first of those is worth acting on before the first quote.

The passed checks: structure, rating formulas referencing only fields that exist, the form and its question count, the underwriting rules, document templates, and the priced test quote — What passed, component by component - including the check that every rating formula references a field that actually exists, and a quote the engine could really price.

The rating line is the one to read twice: two active formulas reference only fields that exist. On a formula-priced product that is the check that catches the most common configuration defect, a formula referring to an attribute that was renamed or never added, and it is why the priced test quote at the bottom is evidence rather than decoration.

Step 9 - And All of It Is a Version

One last thing, at the top of the product: a version number, with an effective date against it.

The product's version table showing v1.0 as current, effective from January 2026 — Every bit of it is versioned: what priced a policy last quarter is still here, and today's change becomes the next version rather than an edit to history.

This matters more on an emerging line than on a settled one. Appetite for AI risk will change several times in the next two years; versioning is what lets it change without rewriting the history of what you already sold.

Insuring something genuinely new tends to be discussed as a systems problem, and it is usually a description problem. Once an AI agent is written down as ten attributes - who made it, what version is pinned, how autonomous it is, what it can spend, what it can reach, whether it is guarded - the rest of the product is the same machinery every other line uses: cover with limits, a form generated from the attributes, rules that read them, a formula that prices them, and a version around the lot.

The interesting work is not the configuration. It is deciding that pinned model version belongs on the schedule, and that a fully autonomous agent without guardrails is outside appetite. Those are underwriting judgements, and they are the part a product builder cannot make for you.