In-House Counsel AI Coding Assistant Approval: Questions to Ask Before Approving Cursor

Why the indemnity is one input, not the verdict

When one tool ships with a vendor IP indemnity and another does not, the indemnity can look like the deciding factor. It is better read as a single risk-transfer mechanism. Its value depends on what it covers, what the customer must do to keep it valid, what the vendor excludes, and whether the customer can later demonstrate that it met those conditions.

Commentary from practitioners reviewing these agreements points to the main weakness. Defence promises in this category are reported to be withdrawn when the customer edits, combines or otherwise modifies the output. One practitioner reports that across dozens of coding-tool agreements reviewed in the past year, none offered indemnification for a suggestion once an engineer had rewritten it. That is one reviewer's experience, not a general finding, but the logic is clear: most shipped code is edited, so counsel should ask how much of it would ever sit inside the indemnity.

The reverse also holds. The absence of an equivalent indemnity does not settle the decision. Published commentary characterises Cursor's terms in different ways, which is a reminder that public terms, order forms and negotiated agreements can differ. The review should be run against the documents that would actually govern your deployment, with the vendor's written confirmation of anything ambiguous.

Indemnity questions to put to the vendor

Apply the same questions to every candidate tool, including the one that offers the indemnity. Ask for answers in writing and tie them to the specific plan you would buy.

• Which plans and products carry the defence?: Confirm the exact tiers and products covered, and whether the defence is a contractual term or a policy statement.
• Does it sit outside the liability cap?: A defence obligation subject to a low cap has a different value from one that is uncapped or separately limited.
• What counts as modified output?: Ask for a definition of edited, combined or adapted output and how the vendor expects a customer to evidence the difference.
• What settings or filters must be enabled?: If validity depends on configuration, such as a duplicate-detection setting, ask whether it can be enforced for all users and shown to have been on.
• What exclusions and notice duties apply?: Review exclusions, claim notification timing, control of the defence and settlement rights.
• What do we owe the vendor?: Commentary reports that Cursor's public terms require the customer to indemnify the vendor for claims about the customer's inputs. Check this reverse obligation for every tool.

Data handling, retention and dependencies

Indemnity terms say little about what happens to your code and prompts. Most SaaS-based coding assistants, including GitHub Copilot and Cursor, process code through vendor-managed infrastructure, and enterprise buyers increasingly require assurance that proprietary code will not be used for model training. Treat marketing pages and comparison articles as leads, not evidence.

Counsel should ask for written positions on four points. First, whether code or prompts are retained, for how long, and under which plan or mode. Second, whether customer data is used for training, and whether that position is fixed in the contract rather than in product documentation that can change. Third, which model providers and subprocessors handle prompts and code, and how changes to that list are notified. Fourth, whether any zero-data-retention commitment applies to all models or only some, and who approves exceptions.

Internal security and engineering teams own a related question: which tools, in which configurations, send code outside the organisation's boundary at all. A governance position that does not distinguish between configurations will be too loose for some and too strict for others. Ask engineering to document the data flow per tool and per configuration before the approval is signed.

Model and subprocessor chains are also third-party dependencies. NIST AI RMF 1.0 refers to risks from third-party entities, including the risk of infringing a third party's intellectual property or other rights, so these dependencies belong in the AI risk register alongside the approval.

Code origin, licence exposure and what stays with you

Even where an indemnity applies, several exposures remain with the customer. Edited or combined output may fall outside the defence. Licence obligations attached to code that resembles existing open source do not disappear because a vendor promises to defend a claim. Security weaknesses in generated code are not an intellectual property matter and are unlikely to be addressed by an IP indemnity at all. Counsel should also keep in mind that exposure for inputs, meaning what your engineers paste into the tool, can run toward the vendor under some terms.

The practical gap is evidence. If a claim arises, the organisation needs to say where a piece of code came from, what licence context applied, and whether it was unmodified assistant output or human-authored. Few teams can answer that after the fact from commit history alone.

NIST draft guidance on generative AI recommends transparency policies and processes for documenting the origin of generated data, including copyrights, licences and data privacy, to advance content provenance. The draft has since been withdrawn, so use it as indicative rather than as a standard. It still maps cleanly to a counsel requirement: records of code origin, licence and security context that exist before a dispute, not reconstructions made after one.

Ask engineering what such records the organisation can produce today, and which gaps would need to be closed before approval.

Runtime enforcement and audit-ready evidence

A written policy that engineers may or may not follow is weak support for an approval decision. Counsel can instead require that policy be enforced at runtime, not reviewed after the fact, and that the enforcement itself produces the records needed to show compliance with indemnity conditions and internal rules.

In practice that means a control point in the execution path of the coding assistant that can allow, redact or block individual interactions according to policy. If a vendor condition depends on a particular setting, the question becomes whether a central control can apply it to every user and show it was applied. If internal policy prohibits certain nonpublic data from reaching an external model, the question is whether that rule is enforced at the point of the interaction.

Trussed provides this kind of runtime control for coding assistants, enforcing policy in the execution path with allow, redact and block decisions. It also supplies code provenance covering the origin, licence and security context of code, and generates audit-ready evidence from enforcement. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. Whatever tooling is used, the requirement for counsel is the same: evidence generated by the control itself, retained for a defined period, and available to legal and audit on request.