AI coding tool security moved from a developer concern to a procurement one in late October 2026. Researchers at Forever Security found exploitable flaws in five AI developer tools. The Register reported that the Codex and VS Code issues remained unpatched at publication. Separately, an official Anthropic extension distributed through Cursor's marketplace was backdoored. It affected as many as 5,000 users, according to Ars Technica.
That matters if you are about to sign or renew a contract for AI developer seats. The tools your teams want are now a software supply chain you buy. Most contracts still describe them as a licence, not a running service with a patch and disclosure obligation. This article sets out what to ask for before seat counts go up.
What went wrong in October 2026
The Forever Security research group found a common weakness across Cursor, GitHub Copilot, Claude Desktop, VS Code and Codex. Each embedded a browser with more capability than a normal one. The reported outcomes included code execution in Cursor. They also included file theft in Claude Desktop, Codex and VS Code, and address bar spoofing in GitHub Copilot.
Response times varied widely. Cursor patched quietly on 1 October after a 10 September disclosure and published no advisory, per The Register. GitHub fixed Copilot in build 1.1.29 on 13 October without receiving a report at all. That mix of silent fixes and missing notices is exactly what a contract should regulate.
The extension incident is the sharper warning. Version 2.1.313 of Anthropic's Claude extension was posted to Anthropic's verified Cursor account. It superseded the legitimate 2.1.312, per Ars Technica. Extensions auto-update by default in Cursor. The malicious build tried to add an attacker SSH key, enable local SSH and open a reverse tunnel. It also collected host and user details.
Both events point at the same gap. Buyers were not told, in writing and on a clock, what would happen when something went wrong. That gap is the core of AI coding tool security today.
Why governance has not kept up with adoption
The adoption numbers are not subtle. In a Checkmarx survey of more than 1,500 CISOs, AppSec managers and developers, 50% of organisations said they use AI to write code. Only 18% had clear policies on AI, per the Checkmarx report. The same study found 81% knowingly ship vulnerable code. It also found that 98% experienced a breach stemming from vulnerable code in the past year.
Developer behaviour confirms the pressure. In a survey of 241 developers, about 76% said they use AI coding tools constantly. Meanwhile 31% said they do not have enough time to review AI-generated code before deployment, per Pentest-Tools.com.
So the buying question is no longer whether the tool writes risky code. It is whether the vendor, and your own delivery organisation, can detect, disclose and fix problems. That speed has to match the pace at which seats are being added.
The clauses to put in the contract
Treat AI coding tool security as a set of testable commitments. Each item below should appear in the schedule, not the marketing annex.
- Patch SLA by severity. State a maximum time from verified vulnerability to fixed release for critical and high findings. Reference the vendor's own published advisories.
- Disclosure duty. Require notice to your named security contact within a set number of hours. This must cover fixes that ship silently and upstream or marketplace extension problems.
- Extension and update control. Confirm whether extensions auto-update, whether you can pin versions, and who approves marketplace publishers.
- Incident support. Name the escalation path and the forensic information you will receive. Also fix the credit or termination right if a breach originates in the tool.
- Audit and test rights. Secure the right to review penetration test summaries and to run your own adversarial testing before renewal.
These map onto recognised control sets. The OWASP AI Security Verification Standard asks organisations to verify that a written workflow names approved tools, prohibited use cases and permitted input data. It also asks them to threat-model every AI tool including its dependency chain, in OWASP AISVS Appendix C. An RFP schedule can borrow that language almost directly.
Ask for evidence, not posture
A vendor answer of "we take security seriously" carries no weight. Ask for a small set of artefacts that can be checked in a week.
- A current threat model covering prompt injection from untrusted code, extension compromise and model supply chain risk.
- The last two advisories, with dates of report, fix and customer notice.
- Adversarial test results, including indirect injection delivered through pull requests and issue text.
- A version inventory showing which extensions and models are in use.
- Named security contacts and the escalation runbook.
The OWASP Secure Coding with AI cheat sheet is blunt about where this risk sits. It notes that rules files such as `.cursorrules`, `CLAUDE.md` and `.github/copilot-instructions.md` "silently steer every future generation." Those files can be modified by a malicious pull request or by the agent itself. A compromised agent context, it warns, has the same blast radius as a compromised developer workstation.
That is a useful test for a vendor. Can they show how their tool treats repository content as untrusted input rather than instruction? AI coding tool security rests on that distinction more than on any feature list.
"Each tool enriched its embedded browser beyond what a normal browser allows, and those enrichments undermined the traditional threat model - as agent input, as the authority on a tab's own address, or as reach onto the host."
The quote is from Forever researcher Gal Weizman, as reported by The Register. It is the cleanest short explanation of why conventional browser and endpoint controls miss this class of problem.
How AI coding tool security changes your due diligence
Most procurement teams already score security questionnaires. The change is to score the parts that AI tooling makes different. Those are update channels, extension publishers, and the model and dependency chain behind the product.
Ask where visibility stops. A vendor that cannot see marketplace publishers has a blind spot you are buying. The same goes for a vendor that cannot say which model version is serving your developers. Score the honesty of that answer rather than the confidence of it.
Then write down your own side of the bargain. Your teams will run agents with broad permissions, and your working rules files are part of the attack surface. Buyers who can show an internal AI usage policy and an approved tool list will get better answers from vendors. A code review gate that stays mandatory does the same, and it means fewer surprises at renewal.
If you are still shortlisting, the Scopelyst cybersecurity vendor directory is a sensible place to find firms that can test AI developer tooling and review contracts. Teams building the tooling itself can be sourced through generative AI vendors.
What to tell the vendor before renewal
When AI coding tool security comes up at renewal, use the conversation to fix the mechanics rather than to reopen price. Four points do most of the work.
- Name a security contact on both sides and put the response clock in the contract.
- Require notice when a fix ships without an advisory, as happened with Cursor. Require the same when a marketplace extension changes publisher or version.
- Ask for a re-test after any major model or system prompt change. This is consistent with the OWASP AISVS requirement to repeat evaluation after material change.
- Keep one internal gate that applies whether or not AI wrote the code. Verification should not depend on the vendor's own testing.
Vendors who can answer these points in writing have a real advantage in a competitive bid. If you are on the supply side, the guidance on how vendors win RFPs on a marketplace applies here: evidence beats assurance. Our guide to writing an RFP for IT services will help you structure the security schedule so answers are comparable.
Frequently asked questions
Should AI coding tools be treated as a supply chain risk?
Yes. The extension incident shows a verified publisher account can be taken over. A malicious version then reached thousands of machines through normal auto-updates, per Ars Technica. That is a distribution channel risk, not just a code quality risk.
What patch timeline should buyers demand?
Set it by severity and put it in the contract. The October 2026 cases ranged from a fix 21 days after disclosure to a flaw still unpatched at publication, per The Register. Use those outcomes to argue for a fixed, measured clock.
Do AI coding tools produce insecure code?
Yes, regularly. Veracode's 2025 testing of more than 100 models found 45% of code samples failed security tests. Those samples introduced OWASP Top 10 vulnerabilities, in the 2025 GenAI Code Security Report. Java was the riskiest language, with a 72% failure rate.
What should a vendor provide at renewal?
Recent advisories with dates, adversarial test results, a version inventory of extensions and models, and named escalation contacts. Ask also for the threat model required by OWASP AISVS. That model covers misuse, prompt injection and dependency chain risk.
What this means for buyers
Start with the contracts already open. Pull the top three AI coding tools in use. Ask for their last advisory history and confirm whether extensions auto-update. Where the answers are thin, add the patch SLA, disclosure clock and evidence schedule at renewal.
Then fix your side. Publish an approved tool list, restrict rules file changes to reviewed pull requests, and keep the mandatory security gate on every branch. Buyers who can describe their own controls get better vendor commitments on AI coding tool security.
Before expanding seats, run a short pilot with adversarial tests and a written exit path. If you need specialist help, post your project and compare proposals from vendors who can show AI tooling security evidence rather than promises.
What this means for vendors
Expect buyers to ask for advisory dates, extension publisher controls and adversarial test results in the RFP. Prepare a one-page security annex with those facts. Be explicit about where your visibility stops, because honest scoping scores better than broad claims.
Finally, treat your marketplace accounts as production infrastructure. The Cursor incident came through a verified publisher account, and buyers will now ask who controls yours. Vendors that can answer that in the bid, with evidence, will win the security-minded deals. That is how a strong AI coding tool security answer turns into a commercial advantage.
Every claim above is one a buyer can test in a week. Ask for the dates, the test results and the named contacts. Then decide whether the seat count goes up.
- AI coding tools
- secure development clauses
- patch SLAs
- software supply chain
- vendor due diligence
- application security
Sources
The pages this article draws on.
- 1.Researchers find bugs in 5 AI developer tools, with OpenAI and Microsoft flaws still unpatchedtheregister.com
- 2.Anthropic VS code extension on Cursor backdoored for nearly 12 hours - Ars Technicaarstechnica.com
- 3.The Future of Application Security in the Era of AI - Checkmarxcheckmarx.com
- 4.AI-assisted coding security: a survey of 241 developers | Pentest-Tools.com Blogpentest-tools.com
- 5.1.0/en/0x92-Appendix-C_AI_for_Code_Generation.mdgithub.com
- 6.Secure Coding with AI - OWASP Cheat Sheet Seriescheatsheetseries.owasp.org
- 7.Insights from 2025 GenAI Code Security Reportveracode.com
The Scopelyst team
Written by the people who run the marketplace, from what buyers and vendors do on it. No guest posts, no sponsored articles.
