A model inventory describes what a system generates or predicts. An agent or MCP server inventory describes what it can actually reach, invoke, and change. For agentic systems, teams need to record connected tools, human confirmation requirements, credential scope, and which agents connect to which MCP servers. That is the only way to assess exposure when tool-level vulnerabilities emerge.
Why the inventory boundary matters
An ai model inventory answers a different question from an agent or MCP server inventory. The model list tells you which models are present, what they are used for, and where they are embedded. The agent or server list tells you which runtime components can reach tools, invoke actions, and alter systems, which is the inventory that becomes operationally important when exposure, privilege, or misuse is under review.
That distinction matters because a model can be low risk in isolation while the connected agent or server carries the real blast radius. An accurate operational picture therefore starts with the model layer and then extends to the execution and access layer that MCP Security Guide and Model Context Protocol: Authorization specification describe.
For practitioners, the key question is not “which model exists?” but “what is the system allowed to touch?” That is why an agent or MCP server inventory should capture tool connectivity, downstream systems, and any authorization boundary that limits what the runtime can do. A model inventory alone cannot answer those questions.
What belongs in an AI model inventory
An AI model inventory is about the intellectual and predictive layer. It records model name, version, provider or origin, where it is deployed, what business function it supports, and whether it is embedded in a product, workflow, or internal service. Its main value is governance: you can identify model sprawl, dependency concentration, version drift, and where a change in model behaviour may affect outputs or decisions.
That inventory becomes especially useful when teams need to compare models across applications, review lifecycle state, or determine which systems still depend on an outdated model version. It is a catalogue of what the system generates or predicts, not a catalogue of what it can reach or modify.
In practice, model inventory is the right artefact for questions about lineage, evaluation, replacement, and impact from model changes. It is not sufficient for questions about runtime authority, tool access, or operational reach, because those are properties of the surrounding agentic layer, not the model itself.
What belongs in an agent or MCP server inventory
An agent or MCP server inventory is about execution authority. It should record which agents exist, which MCP servers they connect to, what tools or resources each connection exposes, whether human confirmation is required, and what credential scope is attached to each path. This is the inventory that shows how the system can act, not just how it reasons.
That makes it the better source of truth for blast-radius analysis. If an agent can call a ticketing system, a code repository, a cloud control plane, or a data source through an MCP server, then the inventory should show that relationship explicitly. It should also show whether access is broad, task-scoped, delegated, or time-bound, because those details change the consequence of compromise.
For agentic systems, this layer is where teams should also document human approval gates, per-action constraints, and any trust relationship between the agent and the MCP server. The AI Agent Authorisation Guide is relevant here because the inventory should reflect not just presence, but the exact permission shape behind each action.
Risk and Threat Considerations
The main failure mode is mistaking model visibility for operational visibility. If teams can list models but not the agents and MCP servers that hold authority, they may miss the real exposure path, especially when a tool-level vulnerability, token issue, or unsafe server configuration turns a routine integration into a compromise path.
Failure mechanism: Attackers and bugs exploit the gap between a harmless-looking model record and the actual tool-enabled runtime. The model may be unchanged while the connected agent, server, or credential scope allows unauthorized access, privilege escalation, or unintended changes.
Impact: Teams may understate blast radius, miss affected integrations, and fail to prioritise revocation, isolation, or containment when a connected tool or server is vulnerable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent and MCP inventories must capture runtime authority and scope. |
| ASI02 — Tool Misuse | MCP server inventories exist to show which tools can be invoked and abused. | |
| Recommendation — Record per-agent permissions and limit action scope to the minimum required. Inventory tool reachability and remove unnecessary tool connections. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Credential scope and human approval gates are central to agent/server inventory risk. |
| AU-2 — Event Logging | Operational inventories should support traceability of agent and server actions. | |
| IA-5 — Authenticator Management | Credential scope is part of the inventory boundary between models and runtime access. | |
| Recommendation — Restrict agent and server access to the least privilege needed for each task. Log agent and MCP server actions with enough detail to attribute tool use. Track, rotate, and revoke credentials tied to agents and MCP servers. | ||
Practitioner Guidance
What to prioritise: Use the model inventory for governance and the agent or MCP server inventory for exposure management. If you are responding to a tool, auth, or server issue, start with the agent and server inventory because that is where impact is expressed.
What to verify: Each agent entry should map to the specific MCP servers, tools, and credentials it can use, plus any human approval requirement. If those relationships are not explicit, the inventory is incomplete for security purposes even if the model list is accurate.
Common mistake: Treating the model catalogue as a proxy for the system’s authority. A model inventory can tell you what may be generated; it cannot tell you what may be executed, invoked, or changed.
Practitioner takeaway: If you need to assess security exposure, inventory authority before intelligence. The model tells you what the system can think; the agent or MCP server inventory tells you what it can do.
Related resources from NHI Mgmt Group
- What is the difference between securing an AI model and securing an MCP-enabled agent?
- What is the difference between an MCP server and an AI agent built on top of it?
- What is the difference between controlling an AI model and controlling an AI agent?
- What is the difference between an AI model answering IAM questions and a RAG-enabled IAM agent?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
