TL;DR: More than 75% of enterprises are already embedding LLMs, AI SDKs, and AI services into applications, yet traditional AppSec tooling does not inventory AI assets, assess model-specific risk, or expose MCP and prompt-driven dependencies, according to Checkmarx. The governance gap is now structural: visibility, policy enforcement, and compliance evidence have to extend beyond SBOM-era assumptions.
Editorial analysis by NHI Mgmt Group, based on content published by Checkmarx: “Securing Your AI Supply Chain: Your AI Is Running, But You Don’t Know What It’s Doing”.
By the numbers:
- More than 75% of enterprises are already embedding LLMs, AI SDKs, and AI services directly into their applications.
Key questions
Q: What breaks when AI systems are deployed without a complete inventory?
A: Governance breaks first, then auditability.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI supply chain risks are outpacing traditional AppSec controls