Most agencies and contractors now have a generative AI (GenAI) policy. Far fewer can tell you what their people are actually running.
That gap has a name. Like shadow information technology before it, Shadow AI is what happens when AI tools, services, and components enter an organization outside the processes meant to govern them. The difference is that shadow IT mostly showed up as an unapproved application.
Shadow AI can create risk at three points:
Data that leaves your environment.
AI-generated code your developers commit.
AI models and other components your builds pull down.
Those three are usually discussed as one risk. They are not. They have different failure modes, different owners, and almost no overlap in the controls that address them. An organization can have an excellent acceptable-use policy and still have no idea which AI models are running inside its own software.
None of which is an argument against adoption. The productivity gains are real, and the organizations getting the most from these tools are not the ones that tried to ban them. They are the ones that made the sanctioned path the easiest path to take. That only works if you can see which path people are actually taking.
Here is what each problem is, who owns it, and what closes it.
Verizon's 2026 Data Breach Investigations Report found that 45% of employees are now regular users of AI on corporate devices, authorized or not — up from 15% a year earlier. Two thirds of those users accessed AI services through non-corporate accounts, which means the activity is largely invisible to the organization paying for the device.
Shadow AI is now the third most common non-malicious insider action in the report's data loss prevention findings. And the most common category of data sent to external AI services is source code.
That last detail is the one worth sitting with, because it connects all three problems. Source code leaving is a disclosure problem. The same assistant that received it returns code and dependency choices that come back in. And the models behind these tools increasingly arrive as components inside your own applications.
One behavior, three exposures.
This is the problem most policies already address, and the one most people mean when they say Shadow AI. An employee pastes contract language, personnel data, or controlled unclassified information (CUI) into a public chatbot to summarize or rewrite it.
Ownership: Security and privacy teams, records officers, and acceptable-use policy owners.
Controls: Provide a sanctioned platform people prefer, use data loss prevention and network controls, name approved services, and give staff practical guidance.
Verizon's findings show why prohibitions alone may not work: employees may turn to personal accounts, moving AI use further out of view rather than stopping it.
For Department of War (DoW) components, this is already written down. DoW Instruction 8430.01 bars entering non-public departmental information into generative AI services unless the service resides on departmental systems and is approved for departmental use. Both conditions, not either.
What does not close it: anything in your software supply chain toolchain. No repository control, bill of materials, or scanner sees a developer paste code into a browser. If a vendor tells you otherwise, press on exactly which telemetry they are reading.
Your developers are using coding assistants. The output is unverified input, and the accountability for it does not transfer to the tool that produced it.
DoWI 8430.01 is explicit on this point for defense work: AI-generated code is treated as unverified, and developers and their teams remain fully accountable for what they ship. It also asks software efforts to maintain a record of the models, versions, and significant datasets used to generate or test software, kept with the software evidence package and treated as analogous to a software bill of materials (SBOM).
The subtler issue is that a coding assistant does not only write code. It chooses dependencies. An assistant suggesting a package is making a supply chain decision on your behalf, at a speed and volume no review process was designed for, which is a different problem from whether the code it wrote is correct. We covered that specific question in more depth earlier this month.
Who owns it: engineering leadership and application security.
What closes it is treating assistant output as you would a pull request from an unfamiliar contributor. Human review, software composition analysis (SCA) on everything it introduces, and a record of which models were in the loop, which is both a DoW requirement and the only way to answer the question later.
The third problem is the least discussed and the hardest to see after the fact: AI models and machine learning packages entering your environment as components.
Sonatype calls components retrieved straight from public repositories, bypassing the repository manager, shadow downloads. Sonatype Research Labs audited 9,658 Hugging Face requests across a set of customers in the first half of 2026, as part of our Beyond Traditional Packages report. Nearly 7% were blocked or rejected by policy. Of the 674 models blocked, 55% were stopped on model acceptability and 18% on security grounds, which says models are raising governance questions traditional policies were not built for.
A model is not like a library. It arrives as opaque weights, it may carry a license with terms on how its output can be used, and its published name tells you very little about what it was built from — open models are routinely fine-tuned, merged, quantized and re-released under a new publisher. Three federal exclusion orders now name a single model developer and reach products "developed using" its implementations, which makes model provenance a procurement question and not only an engineering one.
Who owns it: platform engineering and whoever runs your repository manager.
What closes it: one governed path in. Route model pulls through a proxy repository so every request is visible in one place, block direct downloads from the corporate network, and lock client configuration so the path cannot quietly be bypassed. Sonatype Firewall can then audit or quarantine models at that boundary before a developer gets them. Start in audit mode to see what your teams are actually pulling, then move to quarantine. At scan time, Sonatype Lifecycle flags a model as a derivative and names the foundation model it came from, and the AI Models Usage dashboard shows which applications are using models, with lineage, commit hash and publishing date.
That last piece matters for a reason beyond engineering. Joint guidance on AI and machine learning supply chain risks, co-sealed by the National Security Agency and seven other national agencies, tells organizations to require an AI bill of materials from vendors as a condition of procurement. Asking your suppliers for something you cannot produce yourself is a difficult position to hold.
Pick your lane. These are three different jobs and they rarely belong to the same person.
If you own policy. Name specific sanctioned services rather than categories, and pair the policy with a platform people prefer to the alternative. Then confirm your inventory obligation is being met. OMB Memorandum M-26-05 makes each agency head responsible for the security of software on the agency network and directs agencies to maintain a complete inventory. Models are software.
If you own compliance. The obligations people associate with the Cybersecurity Maturity Model Certification (CMMC) did not go away when Phase 2 was suspended. DFARS 252.204-7012, NIST SP 800-171 and Supplier Performance Risk System scoring are unchanged, and annual affirmations remain in effect. An attestation that does not match the environment is the exposure, and that gap is exactly what undeclared AI tooling creates.
If you own the platform. Start with visibility, not enforcement. Put a proxy in front of model pulls, turn Sonatype Firewall on in audit mode, and spend two weeks looking at what comes back before you block anything. Most teams are surprised, and the surprise is the business case. Then make it continuous — an inventory taken once begins decaying the day it is produced, and the reason to route intake through a single path is that the record maintains itself rather than becoming an annual exercise.
Shadow AI is no longer a question of whether people will adopt these tools. They already have. The question is whether you can identify:
Which services receive your data.
Which models help write your code.
Which models run inside the software you ship.
Three questions, three owners, one answer: you can only govern what you can see.
See how Sonatype helps federal teams govern the AI models and open source components entering their software.