Last updated on June 9, 2026
If you are the lawyer at a company with any sizeable technical department (IT, engineering, R&D, etc.), your co-workers are almost certainly using AI coding tools. Tools like GitHub Copilot, Cursor, Claude Code, and OpenAI’s Codex have, in roughly two years, become as ordinary inside engineering organizations as Microsoft Word is inside a law firm.
Most of these tools came in through an inexpensive click-through agreement. Many were signed by individual engineers on a corporate credit card before any procurement or legal review. And almost none of those agreements were drafted to handle the kind of incidents that hit the industry just last month.
If you haven’t contemplated this issue at all, you’re not alone. These tools arrived quickly and are ground-breaking in providing productivity and capability boosts across multiple domains. Before you can craft a solution for your organization, you first must understand the problem.
An example from the news
In mid-May 2026, attackers ran a coordinated campaign against the open-source software ecosystem that nearly every modern AI tool is built on top of. The attackers did not break into a vendor’s data center. They did something subtler: they slipped tampered versions of widely-used building-block software into the public repositories that developers (and developer tools) automatically download from. Within minutes, those tampered versions had been pulled onto the laptops of engineers at major companies — including OpenAI, which publicly acknowledged that two of its own employees’ machines were affected.
Running in parallel, security researchers disclosed a series of serious flaws in the AI coding tools themselves — Claude Code, Cursor, Codex, and LM Studio — that allowed attackers to take control of an engineer’s machine simply by getting that engineer to open a poisoned project file. By the end of the second week, the tools used to launch these attacks had been published publicly on GitHub, meaning the techniques are now available to any motivated bad actor, not just the original group.
Why this is a contract problem
Security teams know how to respond to these incidents from a technical perspective — patch the tools, rotate the keys, inventory the exposure. The legal question is different and, for most companies, unanswered: when one of these events causes a loss inside your business, who pays for it?
The honest answer in most current AI vendor agreements is: you do.
Three patterns show up repeatedly in these agreements.
1. The security warranties are too narrow. They typically cover the vendor’s own infrastructure — its servers, its data center, its corporate network. They do not, on their face, reach the open-source building blocks the vendor itself depends on. When the attack vector is upstream of the vendor, the vendor’s standard warranty often does not apply.
2. The indemnities are insufficient. Industry surveys consistently find that only about a third of AI vendors offer meaningful indemnification for third-party intellectual property claims, well below ordinary SaaS market practice. Where indemnities do exist, they are often hedged with so many exceptions that the protection is, as one practitioner has put it, illusory.
3. The liability cap is too low for the new risk. A typical AI coding tool MSA caps total vendor liability at twelve months of fees. For a tool that costs thirty dollars per developer per month deployed across an engineering team, that cap is approximately the cost of a single engineer’s morning. It is not designed to make anyone whole after a security incident that traces back to the tool.
The result, today, is that the company using the AI coding tool — not the company making it — is sitting on most of the risk. That allocation is defensible if it is the negotiated outcome of a real conversation. It is less defensible when it is the accidental outcome of nobody having reviewed the clauses.
A five-clause checklist for AI coding tool agreements
The good news is that the contract fix is straightforward. Each clause below maps to one of the failure patterns the past two weeks made concrete.
1. A security warranty that reaches the vendor’s own dependencies. Require the vendor to represent that its tool — including the open-source components it relies on, the model itself, and the build process used to produce updates — is delivered free of known compromise. This is the clause that pulls the upstream attack inside the vendor’s contractual responsibility (at least for risks it knows of).
2. A breach-notification obligation that is triggered upstream. Most current contracts only require notice if the vendor itself is breached. Update the language so notice is owed within a defined window (24 to 72 hours, depending on industry) whenever an incident anywhere in the vendor’s supply chain meaningfully affects the integrity of the tool or the work product it generates. You want to learn about TanStack-style incidents from the vendor, not from a security newsletter.
3. Clear allocation of liability when the tool itself executes harmful code. This is the genuinely new category. AI coding tools run with developer-level access on your machines and can take destructive actions automatically. The contract should say plainly who bears the loss when the tool — through security breach or flaws in the tool itself — deletes data, exfiltrates credentials, or introduces vulnerabilities into your codebase.
4. An audit right that lets you verify what is actually inside the tool. Federal guidance is converging on a standard called a Software Bill of Materials — essentially an ingredients list for software. CISA’s 2025 minimum elements, and the new AI-specific extension of that standard, give you a defensible benchmark to require. Ask for the ingredients list, plus reasonable audit rights to verify it. This is the clause vendors push back on most — and the clause that makes the rest of the agreement enforceable in practice.
5. A carve-out from the liability cap for security incidents. All four of the clauses above are decorative if the vendor’s total exposure is twelve months of fees. Try to negotiate a separate, higher cap — or no cap at all for willful misconduct — that applies specifically to losses caused by security incidents. A tiered cap that escalates with severity is also workable. The goal is to make the vendor’s exposure proportional to the harm the tool is now capable of causing.
What an in-house team should do this week
If you are about to sign or renew an AI coding tool agreement, the five clauses above are the spine of a defensible redline. If you are not in an active negotiation, the more productive exercise is a portfolio scan. Pull every active AI coding tool agreement at your company, read the indemnification, the limitation of liability, the security warranties, and the breach-notification clause, and score each contract against the checklist. Any agreement that fails on three or more clauses is a candidate for renegotiation at the next renewal window. Any agreement that fails on all five is a candidate for replacement.
How Silverline can help
Silverline Legal works with in-house counsel, technology companies, and operations teams on AI vendor agreements, software supply-chain risk, and the commercial-contract questions that come with deploying AI tools at scale. If you would like a one-page scorecard scoring your existing AI vendor agreements against the five-clause framework above — or you have a specific AI coding tool MSA you would like a second set of eyes on — reach out.