Gestolen AI-sleutels: Railway meldt $740.000 aan misbruik

Een AI-API-sleutel lijkt een onopvallende regel in een configuratiebestand. Tot iemand anders hem vindt. Dan kan die sleutel ineens toegang geven tot betaalde modellen, grote hoeveelheden rekenkracht en een factuur die niemand had begroot.

Dat is wat de cloudontwikkelomgeving Railway nu in detail beschrijft. Op 10 november publiceerde het bedrijf een uitgebreid onderzoeksrapport over een aanval van 20 en 21 oktober 2026. Volgens Railway leidde het misbruik van buitgemaakte AI-credentials tot naar schatting 740.000 dollar aan ongeautoriseerd verbruik.

Voor kleinere bedrijven die AI-tools of eigen applicaties bouwen, is dit geen ver-van-mijn-bedverhaal. Je hoeft geen eigen datacenter te hebben om hetzelfde soort financiële risico te lopen.

Van ontwikkelomgeving naar sleutelbos

Railway is een platform waarmee ontwikkelaars applicaties kunnen bouwen en hosten. Veel van die applicaties gebruiken API-sleutels: geheime codes waarmee software toegang krijgt tot bijvoorbeeld AI-modellen, databases of betaaldiensten.

Zo'n sleutel staat meestal niet zichtbaar in de broncode, maar in een *environment variable*: een configuratiewaarde die de applicatie bij het starten krijgt. Dat is gebruikelijk en vaak verstandiger dan een geheim rechtstreeks in een Git-repository zetten.

Het systeem dat die waarden opslaat, krijgt daarmee wel een belangrijke verantwoordelijkheid. Wie bij de sleutels kan, kan soms ook namens de eigenaar van de sleutel verzoeken versturen. Een aanvaller hoeft daarvoor niet eerst het wachtwoord van iedere medewerker te kennen.

Wat er bij Railway misging

De aanval begon volgens het bedrijf in de gedeelde infrastructuur waarmee klantapplicaties worden gebouwd. De aanvaller wist deels uit de isolatie van een buildomgeving te ontsnappen en bemachtigde een intern toegangsgegeven. Dat gegeven bleek bij een andere interne dienst meer rechten te hebben dan bedoeld.

Vervolgens kreeg de aanvaller inzage in een beperkte verzameling buildgeschiedenissen en in Railway's eigen code. Na het onderzoeken van die code werd een verkeerd ingestelde cloudvertrouwensrelatie gevonden, waarmee verdere toegang mogelijk werd.

Uiteindelijk bereikte de aanvaller systemen die versleutelde configuratiegegevens opslaan en ontsleutelen. Volgens de forensische logs werd specifiek gezocht naar variabelen met namen die passen bij sleutels van AI-aanbieders.

Dat is een belangrijk onderscheid. Railway zegt niet dat alle klantaccounts waren overgenomen. Het bedrijf berekende dat bij maximaal 1,85 procent van de workspaces, ongeveer 100.000, configuratiegegevens *mogelijk* konden zijn ontsleuteld. Dat is een bovengrens, geen vastgesteld aantal gestolen individuele sleutels.

Ook werden gekoppelde tokens van 1.852 gebruikers ingetrokken of gereset. Railway zegt geen aanwijzingen te hebben gevonden dat aanvallers met deze gegevens op persoonlijke Railway-accounts hebben ingelogd.

Waarom juist AI-sleutels aantrekkelijk zijn

Een gestolen AI-sleutel is anders dan een gestolen document. Hij is niet alleen waardevol vanwege de informatie die erin staat; hij kan ook onmiddellijk kosten veroorzaken.

Veel AI-diensten rekenen per verwerkte hoeveelheid tekst, beeld of andere modelcapaciteit. Met een werkende sleutel kan software automatisch verzoeken blijven sturen totdat een limiet wordt bereikt of de toegang wordt ingetrokken.

Onderzoeksbedrijf Wiz beschrijft een bredere golf van aanvallen op AI-ontwikkelplatforms. Gestolen toegang kan volgens die analyse worden gebruikt om AI-capaciteit goedkoop door te verkopen, soms via tussenliggende diensten. Het gebruik voor het trainen of nabootsen van modellen wordt ook genoemd, maar niet elke waargenomen aanval kan aan dezelfde dader of hetzelfde doel worden toegeschreven.

Railway denkt dat de gestolen sleutels voor zulke doorgeefdiensten bedoeld waren. Dat is de beoordeling van Railway, geen onafhankelijk bewezen identiteit of bestemming van alle buitgemaakte credentials.

De financiële impact is wel concreet. Het bedrijf schat de ongeautoriseerde AI-kosten op ongeveer 740.000 dollar. Railway zegt met aanbieders aan terugbetaling te werken en zelf bij te springen wanneer een aanbieder de kosten niet vergoedt. Dat is de toezegging van Railway voor dit incident, geen algemene garantie die iedere cloudleverancier biedt.

Waarom een klein bedrijf dit moet begrijpen

Stel: een webbureau gebruikt een AI-model om documenten voor klanten samen te vatten. De applicatie draait bij een hostingpartij en bevat één API-sleutel waarmee het bureau voor alle verzoeken betaalt.

Als die sleutel uitlekt, hoeft de eigen website niet zichtbaar gehackt te zijn. De AI-aanbieder kan toch geld afschrijven voor verzoeken die buiten de normale applicatie om worden gedaan. En zolang de sleutel geldig blijft, kan het misbruik doorgaan.

Dat voorbeeld is hypothetisch, maar de onderliggende afhankelijkheid is reëel: wie de API-sleutel bezit, heeft vaak ook de mogelijkheid kosten te maken.

Voor teams die met AI-agents werken, kan het effect nog groter zijn. Agents voeren zelfstandig meerdere modelaanroepen en toolacties uit. Zonder goede limieten kan het lastig zijn om onderscheid te maken tussen een drukke legitieme workflow en ongewenst verbruik.

Daarom hoort beveiliging van AI-sleutels niet uitsluitend op de takenlijst van de ontwikkelaar. Ook de persoon die het budget beheert moet weten welke diensten worden gebruikt, hoe kosten gemonitord worden en hoe toegang in een incident direct kan worden ingetrokken.

Vijf maatregelen die niet ingewikkeld hoeven te zijn

1. Gebruik aparte sleutels per project en omgeving. Geef productie, testen en individuele toepassingen niet onnodig dezelfde toegang. Dat maakt intrekken en onderzoeken eenvoudiger.
2. Beperk rechten en bestedingen. Gebruik waar mogelijk projectgebonden credentials, quota, harde bestedingslimieten en waarschuwingen bij onverwachte pieken. Een melding is geen harde limiet.
3. Controleer waar geheimen terechtkomen. Kijk niet alleen naar Git, maar ook naar CI/CD, deploymentlogs, hostinginstellingen, AI-agenttools en gekoppelde externe diensten.
4. Monitor verbruik en logs buiten de applicatie. Vergelijk factuur- en gebruiksgegevens van de AI-aanbieder met de verzoeken die je eigen systeem denkt te hebben uitgevoerd.
5. Maak een draaiboek voor sleutelrotatie. Leg vast wie direct een sleutel kan intrekken, welke systemen daarna opnieuw geconfigureerd moeten worden en hoe je bewijs van misbruik bewaart.

Voor een bedrijf dat Railway gebruikt of in oktober gebruikte, blijft de concrete herstelroute die van Railway zelf: controleer de gepubliceerde instructies, roteer betrokken credentials en beoordeel eventuele onverwachte kosten. Deze aanbeveling zegt niets over de veiligheid van een willekeurige andere hostingdienst.

De echte les van de inbraak

Railway heeft naar eigen zeggen de misbruikte toegangsroutes afgesloten en zijn builds sterker geïsoleerd. Het bedrijf verving onder meer gedeelde buildomgevingen door afzonderlijke tijdelijke virtuele machines. Een extern forensisch onderzoek liep bij publicatie van het nieuwe rapport nog.

Het opvallende aan de zaak is de combinatie van een technisch complexe cloudinbraak en een heel tastbaar eindresultaat: een rekening voor AI-gebruik. Je hoeft de gebruikte aanvalstechnieken niet volledig te begrijpen om de zakelijke vraag te stellen.

Als morgen een API-sleutel van jouw bedrijf uitlekt, hoeveel geld kan er dan worden uitgegeven voordat iemand het merkt?

Bronnen: Railway-rapport · Railway-melding · Wiz · BleepingComputer · The Hacker News