Google open-sources k8s-aibom for live AI workload audits

Google has open-sourced k8s-aibom for Kubernetes clusters, a tool designed to identify unregistered AI workloads and generate machine learning bills of materials.

The software runs as an unprivileged Kubernetes controller and observes live cluster activity rather than scanning software artifacts before deployment. It continuously monitors cluster resources and container environments to detect AI runtimes and related components that may have been deployed without formal registration.

The move addresses a growing problem for security and platform teams as AI software spreads across large organisations. Developers can deploy models, inference servers, and agent frameworks without going through established registration or review processes, leaving security teams with incomplete visibility into what is running in production.

According to Google, k8s-aibom watches Kubernetes resources including Deployments, StatefulSets, DaemonSets, Jobs, and KServe resources. It then uses pattern matching across container images, environment variables, and command-line arguments to identify software such as vLLM, Triton Inference Server, Text Generation Inference, Ollama, LangChain, AutoGen, CrewAI, Milvus, Qdrant, and pgvector.

Using that data, the controller creates Machine Learning Bill of Materials documents based on the OWASP CycloneDX 1.6 standard. The documents can be attached to an in-cluster custom resource or sent to external destinations including Google Cloud Storage buckets and webhook endpoints.

Runtime focus

Google positions the project as a complement to existing AI software inventory and security products, not a replacement. Many existing tools produce bills of materials at build time or inspect assets from outside the cluster, which can help organisations understand what was intended for deployment but not necessarily what is running at any given moment.

That distinction matters for compliance and security reviews, especially when AI models or supporting components may be pulled in dynamically at runtime. The controller is intended to give teams a view of active workloads without requiring sidecars, privileged DaemonSets, kernel-level access, or manual changes to pod specifications.

The system also uses what Google describes as a deterministic approach: identical cluster inputs are intended to produce identical ML-BOM documents. That could make the output easier to compare in GitOps-based environments, where engineers rely on precise change tracking.

Confidence model

A central feature of the project is a three-tier classification model for discovered assets. Google says this is intended to distinguish software explicitly configured by engineers from software inferred through runtime inspection.

The first tier, Declared, covers cases where a model or other AI asset is directly defined in workload configuration, such as through container arguments. The second, Inferred, applies when the controller identifies software through signatures and pattern matching. The third, Unresolved, is used when the system detects AI-related activity but cannot determine exact model parameters, weights, or versions with certainty.

That distinction is likely to appeal to audit and security teams that need to know whether evidence reflects operator intent or automated detection. It also highlights a broader challenge in AI governance: organisations are being asked to show not only that controls exist, but that records of deployed systems are accurate and current.

Audit trail

The controller operates under a dedicated Kubernetes service account with limited permissions. For external storage, it writes records using a Google Cloud Identity and Access Management Workload Identity with object-creation rights.

In the Cloud Storage sink implementation, object creation uses a DoesNotExist precondition. That means a stored ML-BOM cannot be overwritten after creation, a design choice intended to create an immutable historical record for audits and investigations.

The project arrives as companies try to map technical controls to emerging AI governance requirements. Google says standardised ML-BOM output from running Kubernetes environments could support evidence gathering for frameworks and regulations including the EU AI Act, the NIST AI Risk Management Framework, and ISO/IEC 42001.

Although the software is closely tied to Kubernetes operations, its significance extends beyond infrastructure management. For many enterprises, one of the hardest parts of AI governance is not drafting policy but proving which systems are actually in use, especially when deployment practices vary across teams and projects.

By focusing on live cluster observation, Google is trying to close that gap at the point where AI services are actually executed. The project is available as open-source software through Google's public development channels, with support for any conformant Kubernetes cluster.