OWASP setter modenhetsskala på AI-agenter

OWASP vil gjøre sikkerhet rundt AI-agenter mindre abstrakt. Den nye modellen deler agentbruk inn etter hvor langt virksomheten har gått, fra uregulert skyggebruk til egne agenter med kodekjøring, verktøy og interne rettigheter. Deretter må ledelsen måle om styringen faktisk matcher risikoen.

Det er en nyttig justering. Mange selskaper har fortsatt AI-policyer som er skrevet for chatboter og copiloter. De passer dårlig når ansatte og utviklingsteam tar i bruk agenter som kan hente data, kalle API-er, lage kode, endre arbeidsflyt og gjøre handlinger i systemer med virksomhetens legitimasjon.

Infosecurity Magazine rapporterte 5. juni fra OWASP GenAI Security Summit i London, der OWASP GenAI Security Project presenterte rammeverket som en del av rapporten «State of Agentic AI Security and Governance». Hovedpoenget er enkelt: ikke la agentnivået løpe fra kontrollnivået.

Fra skygge-AI til egne agenter

OWASP-modellen beskriver seks nivåer for agentisk AI-bruk. Nederst ligger skygge-AI, der ansatte tar i bruk verktøy uten godkjenning eller oversikt. Deretter kommer leverandørstyrte assistenter, AI-native plattformer som bruker virksomhetens data, lavkode-agenter satt opp av ansatte, kodekjørende agenter og til slutt egne in-house agenter der virksomheten selv kontrollerer identitet, verktøy og grenser.

Dette treffer CIO- og CISO-bordet ganske presist. Risikoen endrer karakter når AI-systemet går fra å skrive forslag til å utføre handlinger. En chatbot som gir et dårlig svar kan skape feil beslutninger. En agent med tilgang til e-post, CRM, GitHub, økonomisystemer eller skyressurser kan skape feil tilstand i produksjon. Den kan også bli et nytt innsidepunkt for angripere.

OWASP kobler derfor agentnivået til fire modenhetsnivåer for styring. Nivå null er ad hoc: ingen formell forståelse av agentrisiko, lite logging, ingen AI-SBOM og generisk hendelseshåndtering. Nivå én er eksperimentering uten tydelige guardrails. Nivå to betyr definerte policyer, ansvarlig eier, logging, versjonering, AI-SBOM og menneske i loopen for høy risiko. Nivå tre er kontinuerlig styring: sanntidsmonitorering, risikobaserte arbeidsflyter, kill switches og policy-as-code.

Det er særlig nivå tre som viser hvor annerledes agentstyring blir. Tradisjonell governance kan ofte leve med periodiske vurderinger. Agentiske systemer opererer raskere. Da holder det ikke å ha en policy i et dokument. Virksomheten trenger teknisk håndheving, synlighet og mulighet til å stoppe autonomi mens hendelsen fortsatt pågår.

Røde celler er ledelsesrisiko

Ariel Fogel, en av rapportens medforfattere, sa ifølge Infosecurity at de fleste organisasjoner nå ruller ut agenter raskere enn de klarer å styre dem. Det er kjernen i saken. Problemet er ikke at AI-agenter finnes. Problemet er mismatch: høy autonomi, svake kontroller.

OWASP viser dette som en matrise. Grønt betyr at styringen passer til agentnivået. Gult betyr at sikkerhet og governance ikke har full oversikt. Rødt betyr at virksomheten har satt ut agenter på et nivå der kontrollene ikke henger med. Rådet fra Fogel var kort: ikke operer i de røde cellene.

For norske virksomheter er dette praktisk. En CISO kan bruke modellen i leverandørgjennomgang: hvilken agentklasse er dette, hvilke handlinger kan den gjøre, hvilke data ser den, og finnes det logging som faktisk kan ettergås? En CIO kan bruke den i porteføljestyring: hvilke pilotprosjekter kan gå videre, og hvilke må begrenses før de får produksjonstilgang? DPO og jus kan bruke den til å skille mellom vanlig AI-bruk og systemer som gjør beslutningsnære handlinger med persondata.

Det gir også en bedre samtale med styret. «Vi bruker AI» er ikke lenger en god nok status. Spørsmålet er hvilke agentiske arbeidsflyter som finnes, hvor de er i modenhetsmatrisen, og hvilke røde celler som må lukkes først.

Kontroller må flyttes nærmere runtime

OWASP peker på flere tekniske kontroller som bør opp på prioriteringslisten. Agenthandlinger må kunne knyttes til identitet, verktøy og formål. Rettigheter bør være kortlivede og avgrensede, ikke brede tokens som lever lenge i miljøet. Handlinger må logges med nok kontekst til at hendelser kan etterforskes. Og virksomheten må ha mekanismer for å pause eller redusere autonomi når atferden avviker.

Dette er ikke bare sikkerhetsarkitektur. Det påvirker innkjøp, utvikling og drift. Leverandører som tilbyr agentfunksjoner bør kunne svare på hvordan de håndterer identitet, logging, rettighetsgrenser, datatilgang, eskalering og hendelsesrespons. Interne utviklingsteam bør ikke få flytte fra pilot til produksjon uten en tydelig vurdering av agentens handlingsrom.

En nyttig konsekvens av modellen er at den ikke sier at alt må stoppes. OWASP peker på to valg når styringen ikke er god nok: bygg bedre kontroller, eller reduser agentens rettigheter og autonomi til dagens kontroller er tilstrekkelige. Det er mer gjennomførbart enn et generelt forbud.

For ledergruppen betyr det at AI-agentprogrammet må få samme type disiplin som sky, identitet og tredjepartsrisiko. Start med inventar. Finn ut hvilke agenter som faktisk er i bruk. Skill mellom skrivehjelp, plattformassistenter, lavkode-agenter og kodekjørende agenter. Koble hver kategori til krav for logging, datatilgang, menneskelig godkjenning og stoppmekanismer.

Den norske vinkelen er enkel: EU AI Act, GDPR og ordinær sikkerhetsstyring belønner ikke entusiasme alene. De belønner dokumenterbar kontroll. OWASPs modell gir et språk for å vise hvor kontrollen mangler før agentene får rettigheter de ikke burde hatt.

Kilder og medier

Primær nyhetskilde: Infosecurity Magazine, «Infosecurity Europe: OWASP Introduces Agentic AI Security Maturity Framework», publisert 5. juni 2026. https://www.infosecurity-magazine.com/news/owasp-agentic-ai-security-maturity/

Primærmateriale: OWASP GenAI Security Project, «State of Agentic AI Security and Governance 2.01». https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance/

Thumbnail: OpenAI Image 2 / hogby.ai