The question that ends most AI governance meetings in 2026 is the same one that ended cloud governance meetings in 2016: how many do we actually have? In 2016 it was unsanctioned SaaS accounts. Today it is models. Open weights pulled from a hub during a hackathon. Fine-tuned variants checked into a research bucket. A small classifier that an engineer embedded inside a microservice because it shaved 80 milliseconds off a hot path. Each of these is a production AI asset by any reasonable definition. None of them appear in the inventory the security team keeps.
Shadow AI is not a moral failing on the part of engineers. It is the predictable outcome of three trends colliding. Model artifacts are easy to acquire. Inference is cheap enough that almost any service can host a small model in process. And the productivity gains from doing it without asking anyone are large enough that nobody is going to wait for a review.
What "shadow" actually means here
The phrase shadow AI gets used loosely. It is worth being precise. A shadow model is any model artifact that is loaded by production code without being represented in the asset inventory the security and platform teams maintain. That definition covers several distinct cases.
The first case is the obvious one. A team downloads a public checkpoint, bakes it into a container image, and deploys it. Nobody outside the team knows the model is there. Provenance is whatever metadata the hub provided, often nothing. The risk surface includes weight tampering, license drift, and sometimes embedded code paths that execute on load.
The second case is more subtle. A team uses a managed inference API for a "real" model, but also loads a small local model for preprocessing, embeddings, or classification. The big model is governed. The small model is invisible. Most embedding models in production today fall into this category.
The third case is the hardest to find. A vendor library that the team thinks of as a normal dependency includes a bundled model. The team did not choose to use AI here. They added a feature to their service and the AI came along for the ride.
Why traditional discovery misses these
The standard cloud asset discovery stack does not see models. Cloud inventories list compute, storage, and network. Container scanners list packages and CVEs. SCA tools list dependencies. None of these treat a model artifact as an asset class with its own identity.
The closest existing tool, container image scanning, will see the file but report it as a generic blob. There is no model card attached. There is no version, no source registry, no training data lineage. The artifact is one of millions of unidentified files in the image. From the scanner's perspective, a 4 gigabyte set of model weights and a 4 gigabyte tarball of test fixtures are equivalent. They are bytes.
Source code analysis does slightly better but only for the cases where engineers explicitly call a model loading function in a recognizable framework. Code that pulls weights via an unusual loader, or that downloads them at runtime from a private mirror, falls outside the heuristic.
The result is that AI assets are systematically underrepresented in every inventory built from non-AI primitives. You can audit your container images for two weeks and still miss every model in production.
Signals that actually find shadow models
Useful discovery starts from signals that are specific to AI artifacts rather than generic files. Several of them are practical to collect at scale.
File format and magic bytes. Common model formats, safetensors, ONNX, GGUF, TorchScript, pickled state dicts, all have recognizable headers. A scanner that knows these formats can flag any file in an image, repo, or bucket as a candidate model regardless of where it came from. False positives exist, but they are tractable.
Loader call sites. Static analysis can identify call sites that load models, including the framework specific functions and the lower level deserialization patterns that custom code uses. These call sites are concentrated enough that an analyzer can list them across a monorepo in minutes.
Runtime introspection. Once a process is running, the loaded model can be observed. Memory mapped files in known formats, framework specific runtime registries, and accelerator memory allocations all leave traces. Sidecar agents and eBPF probes can collect these without modifying the application.
Network telemetry. A service that pulls weights from a known model hub during startup is almost certainly loading a model. Egress logs, image build provenance, and pip install logs all carry this signal.
Each individual signal is noisy. Combined into a single discovery pipeline, they produce a high quality inventory of model artifacts, including the ones that no engineer remembered to declare.
Building this without antagonizing engineers
The thing that breaks shadow AI programs is not technical. It is political. If discovery is positioned as enforcement, engineers will route around it. If it is positioned as inventory, the same engineers will help you build it because they want their work to be findable later.
A few patterns help. Make declaration easy and lightweight. A model.yaml file checked into the repo or a registry call from the loader is far less friction than a ticket. Treat undeclared models as a finding, not an incident. Most of the time the engineer simply did not know the inventory existed. Surface the model in the same place that vulnerabilities and license findings live so it is part of the normal review flow, not a separate ceremony. And tie the discovered models to ownership through SCM blame and deployment metadata so the right team gets the followup automatically.
The point of the program is not to catch people. It is to make sure that when a model has a license issue, a known compromised provenance, or a vulnerable training data path, you can answer the question "where is it?" in seconds rather than days.
What an AI-BOM gives you that scanning does not
An AI bill of materials is the data structure that turns shadow AI discovery into something usable. For each model in inventory, the AI-BOM captures the artifact identity, the source registry, the version, the license, the provenance signals available at acquisition time, the training data references where they exist, and the services that load it. With that data structured, every governance question becomes a query rather than a project.
Which services run a model from a now untrusted publisher. Which models were trained on a dataset that contains a contested license. Which fine tunes inherit weights from a base model with a known watermark. None of these questions are answerable from a flat list of file hashes. All of them are answerable from an AI-BOM.
How Safeguard Helps
Safeguard discovers shadow AI models through the same continuous asset discovery pipeline that builds the rest of your inventory. Container images, repos, registries, and runtime workloads are scanned for model formats, loader call sites, and runtime signals, and the discovered artifacts are reconciled into a single AI-BOM that lives next to your software SBOM. Each model carries provenance, license, source, and ownership metadata, so the question "what AI is in production" stops requiring a survey.
The AI-BOM ties models to the services that load them, the agents that call them, and the MCP servers that expose them, so a finding on a model surfaces immediately in the context of what depends on it. The MCP registry rounds out the picture by giving you a unified view of every tool and server in your agent ecosystem, ensuring shadow AI cannot hide behind an unregistered server. Continuous discovery, AI-BOM, and the MCP registry together turn shadow AI from a recurring audit problem into a tracked, governed asset class.