Shadow AI coding tools: folding them into a rollout
Stefan-Iulian Tesoi · · 6 min read

Find out what people use, on which accounts and for what, before writing any policy, then make the official path easier than the unofficial one. Shadow AI coding tools are a visibility problem before they are a tool problem, and the developers already using them know where agents break in your codebase before any pilot has started.
What counts as shadow AI coding tools?
Any AI tool that touches company code or data under an account, key or contract the company does not know about. The tool itself is rarely the problem. The account it runs under is.
The same Claude Code binary runs under Anthropic's Consumer Terms on a personal subscription and under its Commercial Terms on a company plan or the API. Anthropic's consumer terms update of August 2025 applies to "Claude Free, Pro, and Max plans, including when they use Claude Code from accounts associated with those plans", and lets each user decide whether their sessions train future models. Data is kept for five years if they allow it and 30 days if they do not. That choice is the developer's, not the company's.
| Form | Typical example | What the company cannot see |
|---|---|---|
| Personal chat account | A stack trace and failing function pasted into ChatGPT | What was sent, under whose terms |
| Personal agent subscription | Claude Code or Cursor on the developer's own card | Which repositories it read, which settings were on |
| Personal API keys | A key in a shell profile, billed privately | Spend, and who holds the key after they leave |
Personal API keys are the subtle case. OpenAI states that data sent to its API "is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)", so a private key can be better on training than a consumer chat account. The contract is still the developer's, and the key leaves when they do.
Why does a ban push usage out of sight?
Because it removes the reasons to mention the tools and none of the reasons to use them.
The 2025 Stack Overflow Developer Survey found 84% of respondents "using or planning to use AI tools in their development process", and 51% of professional developers using them daily. In its questions on AI agents, 28.2% agreed that "My company's IT and/or InfoSec teams have strict rules that do not allow me to use AI agent tools or platforms" (13.8% strongly, 14.4% somewhat). It does not say how many people sit in both groups, so neither figure should be subtracted from the other.
Microsoft and LinkedIn's 2024 Work Trend Index, a survey of 31,000 knowledge workers in 31 markets rather than of developers, found "78% of AI users are bringing their own AI tools to work", and that 52% of people using AI at work "are reluctant to admit to using it for their most important tasks."
A ban turns that reluctance into policy. Developers using AI without permission keep using it on a personal laptop or phone, outside single sign-on and any audit trail. The company loses the three things it most needed: which code left, under which terms, and which commits were written with help.
A ban does not reduce how much code reaches an AI vendor. It reduces how much of it you know about.
Three questions to ask before writing a shadow AI policy
Which tools on which accounts, what went into them, and what came out. A policy written before those answers exist regulates a guess.
- Which tools, on which accounts? The account type matters more than the tool name: personal consumer account, personal API key, or company seat. Three developers on Cursor with Privacy Mode on present a different exposure from one pasting into a free chat account.
- What went in? Source code is the usual answer and the least of it. Secrets from a
.envfile, customer records in a test fixture and production logs change the plan, because a leaked secret has to be rotated whatever else is decided. - What came out? Which commits, scripts and migrations were produced with help. Not for blame: their review may have assumed a person wrote every line.
Ask in writing, collect the answers in aggregate, and state the amnesty before the first question. Tracking usage per person ends the conversation fastest, for the reasons in who resists coding agents, and why.
How do you turn unofficial users into the pilot?
Make them the pilot team, move them onto company accounts first, and ask what they already know. A coding agent rollout starts with one team and one repository, and the people already using agents are the obvious first team.
- Bring their setup into the repository. A CLAUDE.md, a
.cursor/rulesfile or a reused prompt is reviewable once committed and invisible in a home directory. - Use their history as the baseline. The first two weeks of an agent pilot count items executed without a human edit. Unofficial users can say in an hour which kinds of item they stopped handing to an agent, and why.
- Replace personal seats in week one. A company seat carries settings the company chose. Cursor's Privacy Mode "can be enabled in settings or by a team or enterprise admin", and new team members inherit it. Claude Code's managed settings override a developer's own, with a few documented exceptions.
Unofficial work does not stop on the day the rollout starts. In Laimonade, once a repository is tracked, a pushed commit that matches no backlog item becomes a drafted item in In Review, so work done outside the backlog reaches a person instead of going unrecorded.
What must stop on day one, and what can wait?
Anything that puts secrets or customer data into an account the company has no contract with stops on day one. Nearly everything else can wait for the pilot's evidence.
| Practice | When | Why |
|---|---|---|
| Secrets or customer data in personal accounts | Stop now | The exposure grows with every session |
| Personal API keys in CI or committed scripts | Stop now | They leave with the person who owns them |
| Choosing one standard tool | After the pilot | The pilot shows which one fits the work |
| A full acceptable use policy | After the pilot | It should describe practice, not guess at it |
The acceptable use policy can then be a page: which accounts are approved, what may never be sent, and that agent-assisted work traces to an item and a person. Getting the first tool through review is covered in getting security review approval, and the vendor questions behind it in AI vendor data handling.
Frequently asked questions
Is code pasted into a personal chatbot account a security incident?
It depends on what was pasted. Ordinary source code with no secrets is a policy gap to close, and treating it as an incident teaches people to stop telling you. A credential is different: treat it as leaked and rotate it the same day. Customer personal data goes to whoever handles data protection.
Should developers be reimbursed for tools they bought themselves?
Reimburse the past if the budget allows, but not a personal subscription going forward. A reimbursed personal account is still a personal account, with consumer terms and settings the company does not control. Move the developer onto a company seat instead, which turns the spend into something the company can see.
Do you need an amnesty to get honest answers?
Yes, in writing and before the first question. Without one, the rational answer to "do you use unsanctioned AI tools" is no, and the survey measures fear rather than usage. State that nothing disclosed by a named date leads to disciplinary action, and that the aim is moving people onto company accounts.