METR's vibe-gecodeerde agentdashboard schakelde zijn eigen login uit, en een aanvaller verbruikte $600.000 aan modeltegoed

In maart 2026 heeft iemand een API-sleutel voor het public-models-account van METR van de persoonlijke Amazon EC2-instantie van een onderzoeker gehaald en die drie weken lang gebruikt. METR — Model Evaluation and Threat Research, de non-profitorganisatie die meet hoe ver AI-agenten komen bij langdurige taken — schatte de commerciële waarde van het verbruikte tegoed op ongeveer $600.000. De sleutel is niet via phishing bij een mens buitgemaakt: de aanvaller zette een agent die op het vibe-coded dashboard van de onderzoeker draaide, ertoe aan de API-sleutel van zijn modelprovider af te staan en voegde daarna een SSH-sleutel toe zodat hij kon terugkeren. METR maakte het incident bekend op 31 augustus 2026, en het record draagt de hoge ernstgraad van het archief en een betrouwbaarheidsbeoordeling van A. De bekendmaking is één record in het AI-incidentenarchief, dat de volledige recordverzameling, de bijbehorende bronnen en de aangrenzende vermeldingen in deze reeks bevat.

Wat het record eigenlijk zegt

Het archief classificeert dit als een daadwerkelijk incident, niet als de onthulling van een theoretische zwakte: ernst hoog, betrouwbaarheid A, niet betwist, met vastgelegde reële schade en bevestigde AI-betrokkenheid. Het typelabel is CRED, de regio is de Verenigde Staten, en de datum is alleen tot op de maand vastgelegd — het archief weet dat de diefstal in maart 2026 plaatsvond en noemt geen dag, en METR evenmin.

De schade behoeft één nuance, en METR levert die. De credits werden METR gratis verstrekt door de modelontwikkelaar, dus de $600.000 is de waarde van wat er is verbruikt, niet geld dat een rekening heeft verlaten. De introductietekst van The Register maakte hetzelfde punt plomper: de modelprovider gaf METR de credits, en een daadwerkelijk betalende klant zou niet zoveel geluk hebben gehad. Infosecurity Magazine rapporteerde het cijfer op dezelfde manier, als commerciële waarde in plaats van direct financieel verlies.

METR's bericht behandelt twee incidenten, niet één. De campagne van mei 2026 wordt verderop afzonderlijk beschreven; de diefstal van de sleutel en de drie weken van uitgaven vormen het incident van maart, en zij zijn het onderwerp van dit artikel.

De fout zat in de login, niet in het model

Een METR-onderzoeker zonder toegang tot gevoelige gegevens liet agents draaien op een persoonlijke EC2-instance die opzettelijk publiek bereikbaar was gemaakt, achter Google-authenticatie. De instance bevatte een API-sleutel voor het account van METR voor algemene toegang — het account dat wordt gebruikt voor publieke modellen, dat METR als zijn op één na minst gevoelige gegevenscategorie beschouwt. De orchestratie-app rond die agents was vibe-coded en bevatte wat METR een fail-open kwetsbaarheid die authenticatie stilzwijgend uitschakelde

Fail-open is de moeite van het vertalen waard, want het is het hele incident in twee woorden. Een logincontrole kan op twee manieren fout zijn: hij kan een legitieme gebruiker weigeren, of iedereen toelaten wanneer de controle zelf stukgaat. Fail-open betekent het tweede: wanneer de authenticatiestap een fout opleverde of werd overgeslagen, behandelde de app het verzoek als toegestaan in plaats van geweigerd. Niets sloeg alarm. In het verslag van METR was het resultaat een systeem dat enkele dagen op het openbare internet stond met de voordeur wijd open en zonder enige aanwijzing dat er iets was veranderd.

METR noemt de orchestratietool of het framework waarmee het dashboard is gebouwd niet, publiceert de code niet en zegt niet op welke manier de authenticatie-integratie mislukte. Wat het bericht wel vaststelt, is de architectuurfout onder de bug: een credential voor een account van een organisatiemodel stond op infrastructuur die METR niet beheerde, in een applicatie die één onderzoeker zelf had uitgerold.

Hoe de sleutel het gebouw verliet

METR's reconstructie van de werkwijze van de aanvaller is uitdrukkelijk een vermoeden, geen bevinding, en het is de meest interessante onbewezen bewering in de openbaarmaking. In het bericht staat dat METR vermoedt dat de aanvaller de instantie heeft gevonden door recent geregistreerde websites te browsen — certificaattransparantielijsten worden als voorbeeld genoemd — op zoek naar vibe-coded sites met trefwoorden die wijzen op LLM- of agentprojecten, om API-sleutels van modelproviders te oogsten die blootgesteld waren achtergelaten.

Certificaattransparantielogs zijn publiek van opzet: elk certificaat dat voor een publiekelijk vertrouwde site wordt uitgegeven, wordt vastgelegd, waardoor een nieuwe hostnaam binnen enkele minuten na livegang in een doorzoekbare feed verschijnt. Die feed filteren op namen die agent- of modelterminologie bevatten, is goedkoop, vereist geen toegang tot het doel en levert een lijst op van nieuwe implementaties die mogelijk door niemand zijn beoordeeld. Gelezen als jachttechniek verandert het de gewone daad van het publiceren van een demo in een signaal.

Eenmaal binnen hoefde de aanvaller geen geheim uit een bestandssysteem te stelen. Die stuurde de agent rechtstreeks een prompt om de API-sleutel van zijn modelprovider te onthullen, wat een zin is die even aandacht verdient: de agent had de credential in zijn context en kon worden overgehaald om hem af te drukken. De aanvaller voegde vervolgens een SSH-sleutel toe voor blijvende toegang, zodat het dichten van het authenticatiegat hem niet zou hebben verdreven, en begon aan drie weken inferentie op openbaar beschikbare modellen.

De modelontwikkelaar wordt niet bij naam genoemd — niet door METR, en niet door The Register, Dark Reading, Infosecurity Magazine of The Hacker News in hun berichtgeving over de onthulling. Er is geen CVE uitgegeven, omdat er geen productkwetsbaarheid in het geding is. Er is geen aanhouding, aanklacht of toeschrijving aan een genoemde groep gemeld.

Waarom drie weken abnormaal gebruik normaal leken

METR beantwoordt de voor de hand liggende vraag rechtstreeks, en het antwoord is het deel dat andere organisaties twee keer zouden moeten lezen. De non-profitorganisatie voert grootschalige evaluaties uit, wat betekent dat ze grondig gewend is aan zeer grote tokenaantallen en aan een stroom van vreemde rate-limit- en API-fouten, waarvan vele onterecht. Een piek in modelverkeer was op zichzelf geen signaal.

Drie specifieke hiaten veranderden die vertrouwdheid in drie weken stilte. Het interne gebruiksdashboard van METR toonde geen gegevens over rate-limited verzoeken bij alle gebruikers, zelfs niet toen die verzoeken plaatsvonden. Omdat de tokens gratis waren, was er geen factuur en dus geen natuurlijk bestedingsplafond dat in werking zou zijn getreden. En volgens METR was het destijds helemaal niet mogelijk om een bestedingslimiet op een dergelijke sleutel te zetten. Een organisatie die de lijstprijs betaalde met een harde limiet zou binnen enkele uren tegen een muur zijn gelopen; een organisatie met gedoneerd tegoed en geen limiet had niets om tegenaan te lopen.

Wat niet is meegenomen

De datataxonomie van METR loopt van gepubliceerd materiaal tot en met generieke modeltoegang, gevoelige modeltoegang en zeer gevoelige bedrijfsinformatie. De betrokken onderzoeker had geen toegang tot de twee hoogste categorieën, en METR verklaart dat voor zover het weet geen gegevens uit die categorieën zijn geraadpleegd als gevolg van een van beide incidenten.

Afgezien van de enkele sleutel zegt METR dat handmatig en door agents ondersteund forensisch onderzoek geen compromittering heeft gevonden, en dat zijn beveiligingsconsultant, Calif, de bevindingen heeft gevalideerd en een eigen compromitteringsbeoordeling heeft uitgevoerd. Dat is een zinvolle beheersmaatregel — een extern bedrijf dat het account controleert in plaats van het zomaar te accepteren — maar het is niet onafhankelijk van METR, dat Calif heeft ingehuurd en betaald. Geen enkele derde partij heeft een eigen forensische beoordeling van het incident gepubliceerd.

Wat METR deed toen het dit opmerkte

De responsreeks in het bericht is concreet. METR stelde vast dat de piek in het gebruik geen deel uitmaakte van een evaluatie, herleidde die tot de gecompromitteerde persoonlijke instantie, trok alle toegang van de onderzoeker in, stopte de instantie en maakte er een image van, roteerde alle inloggegevens die erop aanwezig waren, en maakte een image van de laptop van de onderzoeker en wiste die. Het waarschuwde het partner-AI-bedrijf waarvan de credits werden verbruikt en hield dat bedrijf gedurende de respons op de hoogte.

METR legt niet de redenatie achter het wissen van de laptop uit, en het is de enige stap in de reeks die verder gaat dan het intrekken van toegang tot de instance zelf — de plausibele interpretatie is dat dezelfde onderzoeker met de credential had gewerkt vanaf een werkstation dat de aanvaller kon bereiken, en dat een image maken en vervolgens opnieuw opbouwen de goedkope manier is om zekerheid over een machine te krijgen.

Wat is er daarna veranderd?

METR noemt vier wijzigingen die verband houden met dit incident:

• Het beveiligingsbeleid voor werknemers en contractanten is verduidelijkt en uitgebreid, specifiek met betrekking tot het plaatsen van METR-inloggegevens of -gegevens op infrastructuur en apparaten die geen eigendom van METR zijn.

• Op elke onderzoeker die een applicatie openbaar uitrolt, is nu een formeel beveiligingsreviewproces van toepassing.

• De monitoringdekking is uitgebreid, met werk om ruisalerts weg te nemen die responseteams aanleren ze te negeren.

• Bestedingswaarschuwingen zijn toegevoegd aan sleutels waar de provider dat mogelijk maakt — het voorbehoud is belangrijk, omdat het eerdere punt van de post was dat sommige sleutels van dit soort destijds niet konden worden gemaximeerd.

De openbaarmaking noemt ook organisatiebrede werkzaamheden: het aannemen van een securitylead en het plannen van een fulltime security-engineer, het vergroten van Calif's betrokkenheid, het uitschakelen van legacy-infrastructuur die het aanvalsoppervlak vergrootte, het uitvoeren van regelmatige threat-modellingreviews, het uitbreiden van logging naar databasequery's en API-gebruik, het monitoren op ongebruikelijk gebruik van API-sleutels, het implementeren van extra endpoint- en serversecuritysoftware, het verkorten van de levensduur van inloggegevens en het verkleinen van permissiescopes. METR dateert die maatregelen als accuraat tot 30 juli 2026 en zegt dat ze aan verandering onderhevig zijn — een voorbehoud dat de moeite waard is om te behouden, want het betekent dat het bericht een toestand beschrijft van ongeveer vier maanden na de diefstal en ongeveer een maand voor publicatie.

Het andere incident in dezelfde post

De openbaarmaking van METR koppelt de sleuteldiefstal aan een tweede, afzonderlijke gebeurtenis in begin mei 2026, en de twee zijn gemakkelijk met elkaar te verwarren. In dat tweede geval werd METR getipt dat het doelwit was van aanvallers die financieel gemotiveerd leken en mogelijk uit waren op toegang tot frontiermodellen; het zag hen zijn publieke infrastructuur verkennen, waarbij ze op grote schaal agents inzetten om het opsporen van kwetsbaarheden te automatiseren, waaronder credential stuffing tegen authenticatieproviders, pogingen tot het verlenen van OAuth-tokens, het scannen van nieuw uitgerolde diensten en phishing van medewerkers.

In dezelfde periode heeft METR per ongeluk een alleen-lezen SQL-querymechanisme blootgelegd via de openbare transcriptviewer. Query's waren standaard beperkt tot openbare gegevens, maar een bug kon worden gericht op niet-gepubliceerde evaluatiegegevens, en er was per ongeluk gevoelige modeloutput in die database geladen. Een onafhankelijke beveiligingsonderzoeker vond de fout en meldde deze op verantwoorde wijze; METR haalde de API offline en betaalde een bounty. Volgens METR zijn de aanvallers tijdens hun bredere campagne langs het endpoint gekomen, maar gaven zij geen blijk van het vinden van de exploit of het bereiken van niet-openbare gegevens — een conclusie die METR in een voetnoot op “zeer onwaarschijnlijk” zet in plaats van op nul.

Wat is vastgesteld, en wat niet

Vastgesteld. METR publiceerde de openbaarmaking op 31 augustus 2026 en beschrijft de diefstal in maart, het fail-open-authenticatiefalen, de door de agent bemiddelde sleutelopenbaarmaking, de SSH-sleutel, het venster van drie weken en de waardering van ongeveer $600,000. Vier beveiligingsmedia — The Register, Dark Reading, Infosecurity Magazine en The Hacker News — berichtten binnen een dag over hetzelfde relaas, en geen van hen spreekt dat tegen — hoewel alle vier putten uit hetzelfde METR-bericht in plaats van uit enige onafhankelijke toegang tot METR's logs of de facturering van de provider.

Niet vastgesteld. De $600,000 is METR's eigen schatting van gedoneerd krediet; er is geen factuur, verklaring van de provider of onafhankelijke waardering gepubliceerd, en omdat er niets is betaald, is er geen transactie om het tegen te controleren. De methode om in certificate-transparency te zoeken wordt door METR als een vermoeden bestempeld en is door geen enkele partij met zicht op de activiteit van de aanvaller bevestigd. De identiteit van de aanvaller, de identiteit van de modelprovider en de exacte dag in maart zijn allemaal onbekend of niet gepubliceerd. En de bewering dat er geen gevoelige gegevens zijn bereikt, berust op het forensisch onderzoek van METR en de beoordeling door zijn consultant, niet op een externe audit.

Het is ook de moeite waard om precies te zijn over het woord bijna-ongeval. METR karakteriseert beide incidenten zo, en Dark Reading had bezwaar tegen die framing voor het incident van maart, op grond dat het een geslaagde compromittering was waarbij een aanvaller persistentie wist te bewerkstelligen en drie weken lang rondneusde met een gestolen inloggegeven. Beide beschrijvingen kloppen, elk over iets anders: de uitkomst bleef beperkt, en de inbraak was echt.

Dark Reading gaf in zijn rapport ook de scherpste externe beoordeling weer. Jacob Krell, senior director voor veilige AI-oplossingen en cybersecurity bij Suzu Labs, vertelde het medium dat METR een van de organisaties in de AI-ruimte is die het meest volwassen zijn op het gebied van beveiliging, met SOC 2 Type I-certificering, een toegewijde beveiligingsconsultant en een vierlagig dataclassificatiesysteem, en dat de incidenten zich nog steeds via gewone middelen voordeden — een fail-open-authenticatiefout op een persoonlijke cloudinstantie. Als een organisatie op dat volwassenheidsniveau struikelt over basale cloud- en credentialhygiëne, betoogde Krell, dan zegt dat iets over de ondergrens van de beveiliging in de AI-industrie in plaats van over de bovengrens. Dark Reading merkt op dat METR niet reageerde op zijn verzoek om commentaar op het verhaal.

Waarom de sleutel van een evaluator niet iets kleins is

De rol van METR is de reden dat deze vermelding in een veiligheidsarchief staat en niet in een overzicht van cloudhygiëne. Dark Reading meldt dat de organisatie samenwerkingsverbanden heeft met de meeste grote westerse modelleveranciers, waaronder OpenAI, Anthropic, Google, Meta en Amazon, en The Register merkt op dat METR met OpenAI heeft samengewerkt om te onderzoeken hoe de agents van OpenAI eerder in 2026 Hugging Face-servers bereikten. Een evaluator beschikt over niet openbaar gemaakte resultaten, ongepubliceerde transcripten en toegang tot modellen vóór de release; zijn referenties maken in feite deel uit van de beveiligingsperimeter van zijn klanten.

Het incident van maart reikte tot niets daarvan. Het reikte tot een sleutel voor publieke modellen, op een persoonlijke instantie, achter een login die er stilletjes mee was opgehouden te werken — en dat is precies waarom het een nuttig verslag is. De fout vereiste geen nieuwe aanval op een model. Ze vereiste een demo-uitrol die niemand had beoordeeld, een authenticatiecontrole die bij een storing standaard op ja stond, en een boekhoudsysteem waarin enorm gebruik de normale toestand van de wereld was.