AI Coding Agent Contracts: What Legal Teams Must Check

Your engineering team wants to roll out an AI coding agent, something like Devin or Replit Agent that plans, writes, and ships code on its own rather than just autocompleting a line. Before anyone signs, the contract needs a different read than a normal SaaS tool gets. The clauses that protect you against a chatbot vendor rarely protect you against a vendor whose product can commit code, touch a repo, or deploy to production without a human clicking "send" first.

What "AI coding agent" actually means in a contract

Legally, the distinction matters more than the marketing does. A code-completion tool suggests a line and a person accepts or rejects it: the human stays the actor. An AI coding agent plans a task, writes code across multiple files, runs it, and sometimes deploys it, with a person reviewing the output rather than authoring each line.

That shift changes who "did" the action for liability purposes. If the agent introduces a vulnerability or pushes a breaking change, the vendor's standard terms were almost certainly written for the first model, not the second. Read the contract with that gap in mind before you read anything else.

The distinction also determines which internal stakeholders need to sign off before the contract does. A code-completion tool is usually a procurement decision that engineering leadership makes on its own. An AI coding agent that can execute commands, access a repository, or push to a deployment pipeline touches security review, data protection, and often the same risk-committee process a new core vendor would trigger. Treating the two the same at the sourcing stage is where most of the gaps described below start.

The liability gap nobody flags before signing

Most vendor paper for developer tools still assumes a human is the last line of defence. Clifford Chance's 2026 review of agentic AI contracts found that legacy technology agreements typically place responsibility for the agent's actions entirely on the customer, with suppliers offering the software "as is" and disclaiming liability for accuracy, even when the customer configured everything correctly (Clifford Chance, February 2026).

In practice, this means the standard indemnity in most AI coding agent contracts does not extend to the agent's own acts or omissions. If the agent's autonomous action causes damage, a bad deploy, an exposed credential, a broken production system, you may find the indemnification clause was written for third-party IP infringement claims only, not for the agent's own mistakes.

What to check: Does the indemnification clause explicitly cover losses caused by the agent's autonomous actions (not just third-party claims), or only the narrower case of IP infringement in the code it generates? Ask the vendor to confirm in writing if the contract language is silent.

Worth being blunt about this one: if your current agreement caps the vendor's liability at the subscription fee and excludes "loss of profits, loss of data, and consequential damages," an agent-caused production incident is exactly the kind of loss that gets excluded. That combination is common in default SaaS terms and rarely gets renegotiated unless legal asks first.

Who owns the code the agent writes?

This is where a genuine legal ambiguity sits underneath the commercial question. Copyright law in most jurisdictions, including the EU and UK, requires a human author: code generated purely by a model may not be eligible for copyright protection at all, regardless of what the contract says about ownership. A well-drafted vendor agreement grants you a contractual right to use, modify, and distribute the output, which solves the commercial problem even if the underlying copyright question stays unresolved.

The other ownership risk sits one layer down: open-source license contamination. An agent trained on public repositories doesn't know that the pattern it just reproduced came from a copyleft-licensed project meant for non-commercial use. Ilia Badeev of Trevolution Group put it plainly: the model "doesn't know how that code will be used," which is exactly why license-scanning needs to run on AI-generated code before it ships, not after (CIO, 2026).

§ Sample clause language to look for:
"Customer owns all right, title, and interest in Output, subject to Vendor's
underlying intellectual property in the Service. Vendor represents that
Output is generated without reproduction of licensed third-party code
requiring attribution or copyleft obligations, and will indemnify Customer
against claims arising from Vendor's breach of this representation."

If that representation and indemnity aren't in the contract, don't assume they're implied. Ask for them explicitly, in writing, before rollout, not after a legal team stumbles across a GPL header six months into production.

Data residency and the EU AI Act deadline you can't negotiate around

Most AI coding agents on the market are US vendors, which means Swiss, Austrian, and EU-based teams are running a cross-border data transfer the moment source code and prompts leave the local network. Standard Contractual Clauses cover the transfer mechanism, but they don't answer the harder question: does the vendor train its own models on your proprietary code, and can you actually turn that off?

Devin's enterprise terms, for instance, state that customer data stays within the customer's own VPC deployment and is never used for training, which is the kind of specific commitment worth asking every vendor to match in writing rather than accepting as an industry default (Devin Enterprise). Several competing agents now publish similar language, SOC 2 Type 2 attestation, GDPR and CCPA compliance statements, a Data Processing Agreement built around Standard Contractual Clauses, but the wording varies enough between vendors that a side-by-side comparison of the actual clauses, not the marketing pages, is worth an hour of a paralegal's time before rollout.

That hour typically surfaces gaps the sales call didn't mention: a training opt-out that only applies to paid tiers, a DPA that covers personal data but stays silent on source code specifically, or a sub-processor list that includes a fourth-party LLM provider nobody flagged during procurement. None of these are dealbreakers on their own. They are, however, exactly the kind of detail that turns into a difficult conversation with a data protection officer if it surfaces after the tool is already embedded in daily engineering work.

The EU AI Act's general application begins on 2 August 2026, and it puts the compliance burden on the deploying company, not the vendor. In practice, this means legal and procurement need documented risk assessments, audit trails of what the agent did and why, and, for anything touching regulated decisions, a genuine human-in-the-loop step, before the tool goes into daily use, not retrofitted afterward.

If you self-host, the contract problem doesn't disappear, it moves

Open-source, self-hostable agents change where the risk sits rather than removing it. You skip the vendor's data-training question because there's no vendor processing your code, but you inherit the security hardening, patching, and audit-logging work the vendor would otherwise have owned contractually.

For teams with the internal capacity to run that responsibly, self-hosting is a legitimate way to sidestep the cross-border transfer question entirely. For teams without a platform engineering function to own it, a vendor contract with clear terms is usually the safer bet, even if it takes longer to negotiate.

There is a middle option worth naming too: some legal and procurement teams request a shorter pilot agreement, thirty to sixty days, scoped to a single non-production repository, before committing to the standard annual contract. It doesn't remove any of the clauses discussed here, but it gives security and legal a live environment to test the vendor's actual behaviour, not just its data sheet, before the terms that matter get locked in for a year.

Security clauses that matter more than a SOC 2 badge

A SOC 2 report tells you the vendor's infrastructure controls were audited. It says nothing about who's liable when the agent itself, not the infrastructure around it, writes a security flaw into your codebase. Those are two different questions, and vendor sales teams tend to answer only the first one unless asked directly.

The clauses worth pushing for: audit rights over the agent's decision logs, a documented incident-cooperation obligation (the vendor commits to a response timeline, not just "reasonable efforts"), and a real-time suspension or override capability so your team can pull the agent's access without waiting on the vendor's support queue. Clifford Chance's recommendation is to require human review for any action with legal, financial, or regulatory consequences, and to negotiate expanded indemnities and higher liability caps specifically for high-value deployments rather than accepting the vendor's template as-is.

Skip waiting for the courts to settle this

The advice you'll hear most often, and the one worth ignoring, is "wait until case law clarifies AI copyright and liability before you worry about it." Courts in the US and EU have not resolved whether training an AI model on copyrighted code is itself infringing, and that question sits above the level of any individual contract. Jeffrey Gluck of Panitch Schwarze summed up the current state plainly: "you already have a copyright issue that has not yet been resolved" at the level of the underlying model.

Waiting for that resolution doesn't protect you in the meantime; it just means you're operating without the contractual language that would matter once it is resolved. The clauses in this piece are things you can negotiate today, independent of how the training-data litigation eventually lands.

What to check before the next contract lands on your desk

Three things worth doing before any AI coding agent contract gets signed. First, confirm the indemnification clause covers the agent's autonomous actions, not just third-party IP claims, and that liability caps aren't excluding the loss categories an agent failure would actually cause. Second, get the vendor's training-data commitment and license-scanning representation in writing, not implied by a pricing page.

Third, if the vendor is US-based and your team is in the EU, UK, or Switzerland, confirm the SCC-backed DPA is current and ask specifically what changes under the EU AI Act's August 2026 obligations. None of this replaces your own counsel's sign-off on the final language. It just means the conversation with them starts from the right questions instead of a blank page.