Skip to main content
As codebases adopt LLMs, agents, and the MCP ecosystem, a new class of supply chain appears that a classic dependency scan misses: the AI an application runs, and the AI tooling that builds it. AI Inventory discovers those components across your repositories and assembles them into an AI-BOM you can review, filter, and export. It surfaces which repositories call the OpenAI or Anthropic SDK, where agent frameworks and MCP servers run, which model files are committed to the repo, and which agent instructions and prompt templates steer your coding agents.

​
What gets inventoried

Every detected component is classified by kind:

Runtime AI

LLM SDKs, agent frameworks, ML frameworks and runtimes, vector databases, guardrails, AI observability, speech and audio, and tokenizers.

Models & data

Model files with their format (GGUF, ONNX, SafeTensors), local model configs, and datasets.

Agent tooling

MCP servers, agent configs, agent instructions, skills, and prompt templates: the configuration and instructions that govern what agents can do.

Provider & usage

Each component is tagged with its provider (OpenAI, Anthropic, Hugging Face) and whether it runs at runtime or as dev tooling.
Each component row carries:
  • Kind — one of 17 categories: MCP Server, LLM SDK, Agent Framework, ML Framework, ML Runtime, Vector DB, Guardrails, AI Observability, Speech & Audio, Tokenizer, Model File, Dataset, Agent Config, Agent Instructions, Skill, Prompt Template, and Local Model Config.
  • Usage — Runtime, Dev Tooling, or Ambiguous.
  • Model type — generative AI (GenAI) or classic ML.
  • Provider and version, where known.
  • Detection source — an SCA package, a file path, file content, or a config file.
  • Reachability — for components backed by a dependency, the reachability status inherited from the linked package: reachable, not reachable, or not tested. See Reachability.
  • Direct or transitive — for components detected as dependencies.

​
Reading the inventory

The AI components view groups components by repository, each showing its total count and the kinds present, drawn from that repository’s most recent scan with AI Inventory enabled. Headline tiles summarize the inventory: total AI components, model SDKs and frameworks, and agent configs and rules. Filter by kind, usage, model type, provider, or detection source; search by package, provider, or path; and scope to specific repositories. AI Inventory detects components from your dependencies, file paths, file content, and configuration files.

​
Export the AI-BOM

Export AI-BOM downloads the inventory as a CSV covering every repository’s latest scan with AI Inventory enabled, honoring your current repository scope. Columns include repository, component, kind, usage, model type, provider, version, ecosystem, detection source, manifest path, file path, and transitivity. For a dependency bill of materials in CycloneDX, SPDX, or VEX format, see SBOM exports.

​
Enabling AI Inventory

AI Inventory has its own scanner setting, separate from SCA scanning, and is on by default for full scans.
A component is only inventoried by scans that ran after AI Inventory was enabled. If the view is empty, enable the AI Inventory module in scanner settings and run a new full or SCA scan.

​
API access

The AI Inventory is available over the REST API under the SCA namespace:
  • POST /api/v1/sca/ai-inventory/repositories/search — repositories with AI components, plus per-kind counts.
  • POST /api/v1/sca/ai-inventory/components/search — component rows for a repository’s resolved scan.
  • POST /api/v1/sca/ai-inventory/providers/search — the set of detected providers, for building filters.