AI Visibility Gap: Why CSPM Misses AI Workloads

The AI Visibility Gap: Why You Can't Secure What You Can't See

May 12, 2026

Key Takeaways

The AI visibility gap is an architecture problem, not a configuration one. Cloud security tools were built to inventory VMs and containers, not models, agents, and MCP servers.
CSPMs are agentless and snapshot-based. AI workloads are ephemeral, behavioral, and identity-driven. The two shapes don’t match.
Every CISO should be able to name the four AI visibility blind spots: models, agents, MCPs, and non-human identities (NHIs).
Real AI visibility in 2026 has to be runtime, behavioral, and identity-aware. Static lists and config snapshots cannot close the gap.
AI-Inventory, AI-BOM, and AI-NHI are three capabilities answering one question: what’s actually running, and who’s responsible for it?

What “AI visibility gap” actually means

I’ve spent most of my career running security at companies that were three steps behind their own infrastructure. No judgement because in many ways that’s the job… you catch up, the platform team ships something new, you catch up again. You could consider it a treadmill to be sure, but at least it was a functioning treadmill.

But it’s now 2026 and AI just broke the treadmill.

The AI visibility gap is the distance between what your cloud security tools believe is in your environment and what’s actually running there. It’s the Bedrock model your customer support team is calling from a Lambda. The LangChain wrapper a developer added to a Kubernetes pod three sprints ago. The MCP server an engineer stood up to let an internal agent query your warehouse. You know exactly what I’m talking about.

None of this is malicious. All of it is invisible to the tools most of us bought between 2019 and 2023.

That’s the gap. The tools we bought back then weren’t wrong. They were the best of what we had to work with. But at this point, they’re architecturally outdated. What I mean by that is, the system fix is not as simple as a config problem you patch with a new policy. It’s an architecture problem you patch by changing how your platform sees your environment in the first place.

I hear a version of this on every CISO call I take. The board asked for an AI strategy in February and the platform team had something in production by April. But then the security team got a Slack ping in May asking whether it was OK to expose it to customers. By the time anyone runs an inventory, there are six AI workloads in three accounts and nobody can produce a clean list. The process isn’t the issue, but the tooling can’t keep pace because the platform we built was never designed to see this stuff.

The four blind spots

When I sit down with a security team and ask them to inventory their AI estate, I usually get a list of model endpoints. Sometimes a list of API keys. Almost never a complete picture. Here’s the picture I’d want to see from a team, in four parts.

1. Models

Not just your hosted endpoints, but rather every place a model is being called from inside your environment. That includes managed services (SageMaker, Bedrock, Vertex AI), third-party APIs (OpenAI, Anthropic), open-weight models running in containers, and the dozen libraries pulling those models in (TensorFlow, PyTorch, NLTK, spaCy, LangChain). Most CSPMs catalog the cloud account, but almost none catalog the model.

2. Agents

Models respond. Agents do things on your behalf. They call tools, query databases, open tickets, send emails. From a security perspective, an agent is a workload with permissions you didn’t write and a behavior pattern you didn’t review. And worst, most cloud inventories don’t even have a column for “agent.”

3. MCPs

Model Context Protocol is how agents talk to your systems. If you don’t know how many MCP servers are running, who they talk to, or what data they hand back, you have an unmonitored API surface area sitting between your AI workloads and your production data. Understanding that made me uncomfortable the first time it really sank in.

4. Non-human identities (NHIs)

For every model, agent, and MCP server, there’s an identity behind it. A service account. A workload identity. A token. NHIs already outnumber human identities in most enterprise clouds by something like 50 to 1. AI workloads make that ratio worse. And unlike human identities, NHIs almost never get reviewed in access certifications. They get created, they get over-permissioned, and they sit there.

If you can name all four of these, you have a fighting chance. If you can only name one or two, you have a visibility gap, and the gap is wider than you think.

Why your CSPM can’t see this

I want to be careful here, because I don’t want to rag on a category that’s done a lot of good work over the last five years. I’ve bought a lot of CSPM solutions as a CISO, and my organizations were more secure as a result. To be clear, CSPMs are great at what they were built for: snapshot cloud configurations that tell you which ones look risky (public S3 buckets, over-permissioned IAM roles, unencrypted databases, etc.). Useful, important work.

But CSPM is fundamentally an agentless, snapshot-based architecture. It samples the API plane every few hours and infers risk from configuration drift. That’s exactly the wrong shape of tool for AI workloads, for three reasons.

One: AI workloads are ephemeral. A model gets called, returns a response, and the workload context is gone. By the next snapshot, it never happened.

Two: AI risk lives in behavior, not config. A model endpoint with a perfectly clean configuration can still be reasoning its way into your warehouse via a prompt injection. The config tells you nothing.

Three: AI workloads pull dependencies from places your inventory doesn’t track. A LangChain wrapper, a Hugging Face model, an MCP server. None of those show up in a CSPM scan because they’re not cloud resources. They’re application-layer constructs running on top of cloud resources.

So you end up with a security program that knows its EKS clusters cold and has no idea what’s running inside them.

What runtime visibility actually surfaces (not to mention the gap between “I have a CSPM” and “I have visibility into my AI estate”) is the entire reason we built the way we built. It’s as simple as, snapshot-based tools tell you what your cloud looked like a few hours ago and runtime-based tools tell you what your cloud is doing right now. For AI workloads, those are completely different questions.

What it looks like in real life

Let me walk through a scenario that’s not hypothetical. I’ve watched some version of this play out four or five times in the last year.

A platform team deploys a customer support assistant on a GKE cluster. It’s a small Python service, calls a hosted model, uses LangChain for orchestration, has access to a customer data store so it can answer questions about orders. Standard stuff in 2026.

The deployment passes every CSPM check. The cluster is private, the IAM roles look sane, the encryption settings are right.

Now look at it through a runtime-aware lens.

The pod is running a containerized workload using LangChain and a model wrapper with a critical CVE that hasn’t been patched in production. The service account attached to the pod has read access to a database that contains PII for every customer in the EU. There’s an MCP server in the same namespace that lets the agent query a second internal system the security team didn’t know existed. And the workload is making outbound calls to a third-party API that nobody filed a vendor review for.

None of that is visible in a config snapshot. All of it is visible in runtime telemetry.

That’s the AI visibility gap, in one deployment. And the kicker is that nobody did anything wrong. The platform team built what they were asked to build. The data team gave the workload the access it needed. The security team approved the architecture as described. The gap isn’t between the team and the policy. The gap is between the policy and the tooling.

What visibility has to mean in 2026

If we’re going to actually close this gap (and I think most of the CISOs I talk to are going to have to in the next twelve months), three things have to be true about whatever inventory system we trust.

It has to be runtime. Not a snapshot every four hours. Continuous, behavior-based observation of what’s actually running, what’s calling what, what’s moving where. If your AI inventory is a config scan with extra fields, it’s not an AI inventory.

It has to be behavioral. It has to know when a model endpoint starts behaving differently. When an agent starts calling tools it didn’t call yesterday. When an NHI starts pulling data at a volume that doesn’t match its baseline. Static lists don’t catch any of that.

It has to be identity-aware. Every AI workload should be tied back to the non-human identity that’s running it, the human identity that owns it, and the data it can reach. Without that chain, you can detect anomalies but you can’t act on them.

This is what we call AI-Inventory, AI-BOM, and AI-NHI inside the platform: a continuous catalog of every AI asset, a deep bill of materials covering models, wrappers, agents, and frameworks, and a map of every non-human identity feeding the system. They’re three capabilities, but they answer one question: what’s actually running, and who’s responsible for it?

If you can answer that question on demand, you have visibility. If you can’t, you have a CSPM and a problem.

Nobody bought a CSPM with the intent of being unable to see their AI estate. The market just moved really fast and the architecture couldn’t keep pace. The good news is that runtime visibility isn’t a rip-and-replace conversation. You keep the controls that work for static infrastructure and you add a layer that can actually see workloads as they run. That’s the layer we’ve been building.

Where to start this week

Three things you can do right now, even if you’re not actively evaluating new tooling.

Ask your team for the list. Not “what AI initiatives do we have,” which is a strategy question. The literal list: every model endpoint, every agent, every MCP server, every NHI tied to an AI workload. If the list takes more than a day to produce, the gap is real.
Run an outbound traffic audit on your AI namespaces. Where are your AI workloads calling? You will probably find at least one third-party endpoint nobody flagged.
Pull your NHI report and filter for service accounts created in the last 90 days with read access to production data stores. This is the cohort most likely to be feeding an AI workload nobody documented.

None of these require a new platform. They just require asking the question. The answers will tell you how big your gap is.

The Field Guide drops summer 2026

This is the third post in our AI Security launch series. Over the next several weeks, our CISO, threat research, and field teams will publish deep dives on each of the three gaps (View, Protect, Validate), culminating in AI Security in 2026: A Field Guide to View, Protect, Validate, our complete reference for the discipline.

Get the Field Guide →