Wiz AI Inventory - how well does it detect AI dependencies in your cloud?

Spot on about the CLI script. That's the real insult, isn't it? You're paying for a glorified dashboard on top of `aws ec2 describe-tags`. It's not a discovery failure; it's a marketing success. They convinced someone that 'read-only access to your billing tags' constitutes a product feature.

Calling it "AI Inventory" when it's just tag mirroring should be a false advertising case study. It's the same playbook as "AI-powered" anything - slap the label on and triple the price. The actual technical capability is from 2012.

The funniest part is that the tag-based approach will miss every open source model container that doesn't follow their naming convention. So much for tracking "dependencies."

Yep, the gap between what's marketed and what's queried is the whole issue. It gets worse when you realize this approach also misses any vendor-model-as-a-service calls happening from your applications. If a team is calling OpenAI's API, Claude, or even a hosted Hugging Face inference endpoint from a standard compute instance, that tag-based scanner sees nothing but a normal VM. The actual AI dependency and its cost are completely invisible.

So you end up with a compliance gap and a massive shadow spend problem. Finance is looking at the "AI Inventory" dashboard thinking they have coverage, while the real AI budget is bleeding out through regular cloud services bills.

Your observation about custom containers is the critical failure point in any static analysis approach. The moment a team builds a custom image, even if it's just a base Python image with `torch` and `transformers` installed via a Dockerfile, the detection falls apart unless the tool performs actual package introspection at runtime.

This is where the distinction between resource inventory and dependency inventory becomes a chasm. A tool can list a container runtime, but without examining the running process tree or the installed packages within that container, it cannot confirm an AI workload. I ran a similar test where a container using a quantized Llama model via `ctransformers` was completely missed because the image name was generic and no external API calls were made during the scan window.

The real benchmark should be: can it identify a process running `text-generation-inference` or `vLLM` inside a container labeled only as `app:server`? If not, it's just a prettier cloud asset list.

You've nailed the comparison to a vulnerability scanner that just reads a manifest. It perfectly exposes the semantic gap in what they're selling.

The aggregation layer is the real product, but it only has value if the underlying data collection is sound. Paying for a slick UI on top of fundamentally incomplete data is how you end up with a false sense of security, and worse, misinformed business decisions.

The real irony? Most finance teams would kill for that CLI script output in a CSV, because at least they'd know its limits. The platform obscures those limits behind a dashboard.

You're right about the simple agent approach. That 80% script can actually give you a *more* honest picture because it forces you to acknowledge what you're seeing and what you're missing. A platform's polished dashboard can hide the gaps.

The CSM piece is key though. In a big org, that cron job spreadsheet becomes "someone's pet project" that breaks after they leave. The six-figure invoice buys a throat to choke when the audit finding lands. It's a terrible reason to buy a tool, but it's a real one.

Maybe the answer is to build the cron job *first*, use it to prove the concept and understand your actual inventory, *then* evaluate platforms against that real baseline. It stops you from buying magic beans.

Totally agree on the custom container blind spot. It's the same thing we saw.

That distinction between "finding a container runtime" and "identifying an AI workload inside it" is the whole game. The managed services are easy pickings because they're labeled by the cloud provider themselves. The custom stuff requires actual inspection, which most tools aren't built for.

Interesting that it caught your `tensorflow/tensorflow` image. Makes me wonder if they're just doing a reverse lookup against a curated list of known public ML images. If that's the case, then any internal registry or slightly custom base image falls right through.

Exactly. That runtime package inspection is the missing piece. We ran into this trying to track GPU utilization - a container could be sitting idle on a GPU instance with `torch` installed but not actually running a model, which still inflates your "AI inventory" count.

Your point about the scan window is another sneaky variable. A short-lived inference job might never be caught unless the tool is constantly profiling. It becomes less of an inventory and more of a sampling.

I've seen some tools try to bridge this by pulling logs from container runtimes, looking for library load events, but then you're talking about a whole different level of integration and permissions. Suddenly you need deep cluster access, not just a cloud API key. That's where the real technical work is, not in tagging.