De laatste maanden zien we een duidelijke verschuiving in cyberaanvallen gericht op AI-diensten. In plaats van alleen data te kopiëren, lijken aanvallers vooral op zoek naar AI-toegangslekken waarbij ze toegangssleutels, tokens en opgeslagen klantgeheimen buitmaken. Die informatie is direct te gebruiken om AI-accounts te misbruiken of te verhandelen.
Securityonderzoekers beschrijven dat meerdere AI-gerelateerde developer platforms binnen korte tijd zijn getroffen. Hoewel de incidenten onderling niet één op één lijken te zijn gekoppeld, volgt een herkenbaar patroon: gestolen AI-tokens worden gemonetariseerd, vaak met hulp van AI-tools die het aanvalstraject versnellen.
Waarom AI-toegangslekken zoveel geld opleveren
AI-toegangstokens en keys zijn aantrekkelijk omdat ze niet alleen “informatiewaarde” hebben, maar ook operationele waarde. Met een gestolen token kan een aanvaller bijvoorbeeld diensten aanroepen, inference gebruiken of betalen voor capaciteit omzeilen—afhankelijk van hoe de getroffen partij tokens beheert en autorisatie instelt.
In analyses van de recente incidenten wordt ook gewezen op een extra risico dat ontstaat wanneer hosting- en ontwikkellagen namens veel klanten werken. Compromitteer je zo’n tussenlaag, dan kunnen sleutels of geheimen van meerdere afnemers tegelijk bloot komen te liggen. Daarmee wordt één inbraak potentieel schaalbaar.
Daar komt bij dat de markt voor credential theft groeit. Onderzoekers koppelen de toename aan technieken rondom LLM-jacking en infrastructuur waarmee gestolen tokens eenvoudig te gelde kunnen worden gemaakt. Dat maakt het voor aanvallers relatief efficiënt om meerdere platforms achter elkaar te proberen.
Welke platforms zijn geraakt en wat was het doel?
In de meldingen over AI-toegangslekken komen meerdere namen terug. Incidenten worden onder meer gekoppeld aan CommandCode, Northflank, Trigger.dev, Chainstack en WorkOS. Daarnaast worden ook andere AI- en developer omgevingen genoemd, zoals Andromeda, Brev (NVIDIA), Fireworks AI, Lightning AI, OpenCode, Railway, Warp en Zeabur.
Hoewel de aanvalspaden kunnen verschillen, is het kerndoel in veel gevallen gelijk: het buitmaken van opgeslagen geheimen en klantgerelateerde referenties. De initiële toegang varieert daarbij, van gecompromitteerde inloggegevens tot misbruik van derdepartij-onderdelen of het benutten van kwetsbaarheden.
Een belangrijk detail is dat aanvallers lijken te zoeken naar tokens en secrets die al klaarstaan in systemen die voor klanten werken. Daardoor hoeven ze niet altijd “van nul” te starten; ze kunnen direct door naar misbruik van AI-toegang.
Van ontwikkelconsole tot klantsecret: het aanvalspad
Securityorganisaties beschrijven dat aanvallers credentials bereiken via de “intermediaire laag”: hostingplatformen, evaluatiediensten en developer consoles. Deze lagen bevatten vaak referenties namens downstream klanten.
Het gevolg is dat een enkele compromittatie kan leiden tot meerdere impacten tegelijk. Denk aan sleutels die horen bij verschillende inference-accounts of klantomgevingen. Wie die informatie beheert, bepaalt dus direct hoe groot de schade kan worden.
In sommige gevallen melden onderzoekers dat enterprise-credentials werden misbruikt en dat er sprake was van patronen die snel na de gemelde compromittatie zichtbaar werden. Bovendien lijkt het delen van dezelfde gestolen sleutels door meerdere actoren te wijzen op een robuuste “markt” voor dit soort gestolen toegang.
Artex: automatisering achter aanvallen op ontwikkelplatformen
Naast het bredere credential-theft patroon komt ook een concrete factor naar voren die aanvallen versnelt: automatiseringsframeworks voor penetratietesten. In recente disclosures wordt genoemd dat blockchain- en web3-infrastructuurprovider Chainstack en de API-omgeving WorkOS aanvallen ontdekten die leunden op een open source AI-penetratietestframework: Artex.
Meerdere organisaties verbinden aanvallen die eerder aan een APT-groep (Storm-0940) werden toegeschreven met het gebruik van Artex. Ook werd een campagne genoemd die zich richtte op ConnectWise-klanten.
Wat dit voor de praktijk betekent: automatisering maakt het makkelijker om systemen gericht te scannen, te escaleren en vervolgens specifieke secrets op te sporen. Daarmee neemt niet alleen de snelheid toe, maar ook de kans dat aanvallers vaker terugkomen voor dezelfde soort data.
Chainstack: mogelijk databasetoegang en rotatie van credentials
Volgens Chainstack werd de partij op 26 oktober getroffen. De aanvallers zouden een ontwikkelomgeving en delen van de productieomgeving hebben benaderd via een derdepartijcomponent.
Chainstack beschrijft dat er toegang was tot een database met klantaccountinformatie. Mogelijk blootgestelde gegevens omvatten onder meer organisatienamen, namen van accounthouders, e-mailadressen van leden en password hashes. Ook bestond de kans dat account- of node-credentials zijn blootgesteld, omdat de aanvallers systemen konden benaderen die die gegevens bewaren.
Daarom vroeg Chainstack klanten om getroffen credentials te roteren.
WorkOS: toegang tot interne salesapp en klantcommunicatie
WorkOS meldt dat de compromittatie op 30 oktober plaatsvond. Het incident begon met het binnendringen van een interne applicatie die door de salesorganisatie wordt gebruikt.
Daarna zouden aanvallers zakelijke contactgegevens en samenvattingen van klantcommunicatie hebben ingezien. De beschreven informatie omvat namen, e-mailadressen, telefoonnummers, functietitels, bedrijfsgegevens, klantgeschiedenis, verkoopdetails, CRM-informatie en communicatie-overzichten.
Hoewel dit incident niet in dezelfde zin een “AI token” als eindproduct beschrijft, past het wél in hetzelfde bredere patroon: aanvallers zoeken naar waardevolle klantgegevens en kunnen die mogelijk combineren met andere toegang.
Wat je als organisatie kunt doen tegen AI-toegangslekken
Je kunt dit soort incidenten niet volledig voorkomen met één maatregel. Toch kun je risico’s sterk verlagen door focus te leggen op credential management en segmentatie tussen lagen.
1) Beperk en bewaak tokens en keys
Zorg dat tokens een zo klein mogelijke scope hebben en dat je toegang tot geheime data centraliseert. Volg daarnaast ongebruikelijke gebruikspatronen van AI-toegang (bijvoorbeeld plotselinge stijgingen in requests of requests vanuit afwijkende omgevingen).
2) Let op de tussenlaag: hosting, evaluatie en consoles
Veel AI-aanvallen verlopen via intermediaire systemen. Controleer daarom wie toegang heeft tot developer consoles, evaluatiediensten en hostingomgevingen. Vergeet ook niet de keten van afhankelijkheden: derdepartijcomponenten kunnen een entrypoint vormen.
3) Train teams op snelle rotatie en incidentrespons
Wanneer er AI-toegangslekken worden gemeld, is snelheid essentieel. Leg vooraf vast hoe je tokens en credentials roteert, wie het beoordeelt en hoe je klanten informeert. Zie ook het bredere belang van “niet één laag vertrouwen” in moderne agent- en runtime security.
Lees ter verdieping: Agent runtime security: waarom één laag niet genoeg is.
Verandert het dreigingsbeeld: meer aanvallen, betere monetisatie
De belangrijkste boodschap uit de recente meldingen is dat aanvallen niet willekeurig lijken. Het lijkt te draaien om schaalbaarheid: met gestolen tokens kan de aanvaller snel opbrengst genereren, terwijl automatisering de instap verlaagt.
Verder wordt geduid dat technieken rondom LLM-jacking en broker-infrastructuur de waarde van gestolen AI-toegang vergroten. Als meer partijen deze aanpak “productiseren”, kun je verwachten dat het aantal pogingen verder toeneemt—ook richting organisaties die niet direct “de AI” ontwikkelen, maar wel AI-werkstromen draaien.
Conclusie
AI-toegangslekken groeien uit tot een terugkerend thema: aanvallers jagen op tokens en opgeslagen klantgeheimen via hostinglagen, developer consoles en andere intermediaire systemen. Daarbij spelen automatiseringsframeworks zoals Artex een rol, waardoor aanvallen sneller en consistenter worden.
Door je token- en credentialbeleid strak te maken, de keten van tussenlagen te beveiligen en incidentrespons te versnellen, verklein je de kans dat één compromittatie meteen leidt tot brede blootstelling. Blijf bovendien alert op signalen van misbruik zodra een platform of component getroffen wordt.
