Negotiating Insurance Clauses in MSAs as a Pre-Revenue Hardware Startup
The insurance clauses built for mature vendors don't fit pre-revenue hardware startups.
A founder running a pre-revenue robotics company gets a redlined master services agreement back from the first enterprise customer willing to pilot the hardware, and buried on page 14 is an insurance exhibit that looks routine: general liability at a substantial per-occurrence limit, professional liability, workers' compensation, product liability, the customer named as additional insured. The founder forwards it to a broker expecting a quote within the week and instead gets a set of questions nobody budgeted time to answer, because the policies that would satisfy that exhibit either don't cover what the hardware actually does or don't exist yet in a form an early-stage company can buy. That gap between what the clause asks for and what the market will sell is a structural mismatch between contract language written for mature, fully-insured vendors and a class of company the insurance market has not yet figured out how to price.
The Structurally Different MSA Problem for Pre-Revenue Hardware Startups
Enterprise and government procurement teams write their MSA insurance exhibits once and reuse them across every vendor who crosses their desk, regardless of whether that vendor sells accounting software or an autonomous forklift. The clause assumes a vendor with years of claims history, a broker who has placed the same coverage a hundred times, and an insurer willing to write the account at standard rates. None of that describes a company that has not yet shipped its first unit. At the same time, the insurance products available to autonomous hardware companies are narrowing rather than widening, as carriers add exclusions for AI-related losses faster than they introduce new products to cover them. A startup in this position is negotiating from the weakest footing in the entire MSA because the clause it is being asked to sign was never built to fit the thing it is selling. Everything that follows in this piece, the clause mechanics, the coverage gaps, the indemnity language, the negotiation tactics, the certificate review, exists to help a founder close that gap before signing it closed the other way.
How Standard MSA Insurance Clauses Are Structured
An MSA insurance clause reads as one paragraph but functions as five separate obligations stacked on top of each other, and a startup that satisfies four of them while missing the fifth has still failed the clause. The first obligation is procurement: the vendor has to obtain and keep specific policy types at specific minimum limits before any work starts, typically general liability, professional liability or errors and omissions, cyber, workers' compensation, and product liability. The second is additional insured status, where the customer gets added to the vendor's policy so that the vendor's own insurer covers losses the customer suffers from the vendor's operations. The third is primary and non-contributory language, which says the vendor's policy pays first, before the customer's own coverage responds at all, an exposure that matters enormously to a startup carrying thin limits against a customer with a much larger risk management program. The fourth is delivery of a certificate of insurance before the contract is signed and again at each renewal, proving the first three obligations are actually being met. The fifth is the indemnification clause itself, which typically requires the vendor to defend, indemnify, and hold the customer harmless from claims tied to the vendor's performance, and this is where any gap between what's required and what's insured turns into real dollars owed.
Government contracts raise the floor further. Technology and professional services contracts with government customers commonly carry a recommended minimum errors and omissions limit per occurrence, with a requirement that the contractor's coverage sit primary and non-contributory ahead of any government coverage. California adds a floor specific to autonomous vehicles: manufacturers testing or deploying them must hold $5 million in insurance, a surety bond, or proof of self-insurance, and that obligation starts the moment the hardware leaves the lab for public roads, not when the company reaches some later stage of maturity. A customer's insurance clause describes what that customer's legal team considers standard risk; it is not a complete map of what the vendor actually needs. A startup selling autonomous hardware may need coverage well beyond anything the customer thought to ask for, and treating the clause as a ceiling rather than a floor is one of the more expensive mistakes a founder can make.
Why autonomous hardware breaks the coverage assumptions in those clauses
MSA insurance clauses assume a vendor can walk into the market and buy a policy matching whatever the clause specifies. For companies building robots, autonomous vehicles, or other hardware that uses sensors and models to decide how to act rather than execute fixed commands, that assumption increasingly doesn't hold. A traditional machine does the same thing every time you give it the same input, so insurers built decades of actuarial data around that predictability. Autonomous hardware behaves differently depending on its environment, its software version, and the judgment calls its models make in the moment, and that same flexibility that makes the product valuable is what breaks the liability framework the insurance industry built for fixed-function equipment.
A single incident involving autonomous hardware can trigger claims across several policy lines at once instead of landing cleanly inside one, and the gaps between those lines are where coverage disappears. WTW's Andrew Hill has described a case where a cyberattack on an autonomous robot causes property damage: the property policy may exclude the loss because a cyberattack caused it, while the cyber policy may exclude the same loss because it manifested as property damage. The robot's owner is left holding a claim that two separate policies each declined on the grounds that it belonged to the other. The liability chain compounds the problem further. A single incident involving a deployed robot can produce claims against the hardware manufacturer, the software developer, and the operator simultaneously, and a pre-revenue startup selling into an enterprise customer frequently sits in the middle of that chain as the integrator, absorbing product liability that flows up from the components it sourced and down from the customer deploying the finished system.
Underwriters are also working without the historical claims data that normally lets them price risk with confidence. The same robot model can carry meaningfully different risk at two different warehouses depending on the floor layout, how closely workers interact with the machine, and which software version is running. Underwriting autonomous hardware is inherently site-specific, not a matter of looking up a standard rate for a product category. That is part of why one commercial general liability endorsement, one of the broadest exclusions now circulating in such policies, strips out Products/Completed Operations coverage for property damage arising out of generative AI. If a founder assumes a standard CGL or E&O policy covers anything an AI system touches, they are very likely assuming something that endorsement specifically removed.
Reading the indemnification clause before reading the insurance clause
The indemnification clause defines the liability a startup is taking on; the insurance clause is supposed to fund that liability if it ever comes due. Negotiating the insurance minimums before scoping the indemnity means negotiating the wrong variable first, because the size of the insurance requirement should be set by the size of the exposure the indemnity creates, not the other way around. Standard MSA indemnification language obligates the vendor to defend, indemnify, and hold the customer harmless from third-party claims arising out of the vendor's performance, and that obligation is not capped by whatever insurance minimums appear two paragraphs later unless the contract says so explicitly. Absent that language, the indemnity remains a direct, uncapped obligation against the company, and for a pre-revenue startup with no revenue cushion, that obligation reaches the founders' own balance sheet the moment a claim exceeds whatever coverage exists.
Three provisions deserve attention before a founder spends any time on the insurance schedule itself. An uncapped indemnity should be renegotiated toward a mutual structure, where both parties indemnify each other for their own acts, or toward a cap tied to the contract value or the insurance limits, whichever number is lower. Consequential damages are often swept into standard indemnity language without anyone noticing, covering lost profits and business interruption losses that no policy available to an autonomous hardware company today actually covers, and that category should be carved out of what the startup is indemnifying against. A third check is whether the categories of loss named in the indemnity line up with the categories of loss the insurance clause actually requires coverage for. When they don't match, whatever sits in that gap becomes the startup's uninsured problem the day a claim arrives.
Negotiating the insurance minimums themselves, what is reasonable, what is not, and how to make the case
Enterprise insurance minimums usually come straight out of a procurement template built for a generic vendor, not from any analysis of what an autonomous hardware company's actual risk looks like. That means a founder who comes back with a specific, well-reasoned alternative is often negotiating with a customer who hasn't thought hard about the number either, and specificity tends to win these conversations.
On general liability, the limit the customer asks for means very little if the underlying policy carries the CG 35 08 endorsement, which removes Products/Completed Operations coverage for property damage tied to generative AI while leaving Coverage A, premises and ongoing operations, untouched. A founder should propose satisfying the CGL requirement through a combination of a base CGL policy plus a robot-specific or standalone AI liability endorsement that affirmatively covers autonomous operations, and should name the CG 35 08 gap directly in the redline comment so the customer's risk team understands what's actually missing. Programs built specifically for this risk exist: Axis Insurance's robot-specific program covers bodily injury and property damage from AI navigation or perception failures, physical damage from a cyberattack that takes over a robot's controls, and production losses from a software update or sensor failure that takes a robot offline even without physical damage. Relm Insurance's PONTAAI product, launched in January 2025, covers bodily injury and property damage among other liabilities tied to autonomous systems. Either type of affirmative coverage can replace or supplement a CGL policy that's been hollowed out by an AI exclusion.
Technology errors and omissions coverage functions as a baseline for competing. Large corporations and government entities routinely require a minimum E&O limit as a condition of doing business, and a startup without sufficient Tech E&O simply can't bid on those contracts regardless of how good the product is. At the negotiating table, you can offer a higher Tech E&O limit in exchange for a lower or waived product liability requirement while the product remains in pilot, since the realistic risk at that stage is a software error affecting a handful of pilot units, not a mass-market product defect.
Inland marine coverage, sometimes called an equipment floater, is the line most often missed by founders who come from a software background. Standard commercial property policies put sub-limits on equipment located off-premises, far below what it costs to replace autonomous hardware sitting on a customer's pilot floor. When an MSA requires property insurance for hardware installed at a customer site, it's worth confirming directly whether an equipment floater satisfies that requirement instead of a full commercial property policy, since the floater is cheaper, built specifically for this purpose, and considerably easier for an early-stage company to obtain.
Cyber coverage appears in nearly every enterprise contract now, and SOC 2 auditors are increasingly recommending it as a risk-transfer measure in its own right, so the customer's vendor risk team will read that line of the certificate closely. A cyber-physical extension, such as AIG CyberEdge Plus, covers bodily injury, property damage, and business interruption tied to a cyber-attack, but only when a cyberattack triggers the loss, so it does nothing for an AI system that makes a bad decision without any breach involved. A cyber-physical policy complements a robot-specific policy. On the limit itself, it's reasonable to propose scaling the cyber coverage to the actual data footprint of the pilot rather than matching the enterprise customer's own cyber program, since a startup running a single limited pilot doesn't carry anything close to the data exposure of a mature SaaS platform.
Product liability is the line most likely to hide a gap until it's too late. Product liability coverage can respond to bodily injury and property damage, but only in jurisdictions that treat AI software as a product in the first place, and purely financial losses from the same failure get no product liability coverage under a standard policy regardless of jurisdiction. Where the MSA insists on standalone product liability, the stronger move is folding it into a robot-specific policy rather than carrying it as a separate line, since programs like the ones from Axis and Relm are built specifically to cover the combined product-plus-AI exposure that a conventional product liability policy was never designed to reach.
What the Certificate of Insurance Must Show
A certificate of insurance is where a carefully negotiated clause either holds up against the actual policy or quietly comes apart, and the gap between the two is nearly always invisible to the startup until a claim forces someone to read the fine print. A COI confirms a policy exists and that the customer has been added as an additional insured. It says nothing about the exclusions that may have already hollowed out the coverage both the customer and the startup believe is in place.
For an autonomous hardware company, the exclusions that matter most are absent from the certificate's face page. CG 35 08, CG 40 47, CG 40 48, and various carrier-specific AI exclusions all live as endorsements buried inside the policy document itself, pages the certificate was never designed to summarize. Before delivering a certificate to any customer, a founder should get the full policy from the broker, not just the declarations page, and check directly for any AI or autonomous systems exclusion endorsement attached to it. The second check is just as important: confirm whether the policy affirmatively covers autonomous operations, with language that names them specifically, or whether it's simply silent on the subject. Silence is not the same as coverage once a carrier has filed AI exclusion language with state insurance regulators, because silence in that context usually means the carrier intended the exclusion to apply and just didn't need to spell it out twice. A certificate that satisfies the customer's checklist while concealing one of these endorsements has not protected the startup. It has only delayed the moment the uninsured liability becomes visible to the people who signed for it.