You know how the compliance team asks which LLM workloads you run in production, and someone in Slack answers with a vaguely helpful shrug? This week Google Cloud published a controller aimed at that shrug.
The project is k8s-aibom, open-sourced on July 13. Per the announcement, it is a single unprivileged Deployment that sits in a namespace called k8s-aibom-system, watches the Kubernetes API, and pattern-matches on container images, environment variables and command-line arguments to identify AI stacks. Serving runtimes: vLLM, Triton Inference Server, TGI, Ollama. Agent frameworks: LangChain, AutoGen, CrewAI. Vector stores: Milvus, Qdrant, pgvector. Whatever the controller can fingerprint goes into an OWASP CycloneDX 1.6 ML-BOM.
Verdict up front: this is a sensible shape for AI inventory, and it is going to embarrass some platform teams who thought they knew what was running.
The premise, briefly
Shadow AI is the same organizational problem as shadow IT, with heavier compliance stakes. A developer needs a small model behind an internal endpoint. Ships it. Nobody logs it anywhere the security team can find. Six months later a regulator forces the question: what is running? The answer, in most orgs, is a channel-wide ping.
Google's approach, per the post: stop asking. Watch. The announcement lines this up against EU AI Act Articles 12 and 50, the NIST AI Risk Management Framework, and ISO/IEC 42001. All three of those frames assume you already know what you are running.
What the controller actually watches
The discovery pipeline runs in four steps, per the post. It scrapes cluster workloads: KServe resources, Deployments, StatefulSets, DaemonSets, Jobs. It pattern-matches on images, env vars and args to fingerprint AI stacks. It compiles the findings into a CycloneDX 1.6 ML-BOM. It exports the document to a sink: a Google Cloud Storage bucket, a webhook endpoint, or just the custom resource status field for anything downstream that wants to read it back later.
That last option is the useful bit in pipeline terms. If the ML-BOM lives as a first-class Kubernetes object, your admission controller, policy engine or release gate can consume it the same way they already consume anything else in the cluster. You gate on the BOM the way you gate on an image scan.
The delivery model is the other thing worth noticing. No sidecars, no eBPF module, no privileged DaemonSet, no pod-spec surgery on the target workload. That is the difference between an inventory tool a platform team will actually deploy and one that lives forever in a proof-of-concept namespace.
Confidence tiers, honestly
Not every detection is clean. Per the announcement, k8s-aibom labels every finding with one of three confidence tiers. Declared means the workload configuration says outright what runtime it is. Inferred means the pattern-matcher is confident from the image or env. Unresolved means the controller sees AI-ish signals but cannot pin down which model or which parameters sit behind them.
Read that third tier honestly. Any inventory tool that promises to catch everything and never guess is lying. What matters is that the guess is labelled as a guess. A policy engine can treat Declared and Inferred as gateable and Unresolved as a ticket to follow up on. Or as a hard stop, if your compliance frame says unlabelled inference in production is not allowed to exist.
Trust boundary check, because we are here. The controller runs unprivileged. It reads the cluster API. It writes custom resources. Its sink permission on Google Cloud Storage is roles/storage.objectCreator, and nothing else. That is a defensible least-privilege posture for a component whose whole job is to describe other things. Do not casually widen it, and pay attention if a fork someday wants to.
What the BOM will not do for you
The ML-BOM is a description. It is not provenance for the model weights inside the runtime. It will not tell you the container image was signed, the weights came from a bucket you own, or that no one swapped the config map at 2am. A CycloneDX ML-BOM alongside a signed image alongside a Sigstore-style attestation is the picture you want. On its own the BOM is an ingredients list. You still need the receipt.
It will also over- and under-detect. That is the price of a tool that refuses to demand pod-spec edits. If your platform team has been fastidious about labelling AI workloads, most of your inventory will land in Declared and this thing will feel quiet. If it has not, expect a first-week findings list that is longer than anyone budgeted for.
Kicker
The AI you can see is the AI you can gate. Everything else is running under someone else's assumption, which is not a compliance strategy. Steal the shape even if you never run this particular controller.
Top comments (0)