Your AI code policy covers approved tools. The harder question is whether every change faces the same evidence-backed review, regardless of what wrote it.
Shadow AI is no longer a vague compliance concern. It describes employees using AI systems outside an organization's approved controls. The result can be both data exposure and software entering production without a consistent review record. That second problem matters even when the code looks ordinary.
A note on sourcing: the figures below come from a mix of primary surveys and industry roundups, and each is attributed to the publication that states it. Shadow-AI measurement is still thin, so treat the percentages as directional signals rather than settled numbers.
The visibility gap is larger than most programs assume
Airia's 2026 overview collects findings from named third-party studies: source code represented 35% of sensitive-data events involving AI tools in Cyberhaven's 2024 data; 60% of security teams lacked visibility into which AI tools employees used, per Cisco's 2024 AI Readiness Index; and Gartner reported in 2025 that 43% could not audit or inventory the AI tools in use.
A separate JumpCloud summary reports widespread unsanctioned assistant use. Survey percentages are useful warning signals, but they don't establish which tool authored a given line in your repository. That distinction matters when choosing a control.
Source code creates two different shadow-AI risks
Input risk appears when proprietary code, secrets, customer data, or architecture details are sent to an unapproved service. That requires controls such as approved-tool policy, identity and endpoint management, DLP, vendor review, and data-retention rules.
Output risk appears when generated code is accepted because it looks plausible, or enters through a workflow that never receives equivalent quality, security, and compliance checks. This is the part a repository and release review layer can address directly.
Govern the output without pretending the tool is invisible
Banning unsanctioned tools doesn't guarantee compliance, but governing only the output doesn't solve data leakage either. A durable program needs both: discover and control the tools where possible, then require the same review bar for every software change regardless of authorship.
This avoids a fragile "detect AI code, then review it differently" path. Pull requests, direct commits to the default branch, and pre-PR local diffs can all enter through different routes. The control should follow the change.
What an AI-BOM can, and cannot, tell you
Dromeas generates an AI Bill of Materials when a product actually invokes AI or machine-learning systems: a machine-readable CycloneDX 1.6 ML-BOM plus a human-readable report covering detected AI/ML components, data flows, risk classification, EU AI Act obligations, and source-backed provenance. For multi-repository products, the documentation process assembles evidence across the whole product rather than treating each repository as an isolated system.
That's an inventory of AI/ML components used by the software. It is not a forensic attribution system for which coding assistant wrote each line, and it doesn't calculate a trustworthy percentage of AI-authored code. It complements workforce AI-tool inventory, DLP, endpoint controls, and an AI-use policy; it doesn't replace them.
A practical first step
- Inventory the services: use identity, network, endpoint, procurement, and expense data to find unapproved AI tools.
- Protect the inputs: define what code and data may be sent to each approved service, and enforce it with technical controls.
- Standardize the output gate: review PRs, trunk commits, and local agent diffs against one policy.
- Record what shipped: keep review and release evidence, and generate an AI-BOM for software that contains or invokes AI/ML components.
Shadow AI can't be solved by one inventory or one scanner. It becomes governable when tool controls and change-level evidence meet at the release boundary.
Full piece, with more on Dromeas's changed-code and blast-radius review pipeline (independent Security, Quality, Compliance, and Bug Tracing analysts) plus AI-BOM documentation, originally published at dromeas.ai: https://dromeas.ai/blog/shadow-ai-in-your-codebase
Top comments (0)