The sprawl you can't see
Shadow IT used to mean a marketing team expensing a SaaS subscription that never crossed your desk. Shadow AI is the same instinct — people routing around IT to get work done — but the blast radius is far larger, because the cost of building software has collapsed.
When anyone with a coding-assistant subscription can stand up a working application in an afternoon, the number of unsanctioned tools no longer scales with the size of your engineering team. It scales with your headcount. A finance analyst wires a dashboard straight into the data warehouse. A marketer builds an automation that emails customers through a language model. A legal-ops associate pastes contracts into a script for summaries. None of it appears in a ticket queue, an architecture review, or a budget line.
The hazard is not the experimentation. Most of it is genuinely useful, and banning it outright simply pushes it onto personal devices and out of sight. The hazard is invisibility: data flows, dependencies, and failure modes that no one has reviewed and no one owns. A rogue SaaS tool at least had a vendor behind it. A vibe-coded internal app often has only its creator — who may have changed teams or left.
Why you can't scan your way out
The reflexive answer is to buy a scanner. But shadow AI is invisible almost by definition, and the riskiest instances are the ones a code scanner will never see: a non-engineer's automation running in a personal cloud account, a spreadsheet wired to an LLM, a workflow in a no-code tool. If you wait for a tool that can enumerate all of it, you will wait forever and act on nothing.
A better model is the one security teams have always used for shadow IT: triage, not census. You do not need a complete inventory to act. You need to surface the items that matter and decide what to do with each. Completeness is a trap; time-to-disposition is the real metric.
A four-move audit
Move 1 — Size it from seats you already pay for
You already hold a powerful signal: the seats you are billed for. Add up your GitHub Copilot, Cursor, Claude, and ChatGPT licenses, and note how many belong to people who are not engineers — that cohort is where the riskiest, least-reviewed building happens. A rough planning heuristic (a modest fraction of seat-holders produce something lasting, weighted up for non-engineers) gives you a denominator: an estimate of how many durable shadow builds probably exist. Six known tools against an estimate of sixty is a very different conversation than six against eight.
Move 2 — Surface what you can't see with an amnesty
Because you cannot scan, delegate discovery to the people who already know. Run a short, no-blame disclosure survey — six questions is enough: what did you build, with which tool, what data does it touch, who uses it, how important is it, and who owns it. Frame it as an amnesty: anything registered during the window is in the clear. The connection here is social, not technical, and it consistently surfaces more than any scan, because it asks the only people with ground truth.
Move 3 — Score by exposure, not by gut
Once items are on the table, score each on the dimensions that actually drive risk: the sensitivity of the data it touches, its blast radius (just the builder, a team, a department, customers, the public), its maturity (prototype, in real use, business-critical), whether it has been reviewed, who owns it and whether they are still around, and where it runs. No single dimension is decisive — risk concentrates where several stack up. A prototype on synthetic data is fine; a business-critical onboarding form that writes customer PII to your CRM, built by someone who has since left, is a fire.
Move 4 — Assign a disposition
Scoring is only useful if it ends in a decision. Give every item one of four dispositions:
- Sanction & Adopt — low risk, useful: bless it, give it an owner, move on.
- Contain & Monitor — medium risk: keep it, but add guardrails and a review.
- Sunset — high risk, replaceable: migrate off and retire it.
- Rebuild Properly — high risk and depended upon: you need it, so route it through the real lifecycle.
The combination of risk and maturity points to the disposition: high risk plus business-critical means rebuild; high risk plus prototype means sunset before it spreads.
Make it a standing practice
The register is not a one-time spreadsheet; it is a living artifact. Re-open the amnesty each quarter, because the population of builders grows every time you add a seat. Track time-to-disposition, not completeness. The point is never to have catalogued everything — it is to ensure nothing risky sits unowned and unreviewed for long.
Start
The Shadow AI Exposure Register runs this audit end to end — the seat baseline, a generated disclosure survey, exposure scoring, and a disposition for every entry — entirely in your browser, so you can assess your exposure without sending a single app name to anyone. Pair it with the AI Coding Governance Policy Builder to set the rules that keep the next wave of sprawl in the green zone.