The Regulators Already Assume You Have an AI Inventory. Do You? 

The regulators are done with “Trust as policy”.  

That chain used to be an internal maturity problem, something a security program could work on over time: 

A developer trusts AI-generated code because it compiles. A reviewer trusts an AI-generated summary because it reads plausibly. A security team trusts scanner output because the pipeline shows green. An auditor trusts the evidence because the checklist is complete. At no point does anyone verify the thing itself. Each person is only confirming that the step before them looked fine. 

It isn’t anymore. The EU AI Act, the Cyber Resilience Act, NIS2, and DORA all now assume, or require, documented inventory and demonstrable oversight of AI-enabled systems. ISO 42001 turns that baseline into an actual management system with ownership, risk assessment, lifecycle controls, monitoring. None of these frameworks will accept “the pipeline was green” as evidence. They ask different questions: can you produce the inventory, and can you prove the policy held. 

That’s a gap most organizations are about to discover the hard way. Only 22% of organizations have a formal AI governance policy in place today. The gap runs deeper than adoption, too, leadership believes roughly 27% of AI assets are standardized and governed; the practitioners closest to them put it at 12%. That’s precisely the kind of gap between the compliance report and the ground truth an auditor is trained to find. 

But how complex can it be to produce a list of AI assets?  

The AI Supply Chain Is Bigger Than You Think, and Growing Faster 

It’s tempting to think of AI in the supply chain as a handful of LLM API calls. In practice, the estate keeps expanding to include agent frameworks that can take autonomous action, orchestration layers, and increasingly the MCP servers that connect assistants to tools, files, and data. 

Every model a team downloads comes bundled with more than weights. It ships loading scripts and setup files that execute in the environment the moment the model loads — no pull request, no code review, no security gate. A pickle-backed file can carry executable opcodes and Torch rebuild helpers capable of deserialization attacks. A trust_remote_code=True call hands a downloaded script a runtime pass. Coding assistants compound the problem from the other direction: a model recommends a package, the package is malicious, and the vulnerability isn’t written into the code — it’s installed. 

AI-assisted developers commit at 3–4x the rate of their peers but introduce security findings at 10x the rate (Cloud Security Alliance, 2026). A meaningful share of what’s accumulating underneath that number isn’t a code vulnerability at all — it’s an ungoverned model, an over-permissioned MCP server, a skill file carrying an instruction nobody reviewed. None of that maps to a checklist written before this asset class existed. 

AppSec Tooling was Never Built to Handle This  

This isn’t about developers behaving badly. It’s about pressure. Developers under deadline for whatever gets them to “done” fastest, and unvetted AI tooling is very good at that. Security teams generally know which enterprise AI platforms are officially approved, but they have far less visibility into the browser extensions, IDE plugins, CLI agents, and MCP servers developers are utilizing day-to-day. 

Most AppSec tooling can’t answer that question, because it was never built to see this asset class. SAST reads source code. SCA reads declared dependencies. Neither can open a .pt, .pth, or .pkl file and tell you what’s inside it. 

The reason the tooling can’t see it is that AI components don’t behave like the software supply chain regulation and AppSec were built around. A meaningful share of them aren’t dependencies at all. They’re an API call to a model endpoint, a system prompt in a config file, a skill file, an agent definition. 

The risk question shifts accordingly: not “is this version vulnerable?” But, is this model poisoned? Is this MCP server over-permissioned? Does this skill file carry an injected instruction nobody reviewed? None of these questions map cleanly to a checklist that was written before this asset class existed. 

Essentially, AI adds a second, more complex layer that traditional AppSec tooling today cannot find, including: 

• Who, or what, created this code? 

• What context did the model have access to when it generated it? 

• If an agent called tools, which tools, and what data did it read? 

• Was the human-in-the-loop review a real decision, or a rubber stamp on the way to shipping? 

None of this replaces existing controls. SCA still matters; an orchestration framework or AI library can absolutely carry a critical CVE, and that’s exactly what SCA was built to catch. AI-specific risk requires going beyond that, not instead of it. 

The Solution: One Inventory, Mapped to What Regulators Ask For 

You cannot govern what you cannot inventory. And you can’t inventory it by asking the AI to report on itself. That just turns detection into another assertion.  

This is where AI Supply Chain Security comes in. Not a bolt-on scanner, but deterministic discovery of every model, MCP server, agent, and dataset across your applications. 

LLM Scanners connect directly to where models live: Hugging Face repositories, internal registries, local directories, Git repos, and runs static analysis across the full project surface: Python source, notebooks, and binary model formats including PyTorch, Keras, and pickle-backed files, looking for insecure deserialization, dangerous model loaders, shell execution, and the specific opcodes and rebuild helpers that let a model execute code at load time. The model is never run. No performance hit, no disruption to the ML pipeline. The same rigor extends to MCP servers, evaluating what a connected server’s tools are scoped to do against what’s declared, and to agent frameworks.  

Every scan feeds one artifact: the AI-BOM, an exportable inventory of every model, SDK, agent, MCP server, skill, and dataset across the estate, mapped directly to what EU AI Act, NIS2, DORA, and ISO 42001 documentation requirements ask for. 

AI Regulatory and Standards Landscape: How Checkmarx Can Help 

A policy without a gate is advice, not governance. Enforceable governance means AI components get scored, owned, and gated with the same discipline as any other security finding, using detection deterministic enough to hold up as evidence, not a confidence score from a model grading its own work. 

And because AI adoption is no longer confined to engineering, governance can’t stop at the traditional AppSec perimeter either. Every employee is increasingly a developer of something, a script, an automation, an internal tool, which means governance needs lightweight controls that reach parts of the organization that were never on security’s radar before.  

Visibility alone isn’t the finish line. Once you have it, you still need to assess and categorize what you’re looking at. Governance itself splits into two related but distinct questions, and they carry different evidence requirements: 

• Process — how developers use AI while building software. Which coding assistants are approved, what data can go into a prompt, whether generated code can be accepted directly, what human review is required, and how accountability is preserved. 

• Product — what AI is embedded in what you ship. Which LLMs or providers are in play, what data they process, whether the use case is high-risk, regulated, customer-facing, or safety-relevant, and what documentation or monitoring that triggers. 

Treat these as one undifferentiated “AI governance” conversation, and you’ll end up with partial coverage of either. 

This distinction matters because mandatory compliance is a current driver, not a future one. The AI regulatory and standards landscape is expanding, and the organizations that get ahead of this won’t be the ones that ban AI tooling or the ones that let it run unmanaged. They’ll be the ones that can say, with evidence rather than confidence, exactly what AI is in their pipeline, what it’s capable of, and who’s accountable for it. 

Want the full conversation? We recently sat down with security research, AI supply chain product, and global AppSec advisory leaders for a live panel discussion — “Shadow AI in the SDLC”— covering visibility, MCP risk, and the road to governed AI.