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

At a glance

What this is: This is an analysis of why AI-BOMs are becoming the practical control plane for shadow AI, with MCP visibility identified as the most common inventory failure point.

Why it matters: It matters because IAM, IGA, and NHI teams need a discoverable, auditable view of AI tool connections before agents and models create undocumented access paths.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 53% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Obot's analysis of AI-BOMs, MCP governance, and shadow AI

Context

AI-BOMs are the inventory layer that makes AI systems governable. In this article, AI-BOM means a machine-readable record of model lineage, training data, software dependencies, tool integrations, and the MCP connections that agents use to reach internal systems.

The governance gap is not theoretical. Enterprises are already adopting shadow AI tools, unapproved model integrations, and undocumented MCP server connections faster than review processes can classify them, which leaves identity, access, and compliance teams without a reliable control baseline.

For identity programmes, the key issue is that AI inventory now includes non-human access paths that look more like workload identity than traditional application rollout. If those paths are not discoverable, they cannot be approved, scoped, recertified, or audited in any durable way.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Why do AI-BOMs matter when organisations already have software inventories?

A: Traditional software inventories describe components, but they usually miss the runtime relationships that matter in AI systems. AI-BOMs extend the inventory to models, datasets, configuration, dependencies, and tool connections. That matters because governance depends on knowing what the system can reach, not just what package it contains.

Q: What breaks when MCP connections are not discovered and tracked?

A: The organisation loses the ability to prove which AI system had access to which tool, data source, or credential path. That breaks approval, recertification, audit response, and incident containment at the same time. In practice, the hidden connection becomes the hidden risk surface, and the inventory cannot support governance.

Q: Who should own AI-BOM governance in an enterprise?

A: Ownership should sit across identity, security architecture, and platform teams, with clear accountability for intake, discovery, policy, and logging. AI-BOMs are not only a compliance artefact. They are an operating control that links procurement, access scoping, and evidence generation across the AI lifecycle.

Technical breakdown

Why AI-BOMs need machine-readable provenance

An AI-BOM is only useful if its data can be consumed by other systems. Machine-readable formats such as CycloneDX or SPDX let security tools ingest model lineage, dataset provenance, version history, and dependency relationships without manual re-entry. That matters because AI governance breaks down when inventories live in spreadsheets, PDFs, or scattered ticket comments. A useful AI-BOM must capture what was built, what it depends on, and what changed across versions so that review, audit, and exception handling can be automated rather than improvised.

Practical implication: Practitioners should insist on machine-readable inventory data, not narrative documentation, before approving AI deployments.

How MCP connections create shadow AI inventory gaps

Model Context Protocol connections are the runtime bridge between an AI system and the tools or data sources it can use. In practice, that means an MCP server may grant an agent access to CRM records, code repositories, ticketing systems, or cloud storage with little formal visibility. If the connection exists only in a local config file or a committed script, it becomes an undocumented dependency that never enters the governance catalogue. The inventory gap is not just missing metadata. It is missing control over a live access path.

Practical implication: Teams should treat every unmanaged MCP connection as an inventory defect and an access defect at the same time.

What the governance stack must do beyond discovery

Discovery is the first layer, but it is not governance on its own. AI procurement intake decides what may enter the environment, policy management defines the decision rules, and audit logging preserves evidence of what was approved and accessed. Without intake, discovery produces noise. Without policy, approvals are inconsistent. Without logging, the organisation cannot prove control after the fact. The stack has to function as one system because AI tools can be added faster than manual oversight can be refreshed.

Practical implication: Security and identity teams should build intake, policy, and logging as connected workflows instead of separate review activities.

Threat narrative

Attacker objective: The objective is to obtain or preserve ungoverned AI-enabled access paths that bypass review, scope, and audit controls.

1. Entry occurs when developers connect AI agents or models to internal systems through undocumented MCP servers, local configuration files, or unreviewed scripts.
2. Escalation occurs when those connections expose credentials, tool permissions, or data access that were never captured in the AI inventory or access review process.
3. Impact occurs when the organisation cannot prove which AI systems had access to which data or tools, leaving audit, compliance, and containment efforts behind the deployment footprint.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-BOMs are becoming the minimum viable control for shadow AI. Once enterprises allow agents, models, and MCP connections to proliferate without inventory, the governance problem is no longer about policy design alone. It becomes a visibility failure across discovery, approval, and evidence. The implication is that identity teams must treat AI inventory as a living control surface, not a documentation exercise.

MCP governance is where AI inventory either becomes operational or collapses. An AI-BOM that records model lineage but ignores runtime tool connections still misses the path an agent uses to reach data and systems. That is a control gap, not a reporting gap, because the undocumented connection is the access path. Practitioners should read MCP visibility as part of the non-human identity boundary, not as a separate platform concern.

Shadow AI now behaves like shadow IT with a shorter remediation window. The cloud storage era allowed years of drift before governance caught up. AI tools and agent connections are moving faster, and the August 2026 enforcement horizon compresses the time available to discover, classify, and document what is already running. Organisations that wait for formal mandate will be retrofitting under pressure.

AI governance will increasingly converge with NHI governance and lifecycle controls. Once an agent can connect to internal tools, its access should be treated as an inventory item with provisioning, scoping, review, and offboarding requirements. That does not mean every AI tool is autonomous. It means the access footprint is machine-owned and must be governed with the same discipline applied to service accounts and workload identities.

Runtime access blind spot: The specific failure mode here is assuming that model approval covers the connection layer. It does not. A governed model can still operate through an untracked MCP server, and that is the point where provenance, accountability, and access control break apart. Identity programmes should therefore measure the gap between approved AI systems and discovered runtime connections as a first-class risk signal.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, showing that scoping is a measurable control rather than a policy preference.
• That same survey found only 44% of organisations have policies to manage AI agents, which makes inventory-led governance the next practical step for most teams.

What this signals

AI-BOM programmes will increasingly determine whether AI governance is auditable or performative. With 70% of organisations already granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, the access problem is already outpacing most review models.

Runtime connection blindness: the gap between approved models and discovered MCP integrations will become a standard identity risk metric. Teams that cannot measure that gap will struggle to defend scope, ownership, or offboarding decisions when regulators or auditors ask for evidence.

For IAM and NHI programmes, the immediate planning assumption should be that every AI deployment adds a machine-owned access path that must be discoverable, scoped, and retired like any other identity lifecycle object.

For practitioners

• Inventory every AI and MCP connection continuously Audit agents, model integrations, and MCP server connections from code repositories, local configs, and production environments. Reconcile discovered connections against the approved inventory so that undocumented access paths are visible before the next review cycle.
• Separate model approval from tool-connection approval Require a distinct review for each tool or data source an AI system can reach through MCP. A model may be approved while its runtime connections remain blocked until scope, data access, and logging are documented.
• Build provenance into intake workflow Collect model version, training-data source, dependency, and configuration details at intake rather than after deployment. Use the AI-BOM record as the authoritative artefact for review, exception handling, and future audit requests.
• Tie audit logging to access decisioning Log which AI systems used which MCP servers, what data sources they reached, and who approved the integration. Link those records to policy so that discovery, decisioning, and evidence stay joined throughout the lifecycle.

Key takeaways

• AI-BOMs are becoming the control layer that makes shadow AI visible enough to govern.
• MCP connections are the most likely place for inventory gaps to become access gaps.
• Identity teams should build discovery, approval, and logging into one AI governance lifecycle before enforcement pressure arrives.

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.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• 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

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

• A structured AI-BOM breakdown covering datasets, model metadata, software libraries, hardware resources, and configuration files.
• A step-by-step governance stack for discovery, intake, policy management, and audit logging across AI deployments.
• Practical guidance on where MCP visibility fits into continuous inventory maintenance and enforcement.
• The implementation logic behind building an approval workflow before the next AI deployment request arrives.

👉 Obot's full article covers AI-BOM structure, MCP visibility, and the governance stack in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity security across human and non-human access paths, it is worth exploring.