Most security teams meet an AI coding assistant the same way: someone in engineering asks, security asks what happens to the source code, nobody has a confident answer, and the request stalls. Six months later the tool is in use anyway — on personal accounts, outside SSO, with no logging and no policy.
Blocking it did not prevent adoption. It prevented visibility into adoption.
That is the actual choice in front of you. Not whether developers will use these tools, but whether the version they use is the one you configured.
Why the usual objection is the wrong shape
The objection is almost always framed as a model question: where does our code go, and is it used for training? That is a real question, and vendors answer it in their enterprise tiers. But it is answerable in an afternoon, and once answered the approval still does not happen — because the model was never the risky part.
The risky part is that a coding assistant inherits every permission of the developer using it. It sees the repository they can see. It reads the files they can read. If it is wired into your issue tracker or your internal documentation, it reaches those too. You are not adding a model to your estate. You are adding a very fast, very literal actor that operates with a human's access and none of a human's hesitation.
Framed that way, it stops being a procurement question and becomes an access-and-evidence question — which is a problem your organisation already knows how to solve.
The four controls that actually settle it
1. Decide who gets it, deliberately
The default rollout is "everyone with a licence", which is not a decision, it is an absence of one. Scope entitlement the way you would for any system that reaches source code: which teams, which repositories, which environments.
The useful conversation is not who wants it but whose access would we be uncomfortable seeing amplified. A contractor with broad read access across repositories is a different proposition from a permanent engineer on one product. Same tool, different exposure.
2. Write an acceptable-use policy you can actually enforce
Most AI usage policies are aspirational documents that say "use good judgment" and are never referenced again. A policy is only worth writing if a specific person can point at a specific line when something goes wrong.
A usable one is short and concrete: what categories of data must never be pasted into a prompt, what code requires human review before merge regardless of who or what wrote it, and what happens when the assistant produces something the developer does not understand. That last one matters more than it sounds — the most common real failure is not a leak, it is confidently wrong code that passed review because it looked fluent.
3. Harden the platform away from its defaults
Enterprise tiers ship with settings that favour adoption over control. Go through them explicitly rather than accepting the shipped state: which repositories are indexed, whether public code suggestions are permitted, what telemetry leaves the tenant, how the tool authenticates.
This is unglamorous and it is where most of the actual risk reduction lives. It is also the step most often skipped, because it produces nothing to show a steering committee.
4. Log it like production
If you cannot answer who used it, when, and against what six months from now, you have not deployed a governed tool — you have deployed an unmonitored one with a purchase order attached.
Usage logging is what converts every other control from an assertion into something you can evidence. It is also what lets you retire the argument entirely: when the next question comes ("is anyone actually using this?"), you answer it with data instead of opinion.
The agent problem is the same problem, multiplied
Coding assistants are the easy case. The harder one arrives when the same vendor ships a tool that lets non-engineers build their own agents.
At that point the security question stops being about one product and becomes about hundreds of small ones, built by people who do not think of themselves as developers and who will not come to you for review. Data handling, authentication, and logging have to be settled on the platform, before general availability — because retrofitting governance onto agents that already exist means auditing work you did not know was happening.
If your organisation is anywhere near enabling agent-building, do that groundwork first. It is the same four controls, applied one layer up, and it is enormously cheaper before launch than after.
What approval looks like when it works
The outcome is not a signed exception. It is that the tool is entitled to the right people, governed by a policy someone can cite, configured deliberately rather than by default, and producing an audit trail.
At that point the interesting shift happens: security stops being the function that says no to AI tooling and becomes the function that makes it deployable. That reputation is worth considerably more than the one rejection it replaces — because the next tool is already on its way, and you would rather hear about it early.
Where to start
If you are staring at a request right now, in order:
- Ask what access the assistant inherits, not what the model does with the data.
- Scope entitlement before you negotiate licence counts.
- Walk the enterprise settings and write down every default you changed and why.
- Turn on logging before the first user, not after the first incident.
None of that requires a new tool, a new budget line, or a research project. It requires treating a coding assistant as what it is: a new identity with your developers' access, which is a category your organisation has governed for years.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.