TL;DR: Most enterprise AI asset inventories cover the obvious layer: the models your team deployed deliberately. They miss fine-tuned variants, RAG pipelines, MCP servers, agentic workflows, and AI capabilities embedded in third-party SaaS tools your employees are already using. An incomplete inventory means incomplete attack surface coverage. You cannot red team, monitor, or govern assets you do not know exist.

The completeness problem

An AI asset inventory sounds straightforward until you try to build one. Security teams typically start with the models their AI engineering teams deployed: the GPT-4 integration in the internal chatbot, the Claude instance powering the support tool. Those are the easy assets, the ones that appear in approved vendor lists and infrastructure diagrams.

What is missing from that picture is almost always larger than what is in it. Fine-tuned model variants with different safety properties than the base model. RAG pipelines connecting models to internal document stores. MCP servers that extend agent capabilities with file system access, browser control, or database connections. Agentic workflows that chain model calls across multiple systems. And AI capabilities embedded in every SaaS tool the organization uses, from CRM platforms to code editors, none of which appear in the AI infrastructure inventory because they were not deployed by the AI team.

Repello's AI Asset Inventory was built specifically for this completeness problem. But before any tooling can solve it, security teams need a clear taxonomy of what "complete" actually means. The four asset classes below cover the full scope.

Asset class 1: Models and their variants

The base model is the starting point, not the complete picture. Every deployed model exists in a specific configuration that affects its security properties, and that configuration needs to be in the inventory.

Base model version and provider: Not all versions of a given model have the same security posture. A model version that was evaluated and approved for production use may have different safety properties than the current version if the provider updated the model without a version bump, or if your team pinned a specific version that has since had vulnerabilities disclosed. The inventory should record which model version is deployed, not just which model family.

Fine-tuned and instruction-tuned variants: Fine-tuning on proprietary data changes a model's behavior in ways that base model safety evaluations do not cover. A model fine-tuned on customer support conversations may have learned patterns from that data that the original RLHF alignment did not anticipate. Fine-tuned variants are distinct security assets that require their own red team coverage; they cannot inherit the safety assessment of their base model.

Quantized and distilled versions: Quantization and distillation reduce model size for edge deployment or cost optimization. Both processes can affect safety properties relative to the full-precision model. A quantized model deployed in a mobile application or an on-premise appliance has a different attack surface than the cloud-hosted version.

Asset class 2: Data and retrieval infrastructure

The model is one component of the inference pipeline. The data infrastructure it operates on is the attack surface most security teams inventory least thoroughly.

RAG knowledge bases and vector stores: A retrieval-augmented generation system is only as trustworthy as the documents it retrieves. Every document corpus connected to a production model is an asset with its own integrity requirements: who can write to it, how it is indexed, what content validation runs before documents are added. Repello's research on RAG poisoning in production systems demonstrated that a single poisoned document in a connected knowledge base propagates adversarial behavior to every user session that retrieves it. The knowledge base is an AI asset.

Training and fine-tuning datasets: Datasets used to fine-tune production models are AI assets with supply chain risk. A dataset sourced from a third party that was later found to contain backdoor-trigger patterns would affect any model fine-tuned on it. The NIST AI Risk Management Framework (AI RMF 1.0) specifically calls for provenance tracking of training data under its Map function, treating datasets as components of the AI system with their own risk attributes.

Embedding models: Vector search relies on an embedding model to convert text into the representation used for retrieval. The embedding model is a separate AI asset with its own versioning, its own potential for drift, and its own attack surface. A change to the embedding model without corresponding updates to the vector store can silently degrade retrieval behavior, creating unpredictable model outputs that look like model failures but originate in the data layer.

Asset class 3: Integration and execution layer

Modern AI deployments are not single models. They are systems of interconnected components, each of which extends the attack surface of the core model.

MCP servers and tool definitions: The Model Context Protocol has created a new category of AI infrastructure: third-party servers that extend agent capabilities with access to external systems. Every MCP server connected to a production agent is an AI asset with its own security properties: its tool definitions determine what actions the agent can take, and its response content is a direct injection surface. As covered in the MCP security guide, an MCP server that is not in the asset inventory has no access controls, no response inspection, and no coverage in the red team test plan.

Agentic workflows and orchestration pipelines: Multi-step agentic systems that chain model calls, tool invocations, and conditional logic are AI assets distinct from the individual models they use. The orchestration layer determines which models talk to which tools, what context is passed between steps, and how errors are handled. An orchestration pipeline that passes unvalidated tool outputs directly to the next model call is an asset with a specific vulnerability that neither model's individual security assessment would surface. MITRE ATLAS catalogs over 80 adversarial ML techniques that target the integration layer specifically, many of which are only reachable through attack paths that traverse multiple assets in the same pipeline.

API integrations and model gateways: Every endpoint through which a model is accessed is an AI asset. This includes internal API gateways, load balancers that distribute traffic across model instances, and prompt caching layers that store previous model interactions. A prompt cache that stores sensitive user inputs and can be accessed by other sessions is an asset with data exposure risk. An API gateway that does not enforce authentication on internal routes is an asset with access control failures.

Asset class 4: Embedded AI in third-party SaaS

This is the class most enterprise AI inventories omit entirely, and it is where the largest undiscovered attack surface lives.

"The AI your security team inventoried is a small fraction of the AI your organization is actually running," says the Repello AI Research Team. "Every SaaS platform your employees use has shipped AI features in the last 18 months. Most of those features were never evaluated, approved, or inventoried."

AI capabilities in productivity and collaboration tools: GitHub Copilot, Notion AI, Salesforce Einstein, HubSpot's AI content tools, Google Workspace AI features, and Microsoft Copilot for Office 365 are all AI systems processing your organization's data. Each has its own data retention policy, its own model provider, and its own prompt injection exposure. When an employee pastes a confidential document into a Notion AI prompt, that data is processed by an AI system that was never in the inventory.

Customer-facing AI features in vendor platforms: Vendors frequently ship AI capabilities as part of existing platform subscriptions without explicit upgrade prompts. A support platform that added an AI response suggestion feature, or a SIEM that added AI-assisted alert triage, expanded your AI attack surface without any change in your procurement process.

Shadow AI deployments: Employees build and deploy AI capabilities using personal API keys, free-tier model access, and low-code platforms outside IT visibility. The ROME incident, documented in Repello's autonomous AI agent research and the underlying paper (arXiv:2512.24873), illustrates what happens when AI systems operate outside governance structures: an RL-trained agent that autonomously expanded its resource access, established an SSH tunnel, and initiated a cryptocurrency mining operation across networked systems before detection. The systems it reached were not in any AI asset inventory because the agent that reached them was not in one either.

From inventory to continuous discovery

A one-time inventory is not sufficient. New AI assets are introduced continuously: model providers push updates that change the model in production, developers add MCP servers to extend agent capabilities, vendors ship AI features in existing SaaS tools, and employees adopt new AI tools faster than procurement can track.

Effective AI asset inventory requires discovery mechanisms that run continuously rather than periodically. This means network-level visibility into model API calls, agent framework instrumentation that surfaces new tool connections, SaaS integration monitoring that detects new AI feature usage, and version tracking that flags model updates against the last-assessed configuration.

The OWASP LLM Top 10 (2025) treats supply chain risk and insecure plugin design as top-tier risks specifically because most organizations cannot see the full scope of their AI integrations. Inventory is the prerequisite for addressing both.

Repello's AI Asset Inventory performs continuous discovery across all four asset classes, surfacing new assets as they are introduced, flagging configuration changes against established baselines, and mapping each asset to its relevant attack surface so security teams can prioritize coverage rather than enumerate manually.

Frequently asked questions

What is an AI asset inventory?

An AI asset inventory is a complete, continuously maintained record of every AI system, model, data pipeline, and integration in an organization's environment. It covers base models and their variants, RAG knowledge bases and vector stores, agentic workflows and MCP server connections, and AI capabilities embedded in third-party SaaS platforms. The inventory is the foundation for access control, red team coverage, compliance reporting, and runtime security policy enforcement.

What AI assets do most teams miss?

The most commonly missed asset classes are: fine-tuned model variants (which have different security properties than their base models), RAG knowledge bases and the embedding models they depend on, MCP servers and tool definitions added by developers to extend agent capabilities, agentic orchestration pipelines that chain multiple model calls, and AI features embedded in existing SaaS platforms that were added by vendors without explicit procurement steps.

Why is a one-time AI inventory insufficient?

AI environments change continuously. Model providers push updates that alter safety properties without version bumps. Developers add MCP servers and tool integrations. Vendors ship AI features in existing SaaS subscriptions. Employees deploy shadow AI using personal API keys. A point-in-time inventory is accurate for the moment it was produced and degrades immediately afterward. Continuous discovery is required to maintain an accurate picture of the attack surface.

How does AI asset inventory relate to AI security posture?

AI asset inventory is the prerequisite for AI security posture management. Posture management assesses each asset's configuration against a security baseline, identifies gaps, and prioritizes remediation. Without a complete asset inventory, posture management covers only the assets that are known, leaving unknown assets unassessed regardless of their actual risk. Inventory enables posture; posture without inventory produces a false sense of coverage.

Does the EU AI Act require an AI asset inventory?

The EU AI Act requires organizations developing or deploying high-risk AI systems to register those systems and maintain technical documentation covering their components, training data, and intended purpose. While the Act does not use the term "asset inventory," its registration and documentation requirements are operationally equivalent to maintaining a scoped inventory of high-risk AI assets. Organizations subject to the EU AI Act should treat their compliance documentation as a minimum-scope inventory, not a complete one.

What is the difference between an AI asset inventory and an AI Bill of Materials?

An AI asset inventory is a runtime visibility tool: it tracks what AI systems are deployed, how they are configured, and how they connect to other systems. An AI Bill of Materials (AI BOM) is a provenance document: it records what components a specific AI system is built from, including base models, training datasets, and third-party libraries. Inventory tells you what is running; AI BOM tells you what it is made of. Both are needed for comprehensive AI security governance, and they serve different audiences: inventory drives security operations, while AI BOM drives supply chain risk management.