What Brokers Should Request Before Referring AI Assessments

Before referring an AI company for an independent vulnerability assessment, insurance brokers should establish five things: which AI application needs assessment, what insurance question prompted the referral, which capabilities or failure scenarios are relevant, what technical access is available, and what evidence the intended reviewer needs.

An AI company approaching a broker for coverage or renewal may already have cybersecurity documentation, model safety reports and internal AI governance policies. These materials can help explain how the company manages risk, but they may not demonstrate how its deployed AI application behaves when its operating restrictions are challenged.

For specialist AI liability, cyber and technology errors and omissions (E&O) brokers, an independent AI vulnerability assessment can help address specific technical questions. A well-prepared referral gives the assessor enough context to propose a relevant scope and helps the client avoid commissioning a report that does not address the intended insurer's concerns.

1. Identify the AI Application and Its Actual Capabilities

The first step is understanding what the client is deploying and how the application interacts with its operating environment.

A company might describe its product as an AI customer-service assistant. That description alone reveals little about its capabilities. The assistant might only answer questions from approved documentation, or it might retrieve customer records, recommend account changes and interact with external systems.

Those differences matter because the potential consequences of an application failure depend partly on what the system can access, influence or execute.

Brokers should ask clients to identify:

• Application and deployment: The AI product, its intended users and whether it is in development, testing or production.

• Capabilities: The tasks it performs and the decisions or actions it can influence.

• Technical configuration: The underlying model, connected data sources and relevant application settings.

• Integrations: External tools, APIs and systems the application can access.

• Operating restrictions: Controls governing sensitive information, restricted actions and human approval.

• Material changes: New capabilities or integrations that could affect the application's exposure.

This application-level understanding is relevant to how insurers approach AI risk.

In its AI insurance offering, aiSure, Munich Re identifies exposures including model underperformance, hallucinations, misleading information, privacy infringement and intellectual property violations. Its published assessment approach also considers AI development processes, performance and potential failure scenarios.

These are examples of how one insurer approaches AI-related exposures, not a universal checklist for insurance submissions.

For brokers, the practical objective is to establish what the application actually does and connect the assessor with a technical owner who understands its architecture, permissions and operating requirements.

2. Establish Why the Assessment Is Needed for Insurance

An AI vulnerability assessment referral should begin with a specific insurance event or unresolved question.

The client may be preparing its first AI liability submission, approaching renewal, responding to an underwriter's request or seeking clarity about a potential exclusion. A recent incident or material change in the application may also prompt additional scrutiny.

Insurance products are evolving to address these exposures more explicitly.

In June 2026, CFC announced affirmative AI coverage updates across seven insurance products, including technology E&O, professional liability and other specialist lines. CFC described the changes as a way to provide greater clarity about how AI-related exposures are treated within its policies.

The development illustrates why brokers need to understand both the client's AI activities and the specific coverage being discussed. It does not mean that CFC or other insurers universally require independent AI vulnerability assessments.

Where possible, brokers should confirm the intended insurer's evidence requirements before commissioning an assessment. This helps ensure that the resulting work addresses the recipient's question rather than producing a technically detailed report with limited relevance to the insurance discussion.

Consider two hypothetical situations.

Scenario A: An AI Company Preparing for Insurance Renewal

A company operates a customer-facing AI assistant that generates product recommendations and explains contractual terms.

The application has gained new capabilities since its previous renewal, and the broker wants to understand whether it could produce unauthorized commitments or materially misleading statements.

The broker can communicate this concern to the assessor, who can determine whether and how the relevant application behavior can be evaluated.

The resulting findings may help the company explain how its application responds to requests that conflict with approved product information, contractual restrictions or escalation rules.

Scenario B: An AI Company Responding to an Underwriting Question

A company operates an AI assistant that retrieves internal business documents.

During an insurance submission, an insurer requests additional information about the possibility of unauthorized information disclosure.

The broker can clarify the insurer's question and establish whether the client has existing technical evidence addressing it.

If further assessment is needed, an assessor could examine whether manipulated inputs or retrieved documents cause the application to disclose information outside the requesting user's permitted access.

In both scenarios, the broker identifies the insurance context and communicates the evidence requirement. The technical assessor determines the appropriate testing approach, while the client provides access and application-specific information.

3. Clarify What the Assessment Needs to Establish

A broker does not need to design adversarial tests or determine the technical methodology. However, the referral should explain the application capabilities and potential consequences that prompted the assessment.

The Lloyd's Market Association's research on AI loss scenarios provides useful insurance-market context. Its survey of market participants, conducted in mid-2025, examined potential AI-related losses across several insurance classes, including professional indemnity, cyber, product recall and accident and health.

One scenario concerned erroneous AI-generated professional advice or services causing a loss. Another examined business interruption resulting from AI malfunction.

These are illustrative loss scenarios considered by insurance-market participants, not documented claims or evidence that a particular AI application is vulnerable.

For brokers, the implication is that assessment priorities should reflect the client's activities and the consequences that matter to the insurance discussion.

For example, a broker referring a customer-service AI company might identify concerns about unauthorized information disclosure, misleading contractual statements or actions performed without required approval.

A useful referral should help answer three questions:

• What could go wrong? Identify the application behavior or operating restriction relevant to the insurance discussion.

• Why does it matter? Explain the potential customer, operational or business consequence.

• What needs to be demonstrated? Clarify whether the intended reviewer needs evidence of application behavior, control responses, remediation or retesting.

The assessor can translate those concerns into defined failure scenarios, expected behaviors and observable assessment outcomes.

Testing may also need to consider legitimate application behavior. A control that prevents an inappropriate response but unnecessarily blocks routine customer requests can introduce a separate operational concern.

The technical assessor should establish the methodology, evaluation criteria and feasible scope in consultation with the client.

4. Confirm Technical Access and Assessor Independence

A well-defined assessment can still produce limited findings if the assessor cannot access the relevant application components.

Before referring a client, brokers should establish whether the company can provide an appropriate testing environment, a technical contact and the permissions necessary to examine the agreed scenarios.

The assessor should then clarify which outcomes can be observed or verified.

For AI agents connected to operational systems, three outcomes are particularly important:

• Attempted action: The AI application requests or attempts an operation outside its permitted authority.

• Action blocked by controls: An authorization check, approval mechanism or another control prevents the attempted operation from completing.

• Verified completed action: Available execution evidence establishes that the operation occurred.

For example, an AI assistant might attempt to modify a customer record without authorization. If the backend rejects the request, the assessment has identified an inappropriate attempted action and a control that prevented execution under the tested conditions.

That is different from demonstrating that an unauthorized modification was completed.

Brokers should also clarify the assessor's relationship with the client. An assessor that helped develop the application or supplies its protective controls may still produce useful findings, but relevant relationships and potential conflicts should be disclosed.

Independent assessment can provide an additional perspective on application behavior. Its value, however, depends on the assessor's methodology, technical expertise, available access and clarity of reporting.

5. Agree What Evidence Can Be Shared and When

Before commissioning an assessment, brokers should establish what information the intended reviewer needs, who can receive the findings and when the evidence must be available.

A technical report may contain sensitive application details, internal configurations, test inputs or information about identified vulnerabilities. The client and assessor should agree on confidentiality restrictions and whether the broker or insurer will receive a summary, detailed report or selected supporting evidence.

Depending on the assessment scope, useful deliverables may include:

• Assessment scope: The application, configuration, environment and failure scenarios evaluated.

• Methodology: The testing conditions, evaluation criteria and relevant test counts.

• Observed findings: What the application attempted, how controls responded and which consequences were verified.

• Severity and relevance: Why identified weaknesses matter to the application's intended use.

• Mitigation and retesting: Which findings were addressed, what changes were implemented and whether relevant failures remained reproducible.

• Remaining exposure: Unresolved findings, material exclusions and limitations affecting the conclusions.

The broker should also confirm the submission or renewal deadline before the engagement begins.

An assessment may identify vulnerabilities requiring investigation and remediation. If the insurer expects evidence of completed mitigation, the project timeline should allow for engineering changes and retesting rather than assuming the initial assessment report will be the final deliverable.

The assessor and client should agree on what can realistically be completed within the available timeframe.

A Practical AI Vulnerability Assessment Referral Checklist for Brokers

A broker can prepare an initial referral using the following nine questions. The objective is to provide enough information for a meaningful scoping discussion, not to complete a technical assessment before contacting the assessor.

Information to Establish Before the Initial Referral

1. Client and application: Which company and AI product require assessment? Is the application live, near deployment or undergoing a material change?

2. Insurance trigger: Is the referral connected to a new submission, renewal, exclusion, incident or insurer information request?

3. Insurance question: What specific uncertainty or evidence requirement prompted the assessment?

4. Application capabilities: What does the AI application do, and which data, tools or operational actions can it access or influence?

5. Submission deadline: When is the evidence needed, and is there time for assessment, remediation and retesting?

Details to Finalize During Assessment Scoping

6. Assessment priorities: Which application behaviors, potential failures and operating restrictions should the assessor consider?

7. Technical access: Who is the client's technical contact, and what environment, interfaces and permissions can be made available?

8. Evidence sharing: Who will receive the findings, and what confidentiality or information-sharing restrictions apply?

9. Expected deliverables: Does the intended reviewer need an assessment summary, detailed findings, remediation status, retesting evidence or other technical documentation?

Not every question needs a final answer at the referral stage. Identifying the information already available, and what still needs clarification, allows the broker, client and assessor to agree on a relevant engagement.

For referrals connected to a specific insurer request, the broker should communicate the original question as accurately as possible rather than assuming which technical tests will satisfy it.

How AetherLab Supports AI Vulnerability Assessment Referrals

AetherLab helps AI-deploying companies produce technical evidence about application-level vulnerabilities through independent, scoped assessments.

Its AdversarialScan evaluates applications against agreed failure scenarios and defined assessment objectives. Evidence Pack can document the assessed configuration, observed findings, control responses, mitigation, retesting, limitations and remaining exposure, as applicable to the engagement.

For specialist brokers handling AI liability discussions, the starting point is a clearly identified client application, an insurance-related question and an appropriate technical contact.

AetherLab can discuss a suitable assessment scope and the evidence that may be produced within it. The resulting findings can inform discussions between the client, broker and insurer, while coverage, pricing and underwriting decisions remain with the insurer.

Explore AetherLab's approach to AI vulnerability assessment.