The tool works by continuously monitoring live Kubernetes clusters, identifying unregistered AI components, and generating comprehensive Machine Learning Bills of Materials (ML-BOMs). Think of it as an inventory system for your AI workloads, capturing what’s actually running in production rather than what you think is running.
The Problem It Solves
AI software spreads fast across large enterprises, often without adequate oversight. A developer deploys a model here, an inference server gets added there, and suddenly your security team has no idea what’s actually active in your cluster. k8s-aibom changes that by maintaining an accurate, real-time inventory of AI deployments as they run.
This matters especially for compliance. Regulators and internal auditors need to know what AI systems are operating in production. Whether you’re navigating the EU AI Act, following NIST AI Risk Management Framework guidance, or meeting ISO/IEC 42001 requirements, k8s-aibom generates the evidence you need.
How It Works
The controller continuously watches your Kubernetes environment and applies pattern matching to identify common AI runtimes. Here’s the workflow:
- Resource Monitoring: Watches Deployments, StatefulSets, DaemonSets, Jobs, and KServe resources across your cluster
- AI Runtime Detection: Identifies software like vLLM, Triton Inference Server, Ollama, LangChain, and Qdrant by examining container images, environment variables, and command-line arguments
- ML-BOM Generation: Builds standardized Machine Learning Bills of Materials following the OWASP CycloneDX 1.6 format
- Classification: Tags discovered assets as Declared (explicitly configured), Inferred (identified via signatures), or Unresolved (detected but uncertain)
- Immutable Storage: Stores ML-BOMs to external destinations like Google Cloud Storage with preconditions preventing overwrites, creating an audit trail
Setting It Up
k8s-aibom requires a conformant Kubernetes cluster and operates under a dedicated service account with minimal permissions. This limited access model keeps security tight.
For external storage, it integrates with Google Cloud Storage buckets or webhook endpoints. If you’re storing ML-BOMs outside the cluster, you’ll need a Google Cloud Identity and Access Management Workload Identity configured with object-creation rights.
The deterministic approach ensures identical cluster inputs always produce identical ML-BOM documents. That consistency is critical for governance and change tracking in GitOps-based environments. You’re not just getting a snapshot; you’re building an auditable historical record.
Organizations deploying AI at scale now have a way to keep up with what’s actually running. No more guessing, no more security gaps. The tool is available as open-source software, ready to work with any conformant Kubernetes cluster.
Follow Hashlytics on Bluesky, LinkedIn, Telegram and X to Get Instant Updates
