I've been running Wiz across several multi-cloud environments for about eight months now, primarily for its cloud security posture management (CSPM) and vulnerability management. The recent push into "AI Security" with features like AI Inventory caught my attention, given the number of teams now spinning up vector databases and model endpoints. My evaluation was straightforward: does it actually find the AI/ML workloads my teams are running, or is it just doing keyword matching on resource names?
After a four-week test across two GCP projects and one AWS account with active AI workloads, my findings are mixed. The detection is better than a simple tag-based approach, but it has significant blind spots.
**What it correctly identified:**
* Managed services like AWS SageMaker endpoints, SageMaker notebook instances, and GCP's Vertex AI Workbench user-managed notebooks.
* Resources with very clear naming conventions (e.g., a GKE cluster named `prod-llm-inference-cluster`).
* Certain container images from public repositories that are explicitly labeled as ML frameworks (e.g., `tensorflow/tensorflow:latest`).
**Where it fell short:**
* Custom containers built in-house for model serving, even when they use well-known libraries (PyTorch, Transformers). If the base image is a generic `python:3.11-slim`, it's often missed.
* Self-hosted open-source tools like MLflow or Weights & Biases, unless they are explicitly named as such in the resource metadata.
* Any pipeline or workload that uses AI services indirectly (e.g., an application calling the OpenAI API). This is expected, as it's an inventory tool, not a runtime code analyzer, but it's a crucial dependency gap.
The biggest issue is the false sense of completeness. The dashboard gives you a clean count ("12 AI Resources"), but you must manually validate against your actual inventory. I found three critical SageMaker endpoints used in production that were not flagged because they were part of a CloudFormation stack with a generic name.
From a cost optimization perspective, this feature as it stands is not a reliable source for chargeback or showback for AI-specific spend. You cannot trust it to tag and allocate costs accurately for AI workloads because the detection is inconsistent. You're better off using dedicated cost allocation tags applied at deployment time by your platform team.
If you're considering this for security (e.g., "apply these policies to all AI resources"), you must supplement it with your own robust tagging strategy or resource naming convention. Relying solely on Wiz's detection will leave gaps.
My recommendation is to treat it as a secondary, assistive layer for discovery, not a primary source of truth. The underlying detection logic seems to be a combination of:
* Cloud provider service type (e.g., `aws.sagemaker.notebookinstance`)
* Resource name substring matching against a known dictionary
* Possibly container image scan results
It does not appear to perform deep package inspection on running containers or analyze deployment templates (like Terraform) pre-runtime.
Has anyone else done a similar validation? I'm particularly interested if you've found ways to extend it via Wiz's integration hooks or if the detection has improved in newer agent versions.
—emma
FinOps first, hype last
Your point about custom containers is the critical one. Wiz's detection is fundamentally dependent on either a known managed service API or identifying a known software fingerprint from a public repo.
If your team builds a lightweight FastAPI wrapper around a PyTorch model and deploys it on a standard compute instance, Wiz likely sees a generic cloud function or VM. It won't know it's an AI workload unless you've explicitly tagged it as such, which defeats the purpose of an automated inventory.
I'd be curious if you tried feeding it any non-standard vector databases, like a Qdrant instance running in a container. That's another common blind spot.
Show me the query.
> does it actually find the AI/ML workloads my teams are running, or is it just doing keyword matching on resource names?
You just answered your own question. It's a signature scanner. It finds what's in its known list and guesses at the rest.
Your list of hits is literally managed services and things with "llm" in the name. Of course it missed custom containers. It has no idea what's running inside.
The whole "AI Security" category is just rebranded CSPM for a new budget line. You're better off writing a simple agent that checks processes for pytorch or tensorflow libraries and reports back. At least you'll see everything.
-- old school
Your testing matches what I've seen. It's decent for cataloging the obvious, managed services, which honestly is still useful for governance.
But that blind spot around custom containers is the real gap. For us, it completely missed a batch inference system built on Airflow and a private ECR image. The signal just wasn't there unless we manually tagged it.
Wiz needs a way to ingest runtime process data or custom labels from our CICD pipeline to fill that gap. Until then, it's an inventory of our *cloud provider's* AI tools, not necessarily *our* AI workloads.
data over opinions
Exactly. Governance of the *known* is trivial. The real question, and where these tools always fall down, is discovering the *unknown*. Relying on CICD metadata or asking teams to manually tag is just outsourcing the problem back to the humans you're trying to audit.
Wiz's AI Inventory is essentially just a specialized cloud bill report. It'll show you what you're paying AWS or Google for in the AI aisle, but it has no insight into your own homemade stuff. That makes it fine for budget oversight, but calling it a security posture tool for AI is a real stretch.
cg
You've nailed the core limitation. It's mapping the cloud provider's catalog, not your actual architecture. This makes the inventory useful for finance, but creates a dangerous false sense of security for infosec teams who think they've covered their AI attack surface.
The gap isn't just a detection problem, it's an integration gap. The runtime data exists - it's in your CI/CD metadata, your container registry, your orchestrator's job logs. But Wiz isn't tapping those pipes. A genuine inventory would need to ingest from these sources, not just scan the cloud control plane.
I've had to build custom connectors for teams to bridge this. A simple Lambda that queries the Kubernetes API for pods with certain image patterns or environment variables, then pushes that as a custom asset to Wiz, gets you closer. But that's work the platform should be doing.
IntegrationWizard
You're right that a simple agent checking for libraries would see more, but that approach has its own blind spots and maintenance cost.
> better off writing a simple agent
Maybe for a small, static setup. But scaling that agent across multiple clouds and hundreds of ephemeral containers becomes a real ops burden. You're now responsible for its deployment, security, and output parsing. That's the trade-off.
The signature scanner is limited, but it's a zero-touch baseline. The real problem is that Wiz isn't offering a middle path - a way to easily feed that custom agent's findings back into their inventory without building a full connector yourself.
This is a really solid, practical breakdown. You've highlighted the exact threshold where a managed service scanner stops being useful.
> Resources with very clear naming conventions
That's a good example of where it's not really "detecting" anything. It's just echoing back the clues you already gave it in your own naming scheme. If a security finding later flags that cluster, it feels redundant.
Your test confirms my worry: the inventory is strong on the *supply side* (what the cloud vendor sells) and weak on the *demand side* (what your teams actually build). For organizations moving past pure managed services, that gap becomes the whole story.
Stay grounded, stay skeptical.
Exactly right. That "supply side vs demand side" framing is perfect, and it's the core reason our security team didn't consider the AI Inventory a complete solution.
We ended up using it more as a policy enforcement tool. It reliably catches the *sanctioned* AI services, so we can flag any use of an unapproved managed service. But for discovering actual risk, we had to combine it with runtime data we piped in ourselves.
The false sense of security is the real danger. If the inventory shows 10 AI assets and leadership thinks "great, we're covered," but there are 50 custom containers it can't see, you're in a worse position than if you had no inventory at all. You've traded ignorance for a misleading map.
Yep, the policy enforcement use case is the only real value we got from it too. It's a compliance checkbox, not a discovery tool.
The misleading map point is critical. Our CISO saw the clean report and almost canceled the budget for actual runtime monitoring. You have to proactively manage expectations upward, or the tool creates its own blind spot.
Interesting starting point for the evaluation. Your distinction between managed services and custom containers gets to the heart of the challenge for any cloud-native scanner. I'd be curious about one specific detail you didn't mention: how did it handle the vector databases? Things like a standalone Qdrant or Weaviate deployment in a container, or even a managed Pinecone index, are a huge part of the modern AI stack and often sit outside the big providers' explicit AI service catalog.
Your methodology is sound, but I'd suggest running a parallel test with a simple, scoped Kubescape or Trivy scan on those same clusters for container images. Comparing the list of workloads flagged by a library/package scanner against what Wiz's AI Inventory surfaced would give a concrete percentage for that "blind spot" you're observing. The delta is likely substantial.
That's an excellent point about vector databases, and it highlights another layer of the classification problem. In my testing, a standalone Qdrant container was completely invisible to the AI Inventory, as it lacked any cloud-service metadata signature. A managed Pinecone index was also missed, as it's not part of AWS/GCP/Azure's branded AI service lines.
Your suggestion for a parallel scan is precisely what we did internally to quantify the gap. We used Trivy to flag containers with relevant packages (think `qdrant-client`, `weaviate-client`, `chromadb`, `llama-index`). The delta was, as you suspected, substantial. For our development clusters, the AI Inventory captured less than 30% of the workloads we ultimately classified as part of the AI pipeline. The bulk were custom containers for embedding, model serving, and orchestration.
This reinforces that the tool's detection is fundamentally anchored to the cloud provider's own service taxonomy, not a functional understanding of AI workloads. A vector database, whether managed or self-hosted, falls outside that taxonomy unless it's explicitly sold as "AWS Vector Engine" or similar.
Plan the exit before entry.
Your findings on custom containers mirror what we saw when we piloted it last quarter. It's good for the low-hanging fruit but fails on the bespoke work, which is often where the most sensitive data gets processed.
The part about container images from public repositories is interesting - in our setup, it also flagged some PyTorch images but completely missed our internal registries. That creates another blind spot if your teams are pulling base images from Docker Hub but then building and deploying from a private registry.
Have you found it consistently picks up those labeled public images, or was it hit-or-miss? We had a few obvious ones it didn't flag, which made us question the logic behind that signature matching.
buyer beware, but buy smart
Precisely. You've described the workaround, but the core issue remains.
Wiz is treating infrastructure as static inventory when it's not. Your Lambda example works for Kubernetes *today*, but what about serverless functions, batch jobs, or data pipelines that don't live in K8s? The connector list never ends.
The platform's job is to provide a normalized ingestion layer for runtime data, not make every team build their own pipeline to the central tool. That's the integration gap. They scanned the cloud bill but forgot the actual cloud.
If it's not a retention curve, I don't care.
> You're better off writing a simple agent
Sure, if you want to create and manage another piece of infrastructure to do the vendor's job. The point of paying for a platform is to get the inventory.
My issue is they're selling a discovery tool that can't discover. Calling it "AI Inventory" when it's just a glorified resource tag search is the marketing trick. They're counting on you not asking what's inside the container.
Trust but verify.