Shadow IT is software or services used for work without the organization's knowledge or approval. Shadow AI is the same thing for AI tools and models. Shadow dependencies are packages, images or scripts that reach production without passing a review. All three are gaps between what you approved and what is actually running.
Three terms, one underlying problem
The words get mixed up in meetings, so it helps to pin them down. The common thread is that someone made a reasonable local decision (ship the feature, fix the build, save an hour) and nobody recorded it.
| Term | What it is | Typical engineering example | Where it shows up |
|---|---|---|---|
| Shadow IT | A service or app used for work without approval | A team signs up for a hosted tool with a work email | Single sign-on logs, OAuth grants, expense reports |
| Shadow AI | An AI tool, model or API used without review | A developer pastes code into a chat tool, or a service calls a model API with a personal key | Repo search, network egress, API key inventories |
| Shadow dependency | A package, image, action or script not on your approved path | A lockfile entry that points at a git URL instead of the registry | Lockfiles, Dockerfiles, CI workflows |
None of these require bad intent. Most are found because the person who added them was trying to help.
Why engineering orgs have more of it than they think
Engineers can create value alone. A developer can add a package in one line, pull a container image in another, and wire a hosted service into a pipeline before lunch. Each action is small. Added up over a year across dozens of teams, the result is an estate nobody has fully listed.
AI makes this faster. A model API needs only a key and an HTTP call, and a coding assistant can suggest packages the team has never seen. OWASP's guidance on LLM supply chain risk recommends keeping an up-to-date, signed inventory of components and treats models and datasets as part of that supply chain, not as something separate.
What each one actually risks
Be specific about the risk, or the conversation turns into a ban-or-allow argument. For shadow IT, the usual concern is that a third party now holds company data or has access to repositories. GitHub's documentation notes that without OAuth app restrictions, any OAuth app authorized by an organization member can also access the organization's private resources.
For shadow AI, the concerns are data leaving through prompts, unreviewed model files, and keys that nobody can revoke because nobody knows they exist. For shadow dependencies, it is the plain old supply chain question: who published this, was it reviewed, and will we hear about its next advisory?
How to find each one
You do not need a new program to start. You need three searches.
- Shadow IT: list the third-party apps with access to your identity provider and your source host. See how to see which OAuth apps can reach your GitHub org.
- Shadow AI: search repos for AI client libraries and API hostnames, and for model files. See how to find AI SDK usage across your repos.
- Shadow dependencies: compare lockfile contents with your approved list. See how to find unapproved dependencies in your repos.
Write down what you find in one list, with an owner for each entry. An entry with no owner is the real finding.
Try it yourself
Open the dependency inventory demo and look at how a single project expands into direct and transitive packages. The transitive rows are where most shadow dependencies hide.
Click through it at your own pace, or open it full screen.
Quick check
Is shadow IT always a policy violation?
Not always. Sometimes there is simply no approved option, or the approval path is too slow. Treat the first finding as a signal about your process before treating it as a conduct issue.
Is a package from the public registry a shadow dependency?
It is if it never went through whatever review your team has defined. If your policy is that every package must be on an approved list, then an unlisted package counts, however popular it is.
Where should we start?
Pick the cheapest search first: a repo search for lockfile entries that do not come from your approved registry. It takes minutes and gives you a real list.
Safeguard supports this work with asset discovery, SBOM and dependency scanning, and policies and gates. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
