Agentic AI Insurability & Risk Transfer White Paper 2026

Chapter 1: The New Insurance Question: What Exactly Is Being Transferred?

The meeting usually starts with the wrong question.

A business leader asks, "Are our AI agents insured?" A broker hears a version of it from a client. A CFO asks whether the new AI program changes premium. A CTO asks whether logs will be enough if something goes wrong. Counsel asks whether the vendor agreement or the company's own policy responds. A board member asks whether oversight records are adequate. Everyone wants a direct answer.

The direct answer is not available because the question is not precise enough.

Insurance does not usually begin with "the AI system." It begins with a named or described insured, a policy line, a covered event, conditions, exclusions, limits, sublimits, notice obligations, loss measurement, and claim evidence. Even before one reaches the policy text, there is a factual problem: what happened? Who did it? What was authorized? What object caused or shaped the loss? Was the event cyber, professional error, product failure, governance failure, employment practice, media/IP, crime, or something else? What evidence exists?

Agentic AI compresses those questions into one operational surface. A single workflow may involve a model, a prompt, a planning step, a tool call, an API, a vendor platform, a cloud service, a human reviewer, a business owner, a customer-impacting action, and a remediation record. After a loss, the enterprise may call that an "AI incident." The insurance file cannot stop there.

Consider a simple support workflow. A company deploys an AI agent to handle customer account requests. It can approve refunds under a threshold, update account records, trigger an external payment or CRM API, and send customer-facing notices. A customer asks for a refund after a disputed transaction. The agent reads the account history, selects a response, updates the account, triggers an external API, and sends a notice. Something goes wrong. The wrong customer receives the notice. The refund is processed twice. An account flag is changed incorrectly. A downstream partner receives an instruction that causes a service interruption. A complaint follows.

The first question is not "was AI involved?" Of course it was. That fact is too broad to settle anything. The useful questions are:

• Who is the insured subject?
• Which policy line could be implicated?
• What work object generated or shaped the loss?
• What authority was delegated to the workflow?
• Which human role reviewed, approved, supervised, or accepted the outcome?
• What model, tool, API, vendor, or cloud dependency participated?
• What event trigger matters for the policy line?
• What exclusion, limitation, or sublimit may need to be reviewed?
• What evidence exists to reconstruct the event?
• What remediation was performed and by whom?

Those questions reveal the core architecture of agentic AI insurability. The company may be the policyholder. A director or officer may be relevant if the loss turns into an oversight, disclosure, or governance question. A professional may be relevant under professional liability if the workflow supported advice or client service. A vendor or service provider may be relevant under contract, technology liability, or indemnity analysis. The AI agent may be central to the facts. But the AI agent is usually not the insured legal subject. It is not the policyholder. It is not usually the legal person whose liability is being insured. It is part of the work object that must be reconstructed.

This separation sounds simple until a loss occurs. In ordinary software incidents, the organization may identify the application, transaction, user, and failure mode. In agentic workflows, the failure may sit across a chain: a model output was plausible, a planner selected a tool, an API call executed, a human reviewer relied on a summary, a vendor service returned stale data, and the final business action caused loss. The "object" is not one component. It is the bounded work unit that connects authority, action, dependency, evidence, accepted outcome, and remediation.

That is why the phrase "AI risk transfer" can mislead. Risk transfer does not transfer a vibe. It transfers defined risks through policy language and market mechanisms. If the enterprise cannot say whether the risk object is model performance, cyber abuse, professional reliance, product underperformance, governance failure, customer harm, fraud, or vendor dependency, then it cannot have a serious conversation about transfer. It can only ask for a broad reassurance that the market is not in a position to give.

Public market sources already show this narrowing. Verisk/ISO has described form-development work around generative AI liability exposure in general liability filings, which signals that insurance infrastructure is trying to create language for boundaries rather than treating all AI exposure as one thing. [1] QBE has announced AI-focused cyber coverages and published LLMjacking guidance, which signals that AI-linked cyber risk can be addressed through a cyber lens while still requiring access, usage, and incident evidence. [2] [3] Munich Re describes AI performance insurance structures, which signals that some AI performance risk can be defined as a covered or warranty-like object. [4] These are different signals. They do not answer the same question.

If a customer refund agent causes a loss, a model-performance product might ask whether an AI model failed a defined performance promise. A cyber policy might ask whether there was unauthorized access, credential abuse, data compromise, or compute misuse. A professional liability policy might ask whether a professional service error occurred. A D&O policy might ask whether governance or disclosure failures are implicated. A general liability or product liability context might ask whether a third-party injury or property damage theory exists, subject to policy language. The agentic workflow sits across those questions, but none of them is identical to "the AI system."

This is the first principle of the paper:

The insured subject and the agentic risk object must be separated.

The insured subject is the legal person or organization whose risk may be addressed by a policy. The agentic risk object is the bounded work unit that generated, shaped, or obscured the loss. The two must connect, but they are not the same.

The second principle is that evidence must be separated from conclusion. Logs, traces, prompts, outputs, API records, and cloud usage records may be useful. They do not by themselves determine coverage, causation, liability, or claim outcome. They are inputs into reconstruction. For an agentic workflow, useful evidence must connect what happened technically to who had authority, who reviewed or accepted the outcome, which dependency participated, what policy line is implicated, and what remediation closed or failed to close the event. NIST and CISA incident response materials support the importance of structured timelines, response coordination, containment, recovery, and remediation records, but they do not turn those records into claim approval. [10] [11]

The third principle is that market signal is not market consensus. A product page, filing description, broker report, or industry research paper can show that a category is emerging or being bounded. It cannot be stretched into a universal statement that AI is covered, excluded, insurable, uninsurable, accepted, or rejected. The market is not making one decision about AI. It is sorting AI into narrower objects.

That sorting changes enterprise preparation. If a company wants to discuss risk transfer for an agentic workflow, it should not begin with a slide listing model names. It should begin with the insurance transfer question stack:

This table is not an underwriting standard. It is a thinking tool. Its purpose is to stop the enterprise from collapsing the whole loss into "AI." It gives the broker, insurer, counsel, risk team, and engineering team a common starting point.

The hardest part is cultural. Organizations like broad labels because they are easy to govern at the dashboard level. "AI system" is a broad label. "Agentic workflow" is a broad label. "LLM incident" is a broad label. But insurance is often forced to ask a narrower question after the fact. What was the action? Who authorized it? What line is implicated? What evidence survived? What changed after the event? What can be reconstructed?

Agentic AI makes that question urgent because the work is not only predictive. It can be delegated, tool-using, workflow-shaping, customer-facing, vendor-dependent, and partially autonomous. The final output may be less important than the path by which the work was authorized, executed, accepted, and remediated.

This is where the compliance and auditability white papers will later help. The compliance white paper gives language for lifecycle objects such as authority boundary, accepted outcome, evidence partition, substitution conformance, and remediation closure. The auditability and assurance white paper gives language for evidence chains and auditability. But those are not the opening argument. The opening argument is market-facing: if the insurance question is unclear, the enterprise has not yet defined the thing it is trying to transfer.

Once that becomes visible, the next chapter can ask what the market is doing with the ambiguity. It is not answering with one yes or no. It is covering some AI risks, excluding or bounding some, limiting some, leaving some silent, and packaging some model-performance risks in narrower products. That split is the market's way of telling enterprises that the object problem is real.

Chapter 2: What the Market Is Already Doing: Cover, Exclude, Sublimit, or Leave Silent

The AI insurance market is not a clean story. That is the point.

One buyer hears that AI insurance products exist. Another hears that insurers are writing AI exclusions. A cyber team hears that LLMjacking may be addressed through a cyber product. A professional-services firm hears that AI errors may create E&O exposure. A board hears that AI governance and cyber disclosure are becoming oversight concerns. A cloud-dependent engineering team hears that shared infrastructure creates accumulation risk. Everyone is hearing a fragment of the same larger pattern.

The market is splitting AI risk.

That split is more useful than either extreme. It is not accurate to say that AI is broadly covered. It is not accurate to say that AI is uninsurable. It is not accurate to say that all insurers are excluding AI. It is not accurate to say that affirmative AI coverage proves market acceptance of agentic AI lifecycle risk transfer. Public sources show a more practical market reality: AI risk is being sorted into cover, exclusion, endorsement, sublimit, silent exposure, cyber-linked coverage, professional liability ambiguity, governance exposure, claim reconstruction needs, aggregation concerns, and model-performance warranty structures. [1] [2] [3] [4] [5] [6] [7] [12]

That is why Chapter 2 matters. It proves that the paper is not inventing a theoretical problem. The problem is already visible in market behavior.

Imagine a broker receiving three questions in the same week.

The first client is an AI vendor that wants to offer buyers a performance warranty for its model. It asks whether underperformance against agreed metrics can be insured or backed by an insurance-linked product. Public sources from Munich Re, Armilla, and Chaucer show that product-specific AI performance and underperformance structures exist in defined contexts. [4] [5] [6]

The second client is a company whose cloud bill has spiked because stolen credentials were used to access LLM resources. It asks whether its cyber policy responds. QBE has published AI-focused cyber coverage announcements and LLMjacking materials that make this kind of AI-linked cyber risk concrete. [2] [3]

The third client is a company deploying generative AI into customer-facing and content-producing workflows. It asks whether general liability, professional liability, cyber, D&O, media/IP, or E&O policies will silently absorb the exposure. Verisk/ISO form-development activity and Aon market materials suggest that insurers and brokers are not treating these questions as settled. [1] [12] [13]

Those are not one question. They are three different insurance conversations. The fact that each contains "AI" does not make them interchangeable.

The following matrix is the evidence spine for Part I. It is intentionally framed as signal, not conclusion.

T-02-01 - AI Insurance Split-Market Signal Matrix

The first pattern in the matrix is affirmative coverage. It is real, and it matters. Munich Re's aiSure and related materials describe insurance approaches for AI performance risk and performance guarantees. Armilla describes AI insurance and warranty structures linked to performance, verification, and liability contexts. Chaucer's announced work with Armilla describes an AI third-party liability product for mechanical underperformance, hallucinations, model drift, and claims arising from underperformance. QBE has announced AI-focused cyber coverages. These examples show that market participants are not simply walking away from AI risk. [2] [4] [5] [6]

But the object matters. A model-performance warranty is not the same as a policy responding to every loss produced by an autonomous customer workflow. A cyber coverage extension is not the same as professional liability protection for AI-assisted advice. A cloud/AI service cyber product is not the same as coverage for every downstream business action triggered by an agent. The fact that a product exists tells us that a risk object can sometimes be defined. It does not tell us that all agentic risk has been made transferable.

The second pattern is exclusion and boundary formation. Verisk/ISO's general liability filing discussion is important because it shows that the market is developing optional endorsements and rules around generative AI liability exposures. [1] Whether a specific endorsement is adopted, filed, approved, or applied in a particular jurisdiction is a separate question. The safe conclusion is not that generative AI is excluded everywhere. The safe conclusion is that insurers and insurance infrastructure providers see a need for boundary tools.

That boundary formation is not a sideshow. It is the market saying: we need to know what kind of AI-related loss we are talking about. A generative AI content dispute, a product defect theory, a professional service error, a cyber incident, a customer refund error, and a board oversight failure are not interchangeable. If a policy form, endorsement, exclusion, or underwriting rule tries to draw a line, the enterprise needs evidence that can show on which side of the line its event belongs.

The third pattern is limits and sublimits. AI-linked cyber risk may be partially transferable while still being constrained. QBE's official materials support the existence of AI-focused cyber coverage categories and LLMjacking as a concrete cyber risk. Secondary reports about AI-linked cyber caps or sublimits are useful as market context, but not as primary policy wording. [2] [3] [15] The distinction matters because a sublimit is not the same as denial, and coverage existence is not the same as unlimited transfer. Limits are part of the architecture of risk transfer.

The fourth pattern is silent exposure. This may be the most common enterprise problem in the near term. Before a dedicated AI product or exclusion clearly addresses a loss, AI may enter through familiar lines: cyber, E&O, Tech E&O, D&O, EPLI, crime, professional liability, media/IP, or product liability. Aon materials frame AI as a cross-line risk issue for business leaders, not only a standalone product category. [12] [13] That does not mean coverage applies. It means the exposure may arrive through existing insurance language before the organization has built an AI-specific evidence file.

Silent exposure makes the insured subject vs risk object distinction sharper. A company may have a cyber policy. A professional firm may have professional liability coverage. A director or officer may be relevant under D&O. But the loss-generating object may be an agentic workflow, model output, tool call, API dependency, human approval event, or vendor platform. The policy might name the company. The evidence still has to reconstruct the work.

The fifth pattern is cyber-linked AI risk. LLMjacking is a useful example because it is concrete. It can involve stolen credentials, unauthorized use of LLM resources, abnormal token or compute consumption, API logs, identity records, cloud billing, containment, and remediation. QBE's LLMjacking material supports this evidence profile. [3] A cyber incident response file may include exactly the kind of artifacts that a claim reconstruction effort needs. But the same example also shows the limit of cyber framing. If the AI-linked loss is not only unauthorized access or compute abuse, but a delegated business action taken under valid credentials, cyber records may not answer the whole question.

The sixth pattern is professional liability and technology liability ambiguity. AI can sit inside advice, drafting, triage, code generation, underwriting support, claims support, financial analysis, engineering recommendations, medical workflow support, legal workflow support, customer service, or software-as-a-service delivery. If the loss is a professional error, product underperformance, technology service failure, or customer harm event, the policy-line question changes. Public product examples can show that AI liability products exist in defined settings, but they do not remove the need to ask what the professional or technology service actually did. [5] [6] [13]

The seventh pattern is governance exposure. AI risk can become a board, oversight, disclosure, control, or risk management issue. SEC cyber disclosure rules do not create insurance coverage, but they show why incident governance, materiality analysis, and board oversight records can matter for public companies. [17] NAIC insurer AI governance materials do not prove coverage for insureds, but they show that the insurance regulatory environment itself is paying attention to AI governance, risk management, controls, and third-party oversight. [18] For this paper, the implication is not that regulation equals insurance. It is that governance records can become part of the evidence environment.

The eighth pattern is claim reconstruction. NIST, CISA, QBE, and SEC sources point toward timelines, response procedures, access records, escalation, containment, remediation, and governance context. [3] [10] [11] [17] These sources are not insurance claim standards. They do not approve claims. They do show that post-loss review requires structured evidence. For agentic AI, that evidence must extend beyond ordinary incident response when the loss involves delegated authority, tool action, human acceptance, vendor dependency, or remediation closure.

The ninth pattern is aggregation. Reinsurers and insurance researchers are concerned with accumulation and correlated loss in cyber and digital infrastructure. Geneva Association work on cyber accumulation and generative AI risk, and Swiss Re work on cloud concentration, support the idea that shared dependencies matter. [7] [19] Agentic AI can intensify the same visibility problem. If many workflows depend on the same model provider, cloud service, API, orchestration tool, or vendor platform, then the enterprise and its insurers may need to understand correlation, not only isolated use cases.

The tenth pattern is model-performance warranty. This deserves its own category because it is often confused with broader AI insurance. A model-performance warranty can be a serious, useful product. It can define a performance promise, verification process, KPI, or underperformance remedy. It can make AI risk more legible in a narrow product context. But it does not automatically cover the lifecycle of agentic work. If a model performs within expected tolerance but the agent chooses the wrong tool, acts outside intended authority, relies on stale context, bypasses review, or triggers a harmful downstream action, the loss may not be a model-performance failure.

The final pattern is the agentic lifecycle gap. It is not a claim that no one covers AI. It is the gap between the objects the market is beginning to define and the work enterprises are beginning to delegate. The market has examples for model performance, warranty, cyber, technology liability, and form boundaries. Enterprises are building workflows that combine authority, planning, tool use, human review, vendor dependency, and customer impact. The gap is where this paper focuses.

What does this prove?

It proves that the insurance market is already asking narrower questions than "is AI insured?" It proves that AI-related risk can be covered in some settings, bounded in some settings, limited in some settings, and silent in some settings. It proves that evidence matters. It proves that the object being transferred must be named.

What does it not prove?

It does not prove broad agentic AI insurability. It does not prove universal exclusion. It does not prove claim payment. It does not prove that any insurer accepts the object model, the reasoning model, MPLP, or this paper's vocabulary. It does not prove that a company with good logs is coverage-ready. It does not prove that auditability equals insurability.

The responsible conclusion is more practical:

The market is splitting AI risk because AI is not one risk object. Enterprises that want risk-transfer conversations need to define the subject, object, event, evidence, boundary, and reconstruction path before the loss, not after it.

That conclusion leads directly to Chapter 3. If some AI products and cyber coverages exist, the next danger is false confidence. The reader may assume that "LLM insurance," "AI warranty," or "AI cyber coverage" solves the agentic lifecycle problem. It does not. Those products may be useful and important. They ask narrower questions.

Chapter 3: Why LLM Insurance Is Not Agentic Lifecycle Insurance

"AI insurance" is a label. It is not yet an answer.

The label can refer to several different things. It can mean model-performance insurance, where a model or AI solution fails to meet a defined performance target. It can mean a warranty or guarantee tied to AI product underperformance. It can mean third-party liability linked to model drift, hallucination, or underperformance in a defined product. It can mean AI-linked cyber coverage for LLMjacking, API misuse, cloud dependency, or regulatory costs. It can mean technology E&O, professional liability, or cyber lines encountering AI exposure without a dedicated AI product label.

Each of these categories matters. None should be dismissed. But none should be mistaken for end-to-end agentic lifecycle risk transfer.

The difference is easiest to see in a workflow example.

An enterprise uses a vendor model inside a customer-facing agent. The model produces a plausible output. The agent uses the output to select a next action. The agent calls a tool that updates a customer's account and triggers a downstream API. A human reviewer sees a short summary and approves the action. A vendor platform logs the tool call. The customer suffers a financial or service harm. The company later discovers that the model output was not obviously defective. The loss came from a combination of stale context, delegated authority, weak review criteria, and a tool action that was allowed but poorly bounded.

What question does model-performance insurance ask? It may ask whether the model or AI solution failed a defined performance promise, KPI, or agreed function. If the product is structured around underperformance, hallucination, model drift, or performance guarantee, the covered object is the model or AI product performance in that defined setting. Munich Re, Armilla, and Chaucer/Armilla sources support the existence of such product categories in public materials. [4] [5] [6]

What question does cyber coverage ask? It may ask whether there was unauthorized access, credential compromise, malicious activity, data exposure, compute abuse, business interruption, regulatory investigation, or another cyber-defined event. QBE's LLMjacking materials make the cyber version concrete: stolen access to LLM resources, abnormal usage, API logs, cloud or compute records, containment, and remediation. [2] [3]

What question does professional liability ask? It may ask whether a professional service or advice deliverable was defective, whether a human professional relied on AI inappropriately, whether a client relied on the output, and whether policy terms, exclusions, and professional standards are implicated. That is not the same as asking whether an AI model hit its KPI.

What question does agentic lifecycle risk ask? It asks how the work was authorized, planned, executed, reviewed, accepted, evidenced, changed, and remediated. It asks which legal subject owned the workflow, which human role accepted the outcome, which agent or tool performed the action, which vendor or cloud service participated, which authority boundary applied, which evidence survived, and whether the loss can be reconstructed. That is a broader operational question than model performance and a different question from cyber access.

This distinction is not a criticism of model-performance or AI cyber products. It is a boundary. A narrower product can be valuable precisely because it defines its object. If an AI vendor wants to give buyers confidence that a model will meet a specified performance promise, a model-performance warranty or insurance-backed product can address a real commercial problem. If an enterprise faces LLMjacking or AI-linked cyber abuse, cyber coverage and incident response services can address a real risk channel. The point is not that these products are weak. The point is that they are not the whole lifecycle.

Agentic lifecycle risk includes at least eight layers that model or cyber labels may not capture by themselves:

1. Authority: What was the workflow allowed to do?
2. Planning: How did the agent select a path or action?
3. Tool use: What external system, API, database, or service did it touch?
4. Human role: Who reviewed, approved, supervised, escalated, or accepted?
5. Dependency: Which model, vendor, cloud, API, or data source shaped the action?
6. Accepted outcome: What counted as done, correct, or approved?
7. Evidence: What logs, traces, approvals, records, and incident artifacts survived?
8. Remediation: What changed after the event, who owned the fix, and how was closure recorded?

These layers explain why a model can perform as expected while the agentic work still causes loss. A model can produce a plausible answer, but the workflow can apply it to the wrong account. A model can meet an accuracy benchmark, but the agent can call a tool outside the business context intended by the enterprise. A model can avoid hallucination, but a human reviewer can approve a summary without seeing the underlying evidence. A cyber policy can respond to credential theft, but not answer whether a validly authorized agent action created professional or operational loss. A warranty can address underperformance against a KPI, but not reconstruct authority, acceptance, dependency, and remediation across an enterprise workflow.

The same distinction applies to technical traces. Traces are useful. Logs are useful. Prompt records, output records, tool-call records, API logs, cloud bills, identity records, model versions, and vendor notices can be essential. It would be wrong to say they are useless. But they are not the same as claim evidence. A trace can show that a tool was called. It may not show whether the workflow had authority to call it, whether the human reviewer had the right context, whether the output was accepted under a defined criterion, whether the vendor dependency had changed, whether the policy line treats the event as cyber, E&O, Tech E&O, professional liability, product liability, crime, media/IP, or another category, or whether remediation closed the risk.

The auditability and assurance white paper's concepts become useful here, but with a boundary. An Audit Evidence Chain can help an enterprise move from raw logs to structured evidence. It can ask what object is being reviewed, what evidence was requested, what was sufficient, what was missing, and what boundary caveat applies. For claim reconstruction, that logic helps. But audit evidence is not claim approval. A technically complete evidence chain still needs policy context, legal review, coverage review, causality analysis, loss measurement, and claim handling outside this paper. [9] [10] [11]

Model-performance products also show why "covered object" is the right phrase. In those products, the object is narrowed: a model, AI solution, performance promise, KPI, underperformance event, hallucination, drift, or defined liability scenario. That narrowing makes transfer more plausible because the parties can identify what is being measured. Agentic lifecycle risk must do something similar, but with a different object: not just the model, but the bounded lifecycle work unit.

That work unit is not fully defined in Part I. Part II will do that work. For now, the key is to see why it is needed. Without a bounded work unit, agentic AI remains a blur of model, prompt, tool, vendor, human, and output. With a bounded work unit, the enterprise can begin to ask: what was delegated, what was authorized, what evidence was captured, who accepted the outcome, and what policy line might be implicated?

The market's current signals make this distinction unavoidable. Affirmative AI coverage examples show that some AI objects can be defined. Exclusion and endorsement signals show that insurers want boundary language. AI cyber examples show that some AI-linked losses can be handled through existing or extended cyber lines, but with event and evidence constraints. Silent exposure shows that existing policies may be pulled into AI losses before dedicated language catches up. Aggregation research shows that shared dependencies can turn isolated workflow risk into correlated exposure. [1] [2] [3] [4] [5] [6] [7] [12] [13] [19]

The lifecycle gap sits between those signals.

For an enterprise, the gap is practical. It may have a model inventory but no work-unit inventory. It may have logs but no authority records. It may have a human review step but no responsibility structure. It may have vendor contracts but no dependency map. It may have incident response procedures but no claim reconstruction package. It may have strong governance language but no way to show which agentic work object caused the loss.

For an insurer or broker, the gap is equally practical. The conversation cannot stop at "AI." It must ask whether the loss is model performance, cyber, professional error, technology service failure, governance exposure, product liability, fraud, media/IP, employment practice, or something else. It must ask who is insured, what object is loss-relevant, what evidence exists, what policy language applies, and what remains unresolved.

For a reinsurer, the gap includes dependency concentration. If agentic workflows across many insureds use the same model, cloud service, API, orchestration framework, or vendor platform, then risk may accumulate through common infrastructure or common operating patterns. That is not a pricing conclusion. It is a visibility problem. [7] [19]

This chapter therefore makes a narrow but important claim:

LLM insurance, model-performance insurance, AI warranty products, and AI-linked cyber coverage are important market signals. They do not by themselves solve agentic lifecycle risk transfer.

They do not need to. Their value is that they teach the right lesson: define the object. Model-performance products define a performance object. Cyber products define a cyber event object. Agentic lifecycle risk transfer must define a work object that can connect authority, tool use, human role, dependency, accepted outcome, evidence, and remediation.

That is why Part II begins with the core object problem. Once the market reality is clear, the paper can ask the question that every later chapter depends on:

Is the insured object the company, the human, the officer, the professional, the vendor, the AI agent, or the bounded agentic work unit that created the loss?

The answer is not one object. It is a map. Part II builds that map.

Part II: The Insurable Agentic Risk Object

Part I ended with a map, not a slogan. The market does not need another broad claim that AI is insured, uninsurable, excluded, covered, risky, or revolutionary. It needs a cleaner object.

That object is not usually the AI agent itself. It is not simply the model output, the cloud event, the API trace, the workflow label, or the fact that a human clicked approve. Those records matter, but they do not by themselves say what was transferred, who owned it, what authority was delegated, what evidence survived, or what kind of policy question was created.

Part II defines the working object for the rest of the paper: the Insurable Agentic Risk Object. The phrase is an authored analytical construct. It is not an insurance standard, not a coverage trigger, not a policy definition, not a certification, and not proof that any insurer accepts the object. Its purpose is narrower and more useful. It gives insurers, brokers, reinsurers, risk leaders, counsel, boards, and engineering teams a way to describe the bounded work that might generate or shape loss.

The policyholder remains the legal insured subject. The agentic work can become the loss-relevant risk object. Part II is about keeping those layers separate long enough for underwriting discussion, incident response, and claim reconstruction to become possible.

Chapter 4: The Insurable Agentic Risk Object

The practical question after an agentic AI loss is rarely "which model was used?" That question matters, but it is not enough.

A company deploys an agent that can receive a customer request, classify the issue, approve a refund within a defined range, update the customer account, send a confirmation email, and trigger a downstream payment API. The model output looks plausible. The workflow completes. A human supervisor reviews only a summary queue. Days later, the company discovers that the agent applied the refund rule to the wrong class of customers and triggered a series of account changes that created financial loss, customer complaints, and regulatory concern.

The first insurance question is not whether "the AI" was involved. It is what object should be examined.

If the object is the model output, the analysis may miss the delegated refund authority. If the object is the cyber event, the analysis may miss that the action used valid credentials and ordinary system permissions. If the object is the runtime trace, the analysis may miss the human role and the accepted business outcome. If the object is the completed workflow, the analysis may miss the vendor dependency, substitution history, and exception record. If the object is only the company, the analysis may name the insured subject but fail to identify the work that produced the loss.

The Insurable Agentic Risk Object is the bounded lifecycle work unit that connects these fragments. It is the work as authorized, planned, executed, evidenced, handed off, accepted, excepted, remediated, and closed. It is a unit of analysis for insurance-facing review. It is not the insured legal subject.

This distinction is the hinge of this paper. The company may be the policyholder. A professional may be relevant under professional liability. An officer may matter in a governance or D&O context. A vendor or platform may matter in contract, service, technology, or liability analysis. But the agentic risk object is the bounded work that generated, shaped, amplified, or obscured the loss. It is where the insurance question becomes operational.

The object must be bounded because "AI system" is too large. It must be lifecycle-based because the loss may arise before or after the final output. It must be evidence-linked because post-loss reconstruction cannot depend on memory, dashboard summaries, or generic control claims. It must preserve responsibility because insurance conversations eventually ask who owned authority, review, acceptance, remediation, and external consequence.

The object has several minimum fields:

• initiating intent: what business purpose started the work;
• authority boundary: what the work was allowed to do, by whom, under what limit;
• agent role: what the agent drafted, recommended, selected, executed, monitored, or escalated;
• human role: who configured, supervised, approved, accepted, escalated, or remediated;
• tool action: which system, API, database, account, message, payment, code repository, or external service was touched;
• dependency chain: which model, runtime, vendor, cloud, data source, or orchestration layer shaped the work;
• evidence partition: where model, tool, human, vendor, data, project, and incident records are stored and how they can be joined;
• accepted outcome: what counted as done, correct, approved, or business-accepted;
• exception path: what happened when the work exceeded threshold, encountered uncertainty, or failed control checks;
• remediation closure: who fixed, rechecked, reauthorized, and closed the residual risk.

These fields borrow analytical vocabulary from the compliance white paper and the auditability and assurance white paper, but they are not insurance facts by themselves. The compliance white paper helps name lifecycle objects such as authority boundary, accepted outcome, evidence partition, substitution conformance, and remediation closure. The auditability and assurance white paper helps distinguish raw logs from evidence chains. In this paper, those ideas become inputs to insurability reasoning only when tied back to insured subject, policy line, loss event, and claim reconstruction. [20] [21]

This is why model output is insufficient as an insurable object. A model output can be correct while the work is wrong. The output may be applied to the wrong customer, used outside scope, executed by the wrong tool, accepted by a human without full context, or preserved without enough evidence to reconstruct the event. Model-performance products can define valuable and narrower objects, as Part I explained, but agentic lifecycle work requires a broader object.

AI cyber event framing is also insufficient by itself. Cyber coverage may be central when there is unauthorized access, credential abuse, compute theft, API misuse, business interruption, regulatory investigation, or data exposure. But an agentic loss may arise from a validly authorized business action performed through ordinary credentials. QBE's LLMjacking materials are useful because they show how access, usage, API records, containment, and remediation become evidence in a cyber-linked AI incident. They do not convert every agentic workflow loss into cyber risk. [22]

Runtime traces are insufficient for a different reason. A trace can show sequence. It can show a prompt, output, function call, API response, tool invocation, latency, token use, or model endpoint. But a trace often does not show why the work was authorized, which human role had authority, whether the action was business-accepted, whether a vendor substitution changed behavior, which evidence was withheld for privacy, or which policy line is implicated. A trace is an ingredient. It is not the meal.

Workflow completion is also insufficient. Enterprise software loves completed states: ticket closed, refund processed, email sent, pull request merged, alert resolved. Insurance review cares less about whether the workflow completed and more about whether the completed work can be reconstructed as a loss-relevant object. A workflow can complete successfully and still create the wrong legal, financial, professional, cyber, or customer consequence.

The Insurable Agentic Risk Object therefore works as a bridge. It sits between market categories and technical systems. It does not replace a policy. It helps the policy conversation ask better questions.

T-04-01 - Insurance Object Shift

The table is intentionally modest. It does not say the risk object proposed here is insured. It says the object is what must be named before the insurance discussion becomes precise.

The boundary note for this chapter is simple: defining an Insurable Agentic Risk Object is not legal advice, not insurance advice, not underwriting guidance, not a coverage opinion, not certification, not proof of insurability, not insurer endorsement, and not a regulator-approved method. It is an analytical way to keep the insured subject, the work object, and the evidence path from collapsing into one vague phrase.

The next chapter asks what happens when that work object crosses hands. Agentic risk does not stay inside a single model call. It moves across humans, agents, tools, vendors, processors, projects, and remediation owners. The question becomes continuity.

Chapter 5: Agentic Risk Transfer and Responsibility Continuity

Risk does not transfer just because work moves.

In agentic systems, work moves constantly. A business user gives intent to an agent. The agent decomposes the task. A model generates text or selects a next step. A tool updates a record. A vendor service processes the request. A human approves a summary. A downstream workflow accepts the result. Another team reuses the same component in a different context. A later model substitution changes behavior. A support team remediates the incident. Each transition feels operationally normal.

For insurance analysis, every transition asks a harder question: did responsibility move with the work, or did only activity move?

Handoff is not risk transfer unless the responsibility transfer is evidenced. That does not mean every handoff needs legal ceremony. It means that post-loss reconstruction must be able to show who had authority, who understood the work boundary, who accepted the next state, what evidence moved with the task, and what remained with the prior actor.

Consider a professional services firm using an agent to draft client-facing recommendations. A consultant initiates the work. The agent retrieves prior engagement notes, uses a model to generate a recommendation, calls a document automation tool, and routes a summary for partner approval. The partner approves the summary but does not see the retrieval context or tool-action record. The document goes to the client. The client relies on it. A loss follows.

The firm may say the partner approved the work. The insurer or claims reviewer may ask a different question: approved what? The model output? The summary? The final deliverable? The retrieval context? The tool action? The client-specific suitability? The authority to send? The evidence that exceptions were absent?

That is the responsibility continuity problem.

Tool-action liability is where AI output becomes external consequence. A model can generate a recommendation without changing the world. A tool call can change an account, submit a filing, deploy code, send a payment instruction, issue a customer notice, post content, alter a medical workflow, or update an ERP record. Once the tool acts, the analysis shifts from information generation to external consequence. The risk object must preserve that shift.

Human approval is also not enough unless the human role authority is clear. A human can approve a queue item without owning the whole business decision. A reviewer can verify tone without verifying authority. A manager can approve deployment without seeing sensitive-data treatment. A professional can sign off on output without knowing that a model endpoint was substituted. The phrase "human in the loop" becomes meaningful only when the loop has role, authority, criteria, evidence, and accountability.

Vendor, model, and runtime substitution can break insurability reasoning when responsibility and evidence continuity are lost. A workflow that was reviewed under one model version may run under another. A tool connector may change. A vendor platform may modify logging behavior. A data processor may alter retention settings. A cloud or API dependency may become concentrated across many workflows. Swiss Re's cloud concentration work is useful here as an analogy: visibility into shared dependency matters because correlated infrastructure can affect many insured operations at once. [23]

Cross-project reuse creates another break. The same agentic component may be safe in one business context and risky in another. A refund classifier reused in collections, dispute handling, or compliance review now acts under a different authority scope, different customer impact, different policy line, and different evidence expectation. Reuse without reauthorization is not merely an engineering pattern. It is an exposure multiplier.

Responsibility continuity has five review questions:

1. What work moved?
2. Who or what received it?
3. What authority moved with it?
4. What evidence moved with it?
5. Who owned acceptance, exception, remediation, and closure after the move?

The compliance white paper's responsibility object and authority boundary concepts help name those states. the auditability and assurance white paper's audit evidence chain helps keep records from becoming disconnected artifacts. But again, these are analytical supports, not insurance standards. They help the risk reviewer ask whether continuity exists. They do not determine coverage, liability, claim outcome, or premium. [20] [21]

The responsibility map should include humans, agents, tools, vendors, processors, projects, and remediation owners. It should also include the absence of a responsible role. An empty cell is not a formatting problem. It is a risk signal.

T-05-01 - Responsibility Continuity Map

The map is not a liability allocation chart. It does not say which actor is legally responsible. It says which responsibility questions must be reconstructable if agentic work is to be discussed as a risk-transfer object.

The insurance significance is practical. If responsibility continuity is missing, the insurer, broker, counsel, or risk engineer may not be able to understand the event. The missing record may not be fatal in every policy context, and this paper does not decide that. But missing continuity makes the discussion harder because it turns a bounded work unit back into an undifferentiated AI system.

The boundary note for this chapter: responsibility continuity is not legal liability determination, not insurance advice, not coverage opinion, not underwriting guidance, not certification, not proof of insurability, and not insurer endorsement. It is an evidence architecture for making responsibility questions reviewable.

The next chapter turns from responsibility continuity to evidence. If the work object and responsibility handoffs can be named, what would an insurer, broker, reinsurer, or risk engineer need to review before treating the work as a more understandable risk?

Chapter 6: Underwriting Evidence Model for Agentic AI

Evidence does not guarantee coverage. Evidence does not guarantee insurability. Evidence does not guarantee a quote, a premium, an endorsement, a claim payment, or a favorable coverage position.

Evidence does something more basic: it makes the risk reviewable.

That distinction matters because enterprises often overestimate their evidence posture. A model inventory is not an underwriting evidence model. A SOC report is not a work-unit inventory. A log store is not a responsibility map. A dashboard showing agent runs is not a claim-reconstructable evidence chain. A policy document saying "human approval required" is not proof that the right human saw the right evidence at the right time.

For agentic AI, underwriting-facing evidence should be separated into four time horizons:

• pre-bind evidence: what the organization can show before coverage discussion or renewal;
• runtime evidence: what the system records while work occurs;
• post-incident evidence: what can be reconstructed after a loss or near miss;
• renewal evidence: what changed after incidents, substitutions, new workflows, or control improvements.

The categories overlap, but they should not be collapsed. Pre-bind evidence tells the reviewer what the enterprise intends and how it governs the work. Runtime evidence shows what actually happened. Post-incident evidence reconstructs event, authority, responsibility, consequence, and remediation. Renewal evidence shows whether the organization learned from experience or simply continued operating.

NIST AI RMF is useful as governance context because it frames AI risk management around governance, mapping, measuring, and managing risk. NAIC's model bulletin is useful because it shows insurance regulators thinking about insurer AI governance, risk management, controls, and third-party oversight. Those sources do not create an underwriting standard for enterprise insureds. They support the more cautious point that AI risk review increasingly requires governance, control, evidence, and third-party visibility. [24] [25]

Underwriting evidence for agentic work should include at least nine categories.

First is authority boundary. What can the agentic workflow do? What can it not do? What transaction value, customer impact, data class, tool permission, or external action requires escalation? Authority without boundaries is difficult to underwrite because the range of possible loss-generating behavior is undefined.

Second is role map. Which human role owns intent, configuration, review, acceptance, escalation, remediation, and closure? Which agent role drafts, recommends, executes, monitors, or escalates? Which vendor or platform role provides model, runtime, data, tool, storage, or logging service?

Third is tool-action record. The risk often becomes external when a tool acts. The evidence model should preserve not only model output, but the action taken: account update, API call, payment instruction, code deployment, customer message, content publication, database change, service ticket, or vendor handoff.

Fourth is evidence partition. The reviewer needs to know where records live and how they connect: model record, prompt/output record, tool record, human approval record, vendor record, privacy/redaction profile, incident record, remediation record, and missing-evidence note.

Fifth is privacy treatment. Agentic evidence can contain customer data, employee data, secrets, regulated data, trade secrets, prompts, source code, credentials, or privileged material. Evidence hoarding is not evidence maturity. A usable model must preserve what is needed while filtering or partitioning sensitive data responsibly.

Sixth is accepted outcome. The model output is not the business outcome. The evidence should show what counted as accepted, completed, delivered, filed, deployed, paid, sent, closed, or escalated.

Seventh is exception history. What thresholds were exceeded? What uncertainty was detected? What overrides occurred? What warnings were ignored? What false positives or false negatives happened? What near misses were recorded?

Eighth is remediation closure. Underwriting discussion may care not only that incidents occurred, but whether they were contained, investigated, fixed, rechecked, reauthorized, and closed. NIST and CISA incident-response sources support the value of preparation, response, recovery, remediation, tracking, and continuous improvement records. [26] [27]

Ninth is substitution conformance. If a model, tool, vendor, runtime, data source, or cloud dependency changes, the evidence should show whether the work remained within the same authority, evidence, privacy, and accepted-outcome boundaries. A silent substitution can make a previously reviewed workflow a different risk object.

Logs and traces appear in several categories, but they are not the category. A trace without authority is sequence without permission. A log without role mapping is activity without responsibility. A runtime dashboard without accepted outcome is motion without business consequence. A tool-call record without remediation history is action without closure.

T-06-01 - Underwriting Evidence Request Model

This model is useful because it turns "we have AI controls" into reviewable questions. What work? What authority? Which human? Which tool? Which vendor? Which evidence? Which accepted outcome? Which exception? Which closure? Which substitution?

For brokers, the model can help translate enterprise AI operations into risk-review language without promising a policy result. For insurers and reinsurers, it can help separate reviewable work from opaque automation. For CTOs and engineering leaders, it clarifies which records must be designed into the system before loss. For counsel, it keeps evidence architecture separate from legal conclusion.

The boundary note for this chapter: the Underwriting Evidence Model is not underwriting guidance, not an underwriting standard, not a premium recommendation, not actuarial pricing guidance, not coverage opinion, not insurance advice, not certification, not proof of insurability, and not insurer endorsement. It improves reviewability. It does not decide transfer.

The next chapter turns the same evidence model toward loss. When an incident occurs, the question changes from "what would a reviewer need to understand the risk?" to "what can the enterprise reconstruct now?"

Chapter 7: Claim Evidence Pack for Agentic Incidents

Incident notice is not enough.

An enterprise can notify an insurer, broker, vendor, regulator, customer, or internal executive that an AI-linked incident occurred. That notice may be important. It may be time-sensitive. It may be required by a policy, contract, regulation, or internal process. But the notice itself does not reconstruct the loss.

Agentic AI incidents require a Claim Evidence Pack: an authored analytical construct for organizing the records needed to understand the event. Like the other constructs in this paper, it is not a claims approval method, not a legal proof package, not an audit opinion, not a certification, and not a guarantee that a claim will be accepted.

Its job is to keep the event from dissolving into disconnected artifacts.

Take a small example. An agent incorrectly triggers a refund, sends a customer email, and changes a customer record. The business discovers the issue because a finance reconciliation flags an abnormal pattern. The engineering team retrieves logs. The support team sees the customer emails. The product team sees the workflow configuration. The AI team sees prompts and model outputs. The vendor has a tool-call trace. Counsel asks whether customer notice is required. The broker asks what policy line might be implicated.

Each group has a piece of the event. None has the whole object.

The Claim Evidence Pack should organize those pieces around the work unit:

• work unit ID;
• initiating intent;
• authority boundary;
• agent role;
• human role;
• tool action;
• external consequence;
• affected data;
• evidence chain;
• exception record;
• remediation action;
• closure state;
• privacy/redaction profile.

NIST and CISA sources support the value of structured incident-response processes, timelines, coordination, remediation, recovery, and tracking. QBE's LLMjacking materials show how AI-linked cyber incidents can require access, API, usage, containment, and remediation records. These sources do not define an insurance claim standard. They support the narrower point that reconstruction needs organized evidence, not only technical traces. [22] [26] [27]

The pack should answer six questions.

First: what was the work? This is the work unit ID and scope. A claim file cannot rely on "the AI made a mistake" as the object. It should identify the workflow, transaction, customer segment, project, repository, account, decision, deliverable, or tool action involved.

Second: what authority applied? The pack should show whether the agentic work was inside or outside delegated authority. Did it exceed transaction limits? Did it act on a protected data class? Did it bypass escalation? Did it use a tool permission that was technically available but not authorized for that context?

Third: who or what acted? The pack should separate agent role, human role, vendor role, model/tool role, and corporate owner. It should not assign legal fault. It should identify the roles needed for review.

Fourth: what external consequence occurred? A model output may have no loss by itself. The consequence may be account change, payment, customer message, professional deliverable, code deployment, privacy exposure, regulatory issue, service outage, publication, or other downstream effect.

Fifth: what evidence links the sequence? The pack should connect prompts, outputs, logs, tool calls, approvals, vendor records, data snapshots, exception history, incident timeline, and remediation records. It should also identify missing evidence.

Sixth: what privacy treatment applies? Claim evidence can include sensitive customer data, employee records, proprietary models, privileged communications, source code, security secrets, and vendor confidential information. A useful pack needs redaction, access controls, and source pointers, not uncontrolled data dumping.

T-07-01 - Claim Evidence Pack Components

The Claim Evidence Pack should include a missing-evidence register. Missing evidence is not a moral failure; it is a fact that must be visible. The pack should identify which records are absent, stale, overwritten, inaccessible, vendor-controlled, privileged, redacted, or outside retention. That register may be as important as the records that exist because it tells reviewers what cannot be reconstructed.

The pack should also distinguish technical causality from legal causation. A technical sequence can show that an agent called an API before a customer account changed. It cannot, by itself, decide proximate cause, liability, coverage, exclusion, damages, or claim outcome. That boundary protects the paper from pretending that evidence architecture replaces legal and insurance review.

The Claim Evidence Pack is useful before the claim too. If an enterprise designs the pack only after an incident, the most important records may already be missing. The pack is therefore an incident-readiness design pattern as much as a post-loss organizing tool. It asks engineering, risk, legal, and business teams to preserve the records that future review will need.

The boundary note for this chapter: a Claim Evidence Pack is not claims approval guidance, not legal proof, not legal advice, not insurance advice, not a coverage opinion, not certification, not proof of insurability, and not insurer endorsement. It is a structured way to preserve and organize evidence for review.

The next chapter defines the negative space. If the risk object cannot be bounded, the responsibility cannot be traced, the evidence cannot be reconstructed, or remediation cannot be closed, then the agentic work may remain hard to discuss as a transferable risk.

Chapter 8: Uninsurable or Hard-to-Insure Agentic Risk Patterns

The most useful insurability architecture is honest about what it cannot carry.

This chapter does not declare final insurer positions. It does not say a system is legally uninsurable. It does not create underwriting rules. It identifies risk-readiness patterns that make agentic work difficult to review, difficult to reconstruct, or difficult to discuss as a transferable risk object.

The word "hard-to-insure" is safer than "uninsurable" for most of this discussion because insurance outcomes depend on policy language, market appetite, jurisdiction, insured profile, loss type, limits, exclusions, underwriting judgment, and claim review. Still, some patterns are so weak from an evidence and responsibility perspective that an enterprise should treat them as severe blockers for serious risk-transfer discussion.

The first pattern is fully opaque agentic execution. If the enterprise cannot identify what the agent did, which model or tool it used, which data it touched, or why it selected a path, the risk object is not reviewable. A black box may be commercially convenient, but insurance review needs some path from event to evidence.

The second pattern is no delegated authority boundary. If an agent can draft, decide, execute, message, transact, or deploy without a recorded scope, the range of possible consequences is undefined. The problem is not autonomy by itself. The problem is unbounded autonomy without authority evidence.

The third pattern is no human-role-to-agent-responsibility map. If the enterprise says "a human reviewed it" but cannot show who reviewed what, under what authority, using what criteria, with what visible evidence, the human step may not reduce ambiguity. It may add it.

The fourth pattern is no accepted outcome state. If the enterprise cannot show when an output became an accepted business action, it cannot separate generation from adoption. That matters for customer communications, professional deliverables, payments, filings, code deployments, account changes, and operational decisions.

The fifth pattern is no tool-action liability boundary. The agent may use tools that create external consequence, but the organization has not separated suggestion from action. It cannot tell when text became transaction, when recommendation became instruction, or when internal output became customer-facing effect.

The sixth pattern is broken or non-reconstructable evidence chain. Logs exist, but they are not joined. Traces exist, but they omit human acceptance. Vendor records exist, but are inaccessible. Retention is too short. Privacy controls erased needed pointers. Incident records do not connect to model or tool records. The result is evidence fog.

The seventh pattern is cross-project reuse without reauthorization. A component built for one workflow is reused in another business context with different authority, data, customer impact, policy-line exposure, or dependency concentration. The object looks familiar to engineers but different to risk reviewers.

The eighth pattern is vendor, runtime, or model substitution without conformance review. If the behavior of the work changes because a model endpoint, orchestration layer, tool connector, data source, or vendor platform changes, the enterprise needs evidence that the risk object remained within its approved boundary. Without that evidence, the prior review may not travel.

The ninth pattern is privacy evidence hoarding or uncontrolled sensitive-data trace retention. Insurability reasoning needs evidence, but evidence maturity is not the same as keeping every prompt, customer detail, credential, secret, privileged communication, or employee record forever. A serious evidence model must handle redaction, minimization, access control, privilege, and source pointers.

The tenth pattern is no dispute or remediation closure. The enterprise notices a failure, patches something, and moves on. Months later it cannot show who owned the fix, whether it was retested, whether residual risk was accepted, whether the workflow was reauthorized, or whether the customer impact was closed. The loss may be over operationally, but not reconstructable.

These patterns often appear together. Fully opaque execution tends to create weak evidence chains. Weak evidence chains make human responsibility harder to show. Weak responsibility makes tool-action consequences harder to explain. Tool-action ambiguity makes claim reconstruction harder. Poor remediation closure makes renewal evidence weaker.

T-08-01 - Hard-to-Insure Agentic Risk Patterns

The possible remediation paths in the table are not underwriting requirements. They are engineering, governance, and evidence design moves that can make the risk object more reviewable. Whether any insurer values them, requires them, discounts for them, excludes without them, or accepts them remains external.

This negative space is important because it prevents this paper from becoming a confidence machine. The paper is not here to say every agentic workflow can be insured if the enterprise fills out the right template. Some work may remain too opaque, too unbounded, too poorly evidenced, too privacy-invasive, too dependent on unreviewable vendors, or too hard to reconstruct.

The point is not pessimism. It is precision. A hard-to-insure pattern is often a design problem that can be surfaced earlier. If an enterprise identifies the missing object before deployment, it may be able to redesign authority, evidence, privacy, responsibility, substitution, and remediation. If it discovers the gap only after a loss, it may have fewer options.

The boundary note for this chapter: the hard-to-insure patterns are an analytical risk-readiness view, not final insurer position, not underwriting rule, not legal advice, not insurance advice, not coverage opinion, not certification, not proof of insurability, not proof of non-insurability, not insurer endorsement, and not regulator-approved method.

Part II has now built the object layer. Part I showed that the market is already splitting AI risk. Part II explains why the object has to be bounded, responsibility-linked, evidence-backed, claim-reconstructable, and honest about negative space. Part III can now return to the compliance white paper and the auditability and assurance white paper without confusing them for insurance facts: lifecycle governance and auditability matter because they help create reviewable objects, not because they make systems insurable by themselves.

Part III: From Lifecycle Governance and Auditability to Insurability Reasoning

Part I established the market reality: AI risk is not moving through insurance in one clean line. Some risk is affirmatively addressed. Some is bounded. Some is silent inside existing lines. Some belongs closer to model performance or cyber than to the full agentic lifecycle.

Part II then named the object problem. The policyholder remains the insured legal subject. The agentic work can become the loss-relevant risk object. That object must be bounded, responsibility-linked, evidence-backed, claim-reconstructable, and honest about negative space.

Part III translates the first two white papers into this insurance-facing layer.

The compliance white paper gives lifecycle governance vocabulary. It names missing regulatory objects, authority boundaries, responsibility states, accepted outcomes, evidence partitions, privacy constraints, substitution conformance, and remediation closure. The auditability and assurance white paper gives auditability vocabulary. It distinguishes raw logs from evidence chains, trace visibility from audit evidence, and audit readiness from professional assurance. Those foundations matter for this paper because they help describe the risk object. They do not create coverage, determine liability, approve claims, bind insurers, set underwriting rules, or make a system insurable.

This part is therefore a translation exercise. It asks how lifecycle governance and auditability become useful to insurability reasoning without being mistaken for insurance facts.

Chapter 9: From Lifecycle Governance Objects to Insurability Objects

Many enterprises now have AI governance language. They can describe models, controls, inventories, policies, risk committees, approval workflows, and sometimes even agentic use cases. After a loss, however, the insurance question often arrives in a different grammar.

What was the insured subject? What object generated or shaped the loss? What authority was delegated? What action crossed into the world? What evidence survived? Which policy line might be implicated? Which records show responsibility, acceptance, exception, and remediation?

The compliance white paper helps because it names lifecycle objects that ordinary governance language often leaves vague. Missing Regulatory Objects, or MROs, are not insurance objects in themselves. They are not coverage triggers, policy definitions, underwriting standards, legal proof, or insurer-endorsed categories. Their value in this paper is more precise: they help identify what must be bounded, evidenced, reviewed, transferred, or closed before agentic work can be discussed as a reviewable risk object. [28]

Consider a customer-operations agent that can classify requests, approve account adjustments, send customer messages, and trigger an external service ticket. The enterprise may have an AI policy, a model inventory, and a control statement saying that humans supervise the system. A risk reviewer will still need a sharper map. Who gave the agent authority to adjust accounts? Which human role accepted the outcome? Was the customer message treated as a draft, recommendation, or authorized communication? Did the external service ticket create a downstream obligation? If the model or runtime changed, did the prior review still apply? If customer data appears in traces, what evidence is retained, redacted, or minimized?

Those are MRO-shaped questions.

The first insurance-relevant MRO is the human-role-to-MAS-responsibility mapping. Agentic systems often make work look shared. A business owner initiates. A system designer configures. A model generates. An agent selects a tool. A reviewer approves. A vendor hosts. A support team remediates. The insurance problem is not that many roles exist. It is that the roles may not connect to responsibility. A role map does not determine legal liability, but without it the work unit can become difficult to reconstruct.

The second is the delegated authority boundary. Insurance analysis needs an exposure perimeter. If the agent can draft but not send, recommend but not execute, approve below a threshold but escalate above it, use one data class but not another, or call one API but not another, that scope matters. Authority boundary is not legal delegation proof. It is a record of what the agentic work was allowed to do and when escalation should have occurred.

The third is the distinction between agent role and human role. An agent role is not a human role wearing technical clothing. A human may own intent, professional judgment, business acceptance, escalation, remediation, or closure. An agent may draft, route, classify, retrieve, score, execute, monitor, or trigger. The same work unit can involve both. If the enterprise collapses those layers into "AI-assisted," the insurance object becomes blurry.

The fourth is accepted outcome compliance. Model output is not the same as business acceptance. A recommendation becomes risk-relevant when it is sent, filed, paid, deployed, relied on, published, merged, recorded, or otherwise adopted. Accepted outcome records help show when generated content became organizational action. They do not decide legal acceptance, policy compliance, or coverage.

The fifth is the tool-action liability boundary. This is where the agentic lifecycle often becomes external. A generated answer may be internal. A tool action can change a customer record, transmit funds, send an email, alter code, open a ticket, submit a form, or call a vendor API. The tool-action boundary helps separate suggestion from consequence.

The sixth is responsibility transfer across agents. Agentic work may pass from one agent to another, from an agent to a workflow platform, from a workflow to a vendor, or from a vendor to a human team. The insurance-relevant question is whether the responsibility state traveled with the work. Handoff is operational. Responsibility continuity is evidentiary.

The seventh is authority drift. A workflow that begins with a narrow authority can widen through reuse, configuration change, prompt update, tool permission expansion, or role confusion. Drift matters because the risk object originally reviewed may no longer be the object that caused loss.

The eighth is evidence partitioning. Agentic evidence is scattered by design: model records, prompts, tool calls, human approvals, vendor logs, cloud records, data labels, incident tickets, remediation notes, and privacy redactions may live in different systems. An evidence partition tells the reviewer where the pieces are and how they can be joined without pretending that a single log stream is enough.

The ninth is cross-project reuse compliance. Agentic components rarely stay in one place. A classifier built for support may be reused in billing. A code agent built for internal tooling may be reused in customer-facing deployment. A retrieval agent built for policy search may be reused in professional advice. Reuse changes exposure when authority, data, external consequence, or policy-line ambiguity changes.

The tenth through thirteenth MRO families sit around privacy: lifecycle privacy mapping, privacy-preserving third-party validation, evidence minimization and selective disclosure, and data subject rights versus evidence retention. These matter because insurance review needs evidence, while privacy and security disciplines limit what should be retained, copied, disclosed, or shared. Evidence maturity is not evidence hoarding.

The fourteenth is the third-party processor and subprocessor chain. Agentic systems often depend on vendors, cloud services, model providers, orchestration layers, data processors, and logging tools. The insured organization may not control every record needed for reconstruction. The processor chain is therefore not a procurement appendix. It is part of the evidence object.

The fifteenth is vendor, model, and runtime substitution conformance. A change in model endpoint, vendor platform, tool connector, runtime policy, embedding store, or API behavior can make a previously reviewed work unit behave differently. The insurance concern is not simply that change occurred. It is whether authority, evidence, privacy, and accepted-outcome boundaries remained continuous.

The sixteenth is incident, dispute, and remediation closure. A loss event does not end when a ticket is closed. Reviewers may need to know what was contained, what was fixed, who rechecked it, whether the workflow was reauthorized, what residual risk remained, and whether affected parties or business processes were closed out.

NIST AI RMF and NAIC insurer-governance materials are useful context here because they show the broader movement toward governance, mapping, risk management, documentation, controls, validation, and third-party oversight. They do not turn MROs into insurance standards, and they do not prove coverage or underwriting acceptance. [29] [30]

T-09-01 - MRO-to-Insurability Translation Map

The table should be read as a translation map, not a scoring model. It says that MROs can help describe the work object that insurance analysis needs to see. It does not say that the presence of an MRO creates coverage, satisfies an insurer, proves compliance, resolves causation, or makes the risk transferable.

The boundary for this chapter is deliberately narrow: The compliance white paper provides lifecycle governance object vocabulary for insurability reasoning. It does not provide legal advice, insurance advice, underwriting guidance, a coverage opinion, certification, proof of insurability, insurer endorsement, or a regulator-approved method.

The next chapter moves from the compliance white paper's governance objects to the auditability and assurance white paper's auditability architecture. If MROs help name the object, audit evidence helps reconstruct what happened. But auditability still does not equal insurability.

Chapter 10: From Audit Evidence Chain to Claim Reconstruction

After an incident, teams often say the same thing: "We have logs."

Sometimes they do. They have model traces, API records, prompts, outputs, identity logs, cloud usage records, tool-call histories, approval timestamps, service tickets, alerts, and vendor dashboards. But a pile of logs is not a claim reconstruction. It may not even be an evidence chain.

the auditability and assurance white paper matters because it separated raw trace visibility from audit evidence. It introduced the idea that evidence must be linked to an object, a responsibility state, a request, a sufficiency boundary, and a review purpose. This paper uses that discipline for a different purpose: claim reconstruction. [31]

The difference is important. An audit evidence chain can help organize facts. It can show what work unit was reviewed, what evidence was requested, what records were available, and what gaps existed. A claim reconstruction effort may use the same records, but it asks additional questions: what loss occurred, which insured subject is involved, which policy line may be implicated, what event triggered notice, what evidence links action to consequence, what exclusions or limits may be relevant, what remediation occurred, and what remains unresolved?

Auditability is necessary for reconstruction because unreconstructable systems make post-loss review harder. It is insufficient for insurability because insurance decisions depend on policy language, underwriting appetite, line of coverage, loss facts, legal analysis, exclusions, limits, notice, causation, damages, and claim handling. The auditability and assurance white paper helps make the facts legible. It does not decide the insurance outcome.

Consider an agentic code-deployment workflow. A developer asks an agent to propose a patch. The agent retrieves context, writes code, runs tests, opens a pull request, and recommends deployment. A human reviewer approves a summary. The deployment tool pushes the change. A service outage follows.

The engineering logs may show the commit, deployment time, test output, and rollback. The agent traces may show the prompt, retrieved files, tool calls, and recommendation. The ticketing system may show the approval. The incident system may show detection, escalation, containment, recovery, and closure. A claim reconstruction needs all of that, but it also needs responsibility semantics. Was the agent authorized to modify the affected service? What did the reviewer see? Was the deployment inside an approved change window? Did a vendor or model substitution alter behavior? Was customer data exposed? What loss category is being asserted? What remediation closed the event?

NIST and CISA incident-response materials support the value of preparation, detection, coordination, containment, remediation, recovery, reporting, tracking, and continuous improvement. They are not insurance claim rules. They support the narrower point that reconstruction depends on organized, time-linked, role-aware records. [32] [33]

The translation from auditability evidence to risk-transfer analysis has several layers.

The work unit becomes the claim reconstruction object. The reviewer cannot reconstruct "AI failure" in the abstract. The event needs a bounded work unit: deployment run, customer-account update, refund approval, professional deliverable, payment instruction, email campaign, investigation workflow, or vendor handoff.

Authority becomes a reconstruction question. Was the work inside delegated scope? Did it exceed a threshold? Did it use a tool permission that existed technically but was not authorized for the context? Was escalation required?

Role becomes responsibility context. Who initiated, configured, reviewed, accepted, overrode, remediated, and closed the work? What did the agent do? What did the human do? What did the vendor do? What did the organization own?

Tool action becomes the external consequence bridge. The claim file may need to show how an output became an account change, payment, code deployment, customer message, data transfer, filing, or service interruption.

Evidence pointer becomes the opposite of evidence dumping. The evidence chain should point to source records, retention status, redaction profile, access controls, and missing evidence. In many cases the reviewer needs proof that a record exists and can be accessed under appropriate controls, not a bulk export of every prompt and payload.

Accepted outcome becomes the moment of adoption. A model answer may be tentative. A business state may be final. Claim reconstruction needs to know when the organization accepted the action and what criteria were visible.

Exception becomes the early warning record. Thresholds, overrides, uncertainty, alerts, failed checks, near misses, and ignored warnings may explain why the event occurred or why it was not contained earlier.

Remediation closure becomes the post-loss state. The record should show what was contained, fixed, retested, reauthorized, monitored, or left open. It should also show who accepted residual risk.

Privacy treatment becomes part of evidence quality. A claim evidence chain that exposes unnecessary personal data, secrets, privileged materials, or vendor confidential information can create a second risk problem. Evidence must be reconstructable and controlled.

T-10-01 - Auditability-to-Claim-Reconstruction Crosswalk

This crosswalk should prevent two mistakes.

The first mistake is technical overconfidence. A trace can show that a tool was called. It may not show whether the tool call was authorized, whether the human reviewer saw the relevant context, whether a vendor substitution changed behavior, whether the action became an accepted business outcome, or whether the affected data should have been retained or redacted.

The second mistake is insurance overconfidence. A strong evidence chain can make a claim file more coherent. It cannot decide causation, liability, coverage, exclusions, limits, damages, settlement, or claim payment. Those decisions sit outside this paper.

AI-linked cyber examples show why this matters. QBE's LLMjacking guidance points toward access, API usage, abnormal consumption, containment, and remediation records. Those records can be essential for reconstructing a cyber-linked AI event. They still do not answer every agentic lifecycle question: who authorized the workflow, what business action was accepted, what responsibility bridge existed, and what line ambiguity remains? [34]

The boundary for this chapter: The auditability and assurance white paper provides auditability and evidence-chain vocabulary that can support claim reconstruction. It does not provide legal advice, insurance advice, underwriting guidance, coverage opinion, certification, proof of insurability, claim approval guidance, legal liability determination, insurer endorsement, or a regulator-approved method.

The next chapter turns from evidence architecture to policy-line ambiguity. The same agentic event may be legible as cyber, professional liability, technology E&O, governance, crime, media, employment, product, or business interruption exposure. Evidence can help sort the questions, but it does not resolve coverage.

Chapter 11: Insurance Lines and Agentic Risk Ambiguity

An agentic incident rarely arrives wearing one policy label.

A customer-support agent triggers refunds to the wrong accounts. Is that a cyber event because credentials and APIs were involved? A technology E&O issue because a deployed software service failed? A professional liability issue because customer-facing advice or service was wrong? A crime or social-engineering issue if payment controls were manipulated? A regulatory or media issue if customer notices were misleading? A D&O or governance issue if the board had ignored known AI control gaps? The answer cannot be inferred from the word "AI."

Policy language controls. Facts matter. Jurisdiction, insured role, policy line, endorsements, exclusions, limits, sublimits, definitions, notice, causation, and loss category all matter. This chapter does not interpret policy wording or provide a coverage opinion. Its purpose is to show why agentic lifecycle evidence can help sort line ambiguity without resolving it.

Broker and market sources already frame AI as a cross-line exposure. Aon discusses AI risk across cyber, E&O/professional liability, employment, crime, D&O/governance, and related enterprise risk categories. That is useful context, not a coverage determination. [35] [36]

Cyber is often the first line people think of because AI systems touch identity, credentials, APIs, cloud services, data stores, prompts, and model endpoints. Cyber may be relevant when there is unauthorized access, credential misuse, data exposure, API abuse, service interruption, compute misuse, LLMjacking, or regulatory investigation tied to a cyber event. QBE's AI cyber and LLMjacking materials show why access records, usage logs, cloud bills, containment steps, and remediation records matter. They do not make every agentic incident a cyber claim. [34]

Technology E&O and professional liability ask different questions. Was there a client deliverable, service failure, implementation defect, professional advice, platform error, or AI product underperformance? Did the insured provide a technology service or professional service? Was the loss tied to a model output, product behavior, integration failure, workflow configuration, or human professional judgment? Model-performance and AI warranty products can be relevant examples, but they are narrower than agentic lifecycle risk transfer.

D&O and governance exposure sits at another layer. The loss may not be only the operational event. It may also involve oversight, disclosure, risk management, AI governance failure, cyber governance, or alleged misstatement. SEC cyber disclosure rules are relevant as governance and disclosure context, not as insurance coverage proof. [37]

General liability and product liability may enter where an AI-enabled product, physical system, public interaction, or generated content creates bodily injury, property damage, or other covered categories, depending on policy language. Verisk's ISO filing discussion is evidence that GenAI liability exposure is being addressed in form development, but exact wording and jurisdictional adoption need careful verification before any precise policy claim is made. In Part III, the point is narrower: agentic evidence must identify the product, action, outcome, and loss path.

Media and IP exposures may appear when agentic systems generate, publish, recommend, train on, or distribute content. The relevant object may be a generated article, image, ad, recommendation, takedown response, rights review, or publication workflow. Evidence should preserve prompt/output records, content provenance, approval, publication, and remediation. This does not decide media liability, copyright, defamation, or advertising coverage.

Employment practices liability may be implicated when agents support hiring, screening, performance review, scheduling, discipline, termination, or workplace investigations. Evidence may need to show human role, decision criteria, data sources, notices, adverse action records, and exception handling. This paper does not provide employment-law analysis or coverage interpretation.

Crime and fraud lines may be implicated by deepfake fraud, synthetic identity, invoice manipulation, AI-enabled social engineering, payment instruction abuse, or internal control bypass. The claim ambiguity may turn on voluntary transfer, social-engineering wording, employee involvement, authentication controls, and cyber overlap. Agentic evidence helps show communications, approvals, identity checks, payment paths, and tool actions. It does not decide policy response.

Property and business interruption may appear when agentic systems affect operational continuity, cloud services, supply chain, code deployment, or physical systems. Beazley and cloud-related cyber examples show that AI/cloud services can enter product-specific cyber or business interruption contexts. Those examples should not be generalized beyond their terms.

The same event can straddle several of these lines. That is why this paper insists on the risk object. A line-of-business question cannot be answered if the enterprise cannot name the work unit, authority, tool action, accepted outcome, affected data, external consequence, dependency chain, incident timeline, remediation closure, and missing evidence.

T-11-01 - Insurance Line Ambiguity Map

Evidence helps sort these lines because it prevents the event from being described as "an AI problem." It shows whether the loss-relevant action was access, advice, deployment, payment, content publication, governance disclosure, data handling, service outage, or product behavior. But sorting is not deciding. The paper does not interpret policies, advise insureds, recommend procurement, or tell claims teams how to pay or deny a claim.

The boundary for this chapter: insurance line ambiguity analysis is not legal advice, insurance advice, underwriting guidance, coverage opinion, claim approval guidance, legal liability determination, certification, proof of insurability, insurer endorsement, or a regulator-approved method. It is an object-and-evidence map for understanding why the same agentic event can raise multiple insurance questions.

The next chapter moves from line ambiguity to portfolio ambiguity. Even when one event can be reconstructed, agentic AI can create aggregation and concentration risk through shared models, vendors, runtimes, cloud dependencies, reusable agents, and common workflows.

Chapter 12: Aggregation, Reinsurance, and Concentration Risk in Agentic AI

One agentic incident is difficult enough. Many similar incidents across the same dependency can become a different kind of insurance problem.

An enterprise may deploy a procurement agent in one division, a refund agent in another, a code agent in engineering, and a customer-response agent in support. Each workflow looks separate to its business owner. Under the surface, they may share the same model provider, orchestration framework, cloud region, authentication service, vector database, tool connector, logging vendor, or prompt library. A failure in that shared layer can affect many work units at once.

For insurers and reinsurers, the concern is not only individual incident severity. It is repeated, correlated, or systemic event shape.

Cyber insurance already gives the closest external analogy. Geneva Association cyber-accumulation work highlights the challenge of common technologies, shared vulnerabilities, providers, systemic loss, quantification limits, and capital capacity. Swiss Re's cloud concentration work emphasizes visibility into shared infrastructure dependencies. Geneva Association's GenAI insurance work adds a more direct AI-business risk context. These sources do not provide an actuarial model for agentic AI. They support the narrower conclusion that shared dependencies matter for insurability reasoning. [38] [39] [40]

Agentic AI adds a lifecycle layer to the cyber/cloud accumulation problem. The question is not only "which technology dependency failed?" It is also "which delegated work objects depended on it, under what authority, with what evidence, and with what accepted outcomes?"

A single reusable agent component can create correlated loss inside one organization. The same agent that classifies support tickets may be reused to classify refund requests, compliance inquiries, and escalation severity. If the component has a hidden failure mode, the losses may appear in different business units and policy lines. Without cross-project lifecycle records, the organization may not see the common object.

A single model or runtime change can create correlated behavior across many workflows. The model may become more permissive, less cautious, more verbose, more likely to call a tool, or less stable under certain prompts. If substitution conformance is not recorded, the enterprise may be unable to identify which workflows changed and which accepted outcomes were affected.

A single vendor or cloud dependency can create portfolio-level exposure. The same API, cloud region, identity provider, logging service, data processor, or orchestration platform can sit inside many insured operations. If it fails, is compromised, changes behavior, or becomes unavailable, the loss may not stay inside one policyholder's isolated workflow.

A single tool connector can create action concentration. Many agents may share the same permission to send emails, update accounts, create tickets, execute code, transfer files, approve payments, or access customer data. The concentration is not just the connector. It is the authority attached to the connector.

A single prompt, policy, or guardrail pattern can create governance concentration. If an enterprise copies one agent instruction template across many workflows, the same ambiguity can repeat across customer service, finance, operations, and engineering. A reused guardrail may be a control. It may also be a common failure point.

A single evidence architecture can create reconstruction concentration. If logs are retained too briefly, vendor records are inaccessible, privacy redaction removes source pointers, or tool-action records are not joined to approvals, then many agentic incidents may become unreconstructable at once.

Reinsurers care about aggregation because an apparently diversified book can contain hidden common dependencies. Enterprises should care for the same reason inside the firm. A risk leader may think ten workflows create ten separate exposures. In practice, they may create one concentrated dependency repeated ten times.

Dependency mapping and substitution conformance make aggregation visible. They do not solve it automatically. A dependency map should identify shared models, runtime layers, cloud services, APIs, tool connectors, data sources, processors, subprocessors, prompt libraries, authentication services, and evidence repositories. Substitution records should show when those dependencies changed, which work units were affected, and whether authority, privacy, evidence, and accepted-outcome boundaries remained intact.

T-12-01 - Agentic Aggregation Risk Map

The table deliberately stops before pricing. It does not offer rates, capital models, actuarial assumptions, accumulation thresholds, reinsurance attachment points, or portfolio management instructions. It says only that agentic AI can concentrate exposure through shared components and that the concentration must become visible before it can be discussed responsibly.

There is also a governance lesson. If the enterprise does not know which workflows depend on the same component, it cannot know which work units to review after a vendor change, model incident, cloud outage, prompt vulnerability, or tool permission error. The loss may look isolated because the evidence architecture is isolated.

The boundary for this chapter: aggregation analysis is not actuarial pricing guidance, not reinsurance underwriting guidance, not capital modeling, not legal advice, not insurance advice, not coverage opinion, not certification, not proof of insurability, not insurer endorsement, and not a regulator-approved method. Cyber and cloud accumulation sources are used as analogy and context unless the source directly addresses GenAI business risk.

The next chapter addresses a tension that runs through every evidence discussion in this paper. Insurance review needs records. Privacy, security, privilege, and data-minimization duties limit what records should be collected, retained, copied, or disclosed.

Chapter 13: Privacy, Evidence Minimization, and Insurance Review

Agentic AI creates a temptation: keep everything.

Keep every prompt. Keep every output. Keep every tool call. Keep every customer payload. Keep every memory entry. Keep every retrieved document. Keep every approval screen. Keep every vendor log. Keep every incident note. Keep every trace forever, just in case an insurer, auditor, regulator, lawyer, customer, or executive asks for it later.

That instinct is understandable. It is also dangerous.

Insurance review needs evidence, but uncontrolled evidence retention can create privacy, security, privilege, contractual, and legal exposure. Personal data may appear in prompts, memory, tool payloads, customer records, employee records, model outputs, retrieval context, incident tickets, vendor logs, screenshots, monitoring dashboards, and claim evidence packs. Secrets and credentials may appear in traces. Privileged communications may appear in remediation notes. Vendor confidential information may appear in dependency records.

Evidence maturity is not the same as hoarding. A mature evidence model preserves the ability to reconstruct the event while minimizing unnecessary sensitive-data exposure.

This is where privacy lifecycle concepts from the compliance white paper and selective-disclosure concepts from the auditability and assurance white paper become important. The compliance white paper helps name privacy lifecycle mapping, evidence minimization, selective disclosure, data subject rights tension, and third-party processor chains. The auditability and assurance white paper helps distinguish source pointers from bulk evidence dumps and reviewable evidence from unrestricted trace collection. These are analytical foundations, not GDPR advice, privacy legal advice, insurance requirements, or certification methods. [28] [31]

The core tension is simple. Underwriting and claim review may need to understand authority, role, tool action, accepted outcome, affected data class, external consequence, exception history, and remediation closure. But those records may contain more data than the reviewer needs to see. A good evidence architecture therefore separates existence, pointer, class, access, and disclosure.

Source pointers are often better than copies. A claim evidence pack can identify the system of record, timestamp, owner, retention period, hash or integrity marker where appropriate, and access pathway without duplicating sensitive payloads into a new uncontrolled file.

Redaction profiles should be designed before incidents. The organization should know which fields can be masked, tokenized, summarized, or disclosed under role-based access. If redaction is invented after a loss, the team may either over-disclose sensitive data or destroy context needed for reconstruction.

Access controls matter because evidence audiences differ. Engineering, counsel, brokers, insurers, vendors, auditors, regulators, and executives do not all need the same records. Some may need summaries. Some may need source pointers. Some may need full technical logs under controlled conditions. Some should not receive personal data, secrets, privileged materials, or vendor confidential information at all.

Data-class labels make evidence more useful. A prompt containing public information, personal data, payment data, health information, source code, security secret, regulated customer record, or privileged communication should not be treated as one generic trace. Labeling helps decide what can be retained, disclosed, minimized, or escalated.

Retention notes matter because evidence can disappear. Logs roll off. Vendor dashboards expire. Model records may be inaccessible after version changes. Data rights requests may require deletion or restriction. Contract terms may limit retention. Security policies may delete secrets. If evidence must be preserved for review, the retention basis and limits should be visible.

Privilege flags matter because incident response and legal review may create protected communications. this paper does not define privilege. It simply observes that evidence packs should not flatten privileged and non-privileged records into one uncontrolled bundle.

Third-party evidence creates a special problem. A vendor may hold model logs, runtime records, security events, cloud usage, monitoring data, or subprocessor details. The enterprise may need those records for reconstruction but may not have them by default. Processor and subprocessor mapping therefore belongs in the insurance evidence conversation. It is not only a privacy or procurement exercise.

Privacy-preserving third-party validation may become useful when direct disclosure is too sensitive. A reviewer may need assurance that evidence exists and supports a fact without receiving raw data. That can mean selective disclosure, controlled review rooms, redacted extracts, attestations limited to existence and integrity, or source-pointer verification. This paper does not define a validation standard. It identifies the evidence problem.

T-13-01 - Insurance Evidence vs Privacy Control Map

The most practical design move is an evidence index. The index should not be a dump of sensitive data. It should tell future reviewers what exists, where it lives, who owns it, what class of data it contains, what access controls apply, what retention limits exist, what redactions are available, what privilege concerns may exist, and what evidence is missing.

That index can support underwriting conversations, claim reconstruction, renewal review, and governance oversight without turning every agentic trace into a portable liability file.

The privacy chapter also reinforces the negative space from Chapter 8. A system can be hard to insure not only because it lacks evidence, but because it keeps evidence irresponsibly. Opaque execution is a problem. So is uncontrolled trace retention. The insurability question is not "more logs or fewer logs." It is whether the right evidence can be preserved, minimized, protected, and reconstructed for the right review purpose.

The boundary for this chapter: privacy and evidence-minimization analysis is not GDPR advice, privacy legal advice, legal advice, insurance advice, underwriting guidance, coverage opinion, certification, proof of insurability, insurer endorsement, regulator approval, or claim approval guidance. It is an evidence design lens for reconciling reviewability with data protection, security, privilege, and controlled disclosure.

Part III closes the translation layer. The compliance white paper contributes lifecycle governance objects. The auditability and assurance white paper contributes auditability and evidence-chain discipline. Insurance adds separate questions: insured subject, line ambiguity, covered object, aggregation, privacy-controlled evidence, claim reconstruction, and risk transfer boundary. Part IV can now move into underwriting-facing architecture with a clearer warning: evidence can make agentic risk more reviewable, but reviewability is still not coverage, pricing, or acceptance.

Part IV: Underwriting-Facing Architecture for Agentic AI Risk

Part IV moves from translation to architecture.

Part I showed that the insurance market is already splitting AI risk across affirmative cover, exclusions, sublimits, silent exposure, model-performance products, cyber-linked exposure, and unresolved lifecycle gaps. Part II defined the Insurable Agentic Risk Object as a bounded analytical object, not the insured legal subject. Part III translated compliance and auditability concepts into insurability reasoning without treating governance or auditability as insurance proof.

The next question is practical: what would an enterprise need to organize if it wanted agentic AI risk to be reviewable by a broker, risk engineer, underwriter, reinsurer, counsel, or internal risk team?

The answer is not a checklist that guarantees coverage. It is not an underwriting standard. It is not a rating model. It is not a certification path. It is not a premium-reduction playbook. It is an underwriting-facing architecture: a way to organize exposure, evidence, change, and review questions around bounded agentic work units.

The phrase "underwriting-facing" is deliberate. It means the architecture is useful for a risk-transfer discussion. It does not mean an insurer requires it, accepts it, discounts for it, or treats it as sufficient. Evidence can make the risk more legible. It cannot by itself make the risk covered, insurable, priced, or accepted.

Chapter 14: Underwriting Evidence Architecture

An enterprise can have a mature AI program and still be difficult to review from an insurance perspective.

It may have a model inventory, AI policy, model-risk committee, vendor list, security controls, incident process, privacy review, and logging system. Those are useful. But when a broker or risk engineer asks what the enterprise is actually trying to transfer, the answer may still be too broad: "We use AI in customer operations," "We use agents in engineering," or "We have governance controls for generative AI."

Underwriting-facing review needs something more exact. It needs evidence organized around bounded agentic work units.

Picture a mid-sized software company preparing for renewal. It has an AI coding assistant, a customer-support response agent, a finance reconciliation agent, and a sales proposal generator. The risk team can name the vendors and models, but it cannot say which work units can send external messages, which can update customer records, which can touch production code, which data classes are involved, which human role accepts the outcome, which tool actions are logged, which model/runtime changes occurred during the period, or which incidents were remediated and closed. The company has AI governance. It does not yet have underwriting-facing evidence architecture.

The architecture should begin with the work-unit inventory. The reviewer needs to know which bounded agentic work exists, not only which AI applications or models exist. A work unit may be a refund workflow, code-deployment assistant, claims triage process, contract review support workflow, customer message generator, invoice matching agent, procurement agent, or regulatory filing assistant. The work unit connects business function, authority, tool action, data, human role, vendor dependency, evidence, and consequence.

Authority boundaries come next. A draft-only agent creates a different review question from an agent that can approve, send, transact, deploy, delete, transfer, or update records. The boundary should show what the agentic work is allowed to do, what requires confirmation, what is prohibited, what thresholds apply, and where escalation occurs.

Role maps matter because agentic work rarely belongs to one actor. The architecture should identify the human role, agent role, vendor role, corporate owner, remediation owner, and any processor or subprocessor that holds relevant evidence. This is not a liability allocation. It is a review map.

Tool-action records are the point where output becomes consequence. Underwriting-facing evidence should identify the systems or services the agent can touch: email, CRM, ERP, payment system, code repository, deployment pipeline, ticketing system, database, cloud console, identity provider, third-party API, or customer record. The existence of tool records is not enough; the records should be linked to authority, role, outcome, exception, and closure.

Accepted outcome states help distinguish generated output from business action. A model response may be provisional. A sent message, approved payment, merged code change, updated customer account, or delivered professional recommendation may be accepted. Reviewers need to see how the enterprise knows the difference.

Exception history tells the reviewer where the system has already struggled. Overrides, threshold breaches, escalations, false positives, near misses, warning suppressions, vendor outages, prompt failures, and tool failures are not embarrassing side notes. They are evidence of how the risk behaves.

Privacy and redaction profiles make evidence usable. As Part III explained, a serious evidence model should not dump every prompt, payload, customer record, credential, secret, privileged note, or vendor log into a portable file. The architecture should show what can be disclosed, what must remain source-pointed, what is redacted, and who can access it.

Substitution and change records are central because agentic systems do not stay fixed. Model endpoints change. Vendor defaults change. Tool permissions widen. Data classes expand. Human review moves from required to sampled. A reviewed risk object can silently become a different risk object.

Remediation closure shows whether the organization can learn from events. A reviewer may need to see not only that incidents occurred, but whether they were contained, fixed, retested, reauthorized, and closed with residual risk visible. NIST and CISA incident-response sources support the importance of preparation, detection, response, recovery, remediation, coordination, and tracking, but they do not create insurance claim or underwriting standards. [41] [42]

Finally, the architecture should include a missing-evidence register. Missing evidence is part of the truth. It may be vendor-held, overwritten, outside retention, privileged, redacted, inaccessible, or never collected. A missing-evidence register helps reviewers understand uncertainty rather than pretend completeness.

Different users will use the architecture differently.

A broker may use it to translate enterprise AI operations into risk-transfer language. A risk engineer may use it to understand exposures, controls, dependencies, and reconstruction gaps. An underwriter may use it to ask better questions, subject to that insurer's own appetite, forms, guidelines, and judgment. A reinsurer may use it to see dependency concentration and aggregation shapes. Counsel may use it to preserve boundaries between evidence, privilege, legal advice, and coverage review. Enterprise risk teams may use it to make internal risk ownership visible.

None of those uses means the architecture is required, accepted, sufficient, or price-relevant. source research supports the general proposition that AI risk review may need exposure inventory, authority scope, dependencies, and evidence readiness, drawing on Aon, NAIC, NIST AI RMF, Geneva Association, Swiss Re, QBE, the compliance white paper, and the auditability and assurance white paper. The exact use by any insurer remains external. [43] [44] [45]

T-14-01 - Underwriting Evidence Architecture Components

The table is intentionally architectural. It does not say "submit these documents to get coverage." It says that a serious discussion of agentic AI risk needs a common evidence map before the parties can even understand the exposure.

The boundary for this chapter: underwriting evidence architecture is not legal advice, not insurance advice, not underwriting guidance, not an underwriting standard, not coverage opinion, not certification, not proof of insurability, not insurer endorsement, not a regulator-approved method, not actuarial pricing guidance, and not a premium recommendation.

The next chapter turns the architecture into an exposure inventory. Once the evidence components are known, the enterprise still needs to segment where agentic work creates different kinds of exposure.

Chapter 15: Agentic Exposure Inventory and Risk Segmentation

Many AI inventories are built for technology management, not risk transfer.

They list the application name, vendor, model family, business owner, data source, risk rating, and approval status. That may help procurement, security, or governance. It does not necessarily help a reviewer understand exposure. A single AI application may contain many agentic work units. A single model may support dozens of workflows. A single workflow may straddle cyber, professional liability, governance, crime, privacy, product, and business interruption questions.

An agentic exposure inventory should therefore sit at the level of work units, not only tools or models.

Consider a bank that lists "customer-service AI assistant" in its AI inventory. That label hides several different exposures. One work unit drafts customer responses. Another updates contact details. Another flags suspected fraud. Another recommends fee reversals. Another opens support tickets with a vendor. Another summarizes complaint history for a human reviewer. These work units differ in authority, data sensitivity, customer impact, external consequence, reversibility, dependency concentration, and line ambiguity.

Risk segmentation is the discipline of separating those work units before the insurance conversation starts.

The first segmentation dimension is business function. Agentic work in customer support, finance, engineering, legal, HR, procurement, sales, operations, claims, compliance, or security may create different exposure patterns. Function is not enough, but it orients the reviewer.

The second is external consequence. Does the work only draft internally, or can it send, file, deploy, pay, approve, deny, update, delete, publish, notify, or instruct an outside party? External consequence changes the risk conversation because the work leaves the model environment and affects someone or something else.

The third is authority level. A recommendation-only workflow is different from one that can transact. A sampled human review boundary is different from mandatory pre-action approval. An agent with emergency override permission is different from one confined to low-value routine activity.

The fourth is data sensitivity. Public content, internal business data, customer personal data, payment data, health data, employee data, source code, credentials, trade secrets, privileged material, and regulated records do not carry the same evidence and privacy implications.

The fifth is tool-action type. Emailing a customer, updating a CRM record, changing code, opening a vendor ticket, querying a database, initiating a payment, publishing content, or changing cloud infrastructure all produce different evidence and loss questions.

The sixth is customer or third-party impact. Some work units affect only internal productivity. Others affect customers, counterparties, vendors, employees, investors, regulators, patients, applicants, or the public. Impact surface matters even when the policy line is not yet known.

The seventh is dependency concentration. A work unit dependent on the same model, runtime, cloud region, identity service, tool connector, or vendor as many other work units carries aggregation relevance. Swiss Re and Geneva Association sources support the importance of dependency concentration and accumulation visibility as context and analogy. They do not provide agentic AI pricing conclusions. [46] [47]

The eighth is human confirmation boundary. "Human in the loop" is too vague. The inventory should record whether human confirmation is pre-action, post-action, sampled, threshold-based, exception-triggered, summary-only, or absent. It should also record what evidence the human sees.

The ninth is reversibility and remediation difficulty. A draft can be deleted. A sent customer notice may be corrected. A payment may or may not be reversible. A code deployment may be rolled back, but customer impact may persist. A regulatory filing may create a different closure problem. Reversibility changes the remediation story.

The tenth is cross-project reuse. A component reused across projects may create hidden exposure drift. The same agentic component can be low-risk in one context and high-impact in another.

This inventory helps risk discussion because it separates exposure units before they are bundled into broad claims like "AI use," "GenAI," or "agent platform." It also connects back to the earlier insurable agentic risk object and insurance line ambiguity analysis. The inventory tells the reviewer which object is being discussed and what kinds of line questions may arise.

It still does not create insurability. A clean inventory can support discussion, but actual insurance outcomes depend on policy language, underwriting appetite, limits, exclusions, loss history, controls, insured profile, jurisdiction, and the facts of the event.

T-15-01 - Agentic Exposure Inventory Template

The strongest inventories will also show gaps. A work unit with unknown authority, unknown data class, unknown human confirmation, unknown vendor dependency, or unknown evidence location should not be forced into a false sense of completeness. Unknowns are risk information.

This chapter's boundary: an agentic exposure inventory is not legal advice, not insurance advice, not underwriting guidance, not an underwriting standard, not coverage opinion, not certification, not proof of insurability, not insurer endorsement, not a regulator-approved method, not actuarial pricing guidance, and not a premium recommendation. It organizes exposure units for review.

The next chapter addresses the question that CFOs and CROs often ask too quickly: which variables matter to premium? The safe answer is to discuss exposure variables without turning them into pricing.

Chapter 16: Premium and Exposure Variables Without Pricing Guidance

The premium question is understandable. It is also easy to mishandle.

A CFO asks whether better AI controls will lower premium. A CRO asks whether autonomous agents will cost more to insure. A broker asks what evidence to gather before renewal. A product leader asks whether a human approval gate changes the insurance conversation. An engineering leader asks whether dependency concentration matters. The pressure is to answer with a formula.

This chapter does not provide one.

It does not provide actuarial pricing guidance, rating methodology, premium recommendation, underwriting rule, insurer appetite statement, rate factor, surcharge, discount, credit, model score, band, or threshold. It identifies variables that may matter for risk review because they affect exposure, evidence, control, aggregation, or reconstruction.

The first variable is autonomy level. A system that drafts text for human use raises different review questions from one that can approve refunds, deploy code, transfer funds, change records, or send customer-impacting instructions. Autonomy matters because it changes timing, intervention, authority, and evidence expectations. It still cannot be converted into a pricing band.

The second is tool-action severity. The same model output can be harmless in a draft and serious when connected to payment, production infrastructure, regulated filing, customer notice, medical workflow, legal advice, or financial decision support. Tool action shows where consequence becomes concrete.

The third is transaction volume. A workflow that runs five times a month has a different opportunity surface from one that acts thousands of times per day. Volume may matter to frequency discussion, but frequency is not a rate formula.

The fourth is customer or third-party reach. Internal productivity tools, customer-facing tools, vendor-facing tools, employee-facing tools, investor-facing disclosures, and public content do not create the same external impact surface.

The fifth is data sensitivity. Agentic work involving personal data, payment data, credentials, source code, health data, employee data, privileged material, or regulated records may raise privacy, security, cyber, professional, and governance questions.

The sixth is reversibility. A low-value internal recommendation may be easy to correct. A payment, customer communication, production deployment, regulatory filing, or public statement may be harder to unwind. Reversibility shapes remediation discussion without deciding loss amount.

The seventh is human confirmation strength. A meaningful confirmation boundary includes role, authority, criteria, visible evidence, timing, and exception handling. A summary-only click may not have the same review value as pre-action approval with full context. This does not mean human review guarantees coverage or lowers premium.

The eighth is evidence maturity. Reviewers may ask whether records connect work unit, authority, role, tool action, accepted outcome, exception, privacy treatment, remediation, and change. Evidence maturity makes the risk more reviewable. It does not guarantee coverage, quote, or claim payment.

The ninth is vendor, model, and runtime concentration. Shared dependencies can create correlated exposure across workflows or insureds. Geneva Association and Swiss Re sources support the importance of accumulation and cloud concentration as context and analogy. QBE LLMjacking materials show concrete AI-linked cyber evidence needs around access, usage, containment, and remediation. None of these sources creates agentic AI pricing guidance. [46] [47] [48]

The tenth is prior incidents and near misses. Events matter because they show how the system behaves under stress and whether controls work. Near misses may be as informative as losses. The safe question is not "what premium change follows?" but "what happened, what evidence exists, and what changed after remediation?"

The eleventh is remediation maturity. Detection is only the beginning. The reviewer may ask how quickly the organization contained, fixed, retested, reauthorized, and closed the issue, and whether residual risk remained visible. NIST and CISA support structured incident and remediation records. They do not provide insurance pricing rules. [41] [42]

The twelfth is cross-project reuse. A component reused across many contexts can spread exposure. A model or tool that was reviewed for one workflow may not be reviewable in another without reauthorization. Reuse matters because it changes object boundaries.

These variables are still incomplete without policy language, line of coverage, insured profile, jurisdiction, market appetite, loss history, controls, exclusions, limits, sublimits, deductibles, retention, and the underwriter's own framework. A variable dictionary is therefore only a way to organize the conversation.

T-16-01 - Non-Pricing Exposure Variables

The careful language is "may matter," "can shape exposure discussion," "risk reviewers may ask," and "evidence signal." The unsafe language is "will affect premium," "earns a discount," "creates a surcharge," "qualifies for coverage," "fails underwriting," or "meets a rating level."

This chapter's boundary: premium and exposure variables are analytical inputs for risk review. They are not actuarial pricing guidance, not rating methodology, not premium recommendation, not underwriting guidance, not underwriting standard, not coverage opinion, not legal advice, not insurance advice, not certification, not proof of insurability, not insurer endorsement, and not a regulator-approved method.

The next chapter adds time. Even a well-described exposure can change quickly when workflows, authority, tools, models, vendors, data classes, human review boundaries, incidents, or evidence gaps change.

Chapter 17: Renewal, Change, and Substitution Evidence

Agentic AI risk does not stand still between renewal cycles.

A workflow that was draft-only in January may send customer messages in April. A model endpoint may change in June. A tool connector may gain write permission in July. A vendor may change logging defaults in August. A team may reuse the same agent in a new business unit in September. A near miss may reveal that the human reviewer was seeing only a summary, not the full evidence. By renewal, the original risk object may exist only on paper.

Underwriting-facing evidence cannot be one-time only. It needs a change layer.

Renewal review should begin with new workflows. Which agentic work units were added, retired, expanded, merged, or reused? The reviewer should not have to infer change from a model inventory.

Changed authority is often the most important update. Did any workflow move from draft to send, recommend to approve, approve to transact, or human-required to sampled review? Did thresholds change? Were emergency overrides added? Was escalation weakened?

New tools matter because tool actions create external consequence. A workflow that gains access to email, payment, CRM, ERP, cloud infrastructure, code deployment, data export, vendor ticketing, or customer records has changed its exposure shape.

New models, vendors, and runtimes matter because substitution can alter behavior and evidence. A reviewed work unit may depend on a model version, orchestration layer, cloud service, logging tool, data processor, or API. If that dependency changes, the enterprise needs substitution conformance evidence.

Changed data classes matter because privacy, cyber, regulatory, and claim reconstruction implications change. A workflow that originally touched public content may now touch customer records, payment data, employee records, code, credentials, or privileged material.

Changed customer impact matters because an internal productivity tool can become customer-facing. A tool used for internal drafting can become a communication channel. A recommendation can become a decision. A decision can become an automated action.

Changed human review boundaries matter because a control may weaken without appearing to disappear. A reviewer may shift from full-context review to summary review, from pre-action review to post-action review, from every action to sampled review, or from named role to rotating queue.

Incidents and near misses matter because they are the evidence of how the system behaves. Renewal evidence should record what happened, which work units were affected, what was contained, what changed, what remains open, and what lessons were implemented. NIST and CISA support continuous improvement and remediation tracking as incident-response disciplines, not as insurance requirements. [41] [42]

Remediation actions matter only if closure is visible. A fix without retest, reauthorization, residual-risk note, owner signoff, or monitoring plan may not close the review question.

Unresolved evidence gaps should travel into renewal. If a vendor-held log was inaccessible, a retention period was too short, a prompt record was redacted without pointer, a human approval screen lacked context, or a tool action was not joined to authority, the gap should not disappear from the file.

The useful frame is before execution, during execution, and after execution.

Before execution, the enterprise defines work unit, authority, role, data, tool, dependency, and evidence expectations. During execution, it records action, confirmation, exception, and outcome. After execution, it records incident, remediation, substitution, closure, and renewal change. This dynamic lifecycle record is what keeps the reviewed object from going stale.

T-17-01 - Renewal and Change Evidence Register

Substitution conformance is the connective tissue. It asks whether a changed component preserves the work unit's authority, role, evidence, privacy, outcome, exception, and remediation boundaries. It is not vendor certification. It is a continuity question.

This chapter's boundary: renewal and change evidence is a continuity record for review. It is not legal or insurance advice, underwriting guidance, coverage opinion, certification, proof of insurability, insurer endorsement, regulator-approved method, actuarial pricing guidance, or premium recommendation.

The next chapter turns the architecture into a practical evidence request structure while preserving the most important boundary: optional evidence requests should not masquerade as standards.

Chapter 18: Reviewer-Facing Evidence Requests Without Creating a Standard

Evidence request lists are useful. They are also dangerous.

If written badly, they become fake standards. A template starts to sound like a requirement. A request list starts to sound like an underwriting checklist. A readiness package starts to sound like certification. A missing field starts to sound like automatic denial. A completed field starts to sound like coverage readiness.

That is not what this paper is doing.

This chapter offers a structured, optional evidence request model for enterprises, brokers, risk engineers, counsel, and reviewers who need a practical way to organize agentic AI risk discussions. It is not a claim demand, not an underwriting checklist, not a certification checklist, not a regulator-approved checklist, not a procurement requirement, and not proof that any insurer will accept, price, quote, renew, bind, endorse, or pay a claim.

The first request area is an inventory summary. It should name the population of agentic work units, not simply the AI tools. The summary should identify business function, owner, authority class, data class, external consequence, dependency concentration, and current status.

The second is a high-impact work-unit list. Reviewers do not need every low-risk experiment at the same depth. They may need to see work units that touch customers, money, regulated data, production systems, professional deliverables, employee decisions, public communications, or high-volume automated actions.

The third is an authority and role map. The request should ask who initiates, configures, approves, accepts, escalates, remediates, and closes, and what the agent, tool, vendor, and corporate owner do. This turns HITL into a reviewable responsibility structure.

The fourth is a tool-action sample. A useful sample should show how model output becomes external action, such as an API call, email, payment, account update, code deployment, database change, filing, or vendor ticket. It should also show authority and accepted outcome.

The fifth is an evidence-chain sample. The goal is not a full data dump. It is to show that core lifecycle records can be joined through source pointers across prompt, output, tool action, approval, exception, incident, remediation, and gap evidence.

The sixth is a privacy and redaction profile. Reviewers may need to know how sensitive data is protected without receiving uncontrolled raw traces. The request should ask for data-class labels, access controls, redaction rules, and source-pointer strategy.

The seventh is incident and near-miss history. The request should identify relevant events, affected work units, external consequence, evidence available, containment, fix, retest, reauthorization, and closure state. It should not ask the enterprise to pre-judge coverage or liability.

The eighth is remediation closure examples. A few examples can show whether the organization closes incidents as evidence objects or merely resolves tickets operationally.

The ninth is a substitution and change register. Reviewers may ask what changed since the last review or deployment: models, tools, vendors, runtimes, permissions, data classes, customer impact, and human review boundaries.

The tenth is a dependency map. This should show shared models, cloud services, APIs, identity providers, data processors, tool connectors, evidence systems, and vendors across work units. For reinsurers and portfolio-minded reviewers, dependency concentration can be as important as individual workflow design.

The eleventh is a missing-evidence register. This is where the enterprise shows intellectual honesty. It should say what is missing, why, who controls it, whether it is recoverable, whether it is redacted, whether retention expired, and whether remediation is planned.

T-18-01 - Optional Reviewer Evidence Request Structure

The request model should be used with judgment. A small internal drafting assistant does not need the same depth as a high-volume payment workflow. A professional-services workflow may need different evidence from a customer-support bot. A cyber-linked LLMjacking event may require different access and usage records than a model-performance warranty scenario. QBE, Aon, Geneva, Swiss Re, NAIC, NIST, the compliance white paper, and the auditability and assurance white paper sources all support pieces of the evidence, governance, dependency, and reconstruction logic, but no cited source supports treating this request structure as a market-wide insurer requirement. [41] [42] [43] [44] [45] [46] [47] [48]

The final discipline is tone. A request should ask, not command. It should say "provide if available," "describe," "identify," "summarize," "show source pointers," and "note gaps." It should not say "must provide to qualify," "required for coverage," "certification evidence," "underwriting pass/fail," or "premium credit."

This chapter's boundary: reviewer-facing evidence requests are optional analytical structures. They are not legal or insurance advice, underwriting guidance or standards, coverage opinions, claim demands, certification checklists, proof of insurability, insurer endorsements, regulator-approved methods, actuarial pricing guidance, premium recommendations, procurement requirements, or claim approval guidance.

Part IV has built the underwriting-facing architecture: evidence components, exposure inventory, non-pricing variables, renewal/change evidence, and optional reviewer requests. It does not say the architecture is accepted by the market. It says the architecture is what an enterprise can use to make agentic AI risk more legible before underwriting, renewal, reinsurance, counsel, and risk-engineering discussions.

Part V can now move to the other side of the loss event: claims, disputes, responsibility and coverage boundaries, and post-loss remediation evidence.

Part V: Claims, Disputes, and Post-Loss Responsibility Evidence

Part IV organized agentic AI risk before loss: exposure inventory, underwriting-facing evidence, non-pricing variables, renewal change records, and optional reviewer evidence requests. Part V moves to the other side of the event.

The question changes after a loss. The enterprise is no longer asking only whether an agentic workflow is understandable enough for a risk discussion. It is asking what happened, who or what acted, what authority existed, what evidence survived, what cannot be reconstructed, what policy boundary questions may arise, what was fixed, and what the event should change before the next review.

That is not the same as claim approval. It is not coverage determination. It is not legal causation. It is not a liability finding. It is post-loss responsibility evidence: the disciplined reconstruction of a bounded agentic work unit after something has gone wrong.

Agentic AI makes this harder because the loss may not be located in a single model output. A model may have produced a plausible answer. An agent may have converted it into an action. A tool may have changed a customer record. A human may have approved a summary without seeing the full evidence. A vendor may hold the logs. A privacy rule may limit disclosure. A model or runtime may have changed before anyone investigated. The claim file may contain fragments, but fragments are not reconstruction.

Part V therefore builds the post-loss layer of the paper. It asks how claim reconstruction, dispute handling, coverage-boundary questions, remediation closure, and renewal feedback can be organized without pretending that evidence decides the legal or insurance outcome.

The compliance white paper supplies lifecycle vocabulary for authority, accepted outcome, substitution, and remediation closure. The auditability and assurance white paper supplies audit-evidence vocabulary for joining traces, records, and source pointers. In Part V, both are used as analytical scaffolding only, not insurance proof. [54] [55]

Chapter 19: Claim Reconstruction After Agentic AI Incidents

An incident notice is not claim reconstruction.

"The AI system made an error" is a useful alarm, but it is a weak claim narrative. It does not say which work unit failed, what the agent was authorized to do, what the human saw, what tool action occurred, which data changed, what loss followed, whether the event was exceptional or ordinary, what was remediated, or which evidence is missing. It may be enough to start an internal response. It is not enough to reconstruct an agentic incident for insurance-facing review.

Claim reconstruction begins with the bounded work unit. The unit may be a refund workflow, customer notice workflow, claims triage workflow, professional deliverable workflow, deployment assistant, payment exception process, or account-update agent. The phrase "AI failure" should be translated into "this work unit acted under this authority, through this role and tool path, producing this consequence, with this evidence and these gaps."

Consider a customer-support agent that incorrectly triggers a refund and sends a confirmation email. The customer receives money they were not owed. The account record changes. A finance reconciliation process flags the mismatch two days later. The team can produce a model trace and an email record, but it cannot immediately answer whether the agent had refund authority, whether a human reviewer approved the action or only reviewed the message, whether the CRM update and payment action were linked, whether the tool action exceeded a threshold, whether the model endpoint changed that week, or whether the exception was closed.

That is the difference between notice and reconstruction.

The first reconstruction layer is initiating intent. What task was the work unit supposed to perform? Was it answering a customer question, correcting an account, processing a refund, triaging a complaint, drafting professional advice, or changing production code? Without intent, the event is only a sequence of technical actions.

The second layer is authority boundary. Was the agent allowed to recommend, draft, approve, send, pay, update, delete, deploy, file, or escalate? Was the action inside a threshold, outside a threshold, or ambiguous? Authority does not decide legal liability, but it frames whether the work acted as designed, drifted, or exceeded the expected perimeter.

The third layer is agent role. Did the agent draft, classify, recommend, decide, execute, monitor, or remediate? A model output is not the same as an agentic role. The reconstruction has to identify whether the agent merely produced text or actually caused a tool-mediated external consequence.

The fourth layer is human role. Human-in-the-loop is not enough. The file should show who reviewed, what they could see, when they reviewed, what authority they held, what criteria applied, and whether they accepted the outcome. A human reviewer who sees only a summary is not in the same position as a reviewer who sees the work-unit evidence chain.

The fifth layer is tool action. This is where generated output becomes business consequence: email sent, refund issued, account changed, code deployed, vendor ticket opened, database updated, filing submitted, credential used, cloud resource consumed, or customer notice published. Tool action is often the hinge between "the model said something" and "the organization did something."

The sixth layer is external consequence. Who or what was affected? A customer, vendor, employee, applicant, patient, investor, regulator, public audience, cloud bill, data system, production service, or professional client may each require different evidence. The consequence also shapes which internal teams, policy lines, vendors, counsel, or response partners may become relevant.

The seventh layer is affected data. Personal data, payment data, employee records, customer records, credentials, source code, privileged material, health data, vendor data, and operational logs carry different evidence and disclosure constraints. Claim reconstruction that ignores data class may either over-disclose sensitive material or fail to preserve source pointers.

The eighth layer is evidence chain. Logs and traces are ingredients. A reconstruction needs source pointers that connect intent, authority, role, prompt/output, tool action, human confirmation, external consequence, exception, remediation, and gap records. NIST and CISA incident-response sources support structured incident timelines, containment, response, recovery, remediation, and tracking. They do not determine claim approval, legal causation, or coverage. [49] [50]

The ninth layer is exception record. Was there a warning, override, failed validation, repeated near miss, manual correction, vendor outage, permission change, abnormal consumption pattern, or threshold breach? In AI-linked cyber settings such as LLMjacking, QBE materials point to access, API usage, abnormal consumption, containment, and remediation evidence as concrete reconstruction inputs. That support remains cyber-evidence support, not a promise of policy response. [51]

The tenth layer is remediation action and closure state. Was the workflow disabled, permission changed, account corrected, affected party notified, customer reimbursed, code rolled back, model endpoint reverted, prompt updated, human review strengthened, or vendor ticket resolved? Was the work unit retested and reauthorized? Was residual risk accepted? Closure is a lifecycle state, not a settlement.

The final layer is missing evidence. Missing evidence should not be hidden inside narrative. It should be named. Vendor-held logs, expired retention, redacted records without source pointers, missing approval screens, overwritten prompts, unjoined payment records, unavailable cloud usage data, and unclear version history all shape what can and cannot be reconstructed.

T-19-01 - Agentic Claim Reconstruction Map

The important distinction is between four different kinds of inquiry. The technical sequence asks what systems, prompts, tools, identities, and records moved in what order. The operational incident asks what business process failed and how it was contained. Legal causation asks questions that belong to counsel, courts, dispute forums, contracts, and applicable law. Insurance claim analysis asks policy-specific questions about notice, facts, wording, exclusions, limits, deductibles, causation, loss category, and claim handling authority.

Agentic claim reconstruction can support the first two and organize facts for the latter two. It cannot replace them.

This chapter's boundary: claim reconstruction after agentic AI incidents is not legal advice, not insurance advice, not underwriting guidance, not coverage opinion, not claim approval guidance, not legal liability determination, not certification, not proof of insurability, not insurer endorsement, not regulator-approved method, not actuarial pricing guidance, and not premium recommendation.

The next chapter turns to what happens when the reconstruction is incomplete or contested. Agentic incidents do not only create loss. They create disputes about responsibility, authority, acceptance, and evidence gaps.

Chapter 20: Dispute, Responsibility, and Evidence Gaps

Disputes often begin where the evidence stops.

An enterprise may tell a customer that an AI agent made an error. The customer may say the company made a promise. The enterprise may tell an insurer that the incident was a covered cyber event. The insurer may ask whether it was authorized operational misuse. The enterprise may tell a vendor that the platform failed. The vendor may point to configuration. A business team may say legal approved the workflow. Legal may say it never saw the tool-action authority. Security may have logs. Privacy may restrict disclosure. Engineering may know the model endpoint changed. No one may own the complete reconstruction.

This is why evidence gaps should be explicit, not hidden.

A dispute can arise between enterprise and customer. The customer experienced the external consequence: wrong notice, wrong refund, wrong account status, wrong professional deliverable, wrong access decision, wrong service interruption. The enterprise needs to explain what happened without overclaiming what the evidence proves.

A dispute can arise between insured and insurer. The question may not be "did AI cause a loss?" but whether the event fits the policy wording, notice requirements, covered peril, loss category, exclusion, sublimit, deductible, or condition. This paper does not answer that. It helps show which facts would need to be reconstructed.

A dispute can arise between enterprise and vendor. The enterprise may depend on a model provider, orchestration platform, cloud service, identity provider, data processor, tool connector, or evidence repository. Vendor-held logs, service notices, model versions, runtime defaults, and API records can be essential. If they are unavailable, the dispute becomes partly an evidence-access dispute.

A dispute can arise around human and agent responsibility. The human may have approved an output, but not the action. They may have seen a summary, but not the source. They may have been responsible for exceptions, but not routine executions. The agent may have acted within configured authority, but the authority may have been poorly designed. Responsibility evidence should not be collapsed into legal liability conclusions.

A dispute can arise inside the enterprise. Business, security, legal, privacy, compliance, engineering, procurement, finance, and risk teams often hold different pieces of the event. Each team may have a true fragment. The review problem is that none of the fragments alone reconstructs the lifecycle work.

The most common gaps are ordinary. There is no authority record. The approval context is missing. The tool-action record is separate from the model trace. The human approval screen did not show the evidence the reviewer would later need. The vendor has logs but the contract does not make them available. Retention expired. Redaction removed the useful source pointer. A model substitution occurred without conformance review. A remediation ticket closed operationally without lifecycle closure.

Those gaps are not just embarrassing documentation defects. They define the boundary of what the event can say.

An evidence gap register should therefore include the missing item, why it is missing, who may control it, whether it is recoverable, whether the absence affects reconstruction, whether a privacy or privilege constraint applies, and whether future remediation is planned. The register should not be written as an accusation. It should be written as a map of uncertainty.

NIST and CISA sources support the value of incident tracking, coordination, recovery, and remediation records. SEC cyber disclosure rules support governance and material incident disclosure context for public companies, but they do not turn an evidence gap into a securities, coverage, or liability conclusion. [49] [50] [52]

T-20-01 - Dispute and Evidence Gap Register

The value of a gap register is discipline. It prevents a team from filling uncertainty with confidence. It also prevents the opposite mistake: treating one missing record as proof that nothing can be reconstructed. Some events can be reconstructed from multiple partial sources. Others cannot. The register helps reviewers see the difference.

Responsibility disputes should remain responsibility disputes until the right forum decides otherwise. A role map can show who initiated, configured, approved, executed, accepted, remediated, and closed. It cannot decide legal liability. An evidence chain can show what happened. It cannot decide coverage. A missing-evidence register can show uncertainty. It cannot by itself approve or deny a claim.

This chapter's boundary: dispute and evidence-gap analysis is not legal advice, not insurance advice, not underwriting guidance, not coverage opinion, not claim approval guidance, not legal liability determination, not certification, not proof of insurability, not insurer endorsement, not regulator-approved method, not actuarial pricing guidance, and not premium recommendation.

The next chapter addresses the most sensitive post-loss question: where the coverage boundary might sit. The paper can help frame the question. It cannot answer it.

Chapter 21: Coverage Boundary Analysis Without Coverage Opinion

Agentic incidents often cross insurance lines before anyone agrees what kind of loss occurred.

A payment agent sends funds to the wrong party after a manipulated email. Is the review about cyber, crime, social engineering, authorized instruction, operational error, professional services, or internal control failure? A coding agent deploys a bad change that interrupts customer service. Is the question cyber, tech E&O, business interruption, professional liability, contract, or service failure? A generative content workflow publishes a misleading statement. Is the issue media liability, professional liability, D&O disclosure, advertising, IP, or operational governance?

The answer depends on policy wording, jurisdiction, facts, notice, exclusions, limits, sublimits, deductibles, causation, loss category, and claim handling control. This paper does not interpret policy language. It does not provide coverage opinion.

What it can do is identify why agentic evidence matters to coverage-boundary questions.

The first boundary is cyber versus authorized operational misuse. If credentials were stolen, an API abused, data exposed, cloud resources consumed, or service interrupted through unauthorized access, cyber evidence may be central. If a permitted workflow performed the wrong business action under configured authority, the question may look different. QBE's AI-linked cyber and LLMjacking materials support the need for access, API usage, abnormal consumption, containment, and remediation evidence, but they do not decide policy response. [51]

The second boundary is technology E&O versus professional liability. A vendor-provided AI service may fail as a product or platform. A professional firm may deliver advice, analysis, design, legal, financial, engineering, medical, or consulting work using agentic support. The same model output can appear in both settings. The evidence question is who promised what service, who accepted the output, what human judgment applied, and where the tool action affected the client.

The third boundary is product versus service. An AI-enabled device, software product, SaaS feature, or embedded agent may create different questions from an internal workflow that supports a service. The evidence needs include product version, use context, model/runtime record, tool action, user interaction, monitoring, and remediation. The paper can name those evidence needs. It cannot determine whether a product or service policy responds.

The fourth boundary is D&O or governance versus operational failure. A board or officer may be relevant where oversight, disclosure, public statements, securities claims, cyber governance, or risk-management failures are alleged. SEC cyber disclosure rules support the importance of governance and material incident context for public companies. They do not create D&O coverage proof or determine securities liability. [52]

The fifth boundary is crime/social engineering versus cyber. Deepfake fraud, invoice manipulation, synthetic identity, agent-assisted payment approval, and credential misuse can straddle policy concepts. The reconstruction should preserve communication records, authentication evidence, approval steps, payment authorization, identity proofing, and tool actions. It should not assume the line outcome.

The sixth boundary is media/IP versus generated content workflow. A workflow may create text, code, images, audio, marketing claims, legal summaries, or public statements. The coverage question may depend on publication, rights review, source material, approval, takedown, and policy wording. The agentic evidence helps show what was generated, reviewed, accepted, and published.

The seventh boundary is business interruption or property versus cloud/API/service interruption. A shared cloud, model, API, identity, data, or vendor dependency may affect operations. The evidence question is dependency map, service status, incident timeline, affected work units, restoration steps, and loss measurement. That evidence may help frame a boundary question, but it is not a business interruption determination.

The eighth boundary is privacy or regulatory investigation versus operational event. A prompt, memory, log, tool payload, customer record, employee record, or evidence pack may contain personal or regulated data. The claim file may need source pointers and redaction controls, but privacy/legal conclusions remain outside this paper.

Aon materials support the general reality that AI risk can touch cyber, E&O, professional liability, crime, D&O, governance, employment, and other enterprise risk lines. source research on silent exposure uses that market context to explain why line ambiguity matters. Neither source permits a universal coverage conclusion. [53] [56]

T-21-01 - Coverage Boundary Question Map

The table should be read as a question map, not an answer key. It helps a team avoid two errors: treating every AI-linked event as one line, and treating line ambiguity as hopeless. The right posture is narrower. Preserve the facts. Separate the work unit. Identify the action. Map the affected data and consequence. Preserve policy-specific questions for authorized review.

This chapter's boundary: coverage-boundary analysis is not legal advice, not insurance advice, not underwriting guidance, not coverage opinion, not claim approval guidance, not legal liability determination, not certification, not proof of insurability, not insurer endorsement, not regulator-approved method, not actuarial pricing guidance, and not premium recommendation. Policy wording, jurisdiction, facts, notice, exclusions, limits, sublimits, deductibles, causation, loss category, and claim handling control remain external and case-specific.

The next chapter moves from boundary questions to post-loss closure. Even when the coverage outcome is unresolved, the enterprise still needs to contain, fix, retest, reauthorize, and record residual risk.

Chapter 22: Post-Loss Remediation, Reauthorization, and Residual Risk

An operational fix is not necessarily remediation closure.

After an agentic incident, teams often move quickly. Disable the workflow. Revoke a permission. Patch the prompt. Change the model endpoint. Roll back code. Refund a customer. Send a correction. Update a playbook. Close the ticket. The organization feels the event is over because operations are stable again.

From a lifecycle evidence perspective, the event may still be open.

Post-loss remediation should show what was contained, what caused the event, which work units were affected, which customers or third parties were affected, which data was involved, which authority boundary failed, which tool permissions changed, whether a model/vendor/runtime substitution mattered, whether the human review boundary was updated, what was retested, who reauthorized the workflow, what residual risk remains, and whether the renewal/change register was updated.

Take a payment workflow incident. An agent incorrectly approves a refund above its intended limit. The team disables the refund tool, manually reverses what it can, updates the threshold, and apologizes to affected customers. That may be a real operational response. But remediation closure still needs to show root cause, affected work units, affected customers, data involved, authority correction, tool permission correction, evidence chain preservation, retest, reauthorization, residual-risk acceptance, and any unresolved gaps.

The first stage is containment. What was stopped, isolated, disabled, suspended, blocked, or escalated? Containment evidence should identify the time, owner, work units affected, tool permissions changed, and immediate customer/system impact. NIST and CISA sources support containment, response, recovery, coordination, and tracking as incident-response disciplines, not insurance requirements. [49] [50]

The second stage is root-cause analysis. Root cause in this paper does not mean legal causation. It means the operational explanation the organization can support: authority misconfiguration, tool permission drift, missing human context, prompt failure, model/runtime change, vendor outage, data-quality issue, identity/access problem, exception-handling failure, or monitoring gap.

The third stage is affected work-unit mapping. Agentic systems are reused. A fix for one work unit may not cover another. The remediation record should identify all workflows that used the same model, tool connector, prompt pattern, permission, vendor, runtime, identity path, or evidence repository.

The fourth stage is affected customer, third-party, and data mapping. Who or what experienced consequence? Which data classes were touched? Was any evidence redacted, privileged, vendor-held, or restricted? This mapping helps preserve reviewability without turning the remediation record into legal advice.

The fifth stage is authority correction. If the agent had too much authority, the record should show the corrected permission, threshold, escalation path, prohibited action, or human confirmation boundary. If the authority was correct but misunderstood, the record should show clarification and training context.

The sixth stage is tool permission correction. The most important post-loss changes may be outside the model: API permission, CRM write access, payment threshold, deployment right, data export, email send capability, ticketing integration, or cloud console access. Tool records connect remediation to consequence.

The seventh stage is substitution review. If the model, vendor, runtime, orchestration layer, logging setting, data processor, or tool connector changed, the organization should ask whether the new component preserves the core lifecycle object fields defined earlier: authority, role, evidence, privacy, outcome, exception, and remediation. This continues the the substitution conformance logic without turning it into vendor certification.

The eighth stage is human review boundary update. If the incident showed that the reviewer lacked context, saw only a summary, reviewed after action, reviewed too many items, or lacked authority to block, the remediation record should say what changed.

The ninth stage is retest and reauthorization. A fix should not only be made. It should be tested against the relevant work-unit scenario and reauthorized by an accountable owner. Reauthorization is not regulatory approval or insurer approval. It is an internal lifecycle state.

The tenth stage is residual-risk acceptance. Some risk remains after remediation. The question is whether the organization names it, owns it, monitors it, and carries it into renewal and future review.

T-22-01 - Post-Loss Remediation Evidence Map

Remediation closure is the state in which the organization can say: the event was contained, the work unit was understood, affected parties and data were mapped, authority and tool boundaries were corrected where needed, substitutions were reviewed, human review was updated where needed, the workflow was retested, an accountable owner reauthorized or retired it, residual risk is visible, and future review records were updated.

That is not the same as legal settlement. It is not claim closure. It is not proof of no liability. It is not a renewal guarantee. It is the lifecycle discipline that prevents incidents from remaining unresolved objects inside the enterprise.

This chapter's boundary: post-loss remediation and reauthorization evidence is a lifecycle closure record. It is not legal or insurance advice, underwriting guidance, coverage opinion, claim approval guidance, legal liability determination, certification, proof of insurability, insurer endorsement, regulator-approved method, actuarial pricing guidance, or premium recommendation. Remediation closure does not eliminate liability or guarantee renewal, coverage, pricing, or claim outcome.

The next chapter closes Part V by sending post-loss learning back into the pre-loss architecture. A serious incident should change the future risk file.

Chapter 23: Claims-to-Renewal Feedback Loop

A serious agentic incident should not disappear after operational closure.

If the event revealed unclear authority, weak human review, missing tool-action evidence, vendor-held logs, privacy/redaction tension, dependency concentration, model substitution, or unclosed remediation, those lessons should feed the next review. Otherwise, the enterprise repeats the same story at renewal: "we have AI governance," while the actual risk object remains hard to understand.

The claims-to-renewal feedback loop is risk learning. It is not pricing guidance. It does not say an incident will increase premium, reduce premium, trigger a surcharge, earn a discount, change appetite, or determine renewal. It says that post-loss facts should update the evidence architecture that future reviewers use.

The loop begins with the incident record. The record should identify the bounded work unit, event timeline, action, consequence, affected data, parties involved, source pointers, and open questions. It should avoid unsupported conclusions about liability, coverage, or claim outcome.

The second input is the evidence gap register. Gaps should not be forgotten because the event was contained. If vendor logs were inaccessible, retention was too short, redaction lacked source pointers, or a tool action was not joined to authority, the gap belongs in future evidence design.

The third input is remediation closure. What was fixed, retested, reauthorized, retired, or left open? Who owns residual risk? What monitoring changed? Which unresolved items should be visible at renewal?

The fourth input is exposure inventory. If the event showed that a work unit had more authority, data sensitivity, customer impact, dependency concentration, or reversibility difficulty than expected, the inventory should change. If the same component appears in other work units, those work units should be reviewed.

The fifth input is the authority map. Did the event reveal unclear delegation, excessive permissions, weak thresholds, missing escalation, emergency override misuse, or an approval role without enough evidence? Authority changes should not live only in engineering tickets.

The sixth input is the dependency map. A model, cloud region, API, identity provider, vendor, processor, evidence repository, or runtime may have become a concentration point. That dependency should be visible before the next broker, risk-engineering, underwriting, reinsurance, or enterprise risk review.

The seventh input is the privacy and redaction profile. Post-loss evidence often exposes where the organization either hoarded sensitive traces or failed to preserve useful source pointers. The next review should improve selective disclosure, access control, data labels, privilege flags, and retention design.

The eighth input is the renewal/change register. Part IV argued that agentic risk changes over time. Part V adds that incidents are change events. A serious incident should update workflow status, authority, tools, data classes, dependencies, human review, remediation closure, missing evidence, and residual risk.

The ninth input is the reviewer-facing request package. The next time a broker, risk engineer, counsel, internal reviewer, or underwriter asks for evidence, the package should reflect what the organization learned. It should not be a static template that ignores observed failure.

Different users will use this feedback differently. Enterprise risk teams use it to own the internal risk story. Engineering teams use it to improve controls and evidence capture. Counsel uses it to preserve legal boundaries. Brokers and risk engineers may use it to frame future conversations. Underwriters may ask their own questions under their own forms, appetite, and judgment. None of those uses converts the loop into a market-wide standard.

T-23-01 - Claims-to-Renewal Feedback Loop

The feedback loop also clarifies what should remain separate. Enterprise internal learning is not insurer acceptance. Broker or risk-engineering review is not underwriting decision. Underwriting review is not coverage opinion. Legal and coverage claim handling remains case-specific. Claim reconstruction is not claim approval. Remediation closure is not no-liability proof. Renewal learning is not premium guidance.

The value of the loop is memory. Agentic systems change quickly. Without a feedback loop, a serious incident becomes a story, then a ticket, then an archived file. With a feedback loop, it becomes a source of better exposure segmentation, better authority design, better evidence capture, better privacy controls, better dependency visibility, better remediation closure, and a more honest future risk discussion.

This chapter's boundary: claims-to-renewal feedback is not legal advice, not insurance advice, not underwriting guidance, not coverage opinion, not claim approval guidance, not legal liability determination, not certification, not proof of insurability, not insurer endorsement, not regulator-approved method, not actuarial pricing guidance, and not premium recommendation. It does not provide pricing, discount, surcharge, insurer appetite, renewal, binding, endorsement, or claim outcome claims.

Part V has moved the paper from pre-loss reviewability to post-loss responsibility evidence. It has shown that agentic AI claims need bounded work-unit reconstruction, explicit evidence gaps, careful coverage-boundary questions, remediation closure, and a claims-to-renewal learning loop. The next part can turn the body into the paper's concluding analytical models and final architecture, while preserving the same boundary discipline: models can organize risk reasoning, but they cannot create coverage.

Part VI: Final Analytical Models and Insurability Architecture

The paper has now moved through the full arc of the insurability problem.

Part I established that the insurance market is not answering AI risk with a single yes or no. It is dividing risk across affirmative products, exclusions and endorsements, limits and sublimits, silent exposures, cyber-linked events, model-performance warranties, professional liability ambiguity, governance exposure, aggregation concern, and claim reconstruction needs. Part II separated the insured legal subject from the loss-relevant agentic work object. Part III translated lifecycle governance and auditability into insurability reasoning without treating either as insurance proof. Part IV organized underwriting-facing reviewability. Part V organized post-loss responsibility evidence.

Part VI now names the final analytical architecture.

The goal is not to invent a standard. It is not to create a score. It is not to declare that an agentic AI system is insurable, coverage-ready, underwriting-ready, claim-ready, certified, accepted by insurers, or approved by regulators. The goal is narrower and more useful: to give readers a disciplined way to discuss the object of risk, the evidence around that object, the maturity of reviewability, the boundaries of non-claim language, and the final conclusion of the paper.

The final synthesis is deliberately conservative. Agentic AI risk becomes more serious for insurance-facing discussion when the work can be bounded, evidenced, reconstructed, and updated. That is still not coverage. It is the precondition for a better conversation about risk transfer.

Chapter 24: Agentic Insurability Object Model

The central object of this paper is not "AI" in the abstract.

It is not the model alone. It is not the prompt. It is not a cyber event label. It is not a log bundle. It is not a governance policy. It is not an audit file. It is not a claim file. It is the loss-relevant agentic work object: the bounded work through which a legal subject, human role, agent role, tool action, evidence chain, dependency context, accepted outcome, exception, remediation state, and renewal feedback become intelligible.

The Agentic Insurability Object Model is an authored analytical model for describing that object. It does not replace policy wording. It does not create an underwriting checklist. It does not certify a system. It does not determine whether any loss is covered. Its purpose is to keep the insurance conversation from collapsing into a vague sentence such as "we use AI" or "the AI failed."

The first layer is the insured legal subject. Insurance begins with a policyholder, insured organization, officer, professional, vendor, additional insured, or other legal subject named or treated under policy language. The agent is usually not that subject. The agent is part of the risk object through which the subject's operations, decisions, services, duties, or dependencies create loss-relevant facts.

The second layer is the loss-relevant agentic work object. This is the bounded unit of work that can be described with scope, owner, business function, permitted actions, affected parties, data classes, dependencies, and lifecycle state. A customer refund workflow, code deployment assistant, claims triage process, professional deliverable workflow, customer notice agent, payment exception workflow, or account-update agent can be a candidate object for analysis. A brand name for a model or platform is too broad.

The third layer is authority boundary. The object has to show what the agent was allowed to recommend, draft, decide, send, transact, update, delete, deploy, escalate, or remediate. Authority does not prove legal authority. It establishes the operational boundary within which the loss-relevant work acted.

The fourth layer is responsibility continuity. Agentic work often moves across humans, agents, tools, vendors, processors, and projects. A handoff is not risk transfer unless the responsibility and evidence trail survives the handoff. Responsibility continuity asks who initiated, configured, approved, executed, accepted, remediated, reauthorized, or retired the work object.

The fifth layer is tool-action consequence. A model output becomes insurance-relevant when it crosses into consequence: payment sent, record changed, email published, code deployed, account locked, data exported, filing submitted, vendor ticket created, cloud resource consumed, or advice delivered. Tool action is where "AI said" becomes "the organization did."

The sixth layer is evidence chain. Logs and traces matter, but they are not enough. The evidence chain must join intent, authority, role, tool action, human review, accepted outcome, exception, remediation, dependency, privacy treatment, and gaps. The auditability and assurance white paper's evidence vocabulary helps organize this chain, while incident response sources support the need for structured records. Neither determines coverage or claim outcome. [57] [60]

The seventh layer is privacy and selective disclosure profile. Evidence that cannot be shared safely may become unusable. Evidence hoarded without data minimization can create new exposure. The object therefore needs source pointers, redaction profiles, access controls, retention notes, privilege flags, and data-class labels. the compliance and auditability white papers provide analytical vocabulary for evidence partitioning and selective disclosure; they do not provide legal advice. [57]

The eighth layer is dependency and substitution context. The object may depend on a model, runtime, cloud region, API, identity provider, tool connector, evidence repository, processor, vendor, or reusable agent component. If one of these changes, the reviewed object may no longer match the operating object. Dependency visibility also matters to aggregation and reinsurance-facing concern, though it does not create a capital model or pricing method. [61]

The ninth layer is accepted outcome. A workflow that has no accepted state remains difficult to review. Did the work close, escalate, fail, require exception, or remain open? Accepted outcome is not legal acceptance. It is an operational lifecycle state.

The tenth layer is exception, dispute, and remediation state. A serious incident should not end as a ticket note. The object needs exception history, dispute posture, remediation evidence, reauthorization or retirement, residual-risk note, and missing-evidence register.

The final layer is renewal and change feedback. Agentic risk changes. The object should carry what has changed: new tools, new authority, changed model/vendor/runtime, changed data classes, changed human review, incidents, near misses, remediation, unresolved gaps, and dependency concentration. The feedback loop makes the object current enough for future review.

This model differs from model governance because it is not centered on a model asset. It differs from cyber event logging because it is not centered only on access, credential, network, or resource-use traces. It differs from raw traces because it gives those traces responsibility semantics. It differs from an audit evidence chain because it is oriented toward insurability reasoning, not audit sufficiency. It differs from an underwriting checklist because it is not a required submission model. It differs from a claim file because it does not decide notice, coverage, causation, damages, settlement, or claim payment.

T-24-01 - Agentic Insurability Object Model

The model improves risk reasoning because it forces the reader to ask what object is being reviewed. It does not create coverage. It does not create insurability. It does not determine liability. It does not prove insurer acceptance. It gives the conversation a subject, object, evidence boundary, and update path.

This chapter's boundary: the Agentic Insurability Object Model is not legal advice, not insurance advice, not underwriting guidance, not coverage opinion, not claim approval guidance, not legal liability determination, not certification, not proof of insurability, not insurer endorsement, not regulator-approved method, not actuarial pricing guidance, not premium recommendation, not a score, not a public standard, and not readiness certification.

The next chapter turns from the object model to a non-scoring reasoning model. Once the object can be described, the next question is how reviewable it is without pretending reviewability is an insurance outcome.

Chapter 25: Agentic Insurability Reasoning Model

The word "readiness" is dangerous if it sounds like an outcome.

An enterprise can be more ready for a risk discussion without being coverage-ready. It can produce better evidence without being underwriting-ready. It can reconstruct an incident without being claim-ready. It can have stronger governance without being certified. It can move from vague AI use to bounded agentic work without proving insurability.

For that reason, this chapter uses a non-scoring Agentic Insurability Reasoning Model. It is an authored analytical model for discussing reviewability. It is not a benchmark, rating model, certification, underwriting rule, insurer-adopted method, score, grade, pass/fail test, market-acceptance label, or policy condition.

The model describes six reasoning states.

The first state is opaque and not reconstructable. The enterprise can say it used an AI system, but it cannot identify the bounded work unit, authority, tool action, evidence chain, accepted outcome, dependency path, privacy treatment, exception history, remediation closure, or owner. This state is not a declaration that the risk is uninsurable. It is a statement that the risk is too vague to review seriously.

The second state is log-visible but responsibility-poor. The enterprise has prompts, outputs, traces, API calls, or system logs. It can show activity, but not responsibility semantics. It cannot show what the agent was allowed to do, what the human saw, which role accepted the outcome, who owned the consequence, or how remediation closed. This state often creates false comfort: there is data, but not enough meaning.

The third state is evidence-linked but boundary-incomplete. The enterprise can connect some records across the work unit. It can show intent, action, and consequence in part. But authority boundaries, privacy controls, human-role clarity, accepted outcome, vendor-held evidence, substitution records, or remediation closure remain incomplete. The object is emerging, but the review still has material gaps.

The fourth state is reviewable work-unit architecture. The enterprise can describe bounded work units with authority, role, tool action, evidence, privacy, dependency, accepted outcome, exception, remediation, and missing-evidence fields. The review can now move from "AI system" to a concrete risk object. This still does not mean an insurer will accept, quote, bind, renew, cover, or pay a claim.

The fifth state is underwriting-facing evidence architecture. The enterprise can organize pre-bind, runtime, post-incident, renewal, dependency, privacy, and change evidence so that a broker, risk engineer, enterprise risk team, counsel, or underwriter can ask better questions. It remains optional and analytical. It is not an underwriting standard or mandatory request.

The sixth state is post-loss reconstructable and renewal-updatable. The enterprise can reconstruct incidents by bounded work unit, identify gaps, frame coverage-boundary questions without answering them, evidence remediation closure, and feed lessons into renewal/change review. This is the strongest reviewability state in the model, but it still does not decide coverage, liability, premium, renewal, or claim outcome.

The stages are intentionally non-numeric. A number would imply precision the sources do not support. A score would invite false use as a checklist, rating factor, certification threshold, or market signal. The model instead asks a sequence of questions: can the object be named, can authority be bounded, can responsibility survive handoff, can action be tied to consequence, can evidence be reconstructed, can privacy be preserved, can dependencies be seen, can remediation close, and can change feed the next review?

The compliance and auditability white papers provide analytical foundations for this reasoning. The compliance white paper helps describe lifecycle governance objects, authority, evidence partitioning, accepted outcome, substitution, and remediation closure. The auditability and assurance white paper helps distinguish raw traces from evidence chains and auditability from sufficiency. Neither converts a reasoning state into insurance proof. [57]

External market and governance sources explain why this matters. Public insurance sources show a split market; governance and incident sources show the need for documentation, controls, and reconstruction; aggregation sources show why dependency visibility matters. They do not endorse this model or turn it into a market standard. [58] [59] [60] [61]

T-25-01 - Non-Scoring Insurability Reasoning Model

A higher state means better reviewability, not guaranteed insurability. It means the enterprise can answer better questions and expose gaps more honestly. It does not mean the risk is acceptable, priced, covered, certified, or approved.

This chapter's boundary: the Agentic Insurability Reasoning Model is not legal advice, not insurance advice, not underwriting guidance, not coverage opinion, not claim approval guidance, not legal liability determination, not certification, not proof of insurability, not insurer endorsement, not regulator-approved method, not actuarial pricing guidance, not premium recommendation, not a score, not a standard, not readiness certification, and not an insurer-adopted method.

The next chapter translates the final architecture back to the paper's readers. Each audience can use the model differently, but none should mistake it for advice, policy interpretation, or obligation.

Chapter 26: What Enterprises, Brokers, Insurers, Reinsurers, and Counsel Should Take Away

The paper's final models are useful only if different readers know what to do with them without overclaiming them.

For enterprises, the takeaway is not "buy AI insurance" or "prove insurability." It is more practical: stop describing exposure only as AI adoption. Inventory bounded agentic work units. Name who owns them. Record authority boundaries. Capture tool-action consequences. Preserve evidence chains. Keep privacy and selective disclosure profiles. Map dependencies. Record substitutions. Close remediation. Carry incidents into renewal/change review.

For brokers and risk engineers, the takeaway is translation. A client may arrive with a slide that says "we use copilots," "we have an agent platform," or "we implemented AI governance." The useful move is to translate that into risk-object questions: which work units act, what authority they carry, what consequences they can produce, what evidence exists, what data is touched, what dependencies concentrate exposure, and what cannot be reconstructed.

For insurers, the takeaway is legibility. This paper does not tell insurers how to underwrite agentic AI. It does not define appetite. It does not recommend forms, exclusions, endorsements, sublimits, pricing, or claim handling. It says that agentic risk becomes more legible when the insured subject, work object, authority, role, tool action, evidence chain, dependency, privacy, accepted outcome, exception, remediation, and change feedback are separated. Policy language, appetite, portfolio judgment, and claim handling remain external.

For reinsurers, the takeaway is dependency visibility. Agentic AI can reuse the same model, cloud provider, runtime, API, identity path, data processor, evidence repository, or agent component across many business units or insureds. Aggregation concern is not only single-incident severity. It is the possibility that shared dependencies create correlated event shapes. Dependency visibility improves the conversation; it does not produce a capital model. [61]

For counsel, privacy, and governance teams, the takeaway is separation. Evidence reviewability is not legal conclusion. Governance is not liability proof. Selective disclosure is not legal advice. Retention is not automatically good if it hoards sensitive traces. Redaction is not automatically good if it destroys source pointers. The task is to preserve useful evidence while protecting legal, privacy, privilege, and confidentiality boundaries.

For boards, CROs, CIOs, CTOs, CCOs, and AI governance leaders, the takeaway is discipline. AI governance that cannot reconstruct lifecycle work is weak for insurance-facing review. A model inventory alone will not answer who acted, under what authority, through what tool, with what human role, producing what consequence, supported by what evidence, remediated by whom, and updated before the next review.

For claims and incident-response teams, the takeaway is continuity. A technical timeline, incident ticket, vendor notice, security alert, or model trace may be necessary. None is sufficient alone. Claim reconstruction needs the bounded work unit and its responsibility semantics. Incident response sources support the importance of structured response, recovery, remediation, and tracking, but they do not decide insurance outcomes. [60]

For implementation leaders, the takeaway is architecture. If agentic work is designed without authority boundaries, evidence pointers, privacy profiles, dependency records, accepted outcome states, exception paths, remediation closure, and change registers, the insurance-facing review problem is already being built into the system.

T-26-01 - Audience Takeaway Matrix

These takeaways are not obligations. They are not legal requirements, insurance requirements, procurement requirements, regulator-approved requirements, or insurer requirements. They are practical implications of the paper's argument: if the work object cannot be bounded and evidenced, the risk conversation remains vague.

This chapter's boundary: the audience takeaways are not legal advice, not insurance advice, not underwriting guidance, not coverage opinion, not claim approval guidance, not legal liability determination, not certification, not proof of insurability, not insurer endorsement, not regulator-approved method, not actuarial pricing guidance, not premium recommendation, not a score, not a standard, and not readiness certification.

The next chapter gathers the paper's remaining caveats. The point is not to weaken the argument. The point is to protect it from becoming something the sources do not support.

Chapter 27: Residual Caveats and Non-Claim Discipline

Boundary discipline makes the paper stronger.

The temptation in a new risk field is to overstate the model. A vocabulary becomes a checklist. A checklist becomes a standard. A standard becomes a certification. A certification becomes an underwriting shortcut. A shortcut becomes a coverage promise. That sequence is exactly what this paper refuses.

AIIRWP v1.0 is a whitepaper for analytical synthesis. It is not a legal opinion. It is not insurance advice. It is not underwriting guidance. It is not actuarial pricing guidance. It is not a claim handling manual. It is not a coverage opinion. It is not a certification scheme. It is not a proof of insurability. It is not an insurer endorsement. It is not a regulator-approved method. It is not a procurement recommendation. It is not a vendor ranking. It is not a public standard.

The market sources should be read as context. Verisk, QBE, Munich Re, Armilla, Chaucer, Aon, Geneva Association, Swiss Re, Beazley, NIST, CISA, SEC, NAIC, and other sources support particular claims in particular ways. They do not collectively prove that agentic AI lifecycle risk is accepted by the insurance market. They show a split market, narrower products, cyber-linked channels, model-performance structures, governance and documentation expectations, incident response discipline, and aggregation concerns. [58] [59] [60] [61]

Cyber, cloud, and reinsurance sources are sometimes analogies. They are strong analogies where agentic AI depends on shared cloud, APIs, identity systems, models, vendors, processors, evidence repositories, and automated resource use. They are still analogies unless directly tied to AI or to a specific insurance product source. The paper should preserve that distinction in full-body assembly.

Policy language remains external. Exact policy wording, exclusions, endorsements, sublimits, deductibles, notice conditions, defense/control provisions, covered loss definitions, and claim forms require primary-source review. Public product pages and broker reports can support market context, not policy interpretation.

Exclusion and sublimit signals remain caveated where primary filings or policy wording are not available. the source research already records source gaps for AIG, WR Berkley, Great American, Beazley/QBE sublimit details, and exact Verisk form text. Later publication-stage work should recheck those sources before using precise language. [62]

Insurer claim documentation and AI underwriting questionnaire sources remain useful possible strengthening sources if later found. Their absence does not block the body draft, but it should keep the paper modest about claims handling and underwriting evidence. The paper can say what evidence would make a risk more reviewable. It should not say what any insurer will require, accept, price, bind, renew, or pay.

The compliance and auditability white papers are analytical foundations, not external insurance facts. The compliance white paper helps describe lifecycle governance objects. The auditability and assurance white paper helps describe audit evidence chains. This paper uses both to build insurability reasoning. It does not say the compliance white paper or the auditability and assurance white paper makes a system insurable, coverage-ready, underwriting-ready, claim-ready, certified, insurer accepted, or legally sufficient. [57]

The model names also require discipline. Agentic Insurability Object Model and Agentic Insurability Reasoning Model are authored analytical constructs. They can organize questions. They cannot score, certify, approve, validate, bind, insure, price, settle, or rank.

T-27-01 - Final Non-Claim Boundary Register

This register is not defensive padding. It is the condition for credible synthesis. The paper asks insurance readers to take agentic AI risk seriously. That requires not pretending that evidence is insurance, governance is coverage, auditability is insurability, or a model name is a market outcome.

This chapter's boundary: residual caveats and non-claim discipline are not legal advice, not insurance advice, not underwriting guidance, not coverage opinion, not claim approval guidance, not legal liability determination, not certification, not proof of insurability, not insurer endorsement, not regulator-approved method, not actuarial pricing guidance, not premium recommendation, not a score, not a standard, and not readiness certification.

The final chapter returns to the thesis. Agentic AI risk is not a single market verdict. It is an object problem, an evidence problem, and a responsibility problem.

Chapter 28: Conclusion: From AI Risk Noise to Agentic Risk Objects

"Is AI insurable?" is the wrong opening question.

Asked in the abstract, it produces noise. One reader thinks about hallucinated professional advice. Another thinks about stolen LLM credentials. Another thinks about model-performance warranty. Another thinks about a customer refund agent. Another thinks about board oversight. Another thinks about cloud concentration. Another thinks about a policy exclusion. Another thinks about a claim file with missing logs. All of them are talking about AI risk. They are not talking about the same risk object.

The better question is: what exactly is being transferred, by whom, through what object, under what authority, with what evidence, across what boundary, and after what event?

This paper's answer is that AI risk is not insurable or uninsurable in the abstract. It becomes more reviewable when the loss-relevant agentic work object can be bounded, evidenced, reconstructed, and updated. The insured legal subject remains the person or organization under policy language. The agentic risk object is the work through which loss-relevant action, consequence, evidence, and responsibility become visible.

Part I showed why the market forces this question. Public sources do not show a single AI insurance answer. They show affirmative AI products, model-performance warranties, AI-linked cyber coverages, exclusion and endorsement development, sublimit and cap signals, silent exposures across existing lines, governance and disclosure context, claim reconstruction needs, and aggregation concern. That split means the paper cannot begin with "AI covered" or "AI excluded." It has to begin with object, evidence, boundary, and line.

Part II defined the insurable agentic risk object. The policyholder remains the legal insured subject. The work object is the loss-relevant lifecycle unit that can carry authority, role, tool action, evidence, accepted outcome, exception, remediation, and closure. Human-in-the-loop alone is not a responsibility structure. A tool action matters because it turns output into consequence. Hard-to-insure patterns emerge when authority, responsibility, evidence, privacy, substitution, or closure cannot be reconstructed.

Part III translated compliance and auditability concepts into risk-transfer analysis without letting them dominate it. The compliance white paper contributes lifecycle governance vocabulary. The auditability and assurance white paper contributes auditability and evidence-chain vocabulary. Auditability is necessary for reconstruction but not sufficient for insurability. Compliance is not auditability. Auditability is not coverage. Evidence chains are not claim approval.

Part IV built the underwriting-facing architecture: work-unit inventory, exposure segmentation, non-pricing variables, renewal/change/substitution evidence, and optional reviewer-facing evidence requests. It did not turn those requests into a standard, turn variables into pricing guidance, or claim that any insurer will accept or reward the architecture.

Part V moved to the post-loss side. Incident notice is not reconstruction. Coverage-boundary analysis is not coverage opinion. Dispute mapping is not liability determination. Remediation closure is not settlement. Claims-to-renewal feedback is not premium guidance. Post-loss evidence matters because agentic AI incidents can leave fragments unless responsibility, evidence, and lifecycle state are joined.

Part VI names the final analytical architecture. The Agentic Insurability Object Model describes what the risk object must contain. The Agentic Insurability Reasoning Model describes reviewability states without scoring them. The audience matrix translates the argument into practical questions. The boundary register keeps the paper from becoming advice, standard, certification, or market claim.

The final rule is simple:

Reviewability is not coverage.

Evidence is not insurance.

Governance is not claim approval.

Auditability is not insurability.

Without bounded lifecycle evidence, agentic AI risk remains too vague to discuss seriously.

That is the contribution of the paper. It does not promise that agentic AI risk can always be transferred. It does not declare that agentic AI risk cannot be transferred. It says the serious conversation begins only when the insured legal subject and the agentic risk object are separated, the object is bounded, authority is visible, responsibility survives handoff, tool action is tied to consequence, evidence is reconstructable, privacy is preserved, dependencies are mapped, remediation closes, and change feeds future review.

This public research edition exposes bounded public HTML, PDF, manifest, and checksum artifacts. It does not create certification, external approval, DOCX distribution, or source Markdown publication.

This conclusion does not claim certification, external approval, insurer acceptance, coverage-ready status, underwriting-ready status, claim-ready status, certification, endorsement, legal proof, insurance advice, legal advice, coverage opinion, underwriting standard, actuarial pricing guidance, premium recommendation, claims approval guidance, external adoption, indexing, SEO-GEO outcome, answer-engine recognition, or future implementation.

Appendices

Integrated Appendix Status: Appendix A-H are included as reference material after Chapter 28. They do not revise the body, do not create standards, checklists, certifications, insurer-adopted methods, coverage opinions, claim guidance, pricing guidance, or external approval status.