AI-agenter utførte 76 av 95 angrepskommandoer i test

Nøkkelpunkter per 2. oktober 2026:

• 76 av 95 angrepskommandoer ble utført vellykket mot en ubeskyttet agent i et kontrollert forsøk (arXiv, 2024).
• Andelen som vurderer sikkerheten i AI-verktøy steg fra 37 prosent i 2025 til 64 prosent i 2026 (World Economic Forum, 2026).
• Bare 40 prosent gjennomfører periodiske gjennomganger av AI-verktøy før utrulling, selv om 87 prosent kaller AI-sårbarheter raskest voksende risiko (WEF, 2026).
• AI-drevne angrep har økt 56 prosent, og modellinversjonsangrep koster i snitt 6 millioner dollar (ibm.com).
• EUs AI-forordning 2024/1689 treffer agenter gjennom konkrete handlinger, og høyrisikosystemer med uidentifiserbar atferdsdrift kan ikke oppfylle kravene (arXiv, 2026).

---

Hva en AI-agent er, og hvorfor sikkerhetsbildet skifter

En chatbot svarer. En AI-agent gjør noe. Forskjellen ser liten ut i en demo og stor ut i en hendelsesrapport. Når et språkmodellbasert system får lov til å kalle verktøy, lese fra en database og skrive tilbake til et CRM, flytter risikoen seg fra feil svar til feil handling i et produksjonssystem. Det er den flyttingen denne artikkelen handler om.

Sikkerhetsmiljøet har begynt å behandle dette som en egen kategori. 94 prosent av respondentene i en global lederundersøkelse mener AI blir den viktigste driveren for endring i cybersikkerhet det kommende året (World Economic Forum, 2026). Det er ikke et utsagn om modellkvalitet. Det er et utsagn om at angrepsflaten endrer form.

Definisjonen som betyr noe juridisk

AI-agenter er systemer som autonomt planlegger, kaller eksterne verktøy og utfører flertrinns handlingskjeder med redusert menneskelig involvering (arXiv, 2026). Den samme kjernen går igjen i teknisk litteratur: agenter planlegger, tar beslutninger og kaller verktøy på egen hånd (ibm.com). Merk hva som ikke står der. Ingenting om modellstørrelse, leverandør eller grensesnitt.

Dette er viktig fordi definisjonen avgjør hvilke krav som treffer deg. Et chatvindu som oppsummerer dokumenter er en ting. Det samme chatvinduet koblet til et verktøy som kan oppdatere ordrestatus er en annen. Grensen går ved handlingsevne, ikke ved hvor smart systemet virker. En SMB som ruller ut «AI-assistent til kundeservice» har ofte krysset grensen uten å ha tatt beslutningen eksplisitt.

Chatboten svarer, agenten handler

En chatbots angrepsflate er vanligvis begrenset til brukerprompter og modellutdata, og chatboter mangler ofte direkte tilgang til virksomhetssystemer eller evne til å utføre autonome handlinger (witness.ai). Agenter samhandler derimot med flere verktøy, API-er og arbeidsflyter samtidig, noe som gjør dem til et prioritert mål. Det er den samme mekanismen som gjør agenten nyttig: den rører ting.

Dimensjon	Chatbot	AI-agent
Angrepsflate	Prompt inn, tekst ut	Prompter, verktøykall, API-er, minne, arbeidsflyter
Tilgang til driftssystemer	Ofte ingen direkte	Ofte direkte, via integrasjoner
Verste utfall ved kompromittering	Usikkert eller villedende svar	Uautoriserte API-kall, endrede poster, eksfiltrert data
Spredning	Begrenset til samtalen	Kan spre seg lateralt mellom systemer
Hvem som må godkjenne	Fagansvarlig	Fagansvarlig, IT og databehandlingsansvarlig

En kompromittert agent kan ikke bare produsere usikre resultater, men også utløse uautoriserte API-kall, endre poster, eksfiltrere sensitive data eller utføre handlinger som sprer seg lateralt (witness.ai). Det er listen du skal ha med deg inn i neste leverandørmøte. Spør hva som skjer med hvert punkt i den listen i deres arkitektur.

Det nye er ikke modellen, det er tilgangen

Agenter er praktiske fordi de har enorm forhåndstrent kunnskap og kan lese verktøydokumentasjon som tilleggsprompter (arXiv, 2024). De har vist god ytelse på oppgaver som å skrive shell-skript, spørre databaser, handle og surfe på nettet. Det er nettopp evnen til å oversette tekst til kommandoer som flytter risikoen.

Et ubehagelig poeng fra forskningen: sårbarhetene i AI-agenter adresseres ikke av rammeverkene som brukes til å bygge dem, og heller ikke av forskningen som forsøker å gjøre agentene bedre. Du kan altså ikke anta at sikkerheten følger med fordi du bruker et etablert agentrammeverk. Den må bygges inn, og noen må kunne vise deg hvor.

Angrepsflaten i praksis: prompt injection, verktøykall og dataforgiftning

87 prosent av respondentene i den globale lederundersøkelsen pekte på AI-relaterte sårbarheter som den raskest voksende cyberrisikoen i 2025 (World Economic Forum, 2026). Det hjelper lite å vite at kategorien vokser hvis du ikke vet hvordan angrepene ser ut. Her er de fire mekanismene du faktisk må kunne beskrive for en leverandør.

Angrepsvei	Hvordan det skjer	Typisk konsekvens
Prompt injection	Manipulert input overstyrer tiltenkte instruksjoner	Eksfiltrering, avslørt legitimasjon, uautoriserte arbeidsflyter
Verktøy- og API-manipulasjon	Agenten lures til å kalle verktøy med endrede parametre	Endrede poster, uønskede transaksjoner
Data- og minneforgiftning	Forurenset kontekst eller lagret minne påvirker senere beslutninger	Vedvarende feilatferd over tid
Privilegiekompromittering	Agentens rettigheter utnyttes utover oppgaven	Lateral bevegelse, bredere systemkompromittering
RCE-angrep	Kodeutførelse gjennom agentens kjøremiljø	Kontroll over verten

Oversikten over sårbarhetstypene over, inkludert prompt-injeksjon, verktøymanipulasjon, minneforgiftning og RCE, er dokumentert hos ibm.com.

Prompt injection: instruksjoner som kommer inn med dataene

Prompt-injeksjonsangrep manipulerer agentens input for å overstyre de tiltenkte instruksjonene, og kan få agenten til å eksfiltrere sensitiv informasjon, avsløre legitimasjon eller utføre uautoriserte arbeidsflyter (witness.ai). Det avgjørende er at angrepet ikke trenger å komme fra brukeren. Det kan ligge i et dokument, en e-post, en nettside eller et JSON-svar fra et API.

Den tekniske grunnen er enkel og ubehagelig: brukere og verktøy samhandler med agentens språkmodell gjennom prompter i samme kontekstvindu (arXiv, 2024). Modellen ser ikke nødvendigvis forskjell på «dette er data jeg skal behandle» og «dette er en instruks jeg skal følge». Dermed blir hvert datafelt agenten leser en potensiell inngang for instruksjoner.

For en SMB betyr det følgende: hvis agenten leser innkommende kundehenvendelser og samtidig har skriverettigheter i CRM, har du gitt en ekstern part en kanal inn til dine data. Ikke nødvendigvis en åpen dør, men en kanal som må dokumenteres og testes. Hvem som skriver inn i agentens kontekst er like viktig som hvem som har tilgang til systemet.

Verktøykall, API-er og privilegier

Agenter utfører oppgaver på vegne av brukere ved hjelp av verktøy og kommandoer i omgivelsene sine (arXiv, 2024). Hvert verktøy er en rettighet du har delegert. En agent med tilgang til et «oppdater kunde»-endepunkt har i praksis skriverettigheter i kunderegisteret, uavhengig av hvor forsiktig systemprompten er formulert.

Uten sterke tilgangskontroller og kontinuerlig kjøretidsovervåking kan agenter utilsiktet eksponere sensitive data eller bli et inngangspunkt for bredere kompromittering (witness.ai). Legg merke til ordet kjøretid. En godkjenning ved utrulling sier ingenting om hva agenten gjør i uke tolv, når integrasjonene har vokst og ingen har oppdatert rettighetsmatrisen.

Data- og minneforgiftning

Forgiftning av data og minne er den mekanismen som er vanskeligst å oppdage, fordi effekten kommer senere enn årsaken (ibm.com). En agent som husker tidligere interaksjoner, eller som henter kontekst fra et kunnskapslager, kan få atferden sin dreid over tid av innhold noen har plantet der. Loggene viser et normalt verktøykall. Beslutningen bak det er påvirket.

Et mottiltak under utvikling er adversarial training, der modeller læres opp til å gjenkjenne angrep ved at villedende input blandes inn i treningsdataene. Teknikken er fortsatt umoden. Det betyr at du ikke kan bygge kontrollstrategien din på at modellen selv tar den. Kontrollen må ligge i hva agenten har lov til å gjøre, ikke bare i hva den klarer å gjennomskue.

---

Les også: Multi-agent koding fungerer best med tre til fem agenter. Anthropic lanserte Claude Code Projects 17.

---

Hva forsøket med 95 oppgaver avslører om ubeskyttede agenter

Mesteparten av debatten om agentsikkerhet er kvalitativ. Et forsøk dokumentert i forskningslitteraturen gir et mer presist bilde: hva skjer når du ber en ubeskyttet agent om å gjøre noe ondsinnet, og lar den jobbe i et miljø uten skranker?

Oppsettet og tallene

Forskerne testet en shell-basert agent mot et sett ondsinnede intensjoner fordelt på tre kategorier. Agenten i ubeskyttet konfigurasjon godtok og genererte angrepsinstruksjoner for 90 av 95 oppgaver, og 76 av de genererte kommandoene ble utført vellykket i et ubeskyttet miljø (arXiv, 2024). Det store flertallet av forsøkene endte altså i et angrep som gikk gjennom.

Kategori i forsøket	Antall oppgaver
Konfidensialitet	25
Integritet	35
Tilgjengelighet	35
Totalt	95
Kommandoer utført vellykket	76

Fordelingen er verdt et øyeblikk. Flertallet av oppgavene handlet ikke om å stjele data, men om å endre eller ødelegge: integritet og tilgjengelighet utgjør til sammen 70 av de 95 oppgavene. Det stemmer dårlig med hvordan mange SMB-er rammer inn AI-risiko internt, der samtalen nesten alltid dreier seg om personvern og datalekkasje alene.

Hva forsøket ikke beviser

Dette er et laboratorieforsøk med en bevisst ubeskyttet agent, ikke en måling av hvordan et modent produkt oppfører seg hos en norsk kunde. Tallet forteller deg hva som skjer når ingen av lagene er på plass: ingen sandkasse, ingen sesjonsstyring, ingen rettighetsbegrensning. Det er en nedre grense for hvor dårlig det kan gå, ikke en prognose.

Verdien ligger i retningen, ikke i det enkelte tallet. Forsøket viser at avslagsmekanismene i modellen alene er et svakt kontrollag, og at utførelsesmiljøet gjør mesteparten av jobben. Det er et argument for å putte pengene i tilgangsstyring og isolasjon fremfor i stadig strammere systemprompter. Vi har sett samme mønster i vår gjennomgang av kritiske sårbarheter i agentutrullinger.

Rammeverket: konfidensialitet, integritet og tilgjengelighet for agenter

Sikkerhet i tradisjonelle datasystemer ivaretas gjennom tre egenskaper: konfidensialitet, integritet og tilgjengelighet, og hver av dem møter unike utfordringer i agentsystemer (arXiv, 2024). Dette er det mest brukbare rammeverket en ledergruppe kan ta i bruk, fordi det er gammelt, kjent og ikke avhenger av AI-terminologi.

Bruk de tre som agenda i stedet for en generisk «AI-risiko»-post. Still samme tre spørsmål for hver agent du vurderer: hva kan den se, hva kan den endre, og hva skjer hvis den stopper eller blir overbelastet.

Konfidensialitet: hva agenten kan se

Konfidensialitetsutfordringene i agentsystemer knytter seg blant annet til sesjonshåndtering og personvernlekkasjer (arXiv, 2024). En agent som betjener flere brukere må holde kontekst fra ulike sesjoner atskilt. Hvis den ikke gjør det, kan informasjon fra en kundes sak dukke opp i svaret til en annen, uten at noe i loggen ser ut som et innbrudd.

Praktisk kontroll: krev at leverandøren beskriver hvordan sesjoner isoleres, hvor lenge kontekst beholdes, og om data fra din instans kan påvirke andre kunders instanser. Dette er et spørsmål med et teknisk svar. Får du et svar om tillit og sertifiseringer i stedet, har du ikke fått svaret.

Integritet: hva agenten kan endre

Integritet er den dimensjonen som skiller agenten tydeligst fra chatboten. Fordi brukere og verktøy snakker til modellen i samme kontekstvindu, er integriteten til data i agentsystemer forskjellig fra tradisjonelle systemer (arXiv, 2024). Det finnes ikke en skarp grense mellom instruks og innhold som du kan håndheve på nettverksnivå.

Konsekvensen er at integritetskontrollen må ligge i verktøylaget. Hvilke verktøy kan skrive? Hvilke felt kan de skrive til? Kreves det menneskelig godkjenning for handlinger over en terskel, og hvem definerer terskelen? En agent som kan sende faktura uten godkjenning er en forretningsbeslutning, ikke en teknisk detalj.

Tilgjengelighet: hva som skjer når agenten faller

Tilgjengelighet var den største kategorien i forsøket, sammen med integritet, med 35 oppgaver hver. For en SMB handler det sjelden om distribuerte angrep. Det handler om at en agent som har overtatt en arbeidsflyt, blir en avhengighet ingen har beskrevet. Hva skjer med ordrebehandlingen hvis agenten er nede en fredag?

Krev et manuelt fallback for hver arbeidsflyt agenten overtar, og test det minst en gang. Dette er den billigste kontrollen i hele artikkelen og den som oftest mangler. Den har også en bieffekt: en organisasjon som vet hvordan oppgaven gjøres manuelt, er mye bedre stilt når den skal vurdere om agentens resultater faktisk er riktige.

Tiltakene som demper risikoen: zero trust, minste privilegium og sandkasse

Mottiltakene som foreslås i litteraturen er ikke eksotiske. De er stort sett kjente sikkerhetsprinsipper anvendt på et nytt sted: sesjonsstyring, sandkasse og beskyttelse av modeller (arXiv, 2024), supplert med zero trust, minste privilegium, mikrosegmentering og prompt-validering (ibm.com).

Det gode med dette er at mange SMB-er allerede har deler av apparatet. Det dårlige er at agenten ofte rulles ut utenfor apparatet, som et fagverktøy kjøpt av en avdeling.

Zero trust og kontekstbevisst autentisering

Zero trust-arkitektur antar at ingen enhet på et nettverk er pålitelig som standard, og krever autentisering og autorisasjon for hver enkelt tilgangsforespørsel (ibm.com). Overført til agenter betyr det at agenten ikke er en betrodd intern komponent fordi den kjører på din side av brannmuren. Hvert verktøykall er en forespørsel som skal autoriseres.

Kontekstbevisst autentisering legger til et lag: hvem spør, fra hvor, om hva, og passer det med mønsteret. En agent som plutselig leser 4000 kunderader klokken 03 bør møte motstand, selv om legitimasjonen er gyldig. Spør leverandøren om agenten har sin egen identitet i systemene, eller om den opererer under en delt tjenestebruker. Delte tjenestebrukere ødelegger både autorisasjon og sporbarhet.

Minste privilegium

Prinsippet om minste privilegium innebærer at hver enhet eller agent skal ha de lavest mulige tillatelsene som trengs for ansvarsoppgavene sine (ibm.com). I agentprosjekter brytes dette nesten alltid på samme måte: agenten får en API-nøkkel med bredere rettigheter enn oppgaven krever, fordi det er raskere enn å lage en egen rolle.

Alura mener minste privilegium er en billig beslutning før utrulling og en dyr opprydding etterpå. Når agenten har kjørt i produksjon i et halvår, er rettighetene vevd inn i arbeidsflyter ingen tør røre, og innsnevring blir et prosjekt med risiko for nedetid. Rettighetsmatrisen koster en time i designfasen.

Sandkasse og mikrosegmentering

Sandkasse er det tiltaket forsøket med de 95 oppgavene peker rettest mot, siden angrepene lyktes nettopp i et ubeskyttet utførelsesmiljø (arXiv, 2024). Hvis agenten kan kjøre kode eller kommandoer, skal det skje isolert, med eksplisitt hvitelistet nettverkstilgang og uten varige rettigheter på verten.

Mikrosegmentering gjør det samme på nettverksnivå og begrenser hvor langt en kompromittert komponent kommer (ibm.com). Dette er det mest effektive svaret på lateral bevegelse. En agent som bare kan nå tre navngitte endepunkter er en håndterbar risiko. En agent på det flate kontornettet er ikke det.

Prompt-herding, validering og kryptering

Prompt-herding og prompt-validering hører med, men hører hjemme som et lag blant flere (ibm.com). Forsøksresultatene gjør det tydelig hvorfor: en agent som lar seg overtale i 90 av 95 tilfeller, er ikke et system der instruksjonslaget er den avgjørende forsvarslinjen. Herding reduserer støy. Det fjerner ikke behovet for isolasjon.

På datasiden er anbefalingen rett fram: data både under overføring og i ro bør krypteres med AES-256 eller tilsvarende. Dette er et krav de fleste leverandører kan svare konkret på, og et godt utgangspunkt for å teste om du snakker med noen som faktisk har et sikkerhetsregime. Mer om hvordan ledende leverandører rammer dette inn finner du i gjennomgangen av AI-sikkerhet for norske bedrifter.

Mandag morgen: kartlegg hvilke systemer agenten får røre

Her er den delen du kan gjøre uten budsjett, uten leverandør og uten å vente på en strategi. Den tar en halv dag for en SMB med normal systemportefølje, og den endrer samtalene du har med leverandører etterpå.

Lag systemkartet først

Skriv ned hver AI-agent eller AI-assistent som finnes i virksomheten i dag, inkludert de avdelingene har kjøpt selv. For hver av dem: hvilke systemer er den koblet til, leser den eller skriver den, hvilken identitet bruker den, og hvem eier den internt. De fleste blir overrasket over kolonnen hvem eier den, som ofte står tom.

Legg til en kolonne for data: inneholder systemet agenten rører personopplysninger, kundeavtaler eller økonomidata? Dette er grunnlaget for alt senere arbeid, både sikkerhetsmessig og regulatorisk. En agent som er et hovedmål for trusler fordi den snakker med flere verktøy og API-er samtidig (witness.ai), bør ikke være udokumentert i et regneark ingen eier.

Les før skriv

Alura mener du bør starte med agenter som leser data før du gir dem skriverettigheter, og utvide først når logging og tilgangsstyring faktisk er på plass. En leseagent som finner informasjon i avtaler, oppsummerer saker eller forbereder svarutkast gir mesteparten av gevinsten i de tidlige fasene. Den gir også et halvår med reelle driftsdata før du gjør noe irreversibelt.

Rekkefølgen har en annen fordel: den gjør kvalitetsproblemer synlige før de blir dyre. Hvis agenten henter feil kontrakt i lesemodus, retter en saksbehandler det. Hvis den samme feilen kommer i skrivemodus, har du oppdatert et kunderegister feil, og du oppdager det når kunden ringer.

Logging som gjør hendelsen etterprøvbar

Kontinuerlig kjøretidsovervåking er en av forutsetningene for at agenten ikke blir et inngangspunkt for bredere kompromittering (witness.ai). Minimumskravet er at du i ettertid kan svare på tre spørsmål: hvilken input utløste handlingen, hvilket verktøy ble kalt med hvilke parametre, og hvilken identitet autoriserte det.

Mangler et av de tre, kan du ikke gjennomføre en hendelsesundersøkelse. Du kan bare gjette. Avklar også hvor lenge loggene lagres og om du har tilgang til dem selv eller må be leverandøren om utdrag. Fjorten dagers logg hos leverandøren er i praksis ingen logg når en hendelse oppdages etter seks uker.

Spørsmålene du stiller leverandøren før du signerer

I svært resiliente organisasjoner oppgir 70 prosent av toppledere at de integrerer sikkerhet i anskaffelsesprosessen (World Economic Forum, 2026). Det er den enkleste strukturelle forskjellen mellom de som får kontroll og de som ikke får det. Alura mener sikkerhetsgjennomgang av AI-verktøy hører i anskaffelsesprosessen, ikke i driftsfasen etterpå.

Område	Spørsmålet du stiller	Hva et godt svar inneholder
Prompt injection	Hvilke konkrete tiltak har dere mot instruksjoner som kommer inn via data?	Navngitte tiltak, testresultater, kjent restrisiko
Identitet	Har agenten egen identitet, eller deler den en tjenestebruker?	Egen identitet per agent, med rollebasert tilgang
Rettigheter	Hvilke verktøy kan skrive, og til hvilke felt?	Eksplisitt verktøy- og feltliste, ikke «full API-tilgang»
Isolasjon	Kjører kode eller kommandoer i sandkasse?	Isolert miljø, hvitelistet nettverk, ingen varige vertsrettigheter
Logging	Hva logges, hvor lenge, og har vi direkte tilgang?	Input, verktøykall, parametre, identitet, med eksportmulighet
Hendelser	Innen hvor mange timer varsles vi ved mistanke?	Tallfestet frist i kontrakten, med eskaleringskontakt
Kryptering	Krypteres data i ro og under overføring?	AES-256 eller tilsvarende, begge tilstander
Tredjeparter	Hvilke underleverandører ser våre data?	Oppdatert liste, varslingsplikt ved endring

Fra markedsmateriell til kontraktstekst

Alura mener dokumenterte tiltak mot prompt injection hører i kontrakten, ikke i leverandørens markedsmateriell. Forskjellen er ikke formalisme. En setning på en nettside kan endres uten varsel og gir deg ingenting hvis noe går galt. En kontraktsfestet beskrivelse av tiltak, med en forpliktelse om å varsle ved vesentlige endringer, gir deg et grunnlag å stå på.

Formuler kravet slik at det kan oppfylles og etterprøves: beskriv hvilke tiltak som er implementert mot instruksjoner i data, hvordan de testes, og hvilken restrisiko leverandøren selv anerkjenner. En leverandør som ikke vil skrive ned noen restrisiko, har enten ikke testet eller svarer ikke ærlig. Begge er nyttig informasjon.

Styring, ansvar og tilsyn

AI-agent-styring defineres som retningslinjer, tilsynsmekanismer og ansvarsstrukturer som sikrer at agentene opererer trygt, etisk og i samsvar med organisatoriske og regulatoriske krav (witness.ai). For en SMB oversettes dette til tre konkrete ting: en navngitt eier per agent, en fast gjennomgangsrytme, og en beslutning om hvem som kan utvide rettigheter.

Det siste punktet er det som faktisk holder. Hvis en avdelingsleder kan koble agenten til et nytt system uten at noen godkjenner det, har du ingen tilgangsstyring, uansett hva policyen sier. Sett en person som må signere på hver nye integrasjon, og gi dem fem minutter til å stille spørsmålene fra tabellen over.

Tredjeparter og leverandørkjeden

Blant toppledere i svært resiliente organisasjoner peker 78 prosent på leverandørkjede- og tredjepartsavhengigheter som den største utfordringen (WEF, 2026). AI-agenter forsterker dette fordi en agent typisk er bygget av en leverandør, kjører på en modell fra en annen, og kobler til verktøy fra en tredje.

Be om kjeden, ikke bare navnet på den du signerer med. Hvem hoster modellen, hvor behandles dataene, og hvilke underleverandører har tilgang? Vi har satt opp kriteriene for dette i en egen gjennomgang av valg av AI-leverandør, og i en sjekkliste over fem sikkerhetskrav før agenter kobles til driften.

---

Les også: Fem sikkerhetskrav før OpenAI-agenter kobles til driften. OpenAI lanserte over 20 nyheter på DevDay 2026, inkludert alltid-på-agenter som når 4 000 apper.

---

Markedet: sikkerhetsvurdering av AI-verktøy har nesten doblet seg

Andelen organisasjoner som vurderer sikkerheten til AI-verktøyene sine har nesten doblet seg, fra 37 prosent i 2025 til 64 prosent i 2026 (World Economic Forum, 2026). Det er en rask bevegelse for et felt der prosesser vanligvis endres sakte, og den sier noe om hvor fort agenter har kommet inn i produksjon.

Samtidig utfører bare 40 prosent periodiske gjennomganger av AI-verktøy før utrulling. Gapet mellom å vurdere sikkerheten en gang og å gjennomgå den systematisk før hver utrulling er der problemene bor. En engangsvurdering av et system som endrer atferd og integrasjoner månedlig, er en øyeblikksbilde med kort holdbarhet.

Hva lederne faktisk rapporterer

77 prosent av organisasjonene har tatt i bruk AI til cybersikkerhetsformål (WEF, 2026). AI brukes altså både som forsvar og som angrepsvektor i samme organisasjon, ofte uten at de to sidene snakker sammen. Sikkerhetsavdelingen kjøper AI-verktøy, forretningssiden kjøper AI-agenter, og ingen har et samlet kart.

Bildet er ikke entydig alarmistisk. At to tredjedeler nå vurderer sikkerheten i verktøyene sine er en forbedring, og at AI-sårbarheter rangeres som raskest voksende risiko tyder på at kategorien er forstått. Problemet er takten: angrepsflaten vokser med hver integrasjon, mens gjennomgangene skjer i prosjektsykluser.

Kompetansegapet er flaskehalsen

54 prosent oppgir utilstrekkelig kunnskap eller ferdigheter som et hinder for å bruke AI i cybersikkerhet (WEF, 2026). For norske SMB-er er dette den mest gjenkjennelige linjen i hele rapporten. Det finnes sjelden en person internt som både forstår språkmodeller, tilgangsstyring og anskaffelser.

Konsekvensen bør ikke være å utsette agenter til kompetansen finnes. Den bør være å velge en startpakke du kan styre: en leseagent, en eier, en rettighetsmatrise og en loggkonfigurasjon du faktisk forstår. Kompetanse bygges raskest på et system som er i drift og er lite nok å ha oversikt over.

Kostnadsbildet for innbrudd og for kontrollene som hindrer dem

Et argument om sikkerhet som ikke har tall i seg, taper mot et argument om effektivitet som har det. Her er tallene du kan sette opp mot kostnaden av kontrollene.

Størrelse	Tall	Kilde
Gjennomsnittlig kostnad for AI-modellinversjonsangrep	6 millioner dollar	ibm.com
Økning i AI-drevne angrep	56 prosent	ibm.com
Toppledere i resiliente organisasjoner som integrerer sikkerhet i anskaffelse	70 prosent	WEF, 2026
Organisasjoner som gjennomgår AI-verktøy før utrulling	40 prosent	WEF, 2026

Hva et innbrudd koster

AI-drevne angrep har økt 56 prosent, og modellinversjonsangrep koster i snitt 6 millioner dollar (ibm.com). Globale gjennomsnitt er ikke din kostnad. En norsk SMB med 40 ansatte får ikke den regningen. Men strukturen i kostnaden er den samme: undersøkelse, varsling, nedetid, juridisk arbeid og tapt tillit.

Modellinversjonsangrep ligger altså høyere enn snittet for datainnbrudd generelt. Det er en indikasjon på at hendelser som treffer AI-laget er dyrere å rydde opp i enn gjennomsnittet, blant annet fordi færre har beredskap for dem og fordi omfanget er vanskeligere å avgrense.

Hva kontrollene koster, og når

De fire tiltakene med best forhold mellom kostnad og effekt for en SMB koster lite i penger og noe i disiplin: egen identitet per agent, eksplisitt verktøy- og feltliste, sandkasse for kodeutførelse, og logg du selv har tilgang til. Ingen av disse krever ny programvare i de fleste oppsett. De krever at noen tar beslutningen før integrasjonen bygges.

Dette er hele poenget med å flytte gjennomgangen til anskaffelsen. Å kreve egen tjenesteidentitet i en kontraktsforhandling koster en setning. Å innføre det i en agent som har kjørt i produksjon i ni måneder koster et prosjekt, med testing, nedetidsrisiko og en diskusjon om hvem som betaler. Rekkefølgen avgjør prislappen.

AI Act og agenter: når autonome handlinger utløser krav

EUs AI-forordning, formelt 2024/1689, regulerer AI-systemer gjennom et risikobasert rammeverk, men leverandører av agenter møter samtidig forpliktelser under flere andre EU-forordninger og direktiver (arXiv, 2026). For en norsk SMB betyr det at agenten kan treffes av flere regelsett parallelt, ikke bare av AI Act.

En fersk regulatorisk kartlegging for leverandører av AI-agenter presenterer en taksonomi med ni kategorier for agent-utplassering som kobler konkrete handlinger til regulatoriske utløsere, og foreslår en tolvtrinns compliance-arkitektur. Nøkkelordet er handlinger. Det er hva agenten gjør, ikke hva den heter, som utløser krav.

Handlingen utløser kravet, ikke etiketten

Det praktiske grepet fra kartleggingen er at utplasseringen beskrives gjennom konkrete handlinger som kobles til regulatoriske utløsere (arXiv, 2026). En agent som sorterer interne dokumenter og en agent som fatter beslutninger med konsekvenser for enkeltpersoner havner ulike steder i risikobildet, selv om de bruker samme modell og samme rammeverk.

Derfor er systemkartet fra kapittelet om mandag morgen også et compliance-dokument. Når du har skrevet ned hva hver agent faktisk gjør, hvilke data den rører og hvilke beslutninger den påvirker, har du grunnlaget en juridisk vurdering trenger. Uten kartet blir vurderingen en øvelse i gjetting.

Atferdsdrift er compliance-problemet

Den skarpeste konklusjonen i kartleggingen: høyrisiko agentiske systemer med uidentifiserbar atferdsdrift kan per nå ikke oppfylle AI-forordningens grunnleggende krav (arXiv, 2026). Det er en påstand fra et arbeidsnotat, ikke en rettskraftig avgjørelse, men den peker på et reelt problem: krav om dokumentasjon og menneskelig tilsyn er vanskelige å oppfylle for et system som endrer atferd uten at endringen kan påvises.

Operativt betyr det at sporbarhet er både en sikkerhetskontroll og en regulatorisk forutsetning. Hvis du ikke kan vise hvorfor agenten gjorde det den gjorde, har du et problem i hendelsesundersøkelsen og i dokumentasjonen samtidig. Det er et godt argument for å prioritere logging høyt i anskaffelsen.

Tidslinjen rundt regelverket

Regelverksarbeidet pågår parallelt med at agenter rulles ut, og det er en del av risikoen. GPAI Code of Practice ble publisert i juli 2025, standardprogrammet for Cyber Resilience Act under mandat M/606 ble akseptert i april 2025, Digital Omnibus-forslagene kom i november 2025, og utkast til harmoniserte standarder under M/613 var ventet i januar 2026 (arXiv, 2026).

Hendelse	Tidspunkt
CRA harmoniserte standarder, mandat M/606 akseptert	April 2025
GPAI Code of Practice publisert	Juli 2025
Digital Omnibus-forslagene	November 2025
Utkast til harmoniserte standarder under M/613	Januar 2026
Arbeidsnotatet «AI Agents Under EU Law» innsendt	6. april 2026

Praktisk råd: ikke bygg arkitekturen rundt dagens bokstav i regelverket. Bygg den rundt egenskapene som alle versjonene krever: dokumentasjon av formål, sporbare handlinger, menneskelig tilsyn på de beslutningene som betyr noe, og rettigheter som er mulige å begrunne. Det holder gjennom flere runder med standardarbeid.

Vanlige feil norske SMB-er gjør når agenter kobles til driften

Feilene under er ikke tekniske. De er beslutningsfeil, og de gjentar seg på tvers av bransjer. De er også grunnen til at gapet mellom de 64 prosentene som vurderer sikkerhet og de 40 prosentene som gjennomgår før utrulling (World Economic Forum, 2026) ikke lukkes av seg selv.

Feilene i tilgang og utrulling

Skriverettigheter fra dag en. Agenten får lov til å oppdatere CRM i pilotfasen fordi det er det som gir den synlige gevinsten. Da har du gjort den dyreste beslutningen først, før du vet om kvaliteten holder. Leseagenten gir deg nesten samme læring til en brøkdel av risikoen.

Delt tjenestebruker. Agenten kobles til med en eksisterende integrasjonsbruker som allerede har bred tilgang, fordi det tar fem minutter mot en halv dag for en ny rolle. Resultatet er at ingen handling kan tilskrives agenten i etterkant, og at rettighetene er langt bredere enn oppgaven. Minste privilegium brytes i det øyeblikket (ibm.com).

Ingen sandkasse for kodeutførelse. Agenter som kan kjøre skript får ofte lov til det direkte på en server med varige rettigheter. Forsøket med 95 oppgaver er en direkte illustrasjon av hva et ubeskyttet utførelsesmiljø koster (arXiv, 2024).

Gradvis utvidelse uten ny vurdering. Agenten godkjennes for en oppgave, og så kobles den til tre nye systemer i løpet av et halvår uten at noen gjør vurderingen på nytt. Hver integrasjon er en ny angrepsflate, og agenten er et hovedmål nettopp fordi den snakker med mange verktøy samtidig (witness.ai).

Feilene i styring og dokumentasjon

Sikkerhetsmateriell forvekslet med sikkerhetskrav. En leverandørside som beskriver «innebygd beskyttelse mot prompt injection» leses som en garanti. Det er markedsføring til det står i en avtale med en beskrivelse av tiltak, testing og restrisiko.

Logg uten eierskap. Mange har logger, men ingen som ser dem og ingen avtale om hvor lenge de beholdes. Kontinuerlig kjøretidsovervåking er en forutsetning for at agenten ikke blir et inngangspunkt for videre kompromittering (witness.ai), og overvåking uten en ansvarlig er bare lagring.

Ingen manuell fallback. Arbeidsflyten legges over til agenten, den manuelle rutinen forvitrer, og tilgjengelighetsrisikoen blir usynlig til første driftsstans. Tilgjengelighet er en av de tre sikkerhetsegenskapene, ikke en driftsdetalj (arXiv, 2024).

Antakelsen om at rammeverket har løst det. Det er den feilen som sitter dypest. Sårbarhetene i AI-agenter adresseres verken av rammeverkene som brukes til å bygge dem eller av forskningen som vil forbedre dem. Sikkerheten er din beslutning, uansett hvilket verktøy du har valgt.

Ofte stilte spørsmål om sikkerhet i AI-agenter

Spørsmålene under er de som oftest kommer fra ledergrupper når agentprosjekter går fra pilot til drift.

Er prompt injection et løst problem?

Nei. Det finnes tiltak som reduserer risikoen, blant annet prompt-herding, prompt-validering og adversarial training, men adversarial training beskrives fortsatt som under utvikling (ibm.com). Den strukturelle årsaken står fast: brukere og verktøy skriver inn i samme kontekstvindu, så grensen mellom data og instruks er uskarp (arXiv, 2024). Planlegg for restrisiko, ikke for en løsning.

Hvor mye tilgang bør agenten ha i starten?

Så lite som oppgaven krever, og helst bare lesetilgang i første fase. Prinsippet er at hver agent skal ha de lavest mulige tillatelsene som trengs for ansvarsoppgavene (ibm.com). Konkret: egen identitet, en navngitt liste over verktøy den kan kalle, og en eksplisitt beslutning for hvert felt den skal kunne skrive til. Utvid når logg og tilgangsstyring er på plass, ikke når gevinsten frister.

Trenger vi egen sikkerhetsgjennomgang når leverandøren er stor?

Ja. Leverandørens størrelse sier noe om deres interne sikkerhet, ikke om hvordan du har konfigurert tilgangen i ditt oppsett. Tredjeparts- og leverandørkjedeavhengigheter oppgis som største utfordring av 78 prosent av toppledere i svært resiliente organisasjoner (WEF, 2026). Gjennomgangen din handler om grensesnittet mellom deres produkt og dine systemer.

Hva skal logges, og hvor lenge?

Minimum: input som utløste handlingen, verktøykallet med parametre, og identiteten som autoriserte det. Uten alle tre kan du ikke rekonstruere en hendelse. Avtal lagringstid som matcher realistisk oppdagelsestid, ikke leverandørens standardoppsett, og avklar om du kan eksportere loggen selv. Kjøretidsovervåking er en uttalt forutsetning for å unngå at agenten blir et inngangspunkt for bredere kompromittering (witness.ai).

Er AI-agenter i en SMB omfattet av AI Act?

Det avhenger av hva agenten gjør. Forordningen 2024/1689 bruker et risikobasert rammeverk, og agenter treffes gjennom konkrete handlinger koblet til regulatoriske utløsere (arXiv, 2026). Samtidig kan flere andre EU-regelverk gjelde parallelt. Start med systemkartet: beskriv handlinger, data og beslutninger per agent, og ta den juridiske vurderingen på det grunnlaget.

Oppsummering: det du tar med deg inn i leverandørmøtet

En AI-agent er ikke en chatbot med bedre hukommelse. Det er et system som planlegger, kaller verktøy og utfører handlingskjeder med redusert menneskelig involvering (arXiv, 2026). Den forskjellen flytter risikoen fra tekstkvalitet til handlinger i produksjonssystemer, og den krever andre kontroller enn de du allerede har for et chatvindu.

Tallene gir retningen. En ubeskyttet agent lot seg overtale i nesten alle tilfellene i et kontrollert forsøk, og 76 av de genererte kommandoene ble utført vellykket i et miljø uten skranker (arXiv, 2024). Markedet har begynt å reagere, men gjennomgangene henger etter utrullingene (World Economic Forum, 2026). Det er i det gapet SMB-er gjør de dyre feilene.

Fire krav er nok til å komme godt i gang: kontraktsfestede tiltak mot prompt injection, egen identitet med minste privilegium, sandkasse for kodeutførelse og logg du selv kan lese. Still dem før signering, ikke etter. Gjennomgangen hører i anskaffelsen, og rettighetene er billige å begrense før utrulling og dyre å rydde i etterpå.

Tre beslutninger for denne måneden

Lag systemkartet. En agent per rad, med systemer, lese- eller skriverettigheter, identitet, eier og datatype. Det er grunnlaget for både sikkerhetsarbeidet og den regulatoriske vurderingen, og det tar en halv dag.

Sett en eier per agent. Uten en navngitt person som må godkjenne nye integrasjoner, finnes ikke tilgangsstyringen i praksis. Styring er retningslinjer, tilsyn og ansvarsstrukturer, ikke et dokument (witness.ai).

Flytt sikkerhetsspørsmålene til anskaffelsen. Blant toppledere i de mest resiliente organisasjonene integrerer 70 prosent sikkerhet i anskaffelsesprosessen (WEF, 2026). Tabellen med leverandørspørsmål lenger opp er en agenda du kan bruke uendret i neste møte.

I Alura bygger vi AI-infrastruktur for norske virksomheter, fra dataplattformer til agentiske systemer i produksjon. Vi er ikke en SaaS-leverandør. Vi er håndverkere som setter sammen byggesteinene som faktisk fungerer for din situasjon.

Bestill en arkitektur-samtale: vi går gjennom din nåværende infrastruktur, identifiserer integrasjonspunkter, og foreslår en pragmatisk vei videre. Uforpliktende, 45 minutter.

Kilder

• arXiv (2024). Security of AI Agents
• World Economic Forum (2026). Global Cybersecurity Outlook 2026
• ibm.com. What is AI Agent Security? | IBM
• arXiv (2026). [2604.04604] AI Agents Under EU Law
• witness.ai. AI Agent Security: Risks, Best Practices & Enterprise Protection - WitnessAI