AI Insurability Begins with Assessable Exposure

An AI system that can authorize a payment creates an exposure that a model evaluation alone cannot describe. Who could receive the money? What limited the amount? What happens if the payment succeeds but the agent retries? An enterprise seeking insurance needs to explain the business activity, the possible loss and the controls governing consequential actions. The architectural question is whether it can connect authority, execution and confirmed outcomes well enough for that exposure to be assessed.

Start with the exposure

RAND’s The Insurability of Artificial Intelligence, by Sasha Romanosky and Celine Robinson, describes a fragmented insurance response. AI-related harms can implicate multiple lines, while carriers respond through affirmative coverage, exclusions or silence. The relevant question therefore concerns a particular deployment and loss pathway, rather than AI as a single undifferentiated risk. [1]

Beazley’s September 2026 announcement makes the distinction concrete: it confirms affirmative AI cover in cyber and technology errors and omissions policies, with wording expressly addressing AI-related risks already covered within its existing cyber cover. The announcement clarifies coverage; the issued policy’s terms determine whether a particular loss is covered. [2]

The exposure also depends on the insured’s role. A frontier model developer’s training-data and copyright liabilities differ from an enterprise’s exposure when a deployed agent takes consequential action. Our architectural proposition focuses on that operational exposure: connecting authority, executed controls and confirmed outcomes so it can be assessed. That evidence does not, by itself, resolve upstream liabilities or establish insurance coverage.

For an architect, this suggests a concrete starting point. Describe the business activity, the people and assets affected, the actions the system can take, and the circumstances in which those actions could cause harm. Identify the enterprise and external systems that complete the workflow. Those details give insurance conversations an operational object to examine.

Make the deployment concrete

Consider an illustrative supplier-payment workflow. An agent assembles payment information, checks supporting records and submits a payment when the enterprise’s approval conditions are satisfied. The exposure depends on the recipient, amount, credentials, available tools, permitted exceptions and payment system’s behavior.

The model is one component. Anthropic’s Trustworthy agents in practice examines trustworthiness across the model, harness, tools and environment. OpenAI’s earlier Practices for Governing Agentic AI Systems identifies insurance for agent harms as one potential application of governance practices. These sources establish relevant framing; neither establishes insurance eligibility for our payment example. [3][4]

The proposed insurance infrastructure in Underwriting the Agent Economy similarly places records and controls within a wider assessment agenda. We use it as a proposal about what an insurance ecosystem could need, without treating its authors’ institutional affiliations as official vendor endorsement. [5]

Luminity’s recommendation is to define the bounded workflow before selecting the evidence to collect. A useful deployment description should identify where authority originates, where it is enforced, what crosses an external-system boundary, and who resolves uncertain outcomes. That description should remain intelligible when the enterprise changes models.

Examine controls where actions occur

OpenAI and Anthropic provide mechanisms that can contribute to this architecture. Their documented behavior also shows why a feature checklist cannot establish how a particular action was governed.

In the OpenAI Agents SDK, selected tool calls can pause for approval and resume after a decision. Approval may be scoped to an individual call or persist for subsequent calls within the run. The architectural question is therefore which decision applied to this invocation, with these parameters, under this configuration. [6]

The Claude Agent SDK documents an ordered permission process involving hooks, deny and ask rules, permission modes, allow rules and a runtime callback. Earlier resolution can mean that the callback is never invoked. An allow list can preapprove tools without establishing an exclusive inventory of available tools. [7]

Both examples make the same enterprise responsibility visible: choose the enforcement point and preserve the effective authority conditions. A statement that “human approval is enabled” leaves unanswered whether the consequential call required a fresh decision, inherited an earlier approval, or followed another permitted path. For exposure assessment, that distinction helps explain which actions could proceed without further human intervention.

Timing matters too. OpenAI documents that parallel input guardrails may complete after the agent has already executed tools; blocking input guardrails finish before agent execution begins. An output check evaluates a later stage. These are materially different positions in a loss pathway. [8]

Containment needs equally precise treatment. Claude’s sandbox documentation describes filesystem and network restrictions alongside exceptions and fallback settings. Inspecting Codex’s sandbox-selection source also shows the role of permission profiles and platform-specific enforcement. Neither example establishes that a permitted downstream business operation is appropriate merely because the process initiating it was contained. [9][10]

For our payment workflow, the enterprise must connect these technical controls to business authority: approved recipient, permitted amount, valid approval scope and stop conditions. Those details explain which payment errors the design aims to prevent and which loss pathways remain possible.

Connect execution evidence to the outcome

After an incident, the enterprise needs more than a statement that controls were configured. It needs evidence showing which configuration applied, which decisions were made, which checks executed, what was sent downstream, and what the external system recorded.

OpenAI’s tracing facilities capture supported execution events and allow customization of capture and export. The inspected default implementation also contains in-memory queue drops and export failures that can exhaust retries. A flush operation should therefore not be described as unconditional proof of durable delivery. [11][12]

Anthropic’s evaluation guidance makes another useful distinction: the transcript records the interaction, while the outcome concerns the resulting environment state. An agent saying a task succeeded is different from verifying the corresponding record in the external system. [13]

Luminity’s recommendation is to preserve durable Audit Trails that correlate policy and configuration versions, approval scope, control verdicts, action parameters and external transaction identifiers. Retention and integrity matter, as does detecting missing records. A technically rich trace becomes more useful when investigators can connect it to an authoritative transaction status.

That still leaves an analytical step. Confirming a transaction does not, by itself, establish downstream harm, economic loss or liability. Causal Agent Replay explores counterfactual attribution using synthetic causal settings and mocked tools. Its results do not justify treating recorded execution order as proof of cause in a real insurance claim. [14]

For an insurance investigation, the useful contribution is a reconstructable event: what was authorized, what executed and what changed externally. Establishing cause, loss and coverage requires further evidence and judgment.

Recovery must reach the external system

Return to the payment. The external system commits it, but the acknowledgment fails to reach the agent. The agent then resumes from an earlier checkpoint. Its local state reports an unknown outcome while the payment system retains a completed transaction.

The rollback study Safe to Resume? demonstrates continuity failures in studied agent workflows, including a constructed payment example. It supports taking this failure mechanism seriously. It does not establish a customer’s realized financial loss or demonstrate the same vulnerability in OpenAI or Anthropic products. [15]

Recovery features also have declared scope. Claude Code checkpointing, for example, tracks supported direct file edits while excluding changes made through Bash and other documented cases. That capability should not be translated into a claim that an external payment can be rewound. [16]

In our illustrative architecture, recovery begins by checking the authoritative payment record using the original business-operation identifier. If the payment is confirmed committed, reconcile the agent’s state and do not pay again. If it is confirmed not committed, revalidate authority before retrying, using the same idempotency key where supported. If the outcome remains uncertain, pause and escalate.

Duplicate suppression belongs at the integration or service boundary capable of enforcing it. Its behavior depends on service support, key scope and retention. If a completed payment must be reversed, that requires a separately authorized reversal or compensating transaction. It does not erase the original event.

The exposure question is therefore specific: can recovery create another financial obligation, and what prevents that from happening? Reconciliation and duplicate suppression make the answer inspectable.

Certification contributes scoped evidence

AIUC-1 brings testing and audit into the discussion. Its published process scopes the agent or system, deployment context and configuration boundaries; combines technical evaluations with independent review of controls; and includes quarterly retesting. Treating it as merely a static certificate would miss that process. [17]

For an enterprise adopting a certified system, the architectural task is to understand the assessed scope and relate it to the deployment actually operated. Which configuration was tested? Which interfaces were included? What changed after assessment? What runtime evidence remains available between assessment activities?

These questions position certification and operational assurance as complementary evidence. An assessment can substantiate claims within its scope. Audit Trails can support examination of particular executions. The insurance contract determines a separate set of obligations and coverage conditions.

Our recommendation is to preserve the connection among the assessed system, the deployed version and material operational changes. A certificate should be accompanied by enough scope information to make that connection meaningful.

The boundaries of the insurability claim

The bridge from technical evidence to insurance economics remains incomplete. The Insurability Frontier of AI Risk analyzes carrier positioning materials; that is different evidence from executed policy interpretations or paid claims. Trace-Economic Underwriting studies economic labels constructed around agent traces. Its control-effect assumption must not be presented as observed insurance loss reduction. [18][19]

RAND also highlights immature loss data and accumulation through shared dependencies. Strong controls in one deployment cannot establish how a common model, infrastructure failure or wider shock affects an insurer’s portfolio. [1]

Architects can make deployment exposure and its evidence more coherent. Insurers still need to assess frequency, severity, aggregation and contractual terms. The reviewed evidence does not establish that this architecture changes eligibility, coverage or premiums, or that an insurer will accept a particular record as sufficient.