AI inventory is becoming the control plane for shadow AI risk

At a glance

What this is: AI inventory is a continuously updated catalogue of AI assets, and Xygeni argues it is becoming the control plane needed to govern shadow AI across development and production.

Why it matters: For IAM and security teams, inventory is the bridge between discovery and control because undocumented AI can introduce unowned access paths, secret exposure and policy gaps.

Context

AI inventory is the operational answer to a governance problem: teams are adopting AI assets faster than they can classify, own and control them. In practical terms, that means the environment now includes models, agents, MCP servers, coding assistants and dependencies that may never pass through traditional approval paths.

The article’s core issue is identity-adjacent even though it is framed around AI asset management. Untracked AI creates unowned access, unmonitored connections and secret exposure risk, which makes discovery, ownership and enforcement the real control plane rather than simple asset counting.

Key questions

Q: What is the first step to governing shadow AI across development and production?

A: Start with continuous discovery across repositories, build systems, developer endpoints and runtime environments. The goal is not to count AI tools but to identify every model, agent, MCP server and AI dependency, then assign ownership and connect each asset to the systems it can reach.

Q: Why does undocumented AI create security risk even before it is abused?

A: Because unowned AI can reach code, data and secrets without being visible to the teams responsible for access control. The risk is not just the asset itself, but the relationships it creates with repositories, APIs, credentials and production systems.

Q: What do security teams get wrong about AI governance inventories?

A: They often inventory only the AI they built themselves and miss embedded AI inside vendor platforms and other shadow AI. That creates a false sense of control because the real decision surface is broader than the visible project list. A useful inventory must cover models, use cases, agents, owners, and the approvals attached to each one.

Q: How should organisations link AI inventory to compliance and enforcement?

A: Use the inventory to generate an AI-BOM, map assets to the EU AI Act, NIST AI RMF and ISO/IEC 42001, and then apply policy controls to the AI assets that present the highest exposure. Compliance becomes evidence-based when inventory feeds enforcement, not just reporting.

Technical breakdown

Why AI inventory is more than asset discovery

An AI inventory is not a static list of tools. It is a living record of what AI assets exist, where they run, what they depend on and what they can reach. That matters because AI risk is relationship-driven: a model is one thing, but a model connected to secrets, code repositories, MCP servers or production data creates a materially different exposure profile. In governance terms, inventory becomes the layer that turns unseen AI into something that can be classified, owned and controlled.

Practical implication: Treat AI inventory as an operational control, not a documentation exercise, and require it to capture relationships as well as assets.

How shadow AI appears inside the software development lifecycle

Shadow AI often hides in the SDLC rather than the cloud console. Developers may enable copilots, pull in AI libraries, run local MCP servers or introduce agentic workflows that open pull requests and install packages without central approval. That makes discovery harder than conventional SaaS sprawl because the relevant signals live in endpoints, repositories and build systems. The control problem is therefore lifecycle-wide: if discovery stops at production, the riskiest AI is already outside the view of the people responsible for governing it.

Practical implication: Extend discovery into code, build and developer environments so AI adoption is detected where it actually enters the workflow.

Why AI-BOMs are becoming the audit artefact that matters

An AI-BOM is the exportable, machine-readable output of an AI inventory. It gives auditors and enterprise buyers a way to verify asset type, provenance, risk level and regulatory mapping rather than relying on a point-in-time spreadsheet. That is a material shift because AI governance is moving toward evidence, not assertion. Once AI systems proliferate across development and production, the question becomes whether the organisation can prove what it runs and how it classifies risk.

Practical implication: Design inventory so it can generate an AI-BOM on demand, with provenance and risk fields that support audit and procurement review.

NHI Mgmt Group analysis

AI inventory is becoming the control plane because governance has to start before enforcement. Once AI assets are deployed without ownership, the security team is already behind the risk curve. Discovery, classification and assignment of responsibility are the only way to make later controls meaningful, especially when models, agents and MCP servers appear outside formal procurement. Practitioners should treat inventory as the first governance decision, not the last documentation step.

Shadow AI expands the attack surface in places traditional tooling does not cover. Repository scanners, CSPM and endpoint tooling each see part of the problem, but none of them fully understand AI-specific assets and relationships. That leaves a control gap where AI can reach data, code and secrets without being represented in the systems that govern access. Practitioners need a joined-up inventory that bridges identity, development and runtime contexts.

AI-BOMs are becoming the accountability layer for AI programmes. Once AI systems are embedded across the SDLC, organisations will be asked to prove what they run, not simply say they have policies. That shifts the burden from awareness to evidence and makes continuous inventory a prerequisite for compliance, procurement trust and operational control. Practitioners should expect AI-BOM generation to become a standard governance requirement.

Inventory without enforcement creates an expensive illusion of control. Discovering AI assets matters only if the organisation can use that knowledge to reject unapproved tools, constrain risky connections and prioritise what can actually affect production or regulated data. The field is moving toward control-plane thinking because visibility alone does not stop shadow AI from creating access and exposure paths. Practitioners should align inventory with policy enforcement from the start.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• One in five organisations reported a breach due to shadow AI, and 97% of those breached through an AI model or application lacked proper AI access controls, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

AI inventory is now the governance boundary for shadow AI. The practical programme shift is from asking whether AI is approved to asking whether every AI asset is continuously discoverable, ownable and enforceable. That means security teams should connect discovery to policy, not leave it as a standalone visibility function.

Control-plane thinking is the right response to AI sprawl. Once models, agents and MCP servers appear across developer endpoints and build systems, a point-in-time review loses value quickly. Practitioners should expect their AI governance model to evolve toward continuous asset mapping, risk scoring and enforcement at the point of introduction.

For practitioners

• Build a continuous AI inventory across the SDLC Discover models, agents, MCP servers, AI coding tools and AI dependencies in repositories, build pipelines, developer endpoints and cloud environments.
• Track ownership and reachable relationships Record who owns each AI asset, what data or systems it can touch and which secrets or APIs it depends on.
• Generate an AI-BOM from the inventory Maintain asset type, provenance, detection confidence and risk fields so the inventory can be exported as an audit-ready AI-BOM.
• Enforce policy at discovery points Use the inventory to block unapproved models, reject unsafe MCP servers and stop AI tools from reaching regulated systems without approval.
• Prioritise assets by exposure, not count Focus remediation on AI assets that are active, connected to sensitive data or capable of changing code, infrastructure or access paths.

Key takeaways

• AI inventory is becoming the control layer for shadow AI because organisations cannot govern AI assets they cannot continuously discover, classify and own.
• The main failure mode is not simple lack of visibility. It is the absence of a live connection between discovery, risk scoring and policy enforcement.
• Security and IAM teams should treat AI-BOM generation, ownership assignment and SDLC-wide discovery as core governance controls, not optional reporting tasks.

Key terms

• AI Inventory: An AI inventory is a governed record of all AI-related assets, enriched with owner, purpose, access, and risk context. It turns discovery into something security, compliance, and IAM teams can use to make approval, review, and revocation decisions.
• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and workload identity. It helps security and identity practitioners build the control foundations needed for environments where AI assets and non-human access overlap.