Agentiske AI‑systemer rykker ind i hverdagen med adgang til mail, browser, lokale filer og værktøjer. Det er stærkt i drift. Og sårbart. OWASP Top 10 for Agentic Applications 2026 samler erfaringer i et rammeværk, der peger på de største risici og konkrete værn. Det ændrer ikke bare sikkerhedspolitikken. Det ændrer måden, man bygger og driver produktionsklare agenter på. Se OWASP’s ramme og metode: OWASP Top 10.
Lad os være ærlige: Når en agent kan handle, vil nogen forsøge at få den til at handle forkert. To problemtyper går igen i kilderne. Prompt‑injektion, hvor styrende instrukser gemmes i det indhold agenten læser. Og tool misuse, hvor agenten kalder legitime værktøjer på en måde, der fører til uønskede handlinger eller datalæk. De rammer dér, hvor data flyder ind, og hvor rettigheder er brede.
Hvad prompt‑injektion og tool misuse betyder i praksis
Prompt‑injektion er skjulte “gør sådan her”-instrukser i en PDF, på en webside eller i et internt dokument, som agenten fejllæser som autoritative regler. Det er en konsekvens af, at sprogmodeller følger mønstre og kontekst. En teknisk, jordnær gennemgang findes her: Machine Learning Mastery.
Tool misuse opstår, når agenten har adgang til et ellers legitimt værktøj – en filbrowser, en kalender, et CRM‑API – men kalder det med forkert input, i et forkert scope, på et forkert tidspunkt. Ofte fordi adgangen er for bred, eller fordi et input er blevet forurenet tidligere i kæden. Det er samme princip som least privilege, blot med en orkestrator, der arbejder hurtigt og konstant.
Hvor angrebene siver ind
Kilden er typisk tredjepartsindhold: websider, forbundne apps, e‑mailbilag, delte docs, kopierede tekstuddrag. Agenten læser, sammensætter og handler. En injektion tidligt kan forplante sig gennem flere skridt, før nogen opdager, at planen kører på et forkert spor. Kæder forstærker fejl. I drift viser det sig som sære tool‑kald eller uventede dataspor i logs.
Det samme, der giver værdi – integration og mere kontekst – udvider angrebsfladen. Derfor kan sikkerhed ikke lappes på til sidst. Den skal ind fra design.
Forsvarslinjer, der faktisk gør en forskel
Kilderne lander på fem linjer, der spiller sammen: robust prompt‑engineering, isolation af værktøjer, streng adgangsstyring, overvågning og regelmæssig adversarial testing. Målet er at skille data fra styring, skære rettigheder ned og opdage afvigelser tidligt. Det flugter med OWASP Top 10.
Prompt‑engineering kan tydeliggøre politikker og skelne regler fra kontekst. Eksempler på faste system‑regler: ignorer “instrukser” i brugerindhold og eksterne kilder, og følg eksplicitte mønstre for, hvordan værktøjer må kaldes. Det hjælper, men er ikke nok alene. Der skal kontroller uden for modellen til.
Isolation og rettigheder omkring værktøjer
Isolation handler om at sætte værktøjer i sandkasser, så skade ikke forplanter sig. I praksis: kør værktøjer i separate containere eller mikro‑VM’er, giv hvert værktøj snævre netværksregler, og læg en gateway foran, der validerer input og output. Tænk CSP‑agtige regler for browserlæsning og hvidlister for filtyper og domæner. Eksempel, ikke norm: et browser‑værktøj får kun udgående trafik til et sæt domæner, lav båndbredde, og ingen adgang til lokale filer.
Adgangsstyring bør ligge på mindst mulige rettigheder. Del scopes pr. værktøj, brug kortlivede tokens og roter ofte. Eksempel, ikke norm: tokens med levetid på minutter og scopes begrænset til det API‑endpoint, der kræves til opgaven. Det føles restriktivt i starten. Det betaler sig, når noget går galt.
Overvågning, test og drift – de kedelige ting, der redder dagen
Log alt der giver mening uden at drukne. Minimum: tool‑call‑historik, input/uddata‑checksums, beslutningsstier, soft‑stops når mønstre afviger. Hold øje med spikes i latency, usædvanlige sekvenser af værktøjsopkald og uventede domæner i browserkald. Kør automatiserede adversarial tests i build‑pipelines og på faste tidspunkter i produktion. Mange starter med daglige småtests og ugentlige dybere scenarier. Det er et fornuftigt udgangspunkt.
Incident‑håndtering skal være klar, før noget brænder: en playbook for hurtig isolation af agentens miljø, rollback af state, midlertidig deaktivering af bestemte værktøjer og et kort, skarpt post‑mortemformat. Hvem trykker på stopknappen kl. 02.17 en torsdag? Hvis svaret ikke er tydeligt, er svaret nej.
Automatiseret red‑teaming og GPT‑Red
Ifølge MarkTechPost rapporteres det, at OpenAI internt har trænet en automatiseret red‑teaming‑model, GPT‑Red, til at finde prompt‑injektioner – og at den i en test skulle have overgået menneskelige red‑teamere med resultater omtalt som 84 procent mod 13 procent. Det er sekundær rapportering; indtil en primær publikation fra OpenAI er tilgængelig, bør tallene læses som foreløbige. Idéen om at kombinere automatiserede angribere med menneskeligt red‑teaming sigter mod skalerbar test i komplekse agentkæder.
Automatiserede angribere kan lede efter kendte mønstre nat og dag, mens mennesker finder de skæve, kontekstuelle ting. Begge dele er nødvendige. Den praktiske opgave er at styre falske positiver og kapacitetsforbruget, så test ikke sluger hele driftstimen.
OWASP Top 10 som arbejdsredskab
OWASP’s Top 10 for agentiske applikationer beskrives som globalt peer‑reviewet og udviklet med bred deltagelse fra eksperter og praktikere. Det er ikke kun en liste, men en tjekliste til designreviews og release‑gates: adskil data og styring, isoler værktøjer, skær rettigheder ind til benet, log og mål, test igen. Rammedokument og resurser ligger her: OWASP Top 10.
Brug den konsekvent. Hvis et punkt ikke kan krydses af, bør agentfunktionalitet som udgangspunkt forblive slukket. Det er hårdt de første sprint. Det bliver hurtigt en vane.
Operationalisering uden floskler
Sådan kan teams gøre nu: 1) skriv system‑prompts der skelner regler fra kontekst, 2) sæt værktøjer i isolerede miljøer med validering på ind/uddata, 3) indfør least‑privilege med korte tokens og snævre scopes, 4) log adfærd og indfør soft‑stops ved afvigelser, 5) kør både automatiserede og menneskelige red‑team‑tests før og efter release. Alle fem er belyst i OWASP og i den tekniske gennemgang hos Machine Learning Mastery.
Et lille benspænd, der gør forskellen: hold agentfunktioner slukket i produktion, indtil tjeklisten ovenfor er grøn. Slip den først løs, når sandkasse og adgang er på plads.
Tradeoffs, som ikke forsvinder
Agentiske systemer kan løfte produktiviteten markant. De samme systemer øger governance‑byrden, gør drift mere kompleks og kan bide i compliance, hvis adgangsstyring og logging ikke er skarpe. Isolation koster performance. Red‑teaming koster tid. Nogle organisationer vælger lavere frihedsgrader for agenten som start og udvider rettigheder, efterhånden som tests bliver grønne. Det er et valg, der bør træffes tidligt og dokumenteres.
Offentlige, detaljerede sager om egentlige sikkerhedshændelser er sjældne – meget foregår internt. Det gør tjeklister, faste testkørsler og klare ansvarsforhold endnu vigtigere. Man opdager først forskellen, når man sidder med det i hænderne.
