AI supply chain risks are outpacing traditional AppSec controls

At a glance

What this is: Checkmarx argues that AI supply chain risk is now a governance problem because common AppSec controls do not see AI assets, model-specific failure modes, or MCP-linked dependencies.

Why it matters: IAM, AppSec, and AI security teams need to treat AI services, prompts, agents, and data flows as governed assets because invisible dependencies cannot be assessed, approved, or audited.

By the numbers:

• More than 75% of enterprises are already embedding LLMs, AI SDKs, and AI services directly into their applications.

Context

AI supply chain governance is the control problem that appears when applications start depending on models, prompts, agent frameworks, embeddings, and vector stores that existing AppSec tools were never built to inventory. The security gap is not just technical drift; it is a lifecycle and accountability gap, because teams cannot govern what they cannot see.

In a mature software programme, dependency management assumes packages, containers, and secrets are the primary artefacts to track. AI changes that assumption by introducing runtime behaviour and third-party service terms into the build and deploy chain, which creates a direct governance intersection with identity, access, and non-human trust boundaries.

Key questions

Q: What breaks when AI systems are deployed without a complete inventory?

A: Governance breaks first, then auditability. If teams cannot identify every model, dependency, and owner, they cannot assign risk tiers, apply the right controls, or prove compliance when regulators ask. The result is shadow AI: systems that process data and influence decisions outside the governance perimeter, often for months.

Q: Why do AI supply chain risks create governance exposure even when code scans are clean?

A: Code scans only cover software defects, not model behaviour, runtime prompts, third-party terms, or tool access. That is why a clean SAST or SCA result does not prove the AI layer is safe, compliant, or within policy boundaries.

Q: What do security teams get wrong about AI model dependency?

A: They treat the model as a stable ingredient rather than a live dependency. In practice, providers change pricing, deprecate models and alter behaviour, which means an internal workflow must be maintained like any other upstream service dependency if it is to remain trustworthy.

Q: How should organisations govern external tools used by AI agents?

A: Organisations should review external tools as security inputs, not convenience features. Each tool needs ownership, approval, metadata inspection, and ongoing monitoring for hidden instructions or unexpected behaviour. If an AI agent can act on a tool, then the tool’s provenance and control status should be governed like any other sensitive integration.

Technical breakdown

Why AI dependencies escape traditional software inventories

Traditional AppSec tooling is optimised for source code, libraries, containers, and known vulnerability patterns. AI introduces hosted services, prompt logic, embeddings, and agent frameworks that may live in configuration rather than code, so they never appear in a conventional SBOM or dependency scan. That means discovery has to extend to runtime configuration, environment variables, service calls, and platform integrations. Once those elements are treated as software dependencies, they become subject to inventory, ownership, review, and change control like any other production component.

Practical implication: extend software inventory processes to capture AI services, prompts, and agent connectors as governed dependencies.

What changes when MCP tools and agent frameworks enter the stack

Model Context Protocol servers and agent frameworks expand what an AI component can do by connecting models to tools and data sources. That matters because the access path is no longer only human-to-application, but application-to-tool through a non-human execution path. From an identity perspective, these are machine-mediated privileges, often with delegated access that is harder to review than a human account. The control issue is not merely whether the model is safe, but whether its tool access, scope, and trust chain are explicitly governed.

Practical implication: classify MCP servers and agent connectors as privileged integration points and review their access scope before production use.

Why AI-specific risk assessment must go beyond CVEs

A traditional scanner can tell you whether a package has a known vulnerability, but it cannot tell you whether a model is poisoned, a prompt alters behaviour, or a service provider changed retention terms. Those are governance and trust failures, not conventional code defects. AI supply chain control therefore needs policy enforcement, approved registries, provenance checks, and compliance evidence. In practice, the risk model shifts from static vulnerability lists to dynamic trust assessment across model origin, modification, deployment path, and usage terms.

Practical implication: add AI-specific approval and provenance checks to release gates instead of relying on CVE-based tooling alone.

Threat narrative

Attacker objective: The objective is to exploit invisible AI dependencies to gain unaudited influence over application behaviour, data flow, or downstream tool access.

1. Entry occurs when AI capabilities arrive through hosted LLM services, agent frameworks, prompts, or MCP-connected dependencies that are not visible in standard application inventories.
2. Credential or trust abuse follows when those components obtain tool access, data access, or runtime influence that developers did not explicitly govern.
3. Impact occurs when hidden AI dependencies change application behaviour, widen data exposure, or create compliance gaps that the organisation cannot evidence or audit.

Breaches seen in the wild

• Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

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 supply chain governance has become an identity problem as much as a software problem. Once an application delegates behaviour to hosted models, agent frameworks, or MCP servers, the control question shifts to who or what is allowed to act on behalf of the system. That makes non-human trust boundaries central to AI governance, not a side issue. Practitioners should treat AI dependencies as governed actors with explicit ownership and lifecycle controls.

AI-BOM is the right conceptual response to SBOM-era blindness. SBOMs were designed to enumerate software components, not the behavioural and contractual dependencies introduced by AI services, prompts, and embeddings. A useful AI-BOM has to capture model provenance, tool connectivity, deployment context, and policy constraints. The practitioner conclusion is straightforward: if the inventory does not include AI assets, the control environment is incomplete by design.

Traditional AppSec did not fail because teams lacked discipline; it failed because the threat model changed. Static code analysis, secrets scanning, and SCA still matter, but they do not answer whether an AI component is safe under real prompts, whether a service can alter retention terms, or whether an MCP tool extends privilege. That means governance has to move upstream to discovery and approval. Practitioners should assume AI risk is now a release-governance issue, not just a detection problem.

AI supply chain maturity will increasingly separate governed adoption from unmanaged experimentation. Organisations that can only describe application code will remain stuck at unknown exposure, while those that can inventory, approve, and evidence AI use will be able to scale adoption with less ambiguity. The named concept here is AI visibility debt: the accumulated inability to see AI assets, their tool paths, and their obligations clearly enough to govern them. Practitioners should close that debt before AI use becomes embedded across critical workflows.

From our research library:

• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: NHI Lifecycle Management Guide

What this signals

AI visibility debt: organisations that can inventory code but not AI services will keep discovering risk only after release, because the control boundary has moved from libraries to behaviour, tool access, and runtime configuration.

AI supply chain governance will increasingly sit at the intersection of AppSec, IAM, and AI oversight. Teams that cannot explain who approved an AI dependency, what it can access, and how its terms changed will struggle to demonstrate control.

At minimum, practitioners should expect release gates to evolve from binary vulnerability checks toward provenance, policy, and delegated-access reviews, because that is where the real exposure now lives.

For practitioners

• Build an AI asset inventory Capture hosted LLM services, agent frameworks, prompts, embeddings, vector stores, and MCP servers alongside traditional software dependencies.
• Add AI-specific approval gates Require review of model provenance, tool access, deployment context, and service terms before AI components reach production.
• Classify MCP and agent connectors as privileged integrations Treat tool-using AI pathways as non-human access paths with explicit ownership, scope limits, and change control.
• Replace CVE-only checks with AI risk criteria Assess poisoning risk, unsafe adapters, policy drift, and licensing or privacy term changes that conventional scanners do not detect.
• Document AI governance evidence for audit Maintain compliance-ready records showing what AI is used, who approved it, and which controls govern its runtime behaviour.

Key takeaways

• AI supply chain risk is no longer a niche AI issue because it now sits inside ordinary application delivery and escapes controls built for code and package scanning.
• The article’s evidence points to a structural visibility problem, not a tooling edge case, because hosted models, prompts, agent frameworks, and MCP tools are often invisible to standard inventories.
• Practitioners need AI asset discovery, approval gates, and audit evidence that cover behaviour and delegated access, or governance will remain incomplete.

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.
• AI supply chain: The AI supply chain is the full chain of models, datasets, prompts, tools, and vendors that influence a deployed AI system. It matters because trust cannot be assigned to the application alone. Practitioners need provenance, ownership, and dependency visibility to govern risk.
• 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.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of modern security programmes. It helps identity and security practitioners connect governance, access, and lifecycle control across human and machine identities.