How to Inventory Every AI Agent, Tool and Model Running in Production

The question arrives from the board, an auditor or a customer questionnaire, and it is always some version of the same one. What AI is running in our production environment? For most security teams the honest answer today is an estimate assembled from a survey, a wiki page and whoever remembers building something.

That answer does not survive a follow-up question. This post covers what belongs in a real AI agent inventory, why the three common ways of building one come up short, and how to produce one from evidence rather than from asking around.

What belongs in an AI agent inventory?

Six component types, with the agent at the center. This is the vocabulary the rest of the post uses.

Every one of these is correlated back to the repository, image and application it ships and runs from, which is what makes ownership and routing answerable from the same evidence rather than from a separate mapping exercise nobody maintains.

One distinction inside that table does more work than it looks. A tool's origin carries three different trust stories. A framework tool shipped inside LangChain or similar: nobody at your company wrote it, and you inherited it upstream. An app-code tool: your developers wrote it, and it is yours to read and fix. An MCP tool: it arrived over a runtime connection, and no code review ever saw it.

Why can't a manifest scan or a gateway produce this inventory?

Each common approach sees a real layer, and each one misses the layer where agent risk lives.

The last row is included deliberately. Runtime evidence is not a superset of the other three, and a plan that pretends otherwise breaks the first time someone asks about token spend or about a workload outside the estate.

How do you build the inventory from runtime evidence?

By reconstructing the live agent hierarchy from the running process. Runtime intelligence reads user-space memory and kernel signals from in-host sensors, so every attribute in the inventory traces back to something observed rather than declared. No code changes, no SDK, no gateway, no repo access.

The model call is what makes this tractable. It is the convergence point of every agentic workload: everything before it is a data source, everything after it is a data sink. That single observation lets an agent's whole data surface be classified without instrumenting the application.

Read this way, the inventory answers two questions no manifest and no packet can. What data can reach this model, and where can data leave. Both are statements about reachable paths drawn from how the agent is wired. They are not recordings of traffic, and the difference matters: the value is surfacing an exposure before it fires, not claiming to have watched data move.

What does a runtime inventory show that a survey cannot?

Four things, and each one is a finding in its own right.

1. Dormant capability. An agent or tool that is loaded and able to run but has never executed. A survey will not mention it, activity monitoring cannot see it, and it is fully wired into production.
2. Locally served models. A model file on disk, confirmed loaded in memory, with format, parameters, quantization, license and digest. It never touches the network, so every gateway and network product is blind to it.
3. Runtime tool surface. Tools imported over MCP after deployment, which expand what an agent may do without any change passing through code review.
4. Guardrails as loaded. Which filters are actually in the process, at what level and in which direction, and which agents are running without any.

These are also the four that make the inventory operationally useful rather than a compliance artifact. Each one names a specific thing to go change.

What do you do with it on day one?

Run the model allow-list. Compare the models actually bound in memory against your approved list, and treat anything off the list as an issue like any other. It is a single comparison, it is easy to explain to a non-technical stakeholder, and it converts the inventory into a control immediately.

From there, discovered risk becomes an AI Risk issue in the queue your team already works, mapped to the OWASP LLM Top 10 and routed by the repo and image it came from, which is the same path vulnerability management follows for everything else. Precise control follows the evidence: because the agent hierarchy is reconstructed rather than inferred, an action can be attributed to the agent that originated it, and policy can name that agent instead of the whole service. Any response is validated before it is applied, scoped, reversible and under your control.

Inventory is not the deliverable. The source is

Plenty of tools will hand you a list of AI assets. The list is not the differentiator, because a list assembled from manifests and a list assembled from process memory disagree in exactly the places that matter: the agent nobody remembers deploying, the model that never leaves the host, the tool that arrived last Tuesday over MCP. When the question is what runs in production, the only answer worth defending is the one read from what is running. See how AI runtime discovery builds it.

Frequently Asked Questions

Related reading

• AI application security: the runtime guide
• What is agentic AI security?
• OWASP Top 10 for LLM Applications, explained