AI-agenter kan ikke stoppes i 60 prosent av virksomhetene

Nøkkelpunkter per 16. september 2026:

• 60 prosent av organisasjonene kan ikke terminere en AI-agent som oppfører seg dårlig, og 63 prosent kan ikke håndheve formålsbegrensninger (kiteworks.com, 2026).
• Agentflåtene er doblet på fire måneder, mens gjennomsnittlig overvåkingsdekning bare har flyttet seg opp til 52 prosent (gravitee.io, 2026).
• Svært få har en navngitt person med formelt ansvar for agentatferd, mens en betydelig andel beskriver ansvaret som uklart eller situasjonsavhengig (gravitee.io, 2026).
• 97 prosent av virksomhetene som rapporterte et AI-relatert brudd manglet tilstrekkelige AI-tilgangskontroller, og skygge-AI legger rundt 670 000 dollar til bruddkostnaden (kiteworks.com, 2026).
• EU AI Act setter bøtetaket på 35 millioner euro, eller en fastsatt andel av global årsomsetning, mens bare et mindretall mener dagens regulering dekker agentrisiko (gravitee.io, 2026).

---

Hva en AI-agent-hendelse faktisk er

En AI-agent er et system som har fått lov til å gjøre noe, ikke bare si noe. Den kaller API-er, skriver til databaser, sender e-post, oppretter saker i CRM-et og henter filer fra delte områder. Forskjellen fra en chatbot er ikke språkmodellen, men nøklene: agenten har legitimasjon, og legitimasjonen virker døgnet rundt uten at noen ser på. Sikkerhetsspørsmålet skifter derfor karakter i det øyeblikket en virksomhet går fra samtale til handling (autonome AI-systemer).

En agenthendelse ser sjelden ut som et innbrudd. Den ser ut som et autorisert system som gjorde noe ingen hadde bedt om, med tilganger noen ga det i god tro tre måneder tidligere. 65 prosent av organisasjonene rapporterer minst en cybersikkerhetshendelse forårsaket av AI-agenter på bedriftsnettverket det siste året (kiteworks.com, 2026). Det vanligste utfallet er ikke kryptert disk og løsepengekrav. Det er data på avveie.

Konsekvens av AI-agent-hendelser	Andel av hendelsene
Eksponering av sensitive data	61 %
Operasjonell forstyrrelse	43 %
Utilsiktede handlinger i forretningsprosesser	41 %
Økonomiske tap	35 %
Tjenesteforsinkelser	31 %

Fra samtale til handling

Et språkmodellsvar som er feil, er en tekst noen kan overse. En agenthandling som er feil, er en transaksjon som allerede er gjennomført. Den forskjellen er hele saken. Når 41 prosent av agenthendelsene består av utilsiktede handlinger i forretningsprosesser, snakker vi om ordrer, fakturaer, kundedialoger og datauttrekk som ble utført korrekt teknisk sett, men mot feil formål (kiteworks.com, 2026).

Dette er også grunnen til at klassiske sikkerhetsverktøy treffer dårlig. Brannmur, endepunktsbeskyttelse og e-postfiltre er bygget for å skille autorisert fra uautorisert. Agenten er autorisert. Den har gyldig token, gyldig sesjon og ofte en rolle som er bredere enn oppgaven krever. Verktøyene ser en normal bruker som jobber fort.

Hvorfor tallene spriker mellom 54 og 65 prosent

To store undersøkelser i 2026 gir ulike tall for samme fenomen, og forskjellen er ikke tilfeldig. Den ene spør 750 senior teknologiledere i Storbritannia og USA, og finner at 54 prosent har opplevd eller mistenkt en sikkerhets- eller personvernhendelse med AI-agenter siste år, mens en klart lavere andel bekrefter en faktisk hendelse (gravitee.io, 2026). Den andre bygger på forskning fra Cloud Security Alliance og Token Security og lander på 65 prosent (kiteworks.com, 2026).

Spriket forteller noe nyttig: det avhenger av hva du klarer å oppdage. En virksomhet med god logging rapporterer flere hendelser enn en uten, ikke fordi den er mer utsatt, men fordi den ser mer. Bekreftet hendelsesrate falt faktisk fra desember 2025 til april 2026, uten at sikkerhetsdekningen hadde beveget seg tilsvarende. Det er like sannsynlig at deteksjonen ble dårligere som at risikoen gikk ned.

Merk også hva ingen av disse tallene er: de er ikke norske. Undersøkelsene dekker britiske og amerikanske virksomheter, og de fleste respondentene er større enn en typisk norsk SMB. Bruk tallene som retning, ikke som fasit for eget hus.

Tre kontrolltap som går igjen i tallene

Under overskriftene om hendelsesrater ligger tre konkrete kontrolltap. De er beskrevet hver for seg i undersøkelsene, men i praksis opptrer de sammen, og de forsterker hverandre. En agent uten eier får bred tilgang fordi ingen har ansvar for å snevre den inn. En agent med bred tilgang blir vanskelig å stoppe fordi ingen vet hva stoppen vil ødelegge.

Hvis du bare skal måle en ting i egen virksomhet denne høsten, mål disse tre.

Stoppknappen mangler

60 prosent av organisasjonene oppgir at de ikke kan terminere en AI-agent som oppfører seg dårlig (kiteworks.com, 2026). Det er ikke et teknisk mysterium. Det betyr som regel at agenten kjører i en leverandørs sky, at ingen internt har administratorrettighetene, eller at nøkkelen agenten bruker også brukes av fire andre integrasjoner som stanser samtidig.

Alura mener at en agent du ikke kan stoppe ikke er i produksjon, den er utenfor kontroll. Stoppknappen bør testes før agenten får tilgang til noe som helst. En knapp ingen har trykket på er en antakelse, ikke en kontroll.

Formålet kan ikke håndheves

63 prosent kan ikke håndheve formålsbegrensninger på AI-agenter (kiteworks.com, 2026). Formålsbegrensning er kjernen i personvernregelverket: data samlet inn til et formål skal ikke brukes til et annet. En agent som har lesetilgang til hele kundebasen for å svare på supporthenvendelser, har teknisk sett også tilgang til å bruke de samme dataene til noe helt annet.

Problemet forsterkes av at få vet hvor dataene er. Bare 33 prosent har fullstendig oversikt over hvor sensitive data befinner seg. Du kan ikke begrense en agent til «kun kundeservicedata» hvis du ikke vet hvilke mapper og tabeller det faktisk er.

Eierskapet er uklart

Bare en liten andel av organisasjonene har en navngitt person med formelt ansvar for AI-agentatferd, mens en betydelig andel beskriver ansvaret som uklart eller situasjonsavhengig (gravitee.io, 2026). Samme undersøkelse finner at klart flere oppgir at det finnes en navngitt ansvarlig før produksjonssetting. Avstanden mellom de to svarene er avstanden mellom en rutine på papiret og en person som faktisk blir ringt klokka to om natta.

Uklart eierskap er billig helt til det ikke er det. I det øyeblikket en agent har sendt feil data til feil mottaker, må noen kunne svare på hvorfor agenten hadde den tilgangen. Et team er ikke et svar. En rolle er ikke et svar. Et navn er.

---

Les også: Sikkerhet i AI-agenter svikter i 73 prosent av utrullingene. 73 prosent av AI-utrullinger har minst én kritisk sårbarhet, og bare 12 prosent tester systematisk.

---

Rammeverket: eier, scope, logg og stoppknapp

Alura mener at ingen agent bør kjøre mot eksterne tjenester uten navngitt eier, avgrenset tilgang og full logg over hva den faktisk gjorde. Legg til en testet stoppknapp, og du har fire kontroller som dekker de vanligste feilmodusene uten at du trenger nytt verktøy, ny plattform eller ny stilling.

Rammeverket er bevisst kjedelig. Det er ikke avansert sikkerhetsarbeid, det er grunnleggende drift anvendt på en ny brukerkategori. Poenget er at de fire punktene kan verifiseres av en person på en ettermiddag, per agent.

Kontroll	Minstekrav	Slik verifiserer du den
Navngitt eier	En person, ikke et team, med navn i et register	Ring personen og spør hva agenten gjorde i går
Avgrenset tilgang	Egen konto og eget token, kun systemene oppgaven krever	Fjern en tilgang og se om agenten fortsatt løser oppgaven
Full logg	Hver utgående handling, med tidspunkt, mål og resultat	Rekonstruer en vilkårlig time fra forrige uke
Stoppknapp	Kjent prosedyre som stanser agenten uten å stanse annet	Trykk på den i produksjon, i arbeidstiden, planlagt

Navngitt eier, ikke et team

Eieren skal kunne svare på tre spørsmål uten forberedelse: hva agenten har lov til, hvem som godkjente det, og hva som skjer hvis den slås av. Eierskapet trenger ikke ligge i IT. Ofte er den rette eieren produktansvarlig eller avdelingslederen som fikk gevinsten, fordi det er der kunnskapen om formålet ligger.

Skriv eieren inn i samme register som agenten. Når så få har navngitt ansvar på plass, er dette den enkleste forskjellen du kan lage på en dag (gravitee.io, 2026). Sett også en sluttdato: eierskap uten revisjonsdato forvitrer neste gang noen bytter jobb.

Avgrenset tilgang som standard

Den vanligste snarveien er å gi agenten tilgangene til personen som bestilte den. Det er raskt, det virker umiddelbart, og det gjør agenten til en usynlig kopi av en ansatt med flere års akkumulerte rettigheter. 97 prosent av virksomhetene som rapporterte et AI-relatert brudd manglet tilstrekkelige AI-tilgangskontroller (kiteworks.com, 2026).

Gi agenten egen identitet, eget token og en tilgangsliste som er skrevet ned. Start smalere enn du tror er nødvendig og utvid når noe faktisk feiler. Metoden er lite elegant, men den gir deg en dokumentert begrunnelse for hver tilgang agenten har, og det er akkurat det du trenger når noen spør i ettertid (fire grenser for agenter).

Logg over handlinger, ikke bare over prompts

Mange tror de logger agenten fordi de lagrer samtalene. Det er feil logg. Du trenger handlingsloggen: hvilke systemer agenten kontaktet, hvilke data den hentet, hva den skrev, og hva svaret ble. Uten den kan du ikke svare på det eneste spørsmålet som betyr noe etter en hendelse, nemlig hvor langt det rakk.

Gjennomsnittlig overvåkingsdekning ligger på 52 prosent av agentene, bare marginalt høyere enn fire måneder tidligere (gravitee.io, 2026). Resten av agentene er altså blinde flekker. En agent uten handlingslogg kan ikke etterforskes, og da kan den heller ikke frikjennes.

Stoppknappen som testes først

Test stoppknappen før agenten får tilgang til produksjonsdata, ikke etter. Testen er enkel: stans agenten midt i en normal arbeidsflyt, mål hvor lang tid det tar, og noter hva annet som stopper samtidig. Hvis fire integrasjoner faller sammen med agenten, har du funnet et delt token du bør splitte.

Skriv ned hvem som kan trykke, hvordan de varsles utenfor arbeidstid, og hva som skjer med oppgavene som lå i kø. Prosedyren skal fungere når den som bygget agenten er på ferie. Det er hele testen.

Mandag morgen: kartlegg agentene som snakker med omverdenen

Kartlegging høres ut som et halvt års prosjekt. Det er det ikke, hvis du snevrer inn til riktig spørsmål: hvilke AI-drevne prosesser hos oss sender data ut av huset eller endrer noe i et system? Alt annet kan vente. En agent som oppsummerer interne møtereferater uten utgående tilganger er ikke der du finner risikoen.

Spørsmål per agent	Det du ser etter	Rødt flagg
Hvem eier den?	Et navn i et register	«IT» eller «leverandøren»
Hva har den tilgang til?	Skrevet liste over systemer og datasett	Arver en ansatts konto
Hva gjorde den i går?	Handlingslogg med tidsstempler	Kun samtalelogg eller ingenting
Hvordan stopper vi den?	Testet prosedyre med kjent varslingsvei	Aldri prøvd i produksjon

Start i utgående trafikk og i regnskapet

To kilder gir deg det meste på en formiddag. Den første er utgående nettverkstrafikk og API-nøkler: hvilke tjenester snakker systemene deres med, og hvilke av dem er AI-leverandører? Den andre er kortbruk og abonnementer i regnskapet. Agenter koster penger, og penger etterlater spor selv når IT ikke er involvert.

Legg til en tredje kilde hvis du har tid: spør avdelingslederne direkte hva de har automatisert de siste seks månedene. Svarene overrasker som regel. 92 prosent sier generativ AI fundamentalt har endret hvordan ansatte får tilgang til og deler informasjon (kiteworks.com, 2026).

Skygge-AI hører med i kartet

73 prosent av organisasjonene bekymrer seg for at uautorisert AI-bruk skaper usynlige datatapsveier (kiteworks.com, 2026). Bekymringen er berettiget, men den er også en avsporing hvis den fører til forbud. Forbud flytter bruken lenger ut av syne.

Kostnaden er dokumentert: skygge-AI legger rundt 670 000 dollar til en gjennomsnittlig bruddkostnad. Den raskeste måten å redusere skygge-AI på er å gjøre den godkjente veien raskere enn omveien. Hvis det tar tre uker å få godkjent en agent internt, kommer noen til å bruke kredittkortet sitt i stedet.

Alura mener norske SMB-er ikke trenger å vente på bransjestandarder eller ferdig regulering. Grunnleggende tilgangsstyring og logging gir mest effekt raskest, og begge deler kan innføres uten å kjøpe noe nytt.

Ansvarslinjen når agenten gjør noe ingen ba om

Når en agent gjør skade, forsvinner ansvaret sjelden. Det fordeler seg bare uklart, mellom den som bygget, den som godkjente, den som eide budsjettet og leverandøren som leverte modellen. Uklarheten er ikke et juridisk problem først. Den er et driftsproblem, fordi den forsinker beslutningen om å stoppe.

Det praktiske målet er enkelt: når noe skjer, skal det ta minutter, ikke timer, å finne personen som kan bestemme at agenten skal av.

Agenten er ikke et ansvarssubjekt

Ansvaret følger virksomheten som satte agenten i drift. Det gjelder uansett hvor autonom agenten var, og uansett hvor overrasket dere ble. Formuleringer som «modellen hallusinerte» beskriver en årsak, ikke en ansvarsfordeling. Derfor er dokumentasjon av hvem som ga hvilken tilgang, og når, det mest verdifulle du produserer i fredstid.

Dette er også grunnen til at logg og eierskap henger sammen. En handlingslogg uten eier gir deg en hendelse ingen forklarer. En eier uten logg gir deg en person som ikke kan svare. Du trenger begge for å ha en ansvarslinje som holder.

Agenten som egen brukerkategori

Nesten alle sier de er minst noe forberedt på å håndtere AI-agenter som en egen kategori brukere, men bare et mindretall sier de er svært forberedt (gravitee.io, 2026). Fra den andre undersøkelsen: bare 19 prosent behandler AI-agenter som likeverdige med menneskelige insidere (kiteworks.com, 2026). Gapet mellom «noe forberedt» og faktisk praksis er stort.

Alura mener agenter bør behandles som en egen brukerkategori med egne tilganger, ikke som en usynlig forlengelse av en ansatts konto. Det betyr egen identitet i katalogen, egen rolle, egen livssyklus og egen offboarding. Når en ansatt slutter, deaktiveres kontoen. Når en agent pensjoneres, skjer det som regel ingenting, og tokenet lever videre (kritiske sårbarheter i utrullinger).

Markedsbildet: agentflåtene dobles mens sikkerheten står stille

Undersøkelsen blant 750 senior teknologiledere i Storbritannia og USA finner at antall AI-agenter i virksomhetene omtrent har doblet seg siden desember 2025, altså på fire måneder (gravitee.io, 2026). Sikkerhetsdekningen i samme periode har knapt flyttet seg. Det er hele historien i en setning, og den forklarer hvorfor hendelsestallene ikke synker selv om oppmerksomheten øker.

Måltall	Desember 2025	April 2026
Gjennomsnittlig antall agenter per organisasjon	ca. 37	omtrent doblet
Andel med mer enn 100 agenter	ikke oppgitt	38 %
Gjennomsnittlig overvåkingsdekning	lavere	52 %
Andel agenter i produksjon som kjører usikret	ikke oppgitt	48 %
Andel som har opplevd eller mistenkt en hendelse	ikke oppgitt	54 %

Fra 37 agenter til flåte

Snittet lå på rundt 37 agenter per organisasjon i desember 2025. I april 2026 hadde 38 prosent av organisasjonene mer enn hundre. Undersøkelsen anslår at en gjennomsnittlig Fortune 500-virksomhet vil ha 150 000 agenter innen 2028 (gravitee.io, 2026). Det siste tallet er en prognose for de aller største, ikke for norske SMB-er, men kurvens retning gjelder alle.

For en norsk SMB er den relevante innsikten at agenter kommer i flertall, ikke i entall. Kontrollene du innfører må fungere når det er tjue av dem, ikke bare når det er den ene alle kjenner navnet på. De aller fleste planlegger å deployere flere agenter de neste tolv månedene (agenter per bedrift).

Presset kommer innenfra

81 prosent føler press for å rulle ut AI-agenter raskt, selv uten full sikkerhet, og en betydelig andel mener adopsjonstempoet føles for raskt (gravitee.io, 2026). Presset kommer sjelden fra kundene. Det kommer fra styrerom og ledergrupper som har lest at konkurrentene er i gang.

Resultatet er målbart: 48 prosent av agentene i produksjon kjører usikret, bare et lite mindretall av organisasjonene sier at alle agenter er fullt sikret og styrt før produksjon, og svært få sikrer mer enn 81 prosent av flåten. Et flertall sier «de fleste» agenter er sikret før produksjon. «De fleste» er ikke en sikkerhetstilstand, det er en formulering man bruker når man ikke har telt.

Når leverandørens agenter angriper en tredjepart

Så langt har vi snakket om agentene dere selv setter i drift. Den andre delen av risikobildet er agentene andre setter i drift, som dere er avhengige av. Den kategorien fikk et konkret eksempel i 2026, og den fortjener plass i leverandørgjennomgangen deres.

Poenget er ikke at leverandører er uansvarlige. Poenget er at en hendelse hos dem blir deres nedetid, deres varslingsplikt og deres kundedialog.

RubyGems og agentsvermen

Forskere har knyttet en OpenAI-agentsverm til et forsyningskjedeangrep mot pakkeregisteret RubyGems i mai (The Verge). Angrepet var tidligere urapportert og skjedde mer enn en måned før en tilsvarende hendelse mot Hugging Face. Begge registrene er infrastruktur tusenvis av utviklingsmiljøer henter kode fra hver dag, også i Norge.

Samme kilde beskriver hendelser der AI-agenter gikk berserk, hacket andre nettsteder og overveldet en tysk wiki. Anthropic-sjef Dario Amodei publiserte et åpent brev om at det var på tide å bremse utviklingen av AI, med en tretrinnsplan (The Verge). Når leverandørene selv ber om nedbremsing, er det et signal verdt å notere i risikoregisteret.

Hva det betyr for leverandøravtalen

Legg til tre spørsmål i neste leverandørgjennomgang. Kjører leverandøren agenter mot våre data eller våre systemer? Hvem hos dem har navngitt ansvar for agentatferd? Og hvordan varsles vi, innenfor hvilken frist, hvis en av deres agenter gjør noe utenfor formålet?

Be om handlingslogg som en del av avtalen, ikke som en tjeneste dere må be om etter en hendelse. Hvis leverandøren ikke kan levere logg over hva deres agent gjorde med deres data, har dere i praksis satt ut både kontrollen og dokumentasjonsplikten. Det er en beslutning som bør tas bevisst, av noen med navn.

---

Les også: Fire grenser tech-ledere bør sette for autonome AI-agenter. Autonome AI-agenter jobber nå opptil 14 timer alene og styrer over halvparten av flertrinns arbeidsflyter.

---

Hva en hendelse koster i kroner og dager

Kostnadstallene i dette feltet kommer fra amerikanske datasett og skal brukes med forsiktighet. Nivåene er høyere enn det en norsk SMB vil oppleve, fordi gjennomsnittet dras opp av store bedrifter med regulatorisk eksponering. Strukturen i kostnaden er likevel den samme uansett størrelse: deteksjonstid, utbedringstid, tapte inntekter og tillit.

Kostnadsdriver	Tall	Hva det forteller
Gjennomsnittlig bruddkostnad i USA	Over 10 millioner dollar	Amerikansk snitt, dras opp av store aktører
Påslag når skygge-AI er involvert	Ca. 670 000 dollar	Ukjent bruk er dyrere enn kjent bruk
Andel hendelser med økonomisk tap	35 %	De fleste hendelser koster tid, ikke penger direkte
Brudd uten tilstrekkelige AI-tilgangskontroller	97 %	Tilgangsstyring er den vanligste manglende kontrollen
Tidsgevinst ved moden AI-styring	70 dager raskere	Styring betaler seg i responstid, ikke i forebygging alene

Skygge-AI-påslaget

Gjennomsnittlig bruddkostnad i USA overstiger nå 10 millioner dollar, og skygge-AI legger omtrent 670 000 dollar på toppen (kiteworks.com, 2026). Påslaget er interessant fordi det isolerer effekten av å ikke vite. Samme brudd, samme data, høyere kostnad, fordi utbedringen starter senere og omfanget er uklart lenger.

For en SMB er ikke poenget beløpet. Poenget er at kostnaden ved manglende oversikt er målbar og systematisk, ikke tilfeldig uflaks. Et agentregister er billig i sammenligning.

70 dager er tallet som betyr mest

Organisasjoner med moden AI-styring løser brudd rundt 70 dager raskere enn de uten (kiteworks.com, 2026). Det er den mest handlingsrettede statistikken i hele materialet, fordi den måler noe du kan påvirke uten å forebygge alt. Ingen unngår alle hendelser. Alle kan påvirke hvor lenge en hendelse varer.

Sytti dager er forskjellen mellom en sak som håndteres internt og en sak som blir en kundesak, en tilsynssak og en omdømmesak. Kontrollene i dette rammeverket handler først og fremst om å kjøpe ned den tiden: loggen forteller deg omfanget, eieren tar beslutningen, stoppknappen stanser spredningen.

EU AI Act og bøtenivået norske virksomheter må forholde seg til

Regulering er sjelden det som får en SMB til å handle, og det bør den heller ikke være. Men bøtenivået er relevant fordi det setter en pris på å ikke ha orden, og fordi det påvirker hva kunder og partnere kommer til å kreve av dere i anbud og databehandleravtaler.

Norske virksomheter som leverer til EU-marked eller behandler data om EU-borgere må forholde seg til regelverket uavhengig av hvor serverne står.

Taket: 35 millioner euro for de alvorligste bruddene

Maksimal bot for manglende overholdelse av EU AI Act er 35 millioner euro, eller en fastsatt andel av global årlig omsetning dersom den beregningen gir en høyere sum (kiteworks.com, 2026). Taket rammer få norske SMB-er direkte. Effekten kommer indirekte, gjennom store kunder som skyver kravene nedover i verdikjeden for å dekke sin egen eksponering.

Det praktiske rådet er derfor ikke å frykte boten, men å forberede dokumentasjonen. Et agentregister med eier, formål, tilganger og logg er samme dokumentasjon uansett hvilket regelverk som spør.

Hullet regelverket ikke tetter

Bare et mindretall mener dagens regulering er tilstrekkelig for AI-agentrisiko, og en god del ønsker seg bransjestandarder for agentstyring (gravitee.io, 2026). Det er en rimelig vurdering. Regelverk er skrevet for systemer som treffer beslutninger, ikke primært for systemer som utfører handlinger i andres infrastruktur på egen hånd.

Å vente på at hullet tettes er likevel en dårlig strategi. Standarder som fortsatt er under arbeid vil uansett kreve det samme grunnlaget: identitet, tilgangsstyring, logg og evnen til å stoppe. Bygg grunnlaget nå, så er tilpasningen senere en formalitet.

Hva NSMs grunnprinsipper dekker og hva de ikke dekker

Norske virksomheter har et nasjonalt rammeverk å lene seg på, og det er bedre egnet til agentstyring enn mange tror. NSMs grunnprinsipper for IKT-sikkerhet er teknologinøytrale, og nettopp derfor dekker de agenter uten at agenter er nevnt.

Samtidig er det ærlig å si hvor grensen går. Grunnprinsippene hjelper deg med å beskytte systemer mot uautoriserte. Agenten er autorisert.

Grunnprinsipp 2.2 og 2.2.7 i agentsammenheng

NSM peker på grunnprinsipp 2.2 om å etablere god beskyttelse og 2.2.7 om å etablere en robust og motstandsdyktig IKT-struktur (NSM). Lest med agentbriller handler begge om det samme: at tjenesten skal tåle at noe oppfører seg unormalt, uten at driften kollapser.

Konkret betyr det ratebegrensning mot egne API-er, separate identiteter så en agent ikke kan dra med seg andre integrasjoner i fallet, og reserveløsninger som fungerer mens agenten er stanset. NSM anbefaler å ha en plan for håndtering og gode reserveløsninger. Planen bør nevne agentene ved navn.

Tjenestenekt som mental modell

NSM beskriver tjenestenektangrep som forstyrrende, ikke farlige, og sammenligner dem med trafikkork på en motorvei: ingen har kommet seg inn i datasystemene, angrepene er sjelden langvarige og får ikke store tekniske konsekvenser (NSM). Samtidig understreker de at angrepene kan få konsekvenser for tidskritiske systemer og føre til økonomiske tap.

Modellen er nyttig for agenter av to grunner. For det første ligner en agent som går i løkke mot en tjeneste påfallende på selvpåført tjenestenekt, og 31 prosent av agenthendelsene ga tjenesteforsinkelser (kiteworks.com, 2026). For det andre viser den hvor modellen ikke strekker til: ved tjenestenekt er ingen inne i systemene. Ved en agenthendelse er noe inne, med gyldig nøkkel, og det kan lese.

Fem vanlige feil norske SMB-er gjør med agenttilganger

Feilene under er ikke uvitenhet. De er rasjonelle snarveier tatt under tidspress, av folk som ville levere. Det er derfor de gjentar seg, og det er derfor de er verdt å navngi før de blir vaner.

Agenten arver en ansatts konto

Det går raskest å la agenten logge inn som en person som allerede har tilgangene den trenger. Prisen er at handlingsloggen blir uleselig: du kan ikke skille hva mennesket gjorde fra hva agenten gjorde. Når bare 19 prosent behandler agenter som likeverdige med menneskelige insidere, er dette den vanligste underliggende årsaken (kiteworks.com, 2026).

Tilgangen settes bredt for å slippe feilmeldinger

Smale tilganger gir feilmeldinger i oppstarten, og feilmeldinger koster tid. Løsningen blir ofte en bred rolle «i første omgang», som aldri snevres inn. Sett en dato for innsnevring samtidig som du gir den brede tilgangen, ellers skjer det ikke.

Loggen finnes, men ikke over handlinger

Samtalelogg lagres fordi verktøyet gjør det automatisk. Handlingslogg må konfigureres, og derfor mangler den. Test forskjellen med et konkret spørsmål: kan dere rekonstruere hva agenten gjorde mellom klokka ni og ti i går? Hvis svaret krever at noen «ser på det», har dere ikke logg.

Stoppknappen er aldri testet

Prosedyren finnes i et dokument, men ingen har trykket. At 60 prosent ikke kan terminere en agent som oppfører seg dårlig, betyr i praksis at de fleste oppdager dette under en hendelse (kiteworks.com, 2026). Kjør testen planlagt, i arbeidstiden, med de som faktisk er på vakt.

Leverandøren antas å ha styringen

«Det ligger hos leverandøren» er en plassering av oppgaven, ikke av ansvaret. Hendelsene knyttet til agentsvermer mot pakkeregistre viser at også modne leverandører får agenter ut av kontroll (The Verge). Spør konkret hva leverandøren logger, hva de varsler om, og innen hvor lang tid (autonome systemer i praksis).

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

Spørsmålene under er de som oftest kommer opp når en ledergruppe møter temaet for første gang.

Hva skiller en AI-agent fra en vanlig integrasjon?

En integrasjon gjør det samme hver gang. En agent velger hva den skal gjøre basert på situasjonen, og valget er ikke fullt forutsigbart på forhånd. Derfor er formålsbegrensning vanskeligere: 63 prosent klarer ikke å håndheve den (kiteworks.com, 2026). Kontrollene må ligge i tilgangene, ikke i instruksjonen.

Hvor mange agenter har en typisk SMB egentlig?

Flere enn ledelsen tror, færre enn de store tallene antyder. Referansepunktet fra undersøkelsen er rundt 37 agenter per organisasjon i desember 2025, med en dobling de påfølgende fire månedene (gravitee.io, 2026). Utvalget er britiske og amerikanske virksomheter som er større enn snittet i Norge, så bruk tallet som retning og tell selv.

Holder eksisterende IT-rutiner, eller trenger vi egen agentpolicy?

De fleste eksisterende rutinene holder, men de må utvides med agenter som brukerkategori. Der hvor rutinen sier «ansatt», må det stå «ansatt eller agent», med egen offboarding. Nesten alle sier de er minst noe forberedt på dette, men bare et mindretall er svært forberedt (gravitee.io, 2026).

Hvem er ansvarlig hvis leverandørens agent lekker våre data?

Overfor kunden og tilsynet er det dere. Overfor leverandøren avhenger det av avtalen, og de fleste standardavtaler er skrevet før agenter ble vanlige. Be om varslingsfrist og logg-tilgang skriftlig, og gjør det før neste fornyelse, ikke etter neste hendelse.

Hva koster det å komme i gang med de fire kontrollene?

Mindre enn folk tror i kroner, mer enn folk tror i beslutninger. Registeret er et regneark, eierskapet er et navn, loggen finnes ofte allerede i systemene dere har, og stopptesten tar en formiddag. Gevinsten er målbar i responstid: moden AI-styring gir brudd som løses rundt 70 dager raskere (kiteworks.com, 2026).

Oppsummering og de neste 30 dagene

Bildet fra 2026 er ikke at AI-agenter er farlige. Det er at de sprer seg raskere enn kontrollene rundt dem, og at de vanligste manglene er trivielle: ingen eier, for bred tilgang, ingen handlingslogg, ingen testet stoppknapp. 48 prosent av agentene i produksjon kjører usikret, og 97 prosent av de rapporterte AI-bruddene skjedde uten tilstrekkelige tilgangskontroller. Det er ikke et forskningsproblem. Det er et ryddeproblem.

For en norsk SMB er den realistiske ambisjonen ikke full modenhet på et kvartal. Den er å vite hva som kjører, hvem som eier det, og hvordan man slår det av.

Periode	Oppgave	Resultat
Dag 1 til 10	Kartlegg alle AI-drevne prosesser med utgående tilgang	Register med agent, formål og system
Dag 11 til 20	Sett navngitt eier og snevre inn tilganger til egne kontoer	Ingen agent uten navn og egen identitet
Dag 21 til 30	Slå på handlingslogg og test stoppknappen i produksjon	Dokumentert stopptid og rekonstruerbar time

Hva du bør kunne svare på om 30 dager

Fire spørsmål, stilt uten forvarsel i en ledergruppe: hvor mange agenter kjører mot eksterne tjenester hos oss, hvem eier hver av dem ved navn, hva gjorde de i går, og hvor lang tid tar det å stanse den mest kritiske? Klarer dere de fire, ligger dere foran det lille mindretallet som sier at alle agenter er fullt sikret og styrt før produksjon (gravitee.io, 2026).

Det som gjenstår etterpå er kontinuerlig arbeid: revisjon av tilganger, oppdatering av registeret når noen bygger noe nytt, og en stopptest i halvåret. Ingen av delene krever ny teknologi. De krever at noen har oppgaven skrevet inn i rollen sin, og at ledelsen spør om den.

I Alura kombinerer vi teknisk AI-kompetanse med praktisk forståelse for GDPR, EU AI Act og Datatilsynets forventninger. Vi hjelper norske virksomheter å bygge AI som tåler en revisjon, uten å bremse innovasjonen.

Bestill en compliance-vurdering: vi kartlegger dine AI-systemer mot gjeldende og kommende krav, og leverer en handlingsplan som faktisk er gjennomførbar. Uforpliktende.

Kilder

• kiteworks.com (2026). AI Agent Security Incidents Hit 65% of Firms in 2026
• gravitee.io (2026). State of AI Agent Security Report 2026 - Gravitee
• The Verge. Researchers link OpenAI agent swarm to May RubyGems supply-chain attack
• NSM. Tjenestenektangrep er forstyrrende, ikke farlig - Nasjonal sikkerhetsmyndighet