AI-agenten brengen een ingrijpende verandering teweeg in de beveiliging van de software supply chain: de documentatie is niet langer vanzelf passieve informatie. Een onderzoek naar duizenden llms.txt-bestanden vond verwijzingen naar pakketten en domeinen zonder eigenaar. Na het registreren van enkele hiervan, ontdekten de onderzoekers dat agenten die samenwerken met Claude, OpenAI Codex en Hermes hun testpakketten installeerden binnen bedrijfsomgevingen, inclusief Fortune 500-bedrijven.
De kern van het risico van orfengeld voor AI-agenten in 30 seconden
- De analyse omvatte 6.214 domeinen van Fortune 500-bedrijven, grote technologiebedrijven en defensiecontractors.
- Op 120 sites werden verwijzingen gevonden naar een of meer pakketten of domeinen die klaar waren voor registratie.
- De onderzoekers claimden enkele namen en publiceerden testcode ontworpen om alleen de uitvoering te bevestigen.
- Signalen kwamen van verschillende bedrijven, en sommige installaties kunnen gerelateerd worden aan Claude, Codex en Hermes.
- Dit probleem verbreedt de beveiliging van de supply chain: een agent kan verouderde documentatie omzetten in een daadwerkelijke actie.
Het was niet nodig om de websites van bedrijven te hacken, phishingmails te versturen of zero-day kwetsbaarheden te exploiteren. Ook werd geen code toegevoegd aan legitieme repositories.
De onderzoekers maakten gebruik van iets eenvoudigs: oude verwijzingen die nog steeds als geldig werden beschouwd nadat het oorspronkelijke resource was verdwenen.
Dit is vooral relevant nu programmeeragenten toestemming beginnen te krijgen om terminalen te gebruiken, afhankelijkheden te installeren, repositories aan te passen, tests uit te voeren en ontwikkelhulpmiddelen te gebruiken.
Een verbroken link leidt niet altijd tot een 404-error.
In geautomatiseerde processen kan dat een kans worden om code te injecteren.
Van llms.txt tot terminal: waar verandert het beveiligingsmodel
llms.txt is een opkomende conventie die models en agents een eenvoudige, gestructureerde weergave biedt van webinhoud.
De gangbare vergelijking is robots.txt, hoewel ze technisch verschillende functies hebben. Terwijl robots.txt instructies geeft aan crawlers, is llms.txt bedoeld om modellen en agenten te helpen relevante documentatie te vinden en te begrijpen.
Het formaat zelf installeert niets.
Het risico ontstaat wanneer de informatie die erin staat of waarnaar wordt verwezen, wordt gebruikt door een agent die de juiste tools heeft om actie te ondernemen.
Technische documentatie kan bijvoorbeeld aangeven dat een bepaalde bibliotheek moet worden geïnstalleerd. Het agent controleert de instructies, beslist dat die afhankelijkheid nodig is, en voert het bijbehorende pakketbeheerhulpmiddel uit.
Dit proces werkt zolang alle onderdelen onder legitieme controle blijven.
Maar het internet zit vol met oude, niet-geüpdatete projecten, verwijderde repositories, ingetrokken pakketten, verlopen domeinen en verouderde documentatie.
De onderzoekers analyseerden 6.214 actieve domeinen van grote organisaties. Volgens de gepubliceerde gegevens vonden ze 8.265 llms.txt-bestanden en llms-full.txt-bestanden, en identificeerden 120 sites die verwezen naar één of meer resources zonder eigenaar.
Dit doet denken aan bekende supply chain-kwetsbaarheden, maar met een belangrijke nuance.
Vroeger was er meestal een persoon tussen documentatie en uitvoering.
Nu kan er een agent tussen zitten.
Een pakket verdwijnt, maar het vertrouwen blijft
Om de gevolgen te testen, registreerden de onderzoekers enkele van de namen die beschikbaar waren geworden.
Ze publiceerden geen malware om bedrijven te compromitteren. In plaats daarvan gebruikten ze testpakketten die een signaal naar hun infrastructuur zouden sturen wanneer ze werden uitgevoerd.
Daarna wachtten ze af.
Dit mechanisme is vooral interessant vanuit beveiligingsoogpunt, omdat de onderzoekers niet actief op zoek hoefden te gaan naar kwetsbare systemen. De verwijzingen waren al gepubliceerd door de organisaties zelf of in documentatie die als legitiem werd beschouwd.
Toen de agenten die informatie verwerkten en de installaties uitvoerden, begonnen de signalen binnen te komen.
Analyse van de procesketens liet zien dat sommige uitkomsten verband hielden met agenten zoals Claude, OpenAI Codex en Hermes van Nous Research.
Dit vereist precieze interpretatie.
Het experiment bewijst niet dat deze agenten altijd en autonoom pakketten installeren die in llms.txt worden genoemd. Het hangt af van hun configuratie, instructies, beschikbare tools en de toegestane permissies door gebruikers of organisaties.
De beveiligingsvraag ligt precies hier.
Hoe zelfstandiger een agent is, hoe belangrijker het wordt om te controleren waar elke instructie vandaan komt voordat deze wordt omgezet in een actie.
Het oude probleem van verlopen domeinen raakt nu ook de agenten
David Carrero Fernández-Baillo, mede-oprichter van Stackscale (Grupo Aire), ziet een interessant parallel met een fenomeen dat al jaren bekend is: de residuale betrouwbaarheid van verlopen domeinen.
Carrero legt uit dat hij af en toe verlopen domeinen registreert voor legitieme projecten, bijvoorbeeld voor SEO-doeleinden. Een domein met veel geschiedenis kan nog steeds links bevatten van andere websites en enige autoriteit behouden van toen het nog in gebruik was.
De nieuwe eigenaar profiteert in zekere zin van een reputatie die hij niet zelf heeft opgebouwd.
De bevindingen omtrent agenten maken dat principe nog delicater.
Als een organisatie jaren lang een domein, pakket of repository aanbeval en dat resource vervolgens verdwijnt, kan de referentie nog steeds vertrouwen behouden door de oude eigenaar, ondanks dat het eigendom is veranderd.
Bij een traditionele webpagina kunnen de gevolgen beperkt blijven tot het doorsturen van bezoekers naar een ander domein.
Bij technische documentatie die door agenten wordt verwerkt, kan de nieuwe eigenaar iets anders erven: een toegangspoort binnen een keten die uiteindelijk leidt tot het uitvoeren van software.
Zoals Carrero aangeeft, is de conceptuele sprong groot: het gaat van het erven van SEO-reputatie via links naar het kunnen erven van een toegang die de documentatie open heeft gelaten.
Het is geen kwetsbaarheid van llms.txt
De hele discussie alleen richten op llms.txt zou een verkeerde conclusie kunnen opleveren.
Het verwijderen van deze bestanden lost het probleem niet op.
Een agent kan instructies krijgen via een README, officiële documentatie, een repository, een supportpagina, een tutorial of elke andere bron die als betrouwbaar wordt beschouwd.
Het probleem ligt in het verwarren van documentaire autoriteit met de autoriteit om uit te voeren.
Beveiligingsteams beschermen al jaren repositories en CI/CD-pipelines. Ze controleren dependencies, containerimages, credentials en artifacts.
Documentatie krijgt meestal een andere behandeling, omdat deze historisch gezien indirect systemen kan beïnvloeden.
Agenten veranderen die scheiding.
Als een document een agent kan laten uitvoeren, een afhankelijkheid kan installeren of een configuratie kan wijzigen, wordt dat document een potentieel aanvalspunt.
Dat vereist dat we ook de beveiliging van bedrijfsinformatie en -publicaties hervormen.
Een organisatie moet vragen kunnen beantwoorden zoals: blijven alle aanbevolen pakketten bestaan? Zijn de gelinkte domeinen nog in bezit van hetzelfde eigendom? Blijven de repositories legitiem? Wat gebeurt er met documentatie van niet-meer-onderhouden producten?
Het beheer van documentatie begint meer op afhankelijkheidsbeheer te lijken.
De supply chain heeft een extra laag nodig voor agenten
De technische oplossing is niet simpelweg het toevoegen van een waarschuwing aan het model.
Organisaties die agenten toestaan code uit te voeren, moeten controles implementeren naast het model zelf.
De eenvoudigste aanpak is geen vertrouwen te stellen op een enkele documentatiebron voor de afhankelijkheid.
De herkomst van een pakket moet apart worden geverifieerd. Afhankelijk van de omgeving kunnen controle op registratie, eigenaar, versie, leeftijd, handtekening, hash, herkomstrepository en andere beschikbare data plaatsvinden.
Agenten mogen niet automatisch dezelfde privileges krijgen als ontwikkelaars.
Een geïsoleerde of tijdelijke omgeving stelt een agent in staat om afhankelijkheden te testen zonder direct code in systemen met toegang tot bedrijfsinformatie te brengen.
Deze scheiding is vooral belangrijk wanneer agenten beschikken over credentials voor cloud-services, private repositories, secrets management, CI/CD-pipelines of productie-infrastructuur.
Menselijke goedkeuring blijft relevant voor bepaalde operaties.
Maar het mag niet de enige verdedigingslinie zijn.
Een persoon die tientallen bevestigingsverzoeken ontvangt, zal ze vaak automatisch goedkeuren, vooral als de interface eenvoudigweg vraagt: “Installatie toestaan?”.
Het controlemechanisme moet context bieden: welk pakket wordt geïnstalleerd, wie onderhoudt het, waar komt de aanbeveling vandaan en waarom vindt het agent het nodig om het te gebruiken?
De culturele achterliggende oorzaak van het technische falen
Carrero wijst verder op een minder zichtbaar aspect van het onderzoek: 120 van de 6.214 geanalyseerde sites bevatten nog steeds verwijzingen naar resources die niet meer goed onder controle waren.
Dit is geen complexe kwetsbaarheid.
Het is het resultaat van praktijken die al decennia bestaan: verouderde documentatie, afgelegen projecten, verlopen domeinen en verwijzingen die jarenlang gekopieerd werden zonder controle.
Copy-paste is altijd een risico geweest bij softwareontwikkeling.
Wat verschilt, is de schaal.
Een ontwikkelaar kan een commando kopiëren, uitvoeren en vervolgens een fout tegenkomen en stoppen. Een agent kan binnen enkele seconden tientallen pagina’s raadplegen, afhankelijkheden oplossen en instructies uitvoeren.
Automatisering maakt niet alleen taken sneller, maar ook de bijbehorende slechte praktijken.
Daarom heeft dit niet alleen een technische, maar ook een diepe culturele dimensie.
De komst van agenten betekent dat we moeten afstappen van de veronderstelling dat alles wat op een domein van een provider staat, automatisch betrouwbaar en actueel is.
Documentatie is een informatiestroom.
Het zou niet moeten fungeren als een digitale handtekening.
Van gebroken links tot een nieuwe aanvalsbasis
Het onderzoek geeft ook een aanwijzing over hoe offensieve beveiliging zich kan ontwikkelen.
Internet bevat miljoenen achtergelaten verwijzingen. Veel gaan over onbeduidende projecten, maar een groot deel zit verpakt in bedrijfsdocumentatie, oude scripts, repositories, tutorials en configuraties.
Tot nu toe was het vinden van zo’n resource weinig waardevol.
Agenten kunnen deze balans wijzigen.
Een aanvaller zou systematisch verwijzingen kunnen zoeken naar verouderde pakketten, domeinen of repositories die voorkomen in documentatie die door geautomatiseerde tools wordt gebruikt.
Het doel is niet meer om een persoon te verleiden iets te installeren, maar om een vertrouwensketen te vinden die nog steeds door machines wordt gebruikt.
Het experiment met llms.txt bewijst dat deze mogelijkheid niet meer puur theoretisch is.
Bedrijven implementeren nu agenten die kunnen programmeren, terminals gebruiken en services beheren met grote snelheid. Ze moeten ervoor zorgen dat de mate van vertrouwen die deze systemen in internet stellen, niet hun eigen veiligheid ondermijnt.
Want orfegeld code bestaat al jaren.
Wat is veranderd, is dat er nu agenten zijn die die code kunnen opsporen, interpreteren en, onder bepaalde omstandigheden, uitvoeren.
Veelgestelde vragen
Is llms.txt een beveiligingskwetsbaarheid?
Niet op zichzelf. llms.txt is een conventie om modellen en agents eenvoudig en gestructureerd informatie te bieden. Het risico ontstaat wanneer een agent de gevonden instructies omzet in acties zonder de betrokken resources onafhankelijk te verifiëren.
Wat is een orfest pakket?
In deze context is het een naam van een pakket, domein of resource dat in documentatie wordt genoemd, maar niet langer onder controle staat van de oorspronkelijke eigenaar. Als iemand anders het claimt, kunnen oude verwijzingen naar dat resource uiteindelijk naar de nieuwe eigenaar leiden.
Werkten Claude, Codex en Hermes daadwerkelijk code uit de onderzoekers?
De onderzoekers vonden dat bepaalde installaties gekoppeld waren aan ketens van processen die verband hielden met Claude, OpenAI Codex en Hermes. Het experiment bewijst niet dat deze agenten altijd en autonoom pakketten installeren die in llms.txt worden genoemd. Dit hangt af van hun configuratie, permissies en omgeving.
Hoe kan een bedrijf dat AI-agenten gebruikt zich beschermen?
Door principes van minimaal privilege toe te passen, uitvoeringen te isoleren, afhankelijkheden via onafhankelijke mechanismen te controleren en periodiek de aanbevolen pakketten, domeinen en repositories te auditen. Kritieke acties zouden niet uitsluitend moeten afhangen van de betrouwbaarheid van webpagina’s door een agent.
Bron: Open Security