Den stille faren som gjemmer seg i dokumentasjonen din

De fleste har hørt om prompt injection og angrep på treningsdata. Men her er en trussel som får altfor lite oppmerksomhet: foreldet dokumentasjon som angrepsflate.

Forskere undersøkte nylig llms.txt og llms-full.txt – filformater designet for å hjelpe AI-systemer med å forstå nettsider. Funnet var alarmerende. På tvers av tusenvis av domener fra forsvarsleverandører, Fortune 500-selskaper og tech-giganter, fant de 120 filer som pekte til pakkenavn eller domener som ikke lenger eksisterer.

Det smarte med dette angrepet er enkelheten. En angriper trenger ikke hacke noe. De trenger bare å vente.

Slik fungerer angrepet i praksis

Tenk deg dette: En utvikler bruker en AI-kodingsagent for å sette opp et prosjekt. Agenten leser selskapets llms.txt-fil for installasjonsinstruksjoner, finner en referanse til en avhengighet som heter cool-utils-lib, og—fordi agenten har tillatelse til å kjøre pakkebehandler-kommandoer—installerer den.

Problemet? Det pakkenavnet var aldri registrert. Før angriperen registrerte det.

I sitt kontrollerte eksperiment gjorde forskerne akkurat dette. De sikret seg noen av disse forlatte navnene, lastet opp uskyldige "phone home"-pakker (designet kun for å logge når de ble tilgjengeliggjort), og ventet. Resultatene var slående: mindre enn én time etter publisering hadde et Fortune 500-selskap allerede installert én av pakkene deres. I dagene som fulgte, kontaktet "noen titalls" organisasjoner mer.

Dette var ikke et ekte angrep—pakkene var harmløse, og ingen produksjonssystemer ble kompromittert. Men rekkevidden var bevist. Angrepsoverflaten er reel.

Hvorfor AI-agenter gjør dette verre

Det som gjør dette spesielt farlig: tradisjonell sikkerhet forutsetter at brukere tar beslutninger. Hvis du gir noen et dokument med dårlige instruksjoner, kan de følge dem. Men mennesker fanger ofte opp åpenbare feil, stiller spørsmål, eller merker når noe virker rart.

AI-agenter opererer annerledes. De behandler dokumentasjon som utførbar sannhet. Hvis din llms.txt sier "kjør npm install legacy-widget", gjør agenten det ofte—uten å tvile på om pakken fremdeles eksisterer, hvem som eier den, eller om det er den riktige.

Forskerne testet flere agenter—Claude, OpenAI Codex og Nous Researchs Hermes—og alle fulgte de problematiske referansene. Dette er ikke en leverandørspesifikk feil. Det er et systemisk problem skapt av kombinasjonen av:

• Vedlikeholdsfri dokumentasjon som blir utdatert
• AI-agenter konfigurert med kjøretillatelser som stoler blindt på dokumentasjon
• Kravbarheten av forlatte pakkenavn i offentlige registre

Hva du kan gjøre med det

Forskernes anbefalinger er praktiske og Handlingsrettede:

1. Revider llms.txt-filene dine regelmessig

Hvis organisasjonen din publiserer AI-lesbar dokumentasjon, behandle pakkereferanser som du behandler kodeavhengigheter. Verifiser at hver nevnte pakke, domene eller kommando faktisk peker til en legitim, aktiv ressurs. En enkel skrivefeil i dokumentasjonen kan bli kravbar infrastruktur.

2. Implementer godkjenningspunkt for agenthandlinger

La ikke AI-agenter kjøre shell-kommandoer eller installere avhengigheter automatisk. Krev eksplisitte godkjenningssteg. Dokumentasjonen skal være referansemateriale, ikke en kjørebok.

3. Overvåk pakkregistre for navneliknere

Vurder å sette opp varsler for pakkenavn som ligner på dine interne avhengigheter. Tidlig oppdagelse gir deg et vindu til å sikre navn før noen andre gjør det.

Det store bildet

Denne forskningen belyser noe viktig om skiftet til AI-assistert utvikling: Tillitsmodellen har endret seg, men praksisene våre har ikke tatt igjen ennå.

Da utviklere jobbet alene, var dokumentasjon en veileder. Når AI-agenter jobber sammen med utviklere, blir dokumentasjon en API. Og som enhver API, trenger den validering, versjonskontroll og sikkerhetsgjennomgang.

Den gode nyheten? Dette er et løsbart problem. I motsetning til mange sikkerhetssårbarheter er fiksene her enkle—dokumenter bedre, stol mindre, verifiser mer. Utfordringen er å bygge vanen med å behandle AI-lesbar dokumentasjon med samme rigor som vi bruker på produksjonskode.

Etter hvert som AI-kodingsagenter blir mer integrert i utviklingsarbeidsflyter, forvent å se mer forskning som dette dukke opp. Angrepene kommer ikke direkte for modellene eller dataene dine. Noen ganger venter de tålmodig i dokumentasjonen din—like tålmodige som en skrivefeil.