An AI coding tool is not an ordinary SaaS purchase. By design, it reads your source code, frequently runs inside your development environment, and sends data to a third-party model provider. That combination, deep access plus external data flow, makes it one of the higher-trust tools you will put in front of your engineers, and it deserves a security review built for what it actually does.
We help engineering organisations run these assessments, and the most common mistake is using a generic SaaS questionnaire. Those questionnaires ask good general questions and miss the ones specific to a tool that ingests your code and routes it through an AI model. This is the review we run, organised around the questions that actually change the decision.
Start by mapping the data flow
Before any questionnaire, answer one question concretely: when a developer uses this tool, where does your code go?
- What is sent to the vendor, and what stays local? Full files, surrounding context, the whole repository, or just the active selection?
- Does it transit a model provider behind the vendor (for example, a foundation-model API), and under what terms?
- Where is data processed and stored geographically? This determines which compliance regime applies.
- What is logged and retained, by the vendor and by any subprocessor, and for how long?
You cannot assess a risk you have not mapped. Most of the meaningful findings come from drawing this flow honestly, before anyone fills in a form.
The questions that actually matter
A handful of questions separate a tool you can trust from one you cannot. Get clear, written answers to these.
| Question | Why it matters | A good answer looks like |
|---|---|---|
| Is our code used to train models? | Training on your code can leak proprietary logic into outputs for other customers. | "No, not under your plan, contractually guaranteed", not "you can opt out in settings." |
| What is retained, and for how long? | Retention defines your exposure if the vendor is breached. | Short, configurable retention with a clear deletion path. |
| Who can access our data internally? | Vendor staff access is a real attack surface. | Least-privilege access, logged, with no routine human review of customer code. |
| Where is data processed and stored? | Determines GDPR and data-residency obligations. | Named regions you can choose, with EU options if you need them. |
| What subprocessors and model providers are involved? | Your data is only as protected as the weakest party in the chain. | A current subprocessor list with their terms, not "various partners." |
| What certifications do you hold? | Independent evidence the controls exist. | Current SOC 2 Type II or ISO 27001, with the report available under NDA. |
The pattern to watch for: vendors who answer training and retention questions by pointing at a settings toggle. A setting can be changed, defaults can shift, and a toggle is not a contractual guarantee. For a tool with this much access, you want the protection in the contract, not in a preferences pane.
Match the review depth to the deployment
Not every tool needs the same scrutiny. The right depth depends on what the tool can reach.
| Deployment | Access level | Review depth |
|---|---|---|
| Suggestions in the editor | Reads active context, suggests inline | Standard review: data handling, training, retention |
| Repository-aware assistant | Reads whole repositories for context | Deeper review: full data-flow map, subprocessor chain, residency |
| Autonomous agent with execution | Runs commands, touches CI, can reach production | Maximum review: the above plus credential scope, audit logging, kill switch, and human-gate design |
The further a tool can reach into your systems, the more its security review overlaps with how you would govern any privileged actor: scoped access, least privilege, full audit trail, and a tested way to stop it. A tool that only suggests text in an editor is a genuinely smaller risk than one that can open and merge pull requests, and your review effort should reflect that.
Do not skip the compliance overlay
For most European teams, the security review and the compliance review are the same conversation, and skipping the second leaves a gap that surfaces in an audit.
- GDPR. If your code or context can contain personal data, the vendor is a processor and you need a data processing agreement, a lawful basis, and documented residency. A security review that ignores this is incomplete.
- EU AI Act. Where the tool operates as part of a higher-risk workflow, human-oversight and record-keeping obligations attach to how you deploy it, not just to the vendor.
- Your own contractual commitments. Confidentiality terms you have signed with your customers may forbid sending their data to a third party at all. The tool's data flow has to be checked against those promises.
The point is not to add bureaucracy. It is that a tool which reads your code touches obligations you have already made to regulators and customers, and the review is where you confirm those promises still hold.
Turn it into a repeatable gate
A one-off review for one tool does not scale to an organisation where teams keep finding new tools. Make it a standard, lightweight gate.
- A short standard questionnaire built for AI tools specifically, not the generic SaaS one, that any team can run before adopting something.
- A clear bar: what a tool must clear to be approved, and what is an automatic no.
- An owner: a named person or team who signs off, so the decision is accountable rather than diffuse.
- A register of approved tools, so teams reach for something already vetted instead of quietly adopting whatever they found. The alternative is shadow AI, and it is far harder to govern after the fact.
This is the same move that works elsewhere in AI governance: make the safe path the easy path, so people do not route around it.
Our view
An AI coding tool earns a deeper security review than ordinary software because it has deeper access: it reads your code, runs in your environment, and sends data outward by design. The generic SaaS questionnaire was not written for that, and it misses the questions that matter: is our code used for training, what is retained, who can see it, where does it live, and who is in the chain behind the vendor.
Map the data flow first. Get contractual answers, not settings toggles, on training and retention. Match the depth of review to how far the tool can reach. Fold in the compliance obligations you already carry. Then make the whole thing a repeatable gate so it scales past the first tool.
Done well, this is not a blocker on adoption. It is what lets you say yes quickly and confidently, because you know exactly what you are trusting the tool with, and exactly where you drew the line.
Sources
- ISO/IEC 27001, information security management requirements, accessed 2026-06-11
- NIST,
AI Risk Management Framework (AI RMF 1.0), on third-party and data risk, accessed 2026-06-11 - EUR-Lex, Regulation (EU) 2016/679 (GDPR), on processors and subprocessors, accessed 2026-06-11
- Cloud Security Alliance,
Consensus Assessments Initiative Questionnaire (CAIQ), accessed 2026-06-11
Frequently asked questions
- How do you security-review an AI coding tool?
- Start by mapping the data flow concretely — what is sent to the vendor, what stays local, which model provider sits behind it, where data is stored, and what is retained. Then get written answers on training, retention, internal access, residency, subprocessors, and certifications, and match the depth of review to how far the tool can reach into your systems.
- What should you ask an AI coding tool vendor about data?
- Whether your code is used to train models, what is retained and for how long, who can access it internally, where it is processed and stored, which subprocessors and model providers are in the chain, and what independent certifications they hold. Insist on contractual answers on training and retention, not a settings toggle that can change.
- Is a standard SaaS security questionnaire enough for AI coding tools?
- No. A generic questionnaire asks good general questions but misses the ones specific to a tool that reads your source code and routes it through an AI model — training use, retention, model-provider subprocessors, and data residency. Use a questionnaire built for AI tools, with depth that scales to how much access the tool has.
- Do AI coding tools need a GDPR review?
- For most European teams, yes. If your code or context can contain personal data, the vendor is a processor and you need a data processing agreement, a lawful basis, and documented residency. The security review and the compliance review are effectively the same conversation, and skipping the second leaves a gap that surfaces in an audit.
