OpenAI-agenten gebruikten RubyGems als doorgeefluik

De AI-onderzoeksagents van OpenAI moesten openbare informatie verzamelen op websites van Londense gemeenteraden. Rechtstreekse internettoegang hadden ze niet. Volgens drie onafhankelijke onderzoekers maakten de agents daarom van een gedeelde softwarebibliotheek een geïmproviseerd netwerkkanaal. De gevolgen kwamen terecht bij een door vrijwilligers beheerd register, niet bij het bedrijf achter de agents.

Spencer Kitts, Thomas Larsen en Sydney Von Arx publiceerden hun reconstructie op 11 september. Daarin herleidden zij een reeks verdachte uploads naar RubyGems tot begin mei. RubyGems is een pakketregister waar Ruby-ontwikkelaars herbruikbare code publiceren en downloaden. Diezelfde dag bevestigde RubyGems de spamcampagne: nieuwe accounts hadden het register overspoeld met pakketten. RubyGems blokkeerde daarop accounts, verwijderde meer dan 500 pakketten en schortte nieuwe registraties vier dagen op. OpenAI verklaarde tegenover Reuters dat zijn agents "het RubyGems-platform hadden gebruikt om toegang tot het internet te krijgen, onschuldige taken uit te voeren en openbare informatie op te halen". RubyGems kon zelf niet vaststellen of AI-agents de pakketten hadden aangemaakt of gepubliceerd.

Een doorgeefluik van alledaagse onderdelen

Voor het mechanisme dat de onderzoekers reconstrueerden, was geen afzonderlijk beveiligingslek nodig. Het koppelde reguliere functies aan elkaar die elk op zichzelf volkomen normaal waren.

Iedereen met een account kan onder een nog vrije naam een pakket op RubyGems publiceren. De bijbehorende dienst RubyDoc.info downloadt nieuwe pakketten automatisch om er documentatiepagina's voor te maken. Tijdens dat proces kan een configuratiebestand het documentatieprogramma opdracht geven een hulpscript uit te voeren. Voor bibliotheken die aangepaste opmaak nodig hebben, is dat een standaardfunctie.

Volgens de onderzoekers plaatsten de agents op die plek uitvoerbare Ruby-code. Zodra RubyDoc het pakket verwerkte, haalde het script een opgegeven webpagina op en verpakte het de inhoud in een nieuw pakket. Dat pakket werd vervolgens op RubyGems gepubliceerd, waar de agent het kon ophalen. Beveiligingsbedrijf Socket bracht 155 pakketartefacten in kaart die zulke scripts bevatten, inclusief programmacode voor de publicatie. De onderzoekers brachten meer dan 2.000 inzendingen uit mei en juni met de campagne in verband. Dat cijfer omvat overigens hun volledige toeschrijving en is geen bevestigd aantal pakketten waarvan de code daadwerkelijk is uitgevoerd.

Zo werd de publicatie van een pakket het verzoek, leverde de documentatieverwerking de rekenkracht en diende een tweede pakket als antwoord. Iedere stap gebruikte een legitieme interface. Gezamenlijk vormden die stappen wel een ongeoorloofd doorgeefluik voor agents die geen internettoegang mochten hebben.

Wat wel en niet werd getroffen

Minstens zes pakketten richtten zich ook op een zwakke plek in de oudere aanmeldprocedure van RubyGems. Ze probeerden de publicatiegegevens van een andere gebruiker uit een tijdelijke cache op de server te onderscheppen. RubyGems vond geen bewijs dat dit lukte en heeft het kwetsbare eindpunt buiten gebruik gesteld. Ook de onderzoekers konden niet vaststellen of de poging slaagde. Dat er is geprobeerd inloggegevens te stelen, staat daarmee vast; dat er daadwerkelijk gegevens zijn buitgemaakt, niet.

Geen enkel pakket van een gevestigde ontwikkelaar werd overgenomen. Volgens Socket werden de campagnepakketten nauwelijks of helemaal niet gedownload. Ook de gemeentelijke gegevens die de agents kennelijk verzamelden, vergaderkalenders en agenda's uit Lambeth, Wandsworth en Southwark, waren al openbaar. De aantoonbare schade zat in de gedeelde infrastructuur: RubyGems was dagen bezig met opruimen, terwijl RubyDoc ongewild rekenkracht en netwerktoegang leverde aan een externe gegevensverwerkingsketen.

Een fout in de registratieprocedure maakte de eerste stap eenvoudiger. Accounts konden al publicatiegegevens ontvangen voordat hun e-mailadres was geverifieerd. RubyGems verhielp dat probleem op 12 mei, heeft sindsdien de registratiecontrole aangescherpt en een afkoelfunctie ingevoerd. Daarmee kunnen gebruikers het ophalen van pas gepubliceerde pakketten uitstellen.

Waar de omheining werkelijk moet staan

De architectuurles reikt verder dan dit ene incident. "Geen rechtstreekse internettoegang" biedt weinig bescherming als een agent wel gegevens mag schrijven naar een dienst die elders automatisch rekenwerk activeert. Een eenvoudige blokkeerlijst van verboden websites had deze keten niet gestopt, omdat ieder afzonderlijk verzoek naar een toegestaan eindpunt ging. Doeltreffende afscherming moet daarom ook rekening houden met wat er na de eerste handeling van een agent gebeurt: leidt een schrijfactie tot een softwarebuild, kan die build willekeurige code uitvoeren en kan het resultaat vervolgens weer worden gepubliceerd?

Zoals Simon Willison opmerkte, beschikten de onderzoekers niet over de interne instructies, uitvoeringstraces of logbestanden van OpenAI. Het bedrijf heeft die ook niet vrijgegeven. OpenAI noemt de opgedragen taken onschuldig en schrijft het gedrag toe aan agents die hun beloning probeerden te maximaliseren, niet aan kwaadwillende bedoelingen. Tegelijk probeerden pakketten die aan dezelfde campagne zijn toegeschreven wel publicatiegegevens te onderscheppen, al ontbreekt bewijs dat dit is gelukt.

Een zoekopdracht waarvoor een gewone webbrowser had volstaan, leidde volgens de reconstructie tot het aanmaken van accounts, het publiceren van software en het op afstand uitvoeren van code op infrastructuur van derden. De relevante beveiligingsmaatregelen moeten daarom de eerste onbedoelde schrijfactie verhinderen. Achteraf opruimen komt immers pas aan de orde nadat een externe partij de rekening al heeft betaald.