De vanskeligste AI‑sikkerhetsproblemene er nå utenfor modellen

Den 2026 OWASP Top 10 for LLM‑applikasjoner gir et kritisk perspektiv på modenheten til produksjons‑AI. Den fanger et avgjørende skifte: bransjen beveger seg forbi sandkassen og takler kompleksiteten i virkelige integrasjoner.

Når du kobler en LLM til bedriftsverktøy og arbeidsflyter, endres trusseloverflaten fundamentalt. Risikoer knyttet til autoritet og ressursbruk blir betydelig vanskeligere å inneholde. Samtidig trer sårbarheter som feil håndtering av utdata tilbake fra frontlinjen, ikke fordi de er løst, men fordi andre problemer har tatt over.

OWASP Top 10‑rangeringen gjenspeiler denne utviklingen. «Excessive Agency» har steget fra sjette til tredje plass, mens «Unbounded Consumption» har klatret til sjette. Omvendt har «Improper Output Handling» falt til tiende.

Dette reduserer ikke risikoen ved håndtering av utdata. Hvis et LLM‑svar når et skall eller en database uten grundig validering, vedvarer tradisjonelle injeksjonsfeil. Paradigmet har imidlertid endret seg. I et agentbasert system er modellens svar ikke målet; det er en inngang som bærer autoritet. Når en modell innehar legitimasjon eller samhandler med et API, fungerer dens utdata som en vektor som kan utløse handlinger på tvers av ulike systemer.

Sikkerhetsutfordringen er ikke lenger bare å evaluere modellen; den handler om å definere grensene for hva som skjer etter inferens. Arkitekturen din bestemmer om en hallusinasjon forblir i tekst eller manifesterer seg som en uautorisert database‑mutasjon.

Rangeringen følger skadene

OWASP utnyttet 7,714 hendelser, 75 % drevet av fellesskapskonsensus, og 25 % av empiriske hendelsesdata. Dette evidensgrunnlaget tvang en reell omprioritering.

«Excessive Agency» steg fordi realiteten i produksjonsmiljøer innhentet teorien. Organisasjoner akselererer utrullingen av autonome funksjoner raskere enn de etablerer nødvendige kontrollplaner. Den kritiske sårbarheten er ikke bare svaret modellen gir, men autorisasjonskonteksten som svaret kjøres i.

Selv om «Improper Output Handling» fortsatt er en bekymring, har DevOps‑teamene modnet i sin evne til å sikre nedstrøms mottakere gjennom skjema‑validering og parameteriserte spørringer. Dette er etablerte praksiser innen applikasjonssikkerhet.

Agentur er imidlertid en annen type problem. Et verktøykall kan være strukturelt gyldig, men kontekstuelt illegitimt. Modellen kan påkalle en godkjent funksjon for en upassende oppgave eller rette seg mot feil ressurs. Statisk sanitering kan ikke vurdere intensjon. Dette krever sofistikert, kontekstbevisst autorisasjon som modellen aldri bør utføre alene.

Behandle hvert verktøy som en eksponert funksjon

Mange team behandler verktøyd definisjoner som kun integrasjonsrørledninger. Dette er en ganske latterlig og grunnleggende feil. Hvert verktøy, hver kobling eller API‑endepunkt utvider AI‑applikasjonens påvirkningsområde.

Tenk på en agent designet for å oppsummere en postboks. Hvis implementeringen bruker en bred kobling som inkluderer skrive‑ eller slettefunksjoner, har du introdusert overdreven funksjonalitet før den første prompten i det hele tatt blir behandlet.

Du må håndheve prinsippet om minst mulig privilegium:

• Begrens grensesnittet: Gi agenten kun leseverktøy i stedet for generelle koblinger.
• Avgrenset kontekst: Utfør forespørsler innenfor brukerens OAuth‑avgrensede identitet.
• Policy Enforcement Points (PEP): Implementer autorisasjonslogikk som obligatorisk mellomlag mellom modellen og nedstrøms systemer. Hver handling må valideres mot policy før utførelse.
• Human-in-the-loop (HITL): Krev eksplisitt godkjenning for operasjoner som er vanskelige å reversere eller har høy materiell påvirkning.

Denne tilnærmingen krever et skifte i leverings‑pipeline. Gjennomgangsprosessen din må utvides utover modellen for å omfatte endringer i verktøyskjemas, tjenesteidentiteter og tillatelsesområder. En modelloppdatering kan virke ufarlig, men en endring i en koblings autorisasjonskontekst kan skape en katastrofal sårbarhet.

Synlighet er ufravikelig. Du må logge den spesifikke verktøyutførelsen, den autoriserende identiteten og den påfølgende endringen i målsystemet. Denne kjeden av ansvar er essensiell for hendelsesrespons, slik at du kan avbryte en aktiv prosess og rekonstruere revisjonssporen etter hendelsen.

Hver autonom kjøring krever en hard stopp

«Unbounded Consumption» har økt kraftig fordi forespørselsvolum er et utilstrekkelig mål for ressursrisiko. En enkelt, konsis prompt kan utløse en rekursiv, ressurskrevende kjede av verktøykall. Måleren stopper ikke før agenten er ferdig.

Enkel varsling er utilstrekkelig når utførelseshastigheten overgår menneskelig respons. Du trenger deterministiske, harde grenser som ligger utenfor agentens kontroll. Implementer strenge tak for token‑bruk, forløpt tid, rekursjonsdybde og samlet driftskostnad. Hvis en kjøring overskrider disse parametrene, må systemet terminere eller throttles kjøringen.

Operasjonelt omfang krever liknende strenghet. Bestem det maksimale antallet poster en agent kan endre, og definer grensene for oppgaveutbredelse. Hvis arkitekturen din mangler en deterministisk “stop”-mekanisme, har du i praksis delegert myndighet uten å definere dens omkrets.

Bygg for feil svar

Systemteknikk har lenge vært avhengig av robust arkitektur for å sikre iboende upålitelige komponenter. Vi forutsetter komponentfeil og nettverksinstabilitet; sikkerheten kommer fra denne antakelsen, ikke fra en illusjon om perfeksjon. LLM-er krever samme arkitektoniske disiplin.

Ikke baser sikkerhetsstrategien på antakelsen om perfekt modelljustering. Forutsett feil, enten det skyldes godartet misforståelse eller ondsinnet utnyttelse. Begrens agentens evner til det absolutte minimum som kreves, og oppretthold strenge brukerautorisasjonskontekster for alle nedstrøms‑kall. Avgjørende er at policy‑håndheving må finnes utenfor modellen for å hindre at prompt‑injeksjon eller resonneringsfeil omgår kontrollene dine.

Vi ser nå på Prompt Injection mindre som en sårbarhet og mer som en fysikklov. Den vil alltid ligge i bakgrunnen. Faktum er at modellene selv ikke kan være effektive beslutningstakere i sikkerhetskritiske spørsmål. I et reelt agentprosjekt jeg bygger, har vi omtrent 100 automatiserte “red team”‑tester. Vi sørger for at vi består dem alle. Men vi gjør dette ved å bygge harde kontroller utenfor modellen. Vi kan slå dette av og se bestå/feile‑ratene for kun modellen. Den eldste, svakeste modellen vi tester, feiler 17 % av gangene. Den nyeste, største modellen feiler 2 % av gangene. Stor fremgang, ikke sant? Men er 98 % godt nok når hver feil betyr lekkasje av sensitiv data? Ikke engang i nærheten.

Operasjoner med høy påvirkning må være observerbare, reviderbare og helst reverserbare. Hver autonom kjøring krever uforanderlige rettesnorer som forblir utenfor modellens rekkevidde.

Rangeringene for 2026 kaster virkelig lys over hvor AI‑feil går over i materielle konsekvenser. Modellen kan starte feilen, men arkitekturen definerer eksplosjonsradiusen. For produksjons‑AI er det mest kritiske sikkerhetsarbeidet i post‑inference‑pipelinen.