AI-BOM governance is now the control plane for shadow AI

At a glance

What this is: This is an analysis of AI-BOM governance as the inventory and control layer for shadow AI, with a focus on model provenance, tool integrations and MCP connections.

Why it matters: It matters because IAM, NHI and AI governance teams need a way to inventory, approve and audit agent-linked access paths before regulatory scrutiny forces retrofit controls.

Context

AI-BOMs are the missing inventory layer for AI systems that now reach into data, tools and runtime connections faster than governance teams can review them. In practical terms, they extend SBOM thinking to cover model lineage, training data, tool integrations and MCP connections that are often created outside formal procurement or security review.

The governance problem is not just visibility. Enterprises cannot enforce policy, prove accountability or support audit evidence if AI services and agent connections live in local files, scripts or unmanaged integrations. The article frames AI-BOMs as the structural answer to that gap, especially as the EU AI Act deadline approaches.

Key questions

Q: What breaks when AI-BOMs are missing for shadow AI and MCP connections?

A: Governance breaks first. Without an AI-BOM, teams cannot reliably inventory models, datasets, integrations or MCP links, so approvals, logging and accountability all lose their anchor. The result is a control environment where AI usage can expand faster than security teams can classify or evidence it.

Q: Why do undocumented MCP connections create AI governance risk?

A: They create live access paths that often bypass procurement, security review and identity oversight. If an agent can reach databases or SaaS tools through an untracked MCP server, the organisation has no dependable way to prove what was connected, who approved it or what data it could touch.

Q: When should organisations prioritise the EU AI Act over voluntary AI governance frameworks?

A: Prioritise the EU AI Act whenever an AI system is in scope for EU users or deployment, because it is binding and extraterritorial. Voluntary frameworks can support internal governance, but they do not replace legal obligations. The first move is to classify each system into the Act’s risk tiers, then build controls around the applicable obligations and deadlines.

Q: Should AI governance be handled as a policy problem or an identity problem?

A: Both, but identity comes first when agents can connect to internal systems. Policy says what should happen, while identity and access controls determine what the agent can actually reach. If the access path is unmanaged, policy cannot prove or prevent the connection.

Technical breakdown

What an AI-BOM actually inventories

An AI-BOM is a machine-readable inventory for the components that shape an AI system’s behaviour and risk. That includes datasets, models, software libraries, configuration files, hardware resources and version history, plus the relationships between them. The point is not a static catalog of names. It is provenance, dependency and reproducibility data that lets teams trace what the system consumed, how it was assembled and where control boundaries should exist. Without that structure, policy and audit work become guesswork. Practical implication: inventory the data, model and configuration chain before treating an AI deployment as governable.

Practical implication: inventory the data, model and configuration chain before treating an AI deployment as governable.

Why MCP connections break AI-BOM visibility

MCP turns agent integrations into a live control problem because the connection layer is where AI systems reach internal tools and data. If an MCP server is created in a local config file or a shared script, it can remain invisible to security, IAM and compliance teams even while it provides real access. That makes the connection itself part of the governance surface, not just the model. The failure mode is not complexity alone, but unmanaged runtime linkage. Practical implication: treat MCP discovery as a prerequisite to any AI inventory programme, not a later audit task.

Practical implication: treat MCP discovery as a prerequisite to any AI inventory programme, not a later audit task.

From inventory to enforceable governance

AI-BOMs solve visibility, but governance only becomes real when inventory feeds approval, policy and logging. Discovery tells you what exists, intake decides what may exist, policy defines the acceptable pattern and logging proves what happened. That sequence matters because a list of AI assets without control points is just documentation. The article’s key lesson is that AI governance fails when the control plane is fragmented across procurement, security and operations. Practical implication: connect inventory generation to approval workflows and audit logging as one continuous process.

Practical implication: connect inventory generation to approval workflows and audit logging as one continuous process.

Threat narrative

Attacker objective: The objective is to create or exploit unmanaged AI access paths that evade inventory, oversight and accountability.

1. Entry occurs when undiscovered AI tools, unapproved model integrations or undocumented MCP connections are introduced into the environment outside formal review.
2. Credential or access exposure follows when agents use those MCP connections to reach internal databases, ticketing systems or cloud storage through unvetted paths.
3. Escalation happens as the organisation loses track of which tools, models and dependencies are active, making the access path invisible to governance controls.
4. Impact is the inability to inventory, approve or prove control over AI-driven access paths before regulatory scrutiny or operational misuse exposes the gap.

Breaches seen in the wild

• Samsung ChatGPT leak 2023: Samsung staff pasted chip source code and meeting notes into ChatGPT weeks after it was allowed, leading Samsung to restrict generative AI tools.
• OmniGPT breach claim 2025: A hacker claims to have leaked 34 million OmniGPT AI chat messages holding users' API keys and credentials; OmniGPT has not confirmed it.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-BOM governance is now a control plane problem, not a documentation exercise. The article shows that AI inventories only matter when they connect discovery, approval, policy and logging into one operational loop. That is the same governance lesson identity teams learned with cloud access and software supply chains: visibility without enforcement does not change risk. Practitioners should treat AI-BOMs as a living control plane rather than an archive.

MCP governance is the point where AI inventory either stays accurate or becomes fiction. MCP connections are the runtime links that let agents act on internal systems, which means they are part of the governed access surface. When those links live in local config files or scripts, the organisation has a control gap, not just an inventory gap. The practitioner conclusion is clear: if MCP discovery is incomplete, the AI-BOM is incomplete.

Undocumented AI tool integrations create shadow AI debt: the longer a connection remains outside procurement and security review, the harder it becomes to prove who approved it, what it can reach and why it exists. That is not just a compliance problem. It is a structural accountability problem for IAM, NHI and AI governance teams. The control question shifts from “what model is this?” to “what access path does this agent open?”

Shadow AI should be governed as an identity and access problem before it is framed as an AI policy problem. The article’s strongest insight is that model provenance matters, but runtime access matters more when agents connect to data and tools. AI-BOMs make sense only if they are tied to intake, least privilege and audit evidence. Practitioners should align AI governance with identity lifecycle controls, not leave it as an isolated AI programme.

The AI-BOM is becoming the lingua franca for proving AI accountability across procurement, security and compliance. That matters because regulators do not just care whether an AI system exists. They care whether an organisation can explain its components, dependencies and decision paths. The practical implication is that governance teams should standardise on machine-readable inventory and continuous discovery rather than relying on annual attestation cycles.

From our research library:

• 63% of organisations surveyed lacked AI governance policies to manage AI or prevent shadow AI, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

AI-BOMs only work when discovery is continuous. A static inventory cannot keep up with agents, model updates and runtime tool links that appear outside normal procurement channels. For practitioners, the programme shift is from periodic review to living visibility across the AI and identity stack.

Undocumented MCP connections are the new governance blind spot. When an agent can reach internal systems through a connection that never entered security intake, the organisation has an access path it cannot explain. That is why AI governance now needs identity controls, audit evidence and runtime discovery in the same operating model.

Shadow AI governance debt: the longer tool integrations remain unmanaged, the more expensive they become to classify, approve and evidence. That debt is already visible in organisations that can name their models but not the connections those models use to act.

For practitioners

• Audit unmanaged MCP connections Map every MCP server, agent integration and tool link currently in use, including local configuration files and shared scripts that may never have gone through procurement or security review.
• Build machine-readable AI-BOM records Capture dataset provenance, model versioning, software dependencies, configuration files and relationship metadata in a format that can be consumed by security and compliance tooling.
• Connect intake to approval workflows Define which AI deployments, agent connections and tool integrations require review before production, then route them through a documented risk and sign-off process.
• Tie audit logging to runtime access Record which agents accessed which systems through which MCP connections so the inventory can support evidence, not just asset discovery.
• Classify systems before the deadline Use a risk-tiered review path to separate internal productivity tools from systems that influence consequential decisions, then prioritise the latter for governance hardening.

Key takeaways

• AI-BOMs matter because they turn shadow AI from an unseen sprawl problem into something security and governance teams can inventory and control.
• MCP connections are the critical gap because they can create real access paths even when the underlying model is understood.
• Practitioners should connect discovery, intake, policy and logging now, before regulatory pressure forces a retrofit.

Key terms

• 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.
• MCP Connection: An MCP Connection is the live link between an AI agent and an external tool, data source, or service using the Model Context Protocol. It defines how the agent discovers capabilities, exchanges context, and requests actions. Security controls should govern authentication, authorization, scope, logging, and revocation for each connection.
• 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.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.