Google har åpnet kildekoden til k8s-aibom, en Kubernetes-kontroller som kartlegger KI-arbeidslastene i den kjørende klyngen i stedet for i byggepipelinen. Den overvåker Deployments, StatefulSets, DaemonSets, Jobs og KServe-ressurser, og kjenner igjen kjøretidsmiljøer som vLLM, Triton, Ollama, Ray Serve og SGLang, samt agent-rammeverk som LangChain, AutoGen og CrewAI og vektorlagre som Milvus, Qdrant og pgvector. Funnene skrives ut som CycloneDX 1.6 ML-BOM-dokumenter. SecurityBrief omtalte lanseringen.
Problemet verktøyet angriper er kjent for alle som drifter en plattform: utviklere ruller ut modeller, inferensservere og agent-stacker uten å innom noen registreringsprosess, og sikkerhetsteamet sitter med et ufullstendig bilde av hva som faktisk kjører. Eksisterende stykklisteverktøy lager stort sett BOM-er ved bygg eller inspiserer artefakter utenfra. De forteller deg hva som var ment å kjøre, ikke hva som kjører nå, og forskjellen er stor når modeller og komponenter trekkes inn dynamisk ved oppstart.
k8s-aibom kjører derfor som en uprivilegert kontroller som bare ser på klyngen gjennom det vanlige Kubernetes-API-et.
«Den krever ingen DaemonSet, ingen privilegert container, ingen kjernetilgang, ingen node-agent.» — README-en i GoogleCloudPlatform/k8s-aibom
Det mest gjennomtenkte grepet er tredelingen av funn. Et attributt merkes declared når det står eksplisitt i workload-spesifikasjonen, inferred når kontrolleren har utledet det via mønstergjenkjenning i container-images, miljøvariabler og kommandolinjeargumenter, og unresolved når den registrerer KI-aktivitet uten å kunne fastslå modellparametere eller versjoner med sikkerhet. Hvert attributt bærer et konfidensflagg og en peker til beviset, slik at en revisor kan se om en linje i stykklista reflekterer noe et menneske har konfigurert eller noe maskinen har gjettet. Identiske input skal gi byte-identiske BOM-er, noe som gjør dem sammenlignbare i GitOps-oppsett.
«Det vanskeligste med KI-styring er ikke å skrive policyen, men å bevise hvilke systemer som faktisk er i bruk.» — SecurityBrief
Lagringen er verdt et blikk før utrulling. BOM-ene kan bli liggende i statusfeltet på en AIBOM-ressurs inne i klyngen, altså uten at data forlater den, eller sendes til en Cloud Storage-bøtte eller et webhook-endepunkt. Cloud Storage-sinken skriver med en DoesNotExist-betingelse, så et lagret ML-BOM ikke kan overskrives i ettertid. Det gir en uforanderlig historikk å revidere mot. Google peker selv på EU AI Act, NIST AI Risk Management Framework og ISO/IEC 42001 som rammeverk denne dokumentasjonen kan mate inn i.
Merk statusen: prosjektet er Apache 2.0-lisensiert og merket v1.0 alpha, og Google beskriver det selv som egnet i produksjon for ikke-kritiske observasjonsformål. For en liten k3s-klynge med en Ollama-instans og en LangChain-agent er nytten mindre juridisk enn praktisk. Du får en maskinlesbar liste over hva som faktisk snurrer, inkludert det du glemte at du rullet ut.
Hva bør du gjøre?
- Installer kontrolleren i en testklynge og les gjennom det den finner. Overraskelsene havner typisk i inferred-kategorien, og det er nettopp de du vil vite om.
- Bestem sink før utrulling. Vil du ikke sende en inventarliste over KI-systemene dine til en bøtte, hold BOM-ene i klyngen på AIBOM-ressursen.
- Ta alpha-merkingen på alvor. Kjør den som observasjonsverktøy ved siden av det du har, ikke som eneste kilde til sannhet i en compliance-prosess.
Bakgrunn
En ML-BOM er en stykkliste for KI-systemer, på samme måte som en SBOM lister programvarekomponenter. CycloneDX 1.6 er standarden Google bruker her, og den beskriver modeller, datasett og kjøretidskomponenter i et maskinlesbart format. Poenget er sporbarhet: når noen spør hvilken modell som svarte på en forespørsel i mars, skal svaret finnes i en logg, ikke i hukommelsen til den som rullet den ut.