En AI-agent, der læser en mail, et dokument eller en webside, kan
En AI-agent, der læser en mail, et dokument eller en webside, kan blive manipuleret til at handle mod sin egen instruks, uden at nogen mennesker rører ved systemet. Det er prompt injection i sin reneste form, og det er ikke længere et teoretisk problem. CrowdStrike har dokumenteret angreb mod over 90 organisationer i 2025, og mønstret peger samme vej hver gang: jo mere autonomi en virksomhed giver sine AI-agenter, jo bredere bliver angrebsfladen.
Hvorfor prompt injection rammer hårdere end klassiske sårbarheder
De fleste it-sikkerhedsmodeller er bygget til at adskille kode fra data. En SQL-injektion virker, fordi et system fejlagtigt behandler brugerinput som kode. Prompt injection udnytter noget lignende, men i en model, der grundlæggende ikke kan skelne mellem en instruks fra ejeren af systemet og en instruks skjult i det indhold, den bliver bedt om at behandle. Når en AI-agent har adgang til mail, kalendere, interne dokumenter eller eksterne API'er, bliver hvert eneste stykke tekst, agenten læser, en potentiel kommandolinje.
Vi har set virksomheder investere massivt i adgangsstyring og logning, men stadig lade AI-agenten fortolke ustruktureret tekst uden nogen form for skel mellem system og indhold. Det er den flaskehals, angriberne har fundet.
To hændelser der viser, hvor konkret truslen er
En sårbarhed i Slacks AI-integration i 2025 gjorde det muligt at plante skjulte instrukser i beskeder, som Slacks assistentfunktion senere læste og udførte, uden at brugeren så noget mistænkeligt i selve chatten. Angrebet krævede ingen adgang til brugerens konto, kun evnen til at få en tekststreng ind i en kanal, assistenten scannede.
Endnu mere alvorligt var EchoLeak, en sårbarhed i Microsoft 365 Copilot, hvor et ondsindet dokument kunne få assistenten til selv at lække følsomme data ud af organisationen, uden at nogen bruger klikkede på noget som helst. Microsoft lukkede hullet, men sagen illustrerede noget vigtigere end selve fejlen: RAG-pipelines, der henter kontekst fra interne dokumenter, er lige så sårbare som selve modellen, fordi de fodrer modellen med indhold, ingen har valideret.
Et beslægtet eksempel er brud hos Hugging Face, der på samme vis viser hvor sårbare AI-systemer kan være over for udnyttelse i produktion.
Seks angrebstyper enhver virksomhed med AI i drift bør kende
Angrebsmønstrene mod agenter, RAG-systemer og model-routere har efterhånden en genkendelig taksonomi. Et eksempel på struktureret forsvar er Visas styrede sårbarhedsjagt, som tester agenter systematisk mod netop disse angrebstyper.
Sådan rammer det agenter og automatiseringsworkflows i den virkelige verden
Det konkrete skadepotentiale afhænger af, hvad agenten har adgang til. En kundeserviceagent med adgang til CRM-data kan lokkes til at afsløre andre kunders oplysninger. En agent, der automatisk behandler indgående mails og opretter opgaver, kan blive narret til at eksekvere ondsindede kommandoer, hvis en mail indeholder skjulte instrukser formuleret som almindelig tekst. En AI-agent, der bruger en model-router til at vælge den billigste model til rutineopgaver, kan blive tvunget over på en model med svagere sikkerhedsfiltre, uden at nogen i organisationen bemærker det.
Det fælles træk er, at skaden sjældent viser sig som et klassisk hackerangreb. Der er ingen advarselslampe, der blinker. Systemet gør bare det, det bliver bedt om, det er blot ikke virksomheden, der har bedt om det. Løsninger som adgangsstyring for AI-agenter kan begrænse, hvor meget skade en vellykket injektion reelt kan gøre.
De fleste sikkerhedshuller opstår ikke, fordi modellen er svag, men fordi ingen har kortlagt, hvilke systemer agenten reelt kan nå, og hvilket ustruktureret indhold den bliver fodret med undervejs.
Seks konkrete tiltag til virksomheder med AI i produktion
Der findes ingen enkeltstående løsning, men der er et sæt tiltag, der reelt reducerer angrebsfladen:
Før det første bør enhver agent have et princip om mindste privilegium, adgang til præcis de systemer og data, opgaven kræver, og intet mere. Det begrænser skaden, selv når en injektion lykkes.
For det andet bør indhold, agenten henter fra eksterne eller ustrukturerede kilder, mail, dokumenter, websider, altid behandles som utroværdigt input, adskilt fra systeminstruksen, med en klar teknisk grænse mellem de to.
For det tredje bør RAG-pipelines have et valideringslag, der screener nyt indhold, før det bliver en del af vidensbasen, særligt hvis dokumenter kan uploades af eksterne parter eller hentes automatisk fra nettet.
For det fjerde bør model-routere logge og alarmere, når en forespørgsel bliver rutet til en model med lavere sikkerhedsniveau end forventet, så et forsøg på at omgå guardrails bliver synligt med det samme.
For det femte bør handlinger med reelt skadepotentiale, dataeksport, betalinger, sletning, altid kræve et menneskeligt godkendelsestrin, uanset hvor meget agenten ellers har fået lov til at automatisere.
Og for det sjette bør organisationer teste deres egne agenter med de samme angrebstyper, som beskrevet ovenfor, før de går i produktion, ikke bare når noget går galt.
Næste skridt
De virksomheder, der allerede har testet deres agentiske opsætning mod disse seks kategorier, opdager typisk problemerne, for de bliver dyre.