Does AI insurance cover third-party tool failures?

An enterprise AI agent rarely fails on its own reasoning alone. More often it calls a search tool, a pricing API, a document retrieval system, or another agent entirely, and the failure originates somewhere in that chain rather than in the orchestrating agent's own logic. Whether your AI liability policy responds to that scenario depends on wording most policyholders have not actually read closely. This article sets out how third-party technology exclusions interact with agentic tool calling, what you remain liable for regardless of where the fault sits, and what underwriters are starting to ask for before they will price the gap away.

The scenario underwriters are only beginning to price

Consider an agent that handles a customer's refund request. The agent itself reasons correctly: it identifies the customer, confirms eligibility, and decides a refund is warranted. It then calls a payments tool to process the transaction. The payments tool, built and maintained by a separate vendor, has a bug that processes the refund at the wrong amount. From the customer's perspective, your business made an error. From an insurance perspective, the question of whether your policy responds depends on whether "your AI system" as defined in the policy schedule includes the payments tool the agent called, or stops at the boundary of the agent's own model and orchestration logic.

This is not a marginal scenario. Agentic systems are built specifically to call external tools, plugins, and increasingly other agents, because that is how they extend beyond what a language model alone can do. A pricing lookup, an inventory check, a document retrieval step, a booking confirmation: each of these is commonly delegated to a tool or a sub-agent rather than handled by the orchestrating model directly. The insurance question this creates, whether coverage follows the customer-facing agent or stops at an internal architectural boundary the customer never sees, is one most enterprises binding AI liability cover in 2026 have not yet asked their broker directly.

How third-party technology exclusions were built, and why they do not fit cleanly

Third-party technology exclusions are a long-standing feature of technology errors and omissions policies, designed to exclude claims arising from software, platforms, or services the policyholder did not build and does not control, most commonly a subcontractor's or vendor's product embedded in the policyholder's offering. The logic behind the exclusion predates agentic AI by decades: an insurer writing a policy for your software business does not want to also underwrite every vendor whose component you happen to integrate, and expects you to seek recovery from that vendor separately if their component fails.

Applied literally to an agentic AI system, this exclusion can produce a result that tracks the technical architecture rather than the commercial reality. If a customer-facing agent's failure traces back to a called tool the policyholder licensed rather than built, a narrowly drafted exclusion can remove coverage for the loss even though the customer has no relationship with the tool vendor at all and holds the policyholder, not the vendor, responsible. The exclusion was written to protect insurers from underwriting unrelated third-party products bundled into an offering. Applied to an agent's own tool calls, which the deployer specifically chose to wire into the customer experience, it can instead remove coverage for exactly the kind of loss the policy was purchased to address.

What you remain liable for regardless of where the fault sits

The coverage question and the liability question are separate, and conflating them is the most common mistake operators make when reviewing this risk. Your liability to the customer does not depend on which internal component of your system caused the failure. The customer's contract, and any duty of care they are owed, runs to your business, not to a tool vendor several layers removed from the interaction they actually had. This is the same principle established in Moffatt v. Air Canada, where the tribunal rejected the argument that a chatbot's statements could be treated as originating from a separate, disclaimable party.

For EU-facing deployments, Directive 2024/2853, the revised Product Liability Directive, reinforces this at the regulatory level. Article 8 provides that where multiple economic operators are each responsible for the same damage, they are jointly and severally liable, meaning a claimant can recover in full from any one of them.^[1] A customer harmed by a failure that technically originated in a called tool can still pursue the deploying operator for the full loss, leaving the operator to seek contribution from the tool vendor separately, a process that takes time and is not guaranteed to succeed. The practical result is that your liability exposure is not reduced by the fact that a tool, not your own agent's core logic, caused the failure. Only your insurance coverage for that exposure is potentially reduced, and only if the policy is drafted narrowly.

What underwriters are starting to ask for

As this gap has become more visible, AI liability underwriters, including those writing under the AIUC-1 standard and Lloyd's syndicates handling bespoke enterprise programmes, are increasingly requesting a call graph as part of the underwriting submission: a documented inventory of every tool, plugin, and third-party agent endpoint the insured system can invoke, the data access and permissions each call carries, and the checkpoints, human or automated, that sit between a tool's response and any consequential action taken on it. This is the same evidence base described in our companion analysis of how certification assessments handle multi-agent and tool-calling systems on agentcertified.eu, and the overlap is not a coincidence: underwriters and certification assessors are converging on the same evidence because it answers the same underlying question, namely what can this system actually do once every call it is capable of making is accounted for.

A submission that can produce this call graph clearly is positioned to negotiate a policy definition of the insured system that follows the customer-facing outcome rather than stopping at an internal architectural boundary, because the underwriter can see exactly what is being priced. A submission that cannot produce it is more likely to face either a narrow definition that excludes tool-originated losses by default, or a broad exclusion applied conservatively because the underwriter cannot otherwise size the exposure. This is the same governance-documentation dynamic already established for AI liability underwriting generally, discussed in our guide to preparing an AI agent underwriting submission, applied specifically to the tool-calling layer of the system.

Do standardised protocols change what is covered

Standardised agent-to-agent and tool-calling protocols, including Anthropic's Model Context Protocol and Google's Agent2Agent protocol, do not themselves change what a given insurance policy covers. What they change is how easily the call graph underwriters want can be produced. A system built on a standardised protocol typically exposes its tool and agent inventory in a structured, inspectable form, rather than in custom integration code whose actual call paths exist only in an engineering team's institutional knowledge. That structured visibility supports a more precise underwriting conversation and a policy definition negotiated with the real system in view, rather than a conservative default applied because the underwriter could not otherwise see what they were being asked to price.

What to check before you assume you are covered

Three checks are proportionate for any enterprise operating an agentic system with meaningful tool-calling behaviour. First, ask your broker directly how the policy defines the insured AI system, and specifically whether that definition extends to tools, plugins, and agent endpoints the system calls, or is limited to the core model and orchestration logic. Second, request the exact wording of any third-party technology exclusion and have it reviewed against your actual architecture, not a generic description of your product. Third, prepare a call graph of your system's tool and agent dependencies before your next renewal or new placement, both because it is the evidence underwriters increasingly want and because producing it will itself surface gaps in your own understanding of what your system can actually do. For the regulatory backdrop that makes this exposure real regardless of policy wording, see the Article 25 value chain responsibilities guide on agentliability.eu, and for SME-scale coverage options addressing a related version of this question, see does my AI chatbot need separate insurance on insureyouragent.com.