När dokumentationen blir din värsta fiende: den dolda säkerhetsrisken i AI-läsbara filer
Den tysta faran som gömmer sig i dokumentationen
De flesta har koll på prompt injection, model poisoning och attacker mot träningsdata. Men här är ett hot som inte fått tillräcklig uppmärksamhet: dokumentationsförfall som attackyta.
En forskargrupp nyligen avslöjade något oroande. De granskade llms.txt och llms-full.txt – maskinläsbara dokumentationsformat designade för att hjälpa AI-system förstå webbplatser. Det de hittade var dramatiskt. Bland tusentals domäner från försvarskontakter, Fortune 500-företag och techjättar hittade de 120 filer som pekade på paketnamn eller domäner som inte längre existerar.
Attacken är elegant i sin enkelhet. En angripare behöver inte hacka något system. De behöver bara vänta.
Så fungerar attacken i praktiken
Tänk dig det här scenariot: En utvecklare använder en AI-kodningsassistent för att sätta upp ett projekt. Assistenten läser företagets llms.txt-fil för installationsinstruktioner, hittar en referens till ett beroende som heter cool-utils-lib, och—eftersom assistenten har tillåtelse att köra pakethanteringskommandon—installerar det.
Problemet? Det paketnamnet var aldrig registrerat. Inte förrän angriparen registrerade det.
I sitt kontrollerade experiment gjorde forskarna exakt detta. De lade beslag på några av dessa övergivna namn, laddade upp ofarliga "phone home"-paket (designade bara för att logga när de accessades), och väntade. Resultatet var slående: mindre än en timme efter publicering hade ett Fortune 500-företag redan installerat ett av deras paket. Under de följande dagarna kontaktade "ett par dussin" organisationer till.
Det här var ingen verklig attack—paketen var ofarliga och inga produktionssystem komprometterades. Men räckvidden bevisades. Attackytan är verklig.
Varför AI-agenter gör detta värre
Det som gör detta särskilt farligt: traditionell säkerhet förutsätter att användare fattar beslut. Om du ger någon ett dokument med dåliga instruktioner kan de följa det. Men människor fångar ofta uppenbara fel, ställer klargörande frågor, eller märker när något känns fel.
AI-agenter fungerar annorlunda. De behandlar dokumentation som exekverbar sanning. Om din llms.txt säger "kör npm install legacy-widget", gör agenten ofta bara det—utan att ifrågasätta om det paketet fortfarande finns, vem som äger det, eller om det är rätt paket.
Forskarna testade flera agenter—Claude, OpenAI Codex och Nous Researchs Hermes—och alla följde de problematiska referenserna. Det här är inget leverantörsspecifikt fel. Det är en systemisk issue skapad av kombinationen:
- Dokumentation som inte underhålls och blir inaktuell
- AI-agenter konfigurerade med körbehörigheter som litar blint på dokumentation
- Kravbarheten av övergivna paketnamn i publika register
Vad du kan göra åt det
Forskarnas rekommendationer är praktiska och handlingsbara:
1. Granska dina llms.txt-filer regelbundet
Om din organisation publicerar AI-läsbar dokumentation, behandla paketreferenser som du behandlar kodberoenden. Verifiera att varje nämt paket, domän eller kommando faktiskt pekar till en legitim, aktuell resurs. Ett enkelt stavfel i dokumentation kan bli kravbar infrastruktur.
2. Implementera godkännandeporter för agentåtgärder
Låt inte AI-agenter köra shell-kommandon eller installera beroenden automatiskt. Kräv explicita godkännandesteg. Dokumentationen ska vara referensmaterial, inte en körinstruktion.
3. Övervaka paketregister efter nästan-kopior
Överväg att sätta upp varningar för paketnamn som liknar dina interna beroenden. Tidig upptäckt ger dig ett fönster att ta hand om namn innan någon annan gör det.
Den större bilden
Den här forskningen belyser något viktigt om skiftet mot AI-assisterad utveckling: tillitsmodellen har förändrats, men våra metoder har inte hunnit med.
När utvecklare jobbade själva var dokumentation en guide. När AI-agenter jobbar tillsammans med utvecklare blir dokumentation ett API. Och som vilket API som helst behöver det validering, versionshantering och säkerhetsgranskning.
De goda nyheterna? Det här är ett lösbart problem. Till skillnad från många säkerhetsproblem är fixarna här enkla—dokumentera bättre, lita mindre, verifiera mer. Utmaningen är att bygga vanan att behandla AI-läsbar dokumentation med samma noggrannhet som vi applicerar på produktionskod.
När AI-kodningsagenter blir mer integrerade i utvecklingsarbetsflöden, förvänta dig mer forskning som denna. Attackerna kommer inte direkt efter dina modeller eller din data. Ibland väntar de tålmodigt i din dokumentation, tålmodig som ett stavfel.