Wat er is gebeurd
OpenAI maakte op 10 april bekend dat een GitHub Actions-workflow in het macOS-signingproces een kwaadaardige versie van axios had gedownload en uitgevoerd nadat het veelgebruikte npm-pakket was gecompromitteerd. Volgens OpenAI had die workflow toegang tot code-signingcertificaten en notarization-materiaal voor ChatGPT Desktop, Codex, Codex CLI en Atlas. OpenAI zegt geen bewijs te hebben gevonden dat gebruikersdata is ingezien, producten zijn aangepast of het certificaat daadwerkelijk is buitgemaakt, maar behandelt het materiaal wel alsof het gecompromitteerd is en roteert het daarom alsnog.
Het bedrijf pakt de nasleep aan zoals een serieuze softwareleverancier dat hoort te doen. Er zijn nieuwe builds gepubliceerd, het getroffen certificaat is vervangen, een externe incident response-partij is ingeschakeld en er is een deadline van 8 mei gezet waarna oudere macOS-versies geen support meer krijgen en mogelijk niet meer werken. Dat is relevant, omdat code-signingcertificaten een vertrouwensanker zijn. Als een aanvaller die kan misbruiken, kan valse software er voor gebruikers en IT-teams alsnog legitiem uitzien.
OpenAI benoemde ook helder waar het misging: de workflow gebruikte een floating tag in plaats van een specifieke commit-hash en er was geen minimum release age ingesteld voor nieuwe packages. Dat klinkt als build-pipeline-detailwerk, maar precies dit soort kleine operationele shortcuts maakt van een package-incident een zakelijk beveiligingsprobleem. De bredere axios-aanval was een klassiek software-supplychainprobleem, waarbij een kwaadaardige dependency upstream werd toegevoegd en via een postinstall-hook code werd uitgevoerd tijdens installatie.
Waarom dit voor bedrijven relevant is
Dit gaat over meer dan een macOS-app. Naarmate bedrijven AI-systemen koppelen aan ontwikkeltools, inboxen, CRM, ERP en interne kennisbronnen, verschuift het echte aanvalsoppervlak weg van het chatvenster en richting de operationele laag eromheen. Het model is het zichtbare deel van het systeem, maar CI-pipelines, package managers, signingworkflows en credentialbeheer bepalen of dat systeem in productie te vertrouwen is.
Veel AI-teams zijn nog steeds te druk met modelbenchmarks en te weinig met deterministische controles. Ze discussieren over latency, context windows en leaderboards, terwijl hun pipelines mutabele dependencies binnenhalen, secrets te breed beschikbaar zijn en toolrechten nauwelijks zijn gesegmenteerd. Als een AI-toepassing klantmail kan lezen, opportunity-fases kan wijzigen of vervolgworkflows kan starten, dan is software-supplychainhygiëne geen DevOps-detail meer maar gewoon bedrijfsrisico.
De reactie van OpenAI is juist nuttig omdat die niet spectaculair is. Er is hier geen magische oplossing, alleen gedisciplineerde incidentafhandeling: certificaten roteren, duidelijke versiegrenzen communiceren, expliciete update-instructies geven en transparant zijn over de misconfiguratie. Dat is de houding die enterprise AI nodig heeft. Productie-AI wordt niet beveiligd door goede bedoelingen of een sterkere system prompt. Het wordt beveiligd door saaie, toetsbare controles rondom het model.
Laava's perspectief
Bij Laava zeggen we steeds hetzelfde: AI is eerst een systems engineering-vraagstuk en pas daarna een prompt engineering-vraagstuk. Dit incident bevestigt dat opnieuw. Een production-grade AI-agent is niet alleen een model met een interface. Het is een keten van dependencies, workflows, secrets, integraties, policies en approvalpaden. Als een deel van die keten zwak is, erft het hele systeem die zwakte.
Dit laat ook zien waarom wij zoveel nadruk leggen op de action layer. Zodra AI verder gaat dan alleen drafts maken en echte systemen raakt, worden permissiegrenzen cruciaal. De moeilijke vraag is niet alleen of het model de juiste beslissing neemt. De moeilijke vraag is wat er gebeurt als de toolchain eromheen wordt vergiftigd, het verkeerde package in een build belandt of een credential uitlekt in een workflow die veilig leek. Wie die scenarios negeert, krijgt slimme demos en broze productieomgevingen.
Er zit ook een soevereiniteitslaag in dit verhaal. Veel organisaties denken dat soevereine AI begint en eindigt bij modelkeuze, bijvoorbeeld door open modellen of self-hosted deployments te verkiezen. Dat is onvolledig. Je bent niet soeverein alleen omdat je je eigen weights host. Echte controle vraagt ook om gepinde dependencies, auditeerbare build-pipelines, gescheiden signing keys, scherp afgebakende credentials en heldere provenance over elk onderdeel dat modelgedrag of uitvoerbare code kan beinvloeden. Anders besteed je vertrouwen nog steeds uit aan wat er vannacht upstream is veranderd.
Wat je nu kunt doen
Begin bij je AI-gerelateerde pipelines. Loop elke workflow na die software signeert, modellen uitrolt, agent-runtimes publiceert of credentials in builds injecteert. Vervang floating tags door gepinde commit-SHAs, stel waar mogelijk package-agevertragingen in, lock dependencyversies en controleer op packages en transitieve dependencies die door het axios-incident zijn geraakt. Als je niet snel kunt beantwoorden welke workflow toegang heeft tot welk secret, heb je nu al een architectuurprobleem.
Bekijk daarna de rechten op agentniveau. Scheid leesrechten van schrijfrechten. Houd productiecredentials weg van experimenteeromgevingen. Log elke geprivilegieerde actie en zorg voor duidelijke audit trails voor menselijke review. Het belangrijkste is dat je deployment-guardrails behandelt als onderdeel van het AI-product zelf en niet als bijzaak in de infrastructuur. Alleen zo ga je van interessante demos naar production-grade AI die een bedrijf echt kan vertrouwen.