AI Cyber Insurance: Build the Evidence File Before Renewal

An AI cyber insurance submission is useful when an underwriter can trace a production request through a named control. The record should identify the caller and the model route. It should also identify the data classification and policy version, plus the permit, redact, or block result. A screenshot of a green dashboard leaves those questions unanswered.

I would reject an AI insurance evidence pack built around product names. Put one denied request and its policy record on a desk, with the related incident ticket beside them. That small stack says more about the control than 40 slides of architecture logos.

TL;DR

• AI cyber insurance evidence should connect routed LLM activity to identity and route authorization. It should also record data classification, policy version, and enforcement outcome.
• Underwriting needs a declared control scope. Renewal needs evidence that the controls operated during the policy period. Claims need a reconstructable event timeline.
• DeepInspect can produce evidence for authenticated application or agent traffic deliberately routed to LLM endpoints through its HTTP proxy.
• Endpoint compromise and stolen credentials require separate controls and evidence owners, as do model training, local execution, and direct provider bypass.

AI cyber insurance starts with a control boundary

The phrase AI cyber insurance can cover several different exposures. A carrier may examine an organization's use of models and its AI products. It may also examine incidents caused by automated systems or failures in the infrastructure around those systems. The Coalition cyber insurance page presents cyber and AI insurance alongside active risk management and incident-response services. That combination makes the evidence question practical: which risks were declared and which controls operated? What happened during an event?

Start with a route inventory rather than a vendor inventory. Record every production path where an authenticated application or agent sends an HTTP request to an LLM endpoint. Name the calling service and identity source. Record the model provider and destination route, then add the data classes and policy owner. Identify where reviewers can retrieve the supporting evidence. Mark direct provider calls and hosted SaaS assistants separately because those paths may bypass the organization's gateway.

This route-level view is narrower than an enterprise AI governance program. That narrower scope gives each insurance control question a precise answer. Broad governance claims rarely provide the same proof.

The underwriting evidence file

Underwriting happens before a covered event. The evidence file should show the current architecture and the controls the organization says are operating. Treat each statement as something a reviewer may ask you to prove later.

Route inventory and ownership

List the production LLM routes that the organization controls. Each row should include the application or agent and the business owner. Add the technical owner and provider endpoint. Record the approved model and identity source, along with the data classes allowed on the route. Add the date of the last review and the person who approved the route.

A separate field should identify bypass exposure. Direct SDK calls and personal API keys follow different control paths, as do browser-based assistants and AI tools managed by vendors. The inventory should say who monitors or accepts each gap. A blank cell is more honest than a claim that every AI interaction passes through one gateway.

Identity and authorization evidence

For each governed route, preserve how the caller's identity reaches the enforcement point. Record the trusted issuer and audience. Add the subject and role or group mapping. State the condition that causes a request to fail closed. Shared service credentials need an explicit statement of what they identify. They identify the service unless the application supplies a verified user or agent identity.

The test pack should contain an approved caller and a caller with the wrong role. Add an expired credential and a token with the wrong audience. Include a request with missing identity context. Keep the expected and actual decisions. This turns an architectural assertion into evidence that an underwriter can inspect.

Data and route policy evidence

Name the data classes evaluated at the request boundary. Record which classes may reach each model route and the permitted action for each class. The action may be permit, redact, block, or escalate. Include the policy version and effective date.

Run versioned fixtures against those rules. Include allowed and prohibited examples. Then add an ambiguous case and a request targeting an unauthorized model. Preserve the classification and policy decision. Record the enforcement action and timestamp. Link failures to the remediation ticket and retest result.

An AI risk assessment template can hold the wider risk decision. The insurance control file should point to it without copying the entire assessment into every route record.

Renewal requires operating evidence

Renewal asks a different question. The architecture diagram may be unchanged, but the organization needs to show that the represented controls operated during the policy period.

Define the sampling method before selecting evidence. Select events across business units and roles. Include different data classes and routes, plus providers and policy versions. Preserve permit decisions as well as blocks. A control that records only denied requests cannot show the population it governed. Include exceptions and fail-open events. Add unavailable classifiers and direct-route discoveries.

The renewal pack should show policy changes during the period. Record who requested each change and who approved it. State when it became effective and which routes it affected. Preserve the fixtures and results used to test it. An overwritten policy document loses the history needed to explain an old event.

Keep an exception register with an owner and expiry date. The register should state the exact route and caller population, plus the data class and compensating control. I prefer an expired exception that triggered a visible escalation over a permanent exception hidden in configuration. The first creates an operational problem. The second creates an evidence problem during a claim.

Claims evidence reconstructs one event

A useful claim file is chronological. Start with the first relevant identity event and follow the request through classification and policy evaluation. Continue through model routing, response handling, and downstream action. Preserve timestamps with enough precision to align systems.

For the routed LLM leg, capture:

• The authenticated caller or agent identity supplied to the gateway
• The application and route, plus the provider and model destination
• The request and response evidence allowed by the organization's retention policy
• The data classification and rule that matched
• The policy identifier and version in force at that moment
• The permit, redact, block, or escalation result
• The integrity record and location of the retained evidence
• The related alert and incident, plus the exception and change records

A claim investigation also needs evidence from other systems. Identity providers show token issuance and account state. Endpoint tools show device activity. Cloud logs record the resources accessed during the event. Application records show the business action taken after the model response. The LLM audit-log retention guide covers the request-record lifecycle, but retention alone never proves that every route was covered.

NIST AI RMF organizes the evidence questions

The NIST AI Risk Management Framework provides a voluntary structure for managing AI risk. Its GOVERN and MAP functions organize ownership and context. MEASURE and MANAGE organize testing and treatment evidence. Together, they give an insurance team a useful index without turning the framework into a coverage promise.

GOVERN identifies accountable owners and policies, along with risk appetite and review authority. MAP records the system context and intended use, plus affected parties, dependencies, and exposure. MEASURE contains test methods and results, along with limitations and monitoring evidence. MANAGE records treatment decisions and exceptions, plus incident actions and residual-risk acceptance.

Map each evidence artifact to one function and one owner. The route inventory may support MAP. Token and policy tests support MEASURE. Exception approvals and incident decisions support MANAGE. Governance charters and accountability records support GOVERN. The same artifact can support more than one question, but its owner and purpose should remain clear.

NIST also prevents a common scope mistake. Runtime gateway records support selected operational risks. Model evaluation and training data need evidence from their own systems and teams, as do human oversight, vendor management, and business impacts.

Control allocation for routed LLM traffic

DeepInspect's boundary is authenticated HTTP traffic between an application or agent and an LLM endpoint when the organization deliberately routes that traffic through the proxy. Inside that boundary, a policy decision can evaluate identity context and route. It can also evaluate the model destination and request or response content. It can create a per-decision record before permitted traffic continues.

Several important cyber insurance risks sit outside that path. Endpoint malware and credential theft require other controls, as do local model execution and CI/CD compromise. Training-data poisoning and provider outages also sit outside the path. Employee use of hosted assistants requires separate controls. Tool calls made after a model response also need application and tool authorization. A gateway record can show what happened on the governed model route. It cannot prove that an unrelated endpoint or tool was controlled, or that a direct provider path was controlled.

Write this allocation into the evidence pack. A narrow, testable statement survives underwriting and claims review better than a broad promise that the organization controls AI.

DeepInspect

DeepInspect produces evidence for the request-boundary slice of an AI cyber insurance file. When an application deliberately routes authenticated HTTP LLM traffic through the proxy and supplies trusted identity context, DeepInspect can evaluate the caller and role. It can also evaluate the route and model destination, plus the data classification and active policy before forwarding permitted traffic.

Each decision can retain the policy version and classification. It can also retain the permit or redact or block result, timestamp, and route evidence. Those records support underwriting control tests and renewal samples, plus claims chronology for the traffic that crossed the governed route. The evidence file should still name the owners for endpoints and credentials. It should also name the owners for direct provider access and local execution, plus the model lifecycle and downstream tools.

Book a technical deep dive at deepinspect.ai.