R
Every once in a while, a research report drops a number so specific and so telling that it just parks itself in your head for weeks. Wiz did that to me back in April with their State of AI in the Cloud 2026 report, and I've been meaning to write about it ever since.
The line is buried on page whatever, under a heading about self-hosted models. 68% of organizations running self-hosted AI ingest those models through third-party software.
That's a mouthful, so let me translate. Two out of three companies with AI models running on their own infrastructure didn't actually decide to run those models. Some vendor product they bought (a knowledge tool, a code assistant, a support router, whatever) quietly shipped a model inside, and the security team never signed off on it because nobody knew there was anything to sign off on.
If you've ever done a security review of a container and moved on because it passed the scan, this is your problem too. And it's not really a "gotcha" or a scare stat. It's just what happens when a new kind of software gets embedded everywhere faster than the tooling that watches it. Which has happened before, several times, and we survived. It's just that the shape of this one is a little different, and worth taking seriously.
I want to walk you through what's actually going on, why it feels weirder than a regular supply chain problem, and what a small, sensible response looks like. No panic, promise.
Picture this. Your engineering team buys a vendor product. Something plain and useful. An internal knowledge platform, say. It ships as a helm chart. The platform team applies it, health checks come back green, everyone moves on.
Inside that chart, though, someone else made a lot of decisions for you. There's probably an embedding model downloaded from Hugging Face at build time. Maybe a local LLM runtime like llama.cpp or vLLM listening on an internal port. A vector database sitting alongside as a sidecar. A retrieval pipeline that scrapes some SharePoint site on a cron. And, increasingly, an MCP server exposing a small set of tools to whichever agent happens to talk to it.
None of that was in the RFP. Nobody on your side reviewed the model weights or the retrieval scope. It's just running.
The Wiz numbers around this are honestly a little wild once you sit with them. 90% of environments had self-hosted AI software of some kind. 80% had MCP servers. 80% had AI coding extensions in IDEs. Whatever your mental picture of "how much AI we have in our environment" is right now, cross-check it against those numbers. It's almost certainly an undercount.
The 68% is telling you the majority of that AI is stuff that arrived as a passenger, not as a feature you deliberately turned on. That's the security surface people are still learning to think about.
We've been doing supply chain security for years now. Log4Shell taught the entire industry in 2021, SBOMs became a federal contract requirement, and every serious CI pipeline has dependency scanning bolted on somewhere. Most engineers know how to reason about "we depend on X, X had a bug, we patch."
Inherited AI breaks that mental model in three specific ways, and once you see them the response starts to make sense.
The artifact is opaque. When you inherit a vulnerable log4j, you can read the code and understand the failure. When you inherit an LLM through a bundled product, the artifact is a pile of weights. You cannot read it, you cannot reason about it statically. You can only observe how it behaves under some inputs, and hope you cover the ones an attacker would try.
The attack surface includes text and data, not just code. Prompt injection. Indirect prompt injection through retrieved documents. Jailbreaks that emerge from unusual phrasings. Behaviors that drift as new data flows through the retrieval side. This is a fluid attack surface, and it doesn't sit still long enough for a static scan to be useful.
Your existing tools mostly don't see this yet. SBOMs catalog libraries and containers. Most don't catalog model weights, tool schemas, or MCP surfaces. Your SAST is looking for injection patterns in code, not in prompts. Your DLP watches structured data flows, not embedding leakage. So the whole thing lives in a blind spot of tools you already trust and pay for.
Put those three together and you get a class of risk that is pervasive, invisible to current tooling, and unpredictable in behavior. That's what the 68% is really pointing at. Not carelessness. Structural blind spot.
Let me be a bit concrete about impact, because "AI supply chain risk" bounces off decision-makers unless you can name a failure mode.
The one that keeps me up is data exposure through embedded retrieval. If a bundled product indexes some internal corpus and answers questions using it, a well-crafted prompt to that product can quietly pull data across trust boundaries the original vendor never intended. Wiz's own commentary mentions that roughly one in five organizations using AI-powered vibe coding platforms had applications with systemic security issues. Same shape of problem, different angle.
Then there's lateral movement through MCP servers. If a product exposes MCP tools that let agents invoke internal APIs, and any of those tools are overprivileged (most first versions are), you've quietly built a lateral movement path that traditional network segmentation can't see. The MCP server thinks it's legitimate. Your firewall agrees. Nobody's wrong, and yet.
There's the compliance surprise. If your compliance team certified "AI is used only in these three approved systems" and the reality is AI is running in forty unapproved places via bundled dependencies, the next audit is going to be a bad afternoon. The gap between AI as tracked and AI as deployed is exactly the sort of thing that shows up as a finding under the EU AI Act.
And finally there's model provenance. When a bundled model gets loaded from an upstream registry at build time and cached in your image, and that upstream registry gets tampered with (which has already happened to Hugging Face and PyPI more than once), you now have a model in your environment whose provenance is fuzzy. If it's been tuned to misbehave under specific conditions, you may not notice for months.
None of these are hypothetical. All of them have publicly reported precedents. What the 68% number contributes is scale. It's saying: this exposure is not a rare edge case, it's the majority condition.
Here's the part I find genuinely comforting about this moment. The response is not heroic. It's a handful of unglamorous work streams that a small team can run over a quarter, they compound nicely, and by the end you're doing better than the vast majority of the industry. Let me walk through them the way I'd actually recommend to a friend.
Run a real AI discovery scan on your own environment. Not through your existing SBOM tooling, because it'll miss most of this. You want to check cloud provider APIs for GPU instances and known AI services, scan container registries for model file extensions (
Build an AI-BOM alongside your regular SBOM. For every inherited AI component, record the model name and version, the source registry, the license, the runtime, whatever tool surface it exposes, and the data flows it touches. This is boring inventory work. It is also the single most valuable artifact you can produce for the next audit cycle. Treat it as a real asset register, not a spreadsheet somebody promises to update.
Separate chosen AI from inherited AI in your governance. Chosen AI, the stuff your team deliberately deployed, probably already has some governance around it. Inherited AI needs its own workflow. Vendor questionnaires that ask specifically about embedded models. Contract clauses that require notification when embedded AI changes. A periodic scan that catches new inherited components as they arrive. Different origin, different controls.
Sandbox inherited AI by default. Any product you bring in that turns out to have embedded AI should run under the strictest network segmentation you're willing to accept for something that produces unpredictable outputs. No blanket outbound. No credentials to production data without an explicit grant. No MCP invocation of internal APIs without a review. Principle of least privilege, applied to a new kind of subject.
Monitor what the AI does, not just how it's configured. Traditional security tools check that things are set up correctly. This risk requires runtime observation: which queries the AI answers with which retrieved data, which tools it invokes, which patterns of prompts it accepts. Building even a lightweight version of this now sets you up nicely for when it stops being optional.
Update your vendor questionnaire. Every product bought between now and end of year should be answering explicit questions about embedded AI. What models. From what source. With what runtime. Exposing what tools. Updated on what cadence. Most vendors don't have great answers yet, and that's actually fine. Ask anyway. Your questionnaire trains the vendor market as much as it protects you.
That's six focused work streams. None of them require heroism. Do them over a quarter and you're comfortably ahead of the 68% baseline the report suggests is the default.
Before I wrap up, let me steelman a few objections I keep hearing.
"We already have a vendor security review." Almost certainly true. Almost certainly your questionnaire doesn't ask about embedded AI in enough detail. Pull it up and check. If "does this product contain or invoke language models" is not on the list, your process is scoped for a slightly earlier world.
"Compliance hasn't flagged this." They will. When AI incidents start showing up in Verizon DBIR breakdowns (they already are), and when sector-specific enforcement lands (early cases are rolling in), compliance teams get pushed to ask what you have. Teams with an AI-BOM already built answer calmly. Teams without one scramble.
"This sounds expensive." The discovery is cheap. The AI-BOM starts as a spreadsheet. The sandboxing applies existing practices. The vendor questionnaire is one paragraph. Doing this now is very cheap. Doing it after an incident is not.
"68% is a Wiz marketing number." Reasonable caution. Wiz has skin in the AI security narrative. That said, the finding is consistent with what other cloud security shops are publishing (the Verizon DBIR AI section, Palo Alto's Unit 42 briefings) and with anecdotes from every security team that has actually run the discovery exercise. Direction of the finding is well supported. Exact number varies by methodology.
Zoom out and this fits a very old shape. Log4Shell in 2021. Public S3 buckets in 2016. Heartbleed in 2014. Every few years, something quietly proliferates through the tech stack, tooling lags adoption, and one day a single well-crafted proof of concept or one high-profile breach forces every organization to run a discovery exercise it should have run a year earlier.
For AI, that moment hasn't happened yet. When it does (and it's a when, not an if), the teams that already have their AI-BOM, their inherited-AI sandbox, and some behavior monitoring are going to look prescient. Not because they were smarter. Because they treated a specific report from a credible vendor as an invitation to do a quiet quarter of work while there was still time.
The 68% number is a gift, honestly. It's the number to bring to your CTO, your CFO, or your board. It's the number that unlocks a calm, deliberate discovery this quarter instead of a chaotic one after the fact.
The line is buried on page whatever, under a heading about self-hosted models. 68% of organizations running self-hosted AI ingest those models through third-party software.
That's a mouthful, so let me translate. Two out of three companies with AI models running on their own infrastructure didn't actually decide to run those models. Some vendor product they bought (a knowledge tool, a code assistant, a support router, whatever) quietly shipped a model inside, and the security team never signed off on it because nobody knew there was anything to sign off on.
If you've ever done a security review of a container and moved on because it passed the scan, this is your problem too. And it's not really a "gotcha" or a scare stat. It's just what happens when a new kind of software gets embedded everywhere faster than the tooling that watches it. Which has happened before, several times, and we survived. It's just that the shape of this one is a little different, and worth taking seriously.
I want to walk you through what's actually going on, why it feels weirder than a regular supply chain problem, and what a small, sensible response looks like. No panic, promise.
The scenario nobody planned
Picture this. Your engineering team buys a vendor product. Something plain and useful. An internal knowledge platform, say. It ships as a helm chart. The platform team applies it, health checks come back green, everyone moves on.
Inside that chart, though, someone else made a lot of decisions for you. There's probably an embedding model downloaded from Hugging Face at build time. Maybe a local LLM runtime like llama.cpp or vLLM listening on an internal port. A vector database sitting alongside as a sidecar. A retrieval pipeline that scrapes some SharePoint site on a cron. And, increasingly, an MCP server exposing a small set of tools to whichever agent happens to talk to it.
None of that was in the RFP. Nobody on your side reviewed the model weights or the retrieval scope. It's just running.
The Wiz numbers around this are honestly a little wild once you sit with them. 90% of environments had self-hosted AI software of some kind. 80% had MCP servers. 80% had AI coding extensions in IDEs. Whatever your mental picture of "how much AI we have in our environment" is right now, cross-check it against those numbers. It's almost certainly an undercount.
The 68% is telling you the majority of that AI is stuff that arrived as a passenger, not as a feature you deliberately turned on. That's the security surface people are still learning to think about.
Why this feels different from log4j
We've been doing supply chain security for years now. Log4Shell taught the entire industry in 2021, SBOMs became a federal contract requirement, and every serious CI pipeline has dependency scanning bolted on somewhere. Most engineers know how to reason about "we depend on X, X had a bug, we patch."
Inherited AI breaks that mental model in three specific ways, and once you see them the response starts to make sense.
The artifact is opaque. When you inherit a vulnerable log4j, you can read the code and understand the failure. When you inherit an LLM through a bundled product, the artifact is a pile of weights. You cannot read it, you cannot reason about it statically. You can only observe how it behaves under some inputs, and hope you cover the ones an attacker would try.
The attack surface includes text and data, not just code. Prompt injection. Indirect prompt injection through retrieved documents. Jailbreaks that emerge from unusual phrasings. Behaviors that drift as new data flows through the retrieval side. This is a fluid attack surface, and it doesn't sit still long enough for a static scan to be useful.
Your existing tools mostly don't see this yet. SBOMs catalog libraries and containers. Most don't catalog model weights, tool schemas, or MCP surfaces. Your SAST is looking for injection patterns in code, not in prompts. Your DLP watches structured data flows, not embedding leakage. So the whole thing lives in a blind spot of tools you already trust and pay for.
Put those three together and you get a class of risk that is pervasive, invisible to current tooling, and unpredictable in behavior. That's what the 68% is really pointing at. Not carelessness. Structural blind spot.
What can actually go wrong
Let me be a bit concrete about impact, because "AI supply chain risk" bounces off decision-makers unless you can name a failure mode.
The one that keeps me up is data exposure through embedded retrieval. If a bundled product indexes some internal corpus and answers questions using it, a well-crafted prompt to that product can quietly pull data across trust boundaries the original vendor never intended. Wiz's own commentary mentions that roughly one in five organizations using AI-powered vibe coding platforms had applications with systemic security issues. Same shape of problem, different angle.
Then there's lateral movement through MCP servers. If a product exposes MCP tools that let agents invoke internal APIs, and any of those tools are overprivileged (most first versions are), you've quietly built a lateral movement path that traditional network segmentation can't see. The MCP server thinks it's legitimate. Your firewall agrees. Nobody's wrong, and yet.
There's the compliance surprise. If your compliance team certified "AI is used only in these three approved systems" and the reality is AI is running in forty unapproved places via bundled dependencies, the next audit is going to be a bad afternoon. The gap between AI as tracked and AI as deployed is exactly the sort of thing that shows up as a finding under the EU AI Act.
And finally there's model provenance. When a bundled model gets loaded from an upstream registry at build time and cached in your image, and that upstream registry gets tampered with (which has already happened to Hugging Face and PyPI more than once), you now have a model in your environment whose provenance is fuzzy. If it's been tuned to misbehave under specific conditions, you may not notice for months.
None of these are hypothetical. All of them have publicly reported precedents. What the 68% number contributes is scale. It's saying: this exposure is not a rare edge case, it's the majority condition.
What a reasonable response looks like
Here's the part I find genuinely comforting about this moment. The response is not heroic. It's a handful of unglamorous work streams that a small team can run over a quarter, they compound nicely, and by the end you're doing better than the vast majority of the industry. Let me walk through them the way I'd actually recommend to a friend.
Run a real AI discovery scan on your own environment. Not through your existing SBOM tooling, because it'll miss most of this. You want to check cloud provider APIs for GPU instances and known AI services, scan container registries for model file extensions (
.gguf, .safetensors, unusual .bin files in AI-looking paths), look for known runtime processes (llama.cpp, vllm, ollama, text-generation-inference), and probe internal networks for MCP server signatures. Every team that does this exercise for the first time is a little surprised by the output. That surprise is the point.Build an AI-BOM alongside your regular SBOM. For every inherited AI component, record the model name and version, the source registry, the license, the runtime, whatever tool surface it exposes, and the data flows it touches. This is boring inventory work. It is also the single most valuable artifact you can produce for the next audit cycle. Treat it as a real asset register, not a spreadsheet somebody promises to update.
Separate chosen AI from inherited AI in your governance. Chosen AI, the stuff your team deliberately deployed, probably already has some governance around it. Inherited AI needs its own workflow. Vendor questionnaires that ask specifically about embedded models. Contract clauses that require notification when embedded AI changes. A periodic scan that catches new inherited components as they arrive. Different origin, different controls.
Sandbox inherited AI by default. Any product you bring in that turns out to have embedded AI should run under the strictest network segmentation you're willing to accept for something that produces unpredictable outputs. No blanket outbound. No credentials to production data without an explicit grant. No MCP invocation of internal APIs without a review. Principle of least privilege, applied to a new kind of subject.
Monitor what the AI does, not just how it's configured. Traditional security tools check that things are set up correctly. This risk requires runtime observation: which queries the AI answers with which retrieved data, which tools it invokes, which patterns of prompts it accepts. Building even a lightweight version of this now sets you up nicely for when it stops being optional.
Update your vendor questionnaire. Every product bought between now and end of year should be answering explicit questions about embedded AI. What models. From what source. With what runtime. Exposing what tools. Updated on what cadence. Most vendors don't have great answers yet, and that's actually fine. Ask anyway. Your questionnaire trains the vendor market as much as it protects you.
That's six focused work streams. None of them require heroism. Do them over a quarter and you're comfortably ahead of the 68% baseline the report suggests is the default.
A few honest pushbacks
Before I wrap up, let me steelman a few objections I keep hearing.
"We already have a vendor security review." Almost certainly true. Almost certainly your questionnaire doesn't ask about embedded AI in enough detail. Pull it up and check. If "does this product contain or invoke language models" is not on the list, your process is scoped for a slightly earlier world.
"Compliance hasn't flagged this." They will. When AI incidents start showing up in Verizon DBIR breakdowns (they already are), and when sector-specific enforcement lands (early cases are rolling in), compliance teams get pushed to ask what you have. Teams with an AI-BOM already built answer calmly. Teams without one scramble.
"This sounds expensive." The discovery is cheap. The AI-BOM starts as a spreadsheet. The sandboxing applies existing practices. The vendor questionnaire is one paragraph. Doing this now is very cheap. Doing it after an incident is not.
"68% is a Wiz marketing number." Reasonable caution. Wiz has skin in the AI security narrative. That said, the finding is consistent with what other cloud security shops are publishing (the Verizon DBIR AI section, Palo Alto's Unit 42 briefings) and with anecdotes from every security team that has actually run the discovery exercise. Direction of the finding is well supported. Exact number varies by methodology.
The bigger picture
Zoom out and this fits a very old shape. Log4Shell in 2021. Public S3 buckets in 2016. Heartbleed in 2014. Every few years, something quietly proliferates through the tech stack, tooling lags adoption, and one day a single well-crafted proof of concept or one high-profile breach forces every organization to run a discovery exercise it should have run a year earlier.
For AI, that moment hasn't happened yet. When it does (and it's a when, not an if), the teams that already have their AI-BOM, their inherited-AI sandbox, and some behavior monitoring are going to look prescient. Not because they were smarter. Because they treated a specific report from a credible vendor as an invitation to do a quiet quarter of work while there was still time.
The 68% number is a gift, honestly. It's the number to bring to your CTO, your CFO, or your board. It's the number that unlocks a calm, deliberate discovery this quarter instead of a chaotic one after the fact.