An AI inventory is a continuously updated catalogue of every AI asset running across your organisation — models, AI-powered endpoints, datasets, AI coding assistants, MCP servers and AI dependencies — together with the relationships, risks and owners that connect them. In a security context this has nothing to do with warehouse or stock inventory management; here, "AI inventory" simply means knowing exactly what AI you are running, where it lives, and what it can reach.
As AI spreads across every stage of software development, from code generation in the IDE to autonomous agents acting inside CI/CD pipelines, the question is no longer whether AI is present in your environment. It is whether you can see it. This guide explains what an AI inventory is, how it relates to an AI-BOM and an SBOM, why shadow AI has become a security problem, and how the practice maps to the EU AI Act, NIST AI RMF and ISO/IEC 42001.
Key takeaways
- An AI inventory catalogues every model, dataset, agent, MCP server and AI coding tool across your software lifecycle, not just the ones IT approved.
- Shadow AI, AI adopted without governance, is now the norm, not the exception: in one 2026 survey of security leaders, only 19% of organisations reported full visibility into where and how AI is used.
- An AI-BOM (AI Bill of Materials) is the audit-ready output of an AI inventory: the AI-era successor to the SBOM.
- Regulation is arriving. The EU AI Act, NIST AI RMF and ISO/IEC 42001 all effectively require you to know what AI you operate.
- An inventory is only the starting point; the value comes from scoring risk and acting on the small number of assets that genuinely matter.
What is an AI inventory?
An AI inventory is the practice of discovering, cataloguing and continuously monitoring every AI asset operating across your software development lifecycle, and the risks attached to each one. A complete inventory answers three questions for every asset: what is it, where does it run, and what can it access?
That scope is broader than most teams expect. A meaningful AI inventory should cover:
- Models: every large language model and foundation model in use across development and production, with version, location and detection confidence.
- Datasets: training data, retrieval datasets and vector stores, including exposure to poisoned context and data leakage.
- Agents: autonomous systems that take actions in your environment, such as opening pull requests, installing dependencies, or touching infrastructure.
- MCP servers: Model Context Protocol servers that connect AI assistants to external tools, APIs and data sources.
- AI coding tools and assistants: copilots and IDE integrations that generate code, suggest dependencies and interact with repositories.
- AI frameworks: LangChain, LangGraph, agent servers and other orchestration layers that wire models to tools and data.
- Relationships between assets: the connections between models, agents, servers, datasets and the secrets tied to them. A relationship graph makes risk visible in context, not as a flat list.
AI inventory vs AI asset inventory vs AI-BOM, and how they differ from an SBOM
These terms are used loosely, so it helps to be precise. “AI inventory” and “AI asset inventory” describe the same thing: the living catalogue of AI assets and their risks. An AI-BOM is the exportable artifact that inventory produces: a machine-readable bill of materials you can hand to an auditor or an enterprise buyer.
The cleanest way to understand the AI-BOM is by analogy to the SBOM:
As AI becomes embedded across the SDLC, the AI-BOM is becoming as foundational as the SBOM, and security leaders are increasingly receiving requests from auditors and enterprise procurement teams for exactly this artifact.
Why AI inventory matters now
Three forces have turned AI inventory from a nice-to-have into a priority.
- First, AI is writing insecure code at scale. Independent research consistently finds that a large share of AI-generated code ships with vulnerabilities. The original NYU/Copilot study by Pearce et al. found roughly 40% of generated programs contained security weaknesses, and more recent large-scale testing points the same way: Veracode’s 2025 analysis across 100+ models found only 55% of AI-generated code was secure. If you do not know which assistants are generating code in your pipelines, you cannot govern that risk.
- Second, the software supply chain has become an AI attack surface. In September 2025, Shai-Hulud, the first self-propagating npm worm, turned developer machines into a distribution mechanism, spreading across hundreds of packages. In March 2026, attackers compromised axios, a package with roughly 100 million weekly downloads, publishing poisoned versions that dropped a remote-access trojan. Attacks like these land in exactly the layer between traditional AppSec and endpoint tooling: the layer an AI inventory is built to illuminate.
- Third, secrets and credentials are leaking through AI. GitGuardian’s State of Secrets Sprawl 2026 reported that leaks of AI-service secrets rose 81% year over year, and that AI-assisted commits leak secrets at roughly twice the baseline rate. Every undocumented model, agent or MCP server is a potential path to a credential.
Traditional AppSec stops at the repository and does not understand what a model is. Endpoint tools watch the operating system but do not understand packages, MCP servers or AI assistants. The gap between them is where AI risk accumulates, and an inventory is the first step to closing it.
Where AI hides: Shadow AI across the SDLC
Shadow AI is any AI system adopted without formal approval or governance: the copilot a developer enabled last week, the MCP server running on a laptop, the model pulled straight from a public hub into a side project. It is not an edge case. In a 2026 survey of 400+ security leaders, only 19% reported full visibility into where and how AI is used across their organisation, while the overwhelming majority were already using or piloting AI coding assistants.
The hardest shadow AI to find is the AI inside the software lifecycle, because it rarely shows up in a cloud console:
- Models and AI libraries pulled into repositories as dependencies.
- AI coding assistants configured per developer, per IDE.
- MCP servers and rule files running locally on developer endpoints.
- Agentic workflows quietly opening pull requests or installing packages.
This is why cloud-only discovery is not enough. A genuinely complete AI inventory has to reach into code and build environments (the developer’s laptop, the repository, the pipeline), not just the production cloud.
What belongs in an AI-BOM
An audit-ready AI-BOM turns your inventory into something you can prove. At minimum, it should include:
- Every AI asset: models, datasets, agents, MCP servers, AI coding tools.
- Asset type, location and detection confidence for each.
- Provenance and dependencies (where the model or component came from).
- A risk level per asset, based on AI-specific attack vectors.
- Regulatory mapping to the EU AI Act, NIST AI RMF and ISO/IEC 42001.
- An exportable, machine-readable format for auditors and customers.
The organisations that can generate an AI-BOM on demand will have a real compliance and trust advantage as AI audit obligations mature.
AI inventory and compliance: EU AI Act, NIST AI RMF and ISO/IEC 42001
None of the major frameworks names “AI inventory” as a line item, but each one is effectively impossible to satisfy without it. You cannot document, classify or govern AI systems you cannot see.
A note on timing: the EU AI Act’s rollout was revised by the May 2026 “Digital Omnibus” agreement, which deferred most high-risk obligations to December 2027, while keeping several 2 August 2026 milestones live (transparency duties, GPAI penalty powers). Treat exact dates as a moving target and confirm against primary EU sources. But the direction of travel is clear, and inventory is the prerequisite for all of it.
How to build and maintain an AI inventory
Building an inventory is less about a one-off audit and more about establishing a continuous process, because AI assets change constantly: new models adopted, new agents deployed, new MCP servers configured, often without approval.
A practical approach:
- Discover automatically across code, build and cloud. Manual spreadsheets go stale within days. Discovery has to run continuously and reach into the SDLC, not just runtime.
- Classify and map relationships. Record type, location, provenance and, critically, how each asset connects to others and to secrets.
- Score risk in context. A flat list of hundreds of findings helps no one; prioritise by what is actually reachable, exploitable and business-critical.
- Assign ownership. Every asset needs an accountable owner.
- Keep it live and exportable. Maintain it as a continuous inventory that can produce an AI-BOM on demand.
What to look for in AI inventory software
If you are evaluating tooling, these are the capabilities that separate genuine AI inventory software from a static list:
- Understands AI-specific asset types (models, agents, MCP servers, datasets), not just packages and libraries.
- Reaches into the SDLC, discovering AI in code and on developer endpoints, not only in the cloud.
- Maps relationships, not just individual assets, so risk is visible in context.
- Scores risk on AI-specific attack vectors (prompt injection, insecure MCP, excessive agency), not only CVE severity.
- Runs continuously, catching new AI as it appears.
- Produces an audit-ready AI-BOM that satisfies both auditors and enterprise procurement.
- Connects inventory to enforcement, so you can act on what you find.
From inventory to action: securing what you find
Discovery is the first step; the second is understanding which assets carry real risk, because most will not. The goal is to move from thousands of raw findings to the handful that can actually compromise systems, data or operations: those that are in active use, accept untrusted input, are realistically exploitable, hold sensitive access, and affect production or regulated assets.
This is where AI Security Posture Management (AI-SPM) picks up: taking the inventory, scoring risk along the AI attack path, mapping it to regulation, and producing the AI-BOM. It is also where inventory meets enforcement: blocking malicious dependencies before they install, rejecting unapproved MCP servers and models, and containing compromised endpoints before an incident spreads.
At Xygeni, this is the model we build towards: continuous AI inventory and AI-BOM through AI-SPM, malware detection that catches malicious packages before a signature exists (MEW, Malware Early Warning), and policy enforcement at the developer endpoint through Xygeni Shield. Detection is aligned to the OWASP Top 10 for LLM Applications, the OWASP Top 10 for Agentic Apps and the OWASP MCP Top 10. But whichever approach you choose, the principle holds: you cannot secure what you cannot see, and an AI inventory is where visibility begins.
FAQs
How is an AI-BOM different from an SBOM?
An SBOM catalogues open-source and third-party software dependencies, scored on CVE severity. An AI-BOM catalogues AI-specific assets (models, agents, MCP servers, datasets) with AI-specific risk scoring and regulatory mapping. As AI spreads across the SDLC, the AI-BOM is becoming as foundational as the SBOM.
What is shadow AI and how do I discover it?
Shadow AI is any AI adopted without formal approval or governance: an enabled copilot, a local MCP server, a model pulled from a public hub. You discover it with continuous automated inventory that reaches into code, build pipelines and developer endpoints, not just the production cloud where most shadow AI never appears.
Does the EU AI Act require an AI inventory?
The EU AI Act does not name “AI inventory” explicitly, but its documentation, classification and registration duties for high-risk systems are impossible to meet without one. The same is true of the NIST AI RMF (Map function, Govern 1.6) and ISO/IEC 42001, which requires maintaining an inventory of AI systems.
What is AI-SPM?
AI Security Posture Management (AI-SPM) is the practice of continuously discovering AI assets, scoring their risk along the AI attack path, mapping them to regulation, and producing an AI-BOM. It extends posture-management thinking (familiar from CSPM and DSPM) to AI-specific assets and attack vectors.
How often should an AI inventory be updated?
Continuously. AI assets change daily as teams adopt new models, deploy new agents and configure new MCP servers, usually without formal approval. A point-in-time scan is stale within days, so effective AI inventory software runs as an ongoing process rather than a one-off audit.
How do I inventory AI used in source code?
Inventorying AI in code means detecting AI models and libraries pulled in as dependencies, AI coding assistants configured per developer, and MCP servers or rule files running locally. This requires discovery that operates inside the SDLC (repositories, build pipelines and developer endpoints) rather than only in cloud consoles.
