AI inventory is becoming the control plane for shadow AI risk

At a glance

What this is: This is an analysis of why AI inventory is now the baseline control for discovering, classifying and governing AI assets across the software lifecycle.

Why it matters: It matters because IAM, PAM and security teams cannot govern AI systems, their secrets or their reach if they cannot first see where those systems exist and what they can access.

By the numbers:

• In a 2026 survey of 400+ security leaders, only 19% reported full visibility into where and how AI is used across their organisation.
• Independent research found roughly 40% of generated programs contained security weaknesses in the original NYU/Copilot study.
• Veracode's 2025 analysis across 100+ models found only 55% of AI-generated code was secure.

👉 Read Xygeni's analysis of AI inventory, shadow AI and AI-BOM governance

Context

AI inventory is the discipline of discovering and continuously tracking every AI asset in use, including models, datasets, agents, MCP servers and AI coding tools. The governance gap is simple: most organisations can name their approved systems, but cannot reliably see the shadow AI already operating inside development and delivery workflows.

That gap matters because AI now sits inside the software supply chain, not just at the edge of it. When models generate code, agents touch infrastructure, and MCP servers connect to tools and data sources, the inventory question becomes an identity and access question as much as a discovery question.

The article argues that inventory is the prerequisite for AI-BOM generation, risk scoring and regulation mapping. That starting position is typical for mature security programmes, but atypical for teams still treating AI as a point technology rather than a changing asset graph.

Key questions

Q: How should teams handle shadow AI inside IT asset inventories?

A: Teams should record shadow AI the same way they record any other business system, then attach the identities, approvals, and data flows that make it operational. If those access relationships are missing, the organisation knows the app exists but not whether it is authorised or reviewable.

Q: Why do autonomous AI systems create more identity risk than normal automation?

A: Normal automation follows a fixed path, but autonomous systems can interpret goals, choose actions, and continue without waiting for a person. That makes intent less predictable and review cycles less useful. The risk increases when the system can broaden scope or trigger actions that affect data, money, or compliance.

Q: What breaks when organisations rely on cloud-only discovery for AI governance?

A: Cloud-only discovery misses the places where AI is most likely to appear first, including developer laptops, local assistants, MCP servers and build tooling. That leaves shadow AI untracked, unowned and often connected to secrets or repositories long before it shows up in production controls.

Q: Should AI inventory feed compliance, or is it mainly a security exercise?

A: It must feed both. Compliance frameworks increasingly depend on being able to prove what AI systems exist, how they are classified and what data or access they can reach. Security teams need the same inventory to prioritise enforcement, block unknown components and reduce exposure before governance becomes a paperwork exercise.

Technical breakdown

What an AI inventory actually covers across the SDLC

An AI inventory is broader than a list of approved models. It should include models, datasets, AI coding tools, agents, MCP servers, orchestration layers and the relationships between them. The important technical shift is from asset naming to reachability and dependency mapping. A model that can call tools, read a dataset or inherit secrets through an MCP server creates a very different risk profile from a model used in isolation. Without that relationship graph, teams miss how AI becomes embedded in build systems, developer laptops and pipeline automation.

Practical implication: inventory AI as a connected graph of assets, dependencies and access paths, not as a static spreadsheet.

Why shadow AI hides in code, endpoints and pipelines

Shadow AI is hard to find because it often lives outside cloud consoles and inside the SDLC. Developers may add copilots, local MCP servers or model libraries without central approval, while agents may act inside repositories and build pipelines. Traditional AppSec tools are built to see code and packages, not the runtime behaviour of AI systems. Endpoint tools see processes and files, but not the governance meaning of an assistant or model dependency. That creates a discovery blind spot exactly where AI can influence code, credentials and deployment actions.

Practical implication: extend discovery into repositories, build systems and developer endpoints if you want shadow AI coverage that is actually complete.

Why AI-BOMs are becoming the audit artifact for AI governance

An AI-BOM is the exportable output of an inventory, similar to how an SBOM formalises software dependencies. The difference is that AI-BOMs need to capture AI-specific assets, provenance, exposure and regulatory mapping, not just package names. This matters because auditors and enterprise buyers increasingly need machine-readable proof of what AI is in use and how it is governed. If the inventory is stale, the AI-BOM is unreliable. If the relationships are missing, the audit trail is incomplete. The technical challenge is continuous synchronisation, not one-time documentation.

Practical implication: treat the AI-BOM as a continuously generated governance artifact, not as a one-off compliance deliverable.

Threat narrative

Attacker objective: The attacker objective is to exploit hidden AI dependencies as a route to code tampering, credential exposure or downstream supply-chain compromise.

1. Entry begins when a developer, team or pipeline introduces undocumented AI tooling, a local MCP server, or a model dependency outside formal approval.
2. Escalation occurs when that AI component can reach repositories, secrets, build steps or infrastructure through inherited permissions and trusted integrations.
3. Impact follows when the unseen AI path exposes credentials, modifies code, or widens the blast radius of compromised development systems.

NHI Mgmt Group analysis

AI inventory is now identity infrastructure, not just asset discovery. Once AI systems can generate code, touch repositories and invoke tools, they become governed entities with reach, ownership and revocation requirements. That places inventory in the same practical category as IAM discovery and NHI visibility. Teams that cannot enumerate AI assets cannot define who or what is authorised to act on their behalf, which is why AI inventory should be treated as a core identity governance control, not an adjacent observability task.

Shadow AI creates a control gap that traditional AppSec and endpoint tooling cannot close alone. Code scanners can see dependencies, and endpoint tooling can see processes, but neither proves whether an AI system is approved, connected, or able to consume secrets. The named concept here is AI visibility debt: the accumulation of unknown models, agents and MCP servers that outpace governance. Practitioners should read this as a discovery failure that becomes a privilege failure as soon as AI gains access.

The AI-BOM is becoming the audit language for AI governance maturity. Security teams are moving from asking whether AI exists to proving what it is, where it runs and what it can reach. That aligns naturally with documentation expectations in the EU AI Act, NIST AI RMF and ISO/IEC 42001. In practical terms, organisations will be judged less on AI enthusiasm and more on whether they can produce an accurate, living inventory on demand.

AI risk concentration will shift toward the assets that can act, not the assets that merely exist. The article's emphasis on relationships is the important clue. A model with no reach is a policy question; a model with tool access, secrets exposure or pipeline presence becomes an operational security issue. Identity leaders should expect AI governance to converge with NHI governance around ownership, access scope and lifecycle control.

Inventory only matters when it feeds enforcement. A list of AI assets without blocking, containment or approval controls becomes another catalog of unmanaged risk. The organisations that turn discovery into policy enforcement will be able to reduce both compliance friction and incident blast radius. For practitioners, the real benchmark is whether unknown AI can still act inside the environment.

What this signals

AI inventory will quickly become a prerequisite for any programme that wants to govern agentic workflows, secrets exposure and software supply chain risk at the same time. The practical shift is toward continuous discovery, then policy enforcement, because periodic audits cannot keep pace with developer-led AI adoption.

AI visibility debt: the fastest-growing risk is not a model breach in isolation but an unseen AI component gaining reach inside repositories, pipelines or toolchains. Security leaders should expect inventory data to be pulled into access governance, procurement review and incident response workflows.

For identity programmes, the most important implication is that AI assets now need ownership, lifecycle status and revocation logic in the same way as other machine identities. That is where the boundary between AI governance and NHI governance starts to blur in operational terms.

For practitioners

• Map AI assets to owners and access paths Build the inventory around models, agents, MCP servers, datasets and AI coding tools, then record which repositories, secrets stores and pipelines each one can reach. That makes the inventory operational rather than descriptive.
• Extend discovery into the SDLC Run continuous discovery across developer endpoints, repositories and build systems, not just cloud estates. Shadow AI often appears first in local tooling and pipeline automation, where traditional discovery misses it.
• Generate AI-BOMs from live inventory data Use the inventory as the source of truth for a machine-readable AI-BOM that includes provenance, asset type, detection confidence and regulatory mapping. Keep it synchronized so auditors are seeing current state rather than stale exports.
• Enforce policy on unapproved AI components Block or quarantine unapproved MCP servers, model dependencies and AI assistants when they appear in development workflows. If the inventory can see an asset but enforcement cannot act on it, the control is incomplete.

Key takeaways

• AI inventory is becoming the control layer that makes shadow AI visible, governable and auditable.
• The real risk is not just unidentified AI, but unidentified AI with reach into code, secrets and pipelines.
• Practitioners should connect discovery to enforcement, or the inventory will remain a list rather than a control.

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.

What's in the full article

Xygeni's full article covers the operational detail this post intentionally leaves for the source:

• How its continuous AI inventory approach distinguishes models, agents, MCP servers and AI coding tools in practice
• The AI-BOM fields it recommends for provenance, detection confidence and regulatory mapping
• How AI-SPM links discovery to enforcement across developer endpoints and pipelines
• The operational criteria it uses to decide which AI assets matter most for remediation

👉 Xygeni's full article covers the operational mechanics of discovery, classification and enforcement across the SDLC.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is built for practitioners who need to connect identity controls to modern security programmes.