Van handleiding tot hacktool: De verborgen beveiligingsrisico's van AI-leesbare bestanden

De Stille Dreiging die Verborgen Zit in Je Documentatie

Je hebt vast gehoord over prompt injection, model poisoning en aanvallen op trainingsdata. Maar er is één bedreiging die te weinig aandacht krijgt: documentation decay als aanvalsvector.

Onderzoekers ontdekten onlangs iets verontrustends. Ze bekeken llms.txt en llms-full.txt bestanden — machine-leesbare documentatieformats die AI-systemen helpen websites te begrijpen. Wat ze vonden was alarmerend. Op duizenden domeinen van defensieaannemers, Fortune 500-bedrijven en techgiganten vonden ze 120 bestanden die verwezen naar pakketnamen of domeinen die niet meer bestaan.

Het mooie van deze aanval is de eenvoud. Een aanvaller hoeft geen systeem te hacken. Ze hoeven alleen te wachten.

Hoe de Aanval Werkt

Stel je dit voor: Een developer gebruikt een AI coding agent om een project op te zetten. De agent leest het llms.txt bestand van het bedrijf voor installatie-instructies, vindt een verwijzing naar een dependency genaamd cool-utils-lib, en — omdat de agent permissie heeft om package manager commands uit te voeren — installeert het.

Het probleem? Die pakketnaam was nooit geregistreerd. Tot de aanvaller hem registreerde.

In hun gecontroleerde experiment deden de onderzoekers precies dit. Ze claimden enkele van deze verlaten namen, uploadden onschuldige "phone home" pakketten (alleen ontworpen om te loggen wanneer ze werden geopend), en wachtten. De resultaten waren opvallend: minder dan een uur na publicatie had een Fortune 500-bedrijf al een van hun pakketten geïnstalleerd. In de dagen daarna "maakten enkele tientallen meer" organisaties contact.

Dit was geen echte aanval — de pakketten waren onschadelijk en geen productiesystemen werden gecompromitteerd. Maar de bereikbaarheid was bewezen. Het attack surface is reëel.

Waarom AI Agents Dit Erg maken

Hier is wat deze aanval bijzonder gevaarlijk maakt: traditionele beveiliging gaat ervan uit dat gebruikers beslissingen nemen. Als je iemand een document met foute instructies geeft, zouden ze die kunnen opvolgen. Maar mensen vangen vaak voor de hand liggende fouten op, stellen verduidelijkende vragen, of merken het op wanneer iets vreemd lijkt.

AI agents werken anders. Ze behandelen documentatie als uitvoerbare waarheid. Als je llms.txt zegt "run npm install legacy-widget", voert de agent het vaak gewoon uit — zonder zich af te vragen of dat pakket nog bestaat, wie het bezit, of of het het juiste pakket is.

De onderzoekers testen meerdere agents — Claude, OpenAI Codex en Nous Research's Hermes — en ze volgden allemaal de problematische referenties. Dit is geen vendor-specifiek mankement. Het is een systemisch probleem veroorzaakt door de combinatie van:

• Onderhouden documentatie die veroudert
• AI agents met uitvoeringspermissies die documentatie impliciet vertrouwen
• De claimbaarheid van verlaten pakketnamen in publieke registries

Wat Je Kunt Doen

De aanbevelingen van de onderzoekers zijn praktisch en uitvoerbaar:

1. Audit je llms.txt bestanden regelmatig

Als je organisatie AI-leesbare documentatie publiceert, behandel pakketreferenties dan zoals je code dependencies behandelt. Verifieer dat elk genoemd pakket, domein of commando daadwerkelijk naar een legitieme, actuele bron verwijst. Een simpele typo in documentatie kan claimbare infrastructuur worden.

2. Implementeer goedkeuringspoorten voor agent-acties

Laat AI agents geen shell commands uitvoeren of dependencies automatisch installeren. Vereis expliciete goedkeuringsstappen. De documentatie moet referentiemateriaal zijn, geen runbook.

3. Monitor package registries op lookalikes

Overweeg om alerts in te stellen voor pakketnamen die lijken op je interne dependencies. Vroege detectie geeft je een window om namen te claimen voordat iemand anders dat doet.

Het Grotere Plaatje

Dit onderzoek belicht iets belangrijks over de verschuiving naar AI-ondersteunde ontwikkeling: het vertrouwensmodel is veranderd, maar onze praktijken zijn nog niet meegekomen.

Toen developers solo werkten, was documentatie een gids. Wanneer AI agents samenwerken met developers, wordt documentatie een API. En zoals elke API, heeft het validatie, versioning en beveiligingsinspectie nodig.

Het goede nieuws? Dit is een oplosbaar probleem. In tegenstelling tot veel beveiligingskwetsbaarheden zijn de oplossingen hier straightforward — documenteer beter, vertrouw minder, verifieer meer. De uitdaging is het opbouwen van de gewoonte om AI-leesbare documentatie met dezelfde strengheid te behandelen als productiecode.

Verwacht dat er meer onderzoek als dit opduikt naarmate AI coding agents meer verweven raken in ontwikkelworkflows. De aanvallen komen niet direct voor je modellen of je data. Soms wachten ze geduldig in je documentatie, geduldig als een typo.