Den stille trussel, du sikkert har overset

Du kender sikkert til prompt injection, model poisoning og angreb på træningsdata. Men der er én trussel, der ikke har fået nok opmærksomhed: dokumentation som angrebsflade.

Et forskerhold har for nylig afdækket noget alarmerende. De undersøgte llms.txt og llms-full.txt filer – maskinlæsbare dokumentationsformater designet til at hjælpe AI-systemer med at forstå hjemmesider. Resultaterne var bekymrende. På tværs af tusindvis af domæner fra forsvarsentreprenører, Fortune 500-virksomheder og tech-giganter fandt de 120 filer, der pegede på pakkenavne eller domæner, som ikke længere eksisterer.

Den elegante del ved dette angreb? Angriberen behøver ikke at hacke noget som helst. De skal bare vente.

Sådan fungerer angrebet i praksis

Forestil dig følgende: En udvikler bruger en AI-kodningsassistent til at sætte et projekt op. Assistenten læser virksomhedens llms.txt fil for at finde installationsinstruktioner, ser en reference til en afhængighed ved navn cool-utils-lib, og – fordi assistenten har tilladelse til at køre pakkehåndteringskommandoer – installerer den.

Problemet? Det pakkenavn var aldrig registreret. Indtil angriberen registrerede det.

I deres kontrollerede eksperiment gjorde forskerne præcis dette. De optog nogle af disse forladte navne, uploadede harmløse "phone home" pakker (designet kun til at logge, hvornår de blev tilgået), og ventede. Resultaterne var slående: mindre end en time efter udgivelse havde en Fortune 500-virksomhed allerede installeret en af deres pakker. I de følgende dage kontaktede "et par snese flere" organisationer dem.

Dette var ikke et virkeligt angreb – pakkerne var uskadelige, og ingen produktionssystemer blev kompromitteret. Men rækkevidden blev bevist. Angrebsfladen er reel.

Hvorfor AI-agenter gør det værre

Det, der gør dette særligt farligt, er: traditionel sikkerhed forudsætter, at brugere træffer beslutninger. Hvis du giver nogen et dokument med dårlige instruktioner, følger de måske bare. Men mennesker fanger ofte åbenlyse fejl, stiller opklarende spørgsmål eller bemærker, når noget virker forkert.

AI-agenter opererer anderledes. De behandler dokumentation som udførbar sandhed. Hvis din llms.txt siger "kør npm install legacy-widget", så gør assistenten det ofte bare – uden at stille spørgsmål ved, om pakken stadig eksisterer, hvem der ejer den, eller om det er den rigtige.

Forskerne testede flere agenter – Claude, OpenAI Codex og Nous Research's Hermes – og alle fulgte de problematiske referencer. Dette er ikke en vendor-specifik fejl. Det er et systemisk problem skabt af kombinationen af:

• Vedligeholdt dokumentation der bliver forældet
• AI-agenter konfigureret med eksekveringstilladelser der stoler blindt på dokumentation
• Kravbarheden af forladte pakkenavne i offentlige registre

Hvad du kan gøre

Forskernes anbefalinger er praktiske og handlingsorienterede:

1. Auditer dine llms.txt filer regelmæssigt

Hvis din organisation udgiver AI-læsbar dokumentation, så behandl pakke-referencer, som du behandler kode-afhængigheder. Verificer at hver nævnte pakke, domæne eller kommando faktisk peger på en legitim, aktuel ressource. En simpel stavefejl i dokumentation kan blive til claimbar infrastruktur.

2. Implementer godkendelses-gates for agent-handlinger

Lad ikke AI-agenter eksekvere shell-kommandoer eller installere afhængigheder automatisk. Kræv eksplicitte godkendelsestrin. Dokumentationen skal være reference-materiale, ikke en køreplan.

3. Overvåg pakke-registre for lookalikes

Overvej at opsætte alerts for pakkenavne, der ligner dine interne afhængigheder. Tidlig opdagelse giver dig et vindue til at optage navne, før nogen andre gør det.

Det store billede

Denne forskning belyser noget vigtigt ved skiftet til AI-assisteret udvikling: tillidsmodellen er ændret, men vores praksisser er ikke fulgt med.

Da udviklere arbejdede alene, var dokumentation en guide. Nu hvor AI-agenter arbejder sammen med udviklere, bliver dokumentation en API. Og ligesom enhver API kræver den validering, versionsstyring og sikkerhedsmæssig granskning.

Den gode nyhed? Dette er et løseligt problem. I modsætning til mange sikkerhedssårbarheder er rettelserne her ligetil – dokumentér bedre, stol mindre, verificér mere. Udfordringen er at opbygge vanen med at behandle AI-læsbar dokumentation med samme stringens som produktionskode.

Efterhånden som AI-kodningsagenter bliver mere integreret i udviklingsworkflows, må du forvente mere forskning som denne at dukke op. Angrebene kommer ikke direkte efter dine modeller eller din data. Nogle gange venter de tålmodigt i din dokumentation, tålmodige som en stavefejl.