AI supply chain governance needs evidence, not trust, now

At a glance

What this is: This analysis says AI supply chain governance has moved from trust-based process checks to evidence-based control proof, because inventory, ownership, and lifecycle oversight are now central compliance expectations.

Why it matters: IAM, PAM, NHI, and AI security teams need proof of what AI assets exist, who owns them, and how they are controlled, because unaudited models, agents, MCP servers, and skills create governance blind spots.

By the numbers:

• Only 22% of organisations have a formal AI governance policy in place today.
• Leadership believes roughly 27% of AI assets are standardized and governed, while practitioners put the figure at 12%.
• AI-assisted developers commit at 3–4x the rate of their peers but introduce security findings at 10x the rate.

Context

AI governance fails when organisations treat pipeline success as proof of asset control. In this article, the primary gap is not model performance but evidentiary governance: teams cannot reliably inventory AI-enabled components, prove ownership, or show how lifecycle controls were applied across models, agents, MCP servers, and datasets. That matters because modern compliance regimes increasingly expect traceable oversight rather than informal confidence.

The article also shows how AI supply chains blur the line between software, configuration, and runtime behaviour. Traditional AppSec sees code and dependencies, but AI systems often include model files, orchestration layers, agent frameworks, skill files, and tool connections that do not fit standard review gates. That creates a governance gap that intersects directly with identity, because many of these components act with delegated access and need lifecycle control like other non-human identities.

The practical question for security leaders is whether their current inventory, ownership, and approval processes can evidence control over AI assets or merely describe intent. The article’s position is that most organisations are still operating at intent level, which is now below the threshold regulators and auditors will accept.

Key questions

Q: What breaks when organisations rely on green pipelines for AI governance?

A: Green pipelines only prove that a build completed, not that the AI component is understood, owned, or constrained. That fails when models, agents, or MCP servers can execute code, call tools, or access sensitive data outside the checks covered by traditional AppSec. Governance needs inventory, scope, and accountability evidence, not just a passing status.

Q: Why do AI agents, MCP servers, and model files create compliance risk even when code scans pass?

A: They often carry runtime behaviour, delegated access, or execution paths that traditional code and dependency scanners do not inspect. A clean SAST or SCA result does not prove the model or agent is governed, because the risky behaviour may live in the artefact, configuration, or tool connection rather than the source code.

Q: How can organisations tell whether AI governance is actually working?

A: Organisations can tell AI governance is working when they can inventory every agent, explain its purpose, show who owns it, and prove that permissions are tightly scoped. If those four things are missing, the programme has policy language but not operational control. Auditors will notice the gap quickly.

Q: Should organisations treat AI as an application or as an identity?

A: Treat it as an identity when the AI can access data, invoke tools, or participate in workflows that affect business systems. That framing makes least privilege, just-in-time access, and lifecycle governance relevant. If you keep treating it only as an application, you will miss the access and delegation behaviours that actually create risk.

Technical breakdown

Why AI supply chains evade traditional AppSec scanning

AI supply chains do not behave like conventional software dependencies. A model can arrive with loading scripts, deserialization paths, embedded instructions, or runtime hooks that execute when the asset is loaded, while agents and MCP servers can extend access into tools and data that never appear in a source-only review. Static analysis for code and package manifests cannot inspect every model format or policy boundary, so organisations miss risk that lives in artefacts, configuration, and execution context. The core issue is that AI governance must inspect the asset itself, not just the repository around it.

Practical implication: extend scanning and approval controls to model artefacts, agent definitions, and connected tool surfaces, not just source code and packages.

Why the AI-BOM becomes the evidence layer for governance

An AI-BOM is more than a catalogue. In this context it is the control record that ties models, SDKs, agents, MCP servers, skills, and datasets to ownership and oversight requirements. That matters because regulators are not asking whether a team intended to govern AI, but whether it can produce evidence of what exists, who is accountable, and what lifecycle controls were applied. For identity teams, this is familiar territory: inventory without ownership does not establish governance, and governance without lifecycle traceability is not defensible.

Practical implication: treat AI-BOM generation as a governance control and link each AI component to an owner, approval path, and review cadence.

How AI inventory changes delegated access assumptions

The governance challenge is not limited to models producing output. Agent frameworks, skill files, and MCP servers can act with delegated permissions, which means the access question shifts from human sign-in to machine-mediated action. That makes AI systems adjacent to NHI governance because each asset may carry standing access, scoped tool rights, or hidden delegation that should be inventoried and reviewed. The article’s central insight is that trust-based workflow checks do not prove what the AI component could actually do in production.

Practical implication: apply NHI-style ownership and access scope review to AI components that can call tools, reach data, or execute actions.

Threat narrative

Attacker objective: The objective is to exploit ungoverned AI components to gain unchecked access, embed malicious behaviour, or hide control failures inside an apparently healthy pipeline.

1. Entry begins when AI assets are introduced through model downloads, coding assistants, plugins, or agent frameworks that bring hidden runtime behaviour into the environment.
2. Credential or control abuse follows when over-permissioned MCP servers, unreviewed skill files, or delegated tool access expand what the AI component can read or execute.
3. Impact appears when organisations cannot prove inventory, ownership, or lifecycle control, leaving auditors and defenders unable to distinguish governed AI from unmanaged shadow AI.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

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

Evidence, not trust, is now the governing principle for AI supply chains: organisations can no longer treat a green pipeline or a completed checklist as proof of control. The article reflects a broader shift in which regulators expect inventory, ownership, and lifecycle evidence for AI-enabled systems. For identity programmes, that means governance must be demonstrable at the asset level, not inferred from process intent.

AI governance debt is accumulating faster than most teams can inventory it: leadership claims about governed AI assets diverge sharply from practitioner reality, which is exactly the kind of gap auditors and attackers both exploit. The problem is not only adoption, but the absence of a trustworthy control record for models, agents, and connected tooling. Practitioners should treat that divergence as a risk signal, not a reporting variance.

AI components now behave like non-human identities with delegated authority: models, MCP servers, agents, and skill files can carry standing permissions, tool access, and execution paths that resemble machine identity governance problems. That places AI supply chain oversight squarely alongside NHI lifecycle controls, because the issue is who or what can act, on which systems, and under what accountability. The practitioner conclusion is to govern AI artefacts as active identities, not passive files.

Model inventory without lifecycle ownership is a false control: the article makes clear that discovery alone does not satisfy governance if nobody can prove approval, review, monitoring, or offboarding. This is the same failure mode seen in broader identity programmes when access exists without ownership. The field should stop asking whether AI is present and start asking whether it is governed end to end.

AI-BOMs should become the minimum evidence layer for regulated environments: if an organisation cannot map AI assets to owners, controls, and review points, it cannot credibly claim operational oversight. That is not a tooling preference, it is a governance threshold for AI-enabled systems in regulated supply chains. Practitioners should build AI-BOMs that can survive audit, not just internal reporting.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

AI governance debt will surface first in identity-adjacent controls: the organisations most exposed are the ones that can describe their AI strategy but cannot evidence who owns each model, agent, or tool connector. That is where lifecycle governance, access scope, and accountability start to converge, and it is why AI inventory now belongs in the same programme conversation as NHI governance and privileged access oversight.

Shadow AI in the SDLC is an identity problem as much as an application problem: once employees can introduce models, plugins, or agents without durable ownership, the environment starts accumulating non-human actors with unclear authority. Security teams should expect governance failures to appear as missing inventories, unowned tools, and unaudited delegation chains rather than as classic code defects.

For practitioners

• Implement deterministic AI asset discovery Scan repositories, registries, local environments, and connected tool surfaces to identify models, agents, MCP servers, datasets, and skill files that are otherwise invisible to source-only review.
• Create an AI-BOM with named ownership Record each AI component, its business owner, approval status, and lifecycle state so the organisation can evidence control rather than assert it.
• Classify AI components by governance and risk tier Separate development tooling, embedded product AI, and regulated high-risk use cases so review depth matches exposure and accountability requirements.
• Treat delegated AI access as an identity control problem Review what models, agents, and MCP servers can read, call, or execute, then align that authority to least-privilege and explicit offboarding.
• Require evidence before approval gates pass Block release or promotion when the inventory, ownership, or monitoring record is incomplete, because a green pipeline is not proof of governance.

Key takeaways

• AI supply chain governance now depends on evidence of inventory, ownership, and lifecycle control rather than trust in pipeline status.
• The article shows a widening gap between leadership’s view of governed AI assets and the practitioner view, which is exactly where audit failure risk concentrates.
• Security teams should govern AI artefacts like active identities, because delegated access and tool use create control obligations that code scanning alone cannot meet.

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 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.
• 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.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle control. It helps practitioners connect delegated access, ownership, and offboarding to real-world control design.