AI Inventory: Which Models, MCP Servers and Agents Your Code Uses

Ask an engineering org which large language models its applications call, which MCP servers its agents can reach, and which agent instruction files ship in its repositories. Most cannot answer from a system of record. The answer lives in a survey from last quarter, a wiki page, and a few people's heads.

An AI inventory closes that gap. It is the list of AI components your code uses, built from source and kept current by the same scans that already read your dependency manifests. Customers, auditors and regulators are starting to ask for it, usually under the name AI-BOM.

This post covers why the request is arriving now, what belongs in the inventory, why a dependency SBOM does not already answer the question, and how to keep the list accurate without a survey.

Why an AI inventory is now an audit question

Three pressures are converging. Procurement questionnaires now carry a section on AI use, and "which models does your product call" is a standard line in it. Security reviews of agentic features want to know what tools an agent can invoke. And governance frameworks ask you to know what you run before you assess it.

The NIST AI Risk Management Framework puts context and inventory in its Map function: you cannot measure or manage a risk attached to a system you have not identified. The OWASP Top 10 for LLM Applications carries a Supply Chain category, and the practical control for it is knowing which models, packages, servers and agent files you depend on. CycloneDX, the SBOM format most of your customers already accept, has component types for machine-learning models and datasets. That is what makes an AI-BOM or ML-BOM a document you can hand over rather than a spreadsheet.

None of these frameworks tells you how to produce the list. They assume you have one. That assumption is the gap, and it is the same gap compliance work hits every time a control starts with "maintain an inventory of".

What belongs in an AI inventory

A useful AI inventory has more than a column of model names. The components that carry risk fall into six groups, and each needs a different source of evidence.

• Models called from code. Every place an application names a model: the string passed to a provider SDK, a Bedrock model ID, a self-hosted endpoint. Record the file and line, the provider, where it is hosted, and the provider's deprecation date if one is published.
• AI packages and providers. Provider SDKs, agent frameworks, vector store clients and MCP SDKs in your dependency data. These are ordinary packages, but they tell you which applications have an AI surface at all.
• MCP servers. Two kinds. Servers your code implements, with the tools, resources and prompts they expose and whether they are reachable over the network. And servers your agents are configured to consume, declared in configuration files.
• Agent files and skills. Instruction files such as CLAUDE.md and AGENTS.md, skills, subagents, hook scripts and agent settings. These are executable intent and belong in the inventory with a risk assessment attached.
• Plugins and external services. Plugin manifests, and the hosts that agent files and MCP servers reference. The external-host list is often the first thing a reviewer asks for.
• ML assets committed to repositories. Model cards, dataset manifests, training configs and model weights checked into source. A customer asking for an AI-BOM usually means these as well as the API calls.

Each row needs an owner, a repository or application, and the evidence that put it there. A model name with no file and line is a claim, not an inventory entry.

Why your SBOM does not already cover it

The first instinct is to grep the existing SBOM for openai and anthropic and call it done. That finds the SDKs. It misses most of the inventory.

Models are not packages. An application selects a model with a string at the call site, and that string is invisible to a manifest parser:

response = client.messages.create(model="claude-sonnet-4-5", max_tokens=1024, messages=messages)

Swap the literal for model=settings.MODEL and even a source scanner has to report an unresolved reference rather than a model name. Your inventory tooling needs to say which case it is in.

MCP servers are not packages either. An agent consumes one through a JSON or TOML configuration file, not a dependency manifest:

{"mcpServers": {"github": {"command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"]}}}

Nothing in package.json records that entry. Agent instruction files are Markdown. Model cards and dataset manifests are YAML and JSON in directories no package manager owns. A dependency SBOM is necessary and nowhere near sufficient, and the supply chain it describes stops at the package boundary.

There is a second gap. A package SBOM is a build-time artifact. Hosted models have lifecycles of their own: providers retire versions on a schedule, and an application pinned to a model with a published deprecation date is carrying an outage, not a vulnerability. The inventory has to record that date, because the SBOM has nowhere to put it.

Keep the AI inventory current from source

The survey approach fails for the same reason it fails for dependencies. It is accurate on the day it is answered and wrong a sprint later, and nobody re-answers it. The alternative is to treat the AI inventory as a derived artifact of the repository and rebuild it on every scan.

That means parsing the sources that hold the evidence:

• Dependency data you already collect, matched against a catalog of AI packages, so no new scan is needed to find the SDKs and frameworks.
• Agent configuration files, parsed into the servers, models and plugins they declare. These files can hold API keys and tokens; the parser has to store only values that cannot carry a secret.
• Application code, read for model identifiers at call sites and for MCP server implementations and their transports.
• Committed ML assets, catalogued from their manifests and model cards. Weights should be listed by path, never read or hashed: they are large, and their contents are not evidence of anything the inventory needs.

Rebuilding from source gives you two properties a survey cannot. Every entry carries a file and line, so a reviewer can verify it. And a change in the repository changes the inventory on the next scan, with no human in the loop to forget.

Trade-offs: declared, observed and in use

An inventory built from source is honest about what it knows only if it separates kinds of evidence. Three distinctions matter.

Configured versus observed. A model declared in a settings file is configured. A model identified at a call site in scanned code is observed. Both belong in the inventory, but they are different claims and should be labeled as such.

Declared versus in use. A provider SDK in a lockfile does not prove the application calls a model at runtime, and an MCP server in a config file does not prove an agent ever invoked a tool. The inventory should list components whether or not they are in use, and say which evidence it has. Treating "declared" as "running" overstates your AI surface; treating it as "not running" understates your risk.

Identity by content, not by name. Two skills named deploy in two repositories may be the same file or two different files. The only reliable identity for an agent file is a hash of its exact bytes. Name matches are a hint. Byte matches let you ask "where else does this exact file run" and get a true answer.

The last trade-off is attribution. An MCP server in a config can be matched to a registry record, and that match tells you which server it is. It does not tell you the server is safe. Inventory identifies; it does not approve.

What to do: an AI inventory checklist

If you are starting from nothing, this order gets you to a defensible list fastest.

1. Pull the AI packages out of the dependency data you already have: provider SDKs, agent frameworks, vector clients, MCP SDKs. This tells you which repositories have an AI surface.
2. Find every agent configuration file in those repositories and across the rest: .mcp.json, assistant settings files, plugin manifests. Extract the MCP servers, models and plugins they declare.
3. Scan application code for model identifiers at call sites. Record file, line, provider, hosting and deprecation date. Flag references that resolve through a variable as unresolved.
4. Catalog MCP server implementations in your own code, with their tools and transport. A network-reachable transport is an endpoint and should be reviewed as one.
5. Inventory agent instruction files, skills, subagents and hooks, and attach a risk assessment to each.
6. List the external hosts your agent files and MCP servers reference. Compare them against the domains you have approved.
7. Catalog committed ML assets: model cards, datasets, training configs, weights.
8. Assign an owner per component through the repository or application it belongs to, and export the result as a CycloneDX AI-BOM when someone asks.

Then stop maintaining it by hand. Wire each step to the scans that already run on every push, so the list is a byproduct of normal work.

How Heeler builds the AI inventory

Heeler's AI Inventory sits under Catalog and lists the AI components collected from repositories and application code, whether or not they are in use. Tabs cover MCP Servers, AI Packages & Providers, Models, Plugins, External Services, and Agent Files & Skills, each with its own columns and filters by source, evidence and role.

The inventory is built from source in the way described above. AI libraries come from your existing dependency data, matched against a catalog of model provider SDKs, AI frameworks, agent frameworks, vector store clients and MCP SDKs, with no new scanning run. Agent configuration files, including MCP server files, Claude, Gemini and Codex settings, and plugin manifests, are parsed into the servers, models and plugins they declare, and only values that cannot carry a secret are stored. External Services lists the hosts that agent files and MCP servers reference.

Each AI model an application calls from its own code appears with its file and line, the catalog family, hosting and deprecation date. A Bedrock ID for a Claude model resolves to Anthropic. A model passed through a variable is listed as an unresolved reference rather than guessed. Model cards, dataset manifests, training configs and model weights committed to a repository are catalogued as ML assets with the publisher's claimed metrics, and weights are never read or hashed.

Evidence, identity and export in Heeler

Evidence is labeled Configured or Observed. Neither state establishes effective permissions or runtime enforcement, and a declared AI dependency does not prove that an application uses it at runtime. Agent files carry an Exact file content identity, so you can view every use of the same bytes across your organization; matching names alone do not establish a match. For declared MCP servers, MCP Registry attribution reports Matched, Ambiguous, Not found or Unavailable, and a match identifies a server without endorsing it.

MCP servers implemented in your own code are analyzed under MCP Server Analysis, with their tools, resources, prompts and transport, and classified as Local or Public by network exposure. The agent files in the inventory are the same ones Heeler scores for risk and maps to the OWASP Top 10 for LLM Applications. Agent Files Are the New Supply Chain covers how that review works, and AI agent security covers the Prevent and Operate controls around it.

When a customer or auditor asks, Export AI-BOM on the repository page downloads a CycloneDX 1.6 AI-BOM of the application's AI, and administrators can export the inventory itself as CSV or JSON. An AI-BOM query is also available through Heeler MCP, so an agent can get the same answer you can.

FAQ

What is an AI inventory?

An AI inventory is a list of the AI components an organization's software uses, built from source: models called from code, AI packages and provider SDKs, MCP servers, agent files and skills, plugins, external services and committed ML assets. Each entry carries evidence, an owner and a repository or application.

What is the difference between an AI inventory and an AI-BOM?

An AI-BOM is the exported document, and the AI inventory is the live system of record it is generated from. CycloneDX defines component types for models and datasets, so an AI-BOM can be a CycloneDX file that customers and auditors already know how to consume.

Does a dependency SBOM already cover AI components?

No. A dependency SBOM finds provider SDKs and frameworks, but models are selected by string at call sites, MCP servers are declared in configuration files, agent files are Markdown, and ML assets are manifests and weights that no package manager tracks.

Should the inventory list components that are not in use?

Yes, with the evidence labeled. A declared dependency or configured server is part of your surface even when nothing calls it, and the honest answer to "do you use this" is "declared, not observed" rather than a guess in either direction.

How often should an AI inventory be updated?

On every scan of the repository. An inventory rebuilt from source changes when the code changes, which is the only cadence that survives contact with a sprint.

Heeler builds the AI inventory from the repositories and application code you have already connected, with file-and-line evidence for every model, MCP server, agent file and ML asset, and exports it as a CycloneDX AI-BOM when someone asks. See it against your own code. Get a demo