Code-only scanning misses models that are published privately, pulled directly from a hub, or fine-tuned and stored outside a repository. That creates blind spots for shadow AI, hidden license exposure, and models that were disabled upstream but remain in use downstream. Without a model inventory, teams cannot reliably tell what exists, who uses it, or whether it is still acceptable.
Why code-only scanning misses the real AI inventory problem
Code scanning tells you what is referenced in repositories, not what is actually in use across the environment. AI models can arrive through private publishing, direct hub pulls, notebook exports, packaging artifacts, or fine-tuned copies stored outside source control. The missing control is inventory, because inventory is what gives teams a reliable list of approved models, owners, locations, and retirement state.
That gap changes the security picture in a way code scanning cannot correct. A model can be live in a workflow, used by a downstream team, or embedded in a service long after the repository that first referenced it has moved on. Without model-level discovery, teams lose visibility into model provenance, version drift, and whether the model is still sanctioned for use.
It also means AI governance decisions are being made on partial evidence. If the only thing you scan is code, you can miss models that were disabled upstream but remain available downstream, or privately published models that were never in a repo at all. An AI-BOM becomes useful here because it records the model itself, not just the code path that reached it.
What inventory reveals that code review cannot
A separate model inventory answers four questions that code scanning does not reliably answer: what models exist, where they are deployed or cached, who owns them, and whether they are still approved. That is especially important when models are fine-tuned copies, external artifacts, or hub-sourced assets that can outlive the repository that fetched them.
Inventory also exposes hidden operational dependencies. One team may believe a model was removed, while another team still consumes a cached version, a private fork, or a container image that packaged the model earlier. In practice, this is where shadow AI appears: not as a dramatic new system, but as an untracked model path that keeps serving production or internal users.
A useful model inventory therefore includes provenance, versioning, ownership, deployment targets, and retirement status. The AI Infrastructure Workload Identity Guide is relevant because models are often tied to pipelines, registries, inference endpoints, and other runtime components that must be tracked together, not as isolated code references.
Why blind spots turn into license, security, and governance exposure
When models are not inventoried, license obligations become hard to verify. Teams may not know which model versions are in use, which licenses apply, or whether a downstream deployment is still allowed after an upstream model was withdrawn or reclassified. That creates avoidable compliance and contractual risk, especially when model provenance is opaque.
The same blind spot increases the chance of hidden security exposure. A model copied into a private location may bypass the controls applied to the original source, and a model that was removed from one place may remain active elsewhere. That is why the Shadow AI and AI Agent Discovery Guide matters here: discovery has to extend beyond repository scanning into the places where AI assets are actually consumed.
For governance, the operational failure is simple: if you cannot enumerate the model, you cannot assess it. The AI Security Platform Buyer’s Guide helps frame the control question in practical terms, because platforms should be evaluated on whether they discover, classify, and monitor the full AI estate rather than only scanning code for known references.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while SLSA, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Model provenance and downstream copies are supply-chain integrity issues. |
| Recommendation — Track model provenance and verify downstream artifacts before approving use. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems inventory | The question centers on inventory gaps that leave AI assets undiscovered. |
| GV.OC-03 — Roles, responsibilities, and authorities are established and communicated | Model ownership and approval state are needed to govern AI assets. | |
| Recommendation — Maintain a complete inventory of AI models, owners, and deployment locations. Assign clear ownership and approval authority for every model in scope. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Model inventory is a component inventory problem when models are deployed artifacts. |
| CA-7 — Continuous Monitoring | Hidden or downstream model use requires ongoing monitoring, not one-time scans. | |
| Recommendation — Include AI models and derived artifacts in the authoritative component inventory. Continuously monitor model presence, version drift, and unauthorized reuse. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Models that remain usable after removal create offboarding and retirement gaps. |
| NHI-03 — Vulnerable Third-Party NHI | Hub-sourced or externally supplied models can introduce untracked third-party risk. | |
| NHI-09 — NHI Reuse | Fine-tuned or copied models can be reused beyond the original control boundary. | |
| Recommendation — Revoke and validate retirement for every model that is no longer approved. Inventory third-party model sources and validate their provenance before deployment. Detect and govern reused models across environments and teams. | ||
Practitioner Guidance
What to prioritise: Build model inventory as a first-class control, then use code scanning as one input to it. If a model can be pulled, fine-tuned, cached, or deployed outside the repository, it needs independent tracking.
What to verify: Confirm that every model record carries an owner, source, version, deployment location, and retirement state. If any of those fields are missing, the inventory is not yet trustworthy enough for governance or approval decisions.
Common mistake: Treating repository scanning as a proxy for AI asset discovery. That shortcut usually produces a false sense of completeness because the highest-risk models are often the ones least visible in code.
Practitioner takeaway: The goal is not to scan more code, it is to be able to answer model-level questions with confidence: what exists, where it runs, who owns it, and whether it is still allowed.
Related resources from NHI Mgmt Group
- How should security teams inventory AI agents across SaaS, cloud, and low-code platforms?
- How should security teams build a current inventory for AI models and agents?
- What breaks when security teams rely on an incomplete asset inventory in AI environments?
- What breaks when security teams track human and AI agent risk separately?
