AI Coding Assistant Security Review — A Checklist Before Rollout

An AI coding assistant reads your source. That single fact is what makes the security review non-optional, and it is why teams that pick a favorite before involving security frequently have to unpick the decision later.

The questions are predictable enough to answer in advance. Working through them before the trial costs an afternoon. Working through them after costs a rollout.

What leaves the machine

Start here, because everything else follows from it. Which of these is transmitted, and when:

• The open file, or the whole repository as context?
• Filenames and directory structure, which frequently leak more about architecture and unreleased products than the code does?
• Terminal output, environment variables, or anything visible in the working directory?
• Prompts and the code generated in reply?

Agent-style tools that operate across a repository necessarily see more than a completion tool watching one buffer. That is not a flaw, but it changes what you are approving.

Retention and training

Two separate questions that vendors sometimes blur.

Retention: how long is your code held, where, and can you require deletion? "Not stored" and "stored transiently for processing" are different answers with different implications.

Training: is your code used to improve models? Business and enterprise tiers routinely exclude this while consumer tiers routinely do not. Confirm which tier your license actually is, because the difference is usually a plan setting rather than a different product, and it is easy to end up on the wrong one.

Secrets

Assume a secret will end up in context at some point, because it will. What you want to know is what happens next: whether the vendor filters credentials before transmission, whether they appear in any retained log, and what your own detection would catch.

This is also a prompt to check your own house. If a hardcoded credential in a config file is a catastrophe when an assistant reads it, it was already a catastrophe waiting for a laptop to be stolen.

Generated code and licensing

Assistants trained on public repositories can reproduce recognizable code. The practical exposure is small but non-zero, and the mitigations are worth confirming: whether the vendor filters output matching public sources, whether they offer any indemnity, and whether your own review would notice.

If you ship anything under a license with obligations, this belongs in the review rather than in a footnote.

Access and offboarding

Who can enable it, on which repositories, and what happens when someone leaves? Per-seat tools have a license to reclaim. Usage-based tools have credentials to revoke, and those are easier to forget precisely because there is no seat sitting visibly unused.

If the tool integrates with your source host, check what scopes it requested. Broad read access granted once and never reviewed is a common finding in audits.

Where the tool runs

Terminal-based tools like Claude Code run wherever the developer runs them, including on machines you may not manage. Editor-based tools are constrained by the editor. Browser-based environments like Replit move the code off local machines entirely, which is either the point or a blocker depending on your posture.

None of these is inherently safer. They are different shapes, and your existing controls fit some better than others.

Getting a decision

Bring security in at trial scoping, give them the vendor's documentation rather than the marketing site, and ask for a decision on a specific tier and configuration rather than on "AI assistants" in general. Vague questions get vague refusals.

To weigh policy constraints alongside capability and rollout, the AI Coding Assistant Finder treats procurement and security review as a first-class constraint rather than an afterthought.