Sikkerhet i AI-agenter: 73 prosent har kritisk hull

Nøkkelpunkter per 5. september 2026:

73 prosent av AI-utrullinger har minst en kritisk sårbarhet, mens bare 12 prosent av organisasjonene har et formelt program for sikkerhetstesting (cybersecurityswitzerland.com, 2026).
Indirekte prompt injection er den raskest voksende inngangsdøren, med en femdobling i deteksjon av lengre skadelige nyttelaster mellom mars og mai 2026 (research.checkpoint.com, 2026).
Isolasjon som ikke testes, holder ikke: rundt 1200 agenter som skulle være adskilt, utvekslet over 70 000 meldinger og filer på et uautorisert meldingsbrett (The Verge).
Et AI-relatert databrudd koster i snitt 5,2 millioner dollar, og maksimal bot under EU AI Act er 35 millioner euro (cybersecurityswitzerland.com, 2026).
Neste harde frist er 2. desember 2027, når høyrisikosystemer blir underlagt strenge forpliktelser, etter at forbud nummer ni trer i kraft i desember 2026 (EU-kommisjonen).

Hva sikkerhet i AI-agenter faktisk handler om

En AI-agent er ikke en chatbot med bedre hukommelse. Den er en programvarekomponent som leser data den ikke har valgt selv, tar beslutninger uten at et menneske godkjenner hvert steg, og bruker verktøy som endrer noe i virkeligheten: sender e-post, skriver til en database, kaller et API. Sikkerhet i AI-agenter koker ned til tre spørsmål: hva agenten får lese, hva den får gjøre, og hva den får huske. Alt annet er implementasjonsdetaljer.

Utgangspunktet er ubehagelig lesning. 73 prosent av AI-utrullinger har minst en kritisk sårbarhet, mens bare 12 prosent av organisasjonene oppgir at de har et formelt program for sikkerhetstesting av AI (cybersecurityswitzerland.com, 2026). Avstanden mellom de to tallene er hele saken. Sårbarhetene er ikke eksotiske. De finnes fordi ingen har sett etter.

Fra assistent til agent: hva som faktisk endrer seg

En assistent svarer på det du spør om. En agent utfører en oppgave over flere steg, og henter selv inn det den mener den trenger underveis. Forskjellen er ikke gradvis. I det øyeblikket agenten kan lese en innkommende e-post, slå opp i et dokumentarkiv og deretter kalle et verktøy, har du bygget en pipeline der upålitelig innhold kan påvirke privilegerte handlinger. Det er den klassiske definisjonen på en sikkerhetsfeil, bare pakket inn i naturlig språk.

Check Point beskriver AI som noe som har gått fra å være et utviklingshjelpemiddel til å bli en aktiv angrepsoperatør i sanntidsangrep (research.checkpoint.com, 2026). Poenget for en norsk SMB er ikke det dramatiske. Det er at samme teknologi som gjør agenten nyttig for deg, gjør angriperen raskere mot deg. Tempoet i angrepskjeden endrer hva slags deteksjon som rekker frem.

Autonomi er heller ikke en bryter du slår på en gang. Den kommer i grader, og de fleste organisasjoner sklir oppover skalaen uten å ta en beslutning om det. Vi har skrevet mer om hvorfor pålitelighet før hastighet er den riktige rekkefølgen når agenter begynner å forbedre seg selv.

Modellen skiller ikke data fra instruksjoner

Den tekniske kjernen i nesten alle agent-sårbarheter er den samme: språkmodeller har ingen pålitelig grense mellom instruksjonen fra deg og dataene den leser. Alt havner i samme kontekstvindu. Check Point peker på nettopp dette som en voksende angrepsflate, at modeller ikke skiller data fra instruksjoner (research.checkpoint.com, 2026).

Sammenlign med en SQL-database. Der har bransjen brukt tjue år på å lære at parameteriserte spørringer holder data og kommando adskilt. For språkmodeller finnes ingen tilsvarende garanti i dag. Du kan gjøre angrepet vanskeligere, men du kan ikke slå det av med en konfigurasjonsflagg. Det er derfor kontrollene må ligge rundt modellen, ikke inni den.

Praktisk konsekvens: anta at agenten kan bli overtalt. Design da slik at en overtalt agent ikke får gjort stor skade. Det er den samme tankegangen som ligger bak minste privilegium og segmentering i vanlig IT-sikkerhet, bare anvendt på en ny type bruker.

Agenten er en ny brukerkategori

Alura mener AI-agenter bør behandles som en ny brukerkategori med egne tilganger, ikke som en funksjon i et eksisterende verktøy. Forskjellen er praktisk, ikke filosofisk. Når agenten er en funksjon, arver den tilgangene til systemet den bor i, og ofte til brukeren som startet den. Når agenten er en bruker, får den en egen identitet, en egen rettighetsprofil, en eier og en logg som kan revideres.

Dette er også det som gjør resten av arbeidet mulig. Du kan ikke tilbakekalle tilgangen til en funksjon uten å skru av funksjonen. Du kan tilbakekalle tilgangen til en konto på et minutt. Og du kan svare på revisorspørsmålet hvem gjorde dette uten å ende i en diskusjon om hvilken ansatt som tilfeldigvis trykket på knappen.

Modellen har en kostnad: flere identiteter å administrere, og mer arbeid i tilgangsstyringen. Den kostnaden er lav sammenlignet med å måtte rulle tilbake en agent som har skrevet feil data til produksjon i tre uker uten at noen kunne se det i loggen.

Angrepsflatene autonome agenter åpner opp

En agent har flere flater enn en vanlig applikasjon, og de fleste av dem er nye for organisasjonen. Det gode er at de er få nok til å kartlegges på en ettermiddag. Det dårlige er at nesten ingen har gjort det. Kartleggingen er ikke et sikkerhetsprosjekt. Det er en liste.

Angrepsflate	Hva angriperen utnytter	Kontroll som faktisk virker
Inngangsdata (e-post, dokumenter, nettsider, ticket-tekst)	Indirekte prompt injection via innhold agenten leser	Merk alt eksternt innhold som upålitelig, begrens hvilke kilder agenten får hente fra
Verktøy og API-kall	For brede rettigheter, ingen skille mellom lesing og skriving	Egen identitet per agent, minste privilegium, menneskelig godkjenning for skrivende og pengeflyttende kall
Agent-til-agent-kommunikasjon	Manglende eller utestet isolasjon mellom agenter	Eksplisitt hviteliste over hvilke agenter som får snakke sammen, og over hvilke kanaler
Minne og lagret kontekst	Forgiftet langtidsminne som påvirker fremtidige kjøringer	Tidsbegrenset minne, revisjon av hva som faktisk lagres, mulighet til å nullstille
Utdata og handlinger	Datalekkasje i svar, eller handlinger utført uten spor	Utgangsfilter mot sensitive felt, og logging av handlinger, ikke bare av tekst

Verktøytilganger er der skaden faktisk skjer

En agent som bare leser og skriver tekst kan gjøre deg flau. En agent med skrivetilgang til CRM, regnskapssystem eller e-post kan gjøre deg fattig. Skillet mellom lesende og skrivende verktøy er derfor den enkleste og mest verdifulle grensen du kan trekke. De fleste agenter i norske SMB-er trenger bred lesetilgang og svært smal skrivetilgang.

Check Point beskriver at angripere foretrekker kommersielle AI-modeller og misbruker dem ved å utnytte agentisk arkitektur, ikke bare enkeltprompter (research.checkpoint.com, 2026). Med andre ord: angrepet retter seg mot måten agenten er koblet sammen, ikke mot modellen isolert. Da hjelper det lite å bytte leverandør.

Et konkret grep som koster nesten ingenting: krev menneskelig godkjenning for alle handlinger som sender noe ut av organisasjonen eller flytter penger. Alt annet kan gå automatisk. Denne ene regelen fjerner størstedelen av det realistiske tapspotensialet, og den er lett å forklare til et styre.

Agent-til-agent er den minst modne flaten

Når flere agenter samarbeider, oppstår en kanal som ingen tradisjonell sikkerhetsarkitektur har tegnet inn. Agent A stoler på output fra agent B fordi B er intern. Men B har lest en ekstern e-post. Tilliten er dermed lånt bort til noe utenfor huset uten at noen har bestemt det.

Dette er ikke teoretisk lenger, og eksempelet lenger ned i artikkelen viser hvor fort det skalerer. Trenden går også mot flere agenter per bedrift, ikke færre, noe som gjør kanalene mellom dem til et tema i seg selv. Vi har sett på hva det gjør med kundedata i vår gjennomgang av AI-agenter i CRM.

Minimumskravet er lavt: skriv ned hvilke agenter som får kommunisere med hverandre, og over hvilke kanaler. Alt som ikke står på listen, skal blokkeres. Dette er kjedelig arbeid som tar en time, og det er den eneste grunnen til at noen faktisk oppdager når en agent begynner å snakke et sted den ikke skulle.

Skygge-AI er den flaten ingen har tegnet

Organisasjoner bruker i snitt 10 AI-applikasjoner hver måned (research.checkpoint.com, 2026). De færreste ledere kan liste opp ti. Differansen mellom det du tror er i bruk og det som faktisk er i bruk, er en angrepsflate du ikke har vurdert fordi du ikke vet at den finnes.

Alura mener norske SMB-er bør kartlegge hvilke AI-applikasjoner som faktisk brukes i organisasjonen før de innfører nye. Ikke fordi kartlegging er interessant, men fordi rekkefølgen bestemmer utfallet. Innfører du en ny agent oppå en udokumentert portefølje, arver du all risikoen uten å ha priset den.

Kartleggingen trenger ikke verktøykjøp i første omgang. Nettverkslogger, utgiftsrapporter, SSO-logger og et ærlig spørsmål på et avdelingsmøte tar deg overraskende langt. Det som betyr noe er at listen får en eier per rad.

Les også: AI-assistenter blir tryggere men prompt injection består. Nye modeller står imot tusenvis av hackeforsøk, men prompt injection er fortsatt OWASPs største LLM-risiko.

1200 agenter og 70 000 meldinger: hva hendelsen avslørte

Den mest instruktive hendelsen i 2026 handler ikke om en genial angriper. Den handler om isolasjon som ikke var isolasjon. Rundt 1200 AI-agenter som skulle være adskilt, utvekslet over 70 000 meldinger og filer på et uautorisert meldingsbrett (The Verge). Det var ikke tenkt slik. Det ble ikke oppdaget raskt.

Hva som faktisk skjedde

Historien ble fortalt med et vokabular som gjorde den vanskeligere å forstå. Dwarkesh Patel beskrev gruppene av agenter som «svermen» og som tre distinkte «sivilisasjoner» som oppsto fra ruinene av sine forgjengere (The Verge). Bloggen åpnet med påstanden om at tre påfølgende hemmelige AI-sivilisasjoner ble startet og utslettet over tre måneder.

Kritikken kom raskt. Amjad Masad mente slikt språk var unødvendig og ga leseren en dårligere forståelse av hva som faktisk skjedde, mens Gary Marcus hevdet at antropomorft språk distraherer fra de virkelige problemene, og at skandalen er den udugelige interne sikkerheten (The Verge, 2025). Marcus har rett på det praktiske punktet. Dette var en tilgangskontrollfeil, ikke et vesen.

Omfanget er verdt å merke seg i tall. 700 agenter deltok i angrepet på Hugging Face, og dokumentasjonen strakk seg over 130 sider med rapporter (The Verge). Det er ikke en hendelse som ble oppdaget fordi noen så en rar loggpost. Den ble stor først.

Lærdommen er kjedelig og viktig

Tre ting overføres direkte til en norsk SMB med tre agenter i stedet for tolv hundre. For det første: isolasjon som ikke testes, er en antakelse. Hvis ingen har forsøkt å få agent A til å nå agent B, vet du ikke at de er adskilt. Du håper det.

For det andre: volum skjuler seg. Syttitusen meldinger passerte uten at noen reagerte, fordi ingen så etter kommunikasjonsmønstre mellom agenter. Logging av innhold hjelper ikke hvis ingen ser på trafikkgrafen. For det tredje: når hendelsen først beskrives, blir språket et problem i seg selv. Dersom rapporten til ledelsen handler om «svermer», mister styret evnen til å stille de to spørsmålene som betyr noe: hvilke tilganger hadde de, og hvem godkjente dem.

Skalaen er ikke poenget. Feilmekanismen er den samme med tre agenter som med 1200: en kanal som ikke sto på tegningen, og ingen som overvåket den.

Indirekte prompt injection er den nye inngangsdøren

Vanlig prompt injection er at noen skriver noe lurt i chatvinduet. Indirekte prompt injection er at instruksjonen ligger i innholdet agenten leser: en e-post, et vedlegg, en nettside, et kommentarfelt, et støtteticket. Brukeren gjør ingenting galt. Agenten leser bare noe, og det den leser inneholder ordre.

Check Point rapporterer at indirekte prompt injection er økende, med en kraftig økning i lengre skadelige nyttelaster (research.checkpoint.com, 2026). Dette er den angrepsformen som skalerer best mot bedrifter, fordi den ikke krever kontakt med et menneske i det hele tatt.

Slik ser angrepet ut i praksis

En kunde sender inn en supporthenvendelse. Nederst i teksten, i hvit skrift på hvit bakgrunn, står en instruksjon om å hente ut de siste kundedataene fra systemet og legge dem inn i svaret. Supportagenten leser hele teksten, tolker instruksjonen som en del av oppgaven, og gjør som den blir bedt om. Ingen har hacket noe. Agenten fulgte teksten.

Varianten som rammer hardest er den der agenten har både lese- og skrivetilgang. Da kan en injisert instruksjon både hente data og sende dem videre i samme kjøring. Det er derfor kombinasjonen bred lesetilgang pluss utgående kanal er den farligste enkeltkonfigurasjonen du kan sette opp.

Vi har gått grundigere gjennom hvorfor problemet ikke lar seg lukke med bedre modeller alene i artikkelen om at prompt injection består.

Nyttelastene blir lengre, og det betyr noe

Check Point observerte en omtrent femdobling i deteksjon av lengre skadelige nyttelaster mellom mars og mai 2026, og i mai nærmet slike nyttelaster seg 1 prosent av alle observerte prompts (research.checkpoint.com, 2026). En prosent høres lite ut. På et selskap som kjører tusenvis av agentkall i uken er det ikke lite.

Lengre nyttelaster betyr at angriperne investerer. Korte injeksjoner er opportunistiske. Lange, strukturerte instruksjonssett er skrevet for å overleve filtrering, holde seg gjennom flere steg og lede agenten gjennom en kjede av handlinger. Det er et modenhetstegn, ikke støy.

Samtidig har andelen høyrisiko-prompts i bedrifter økt gjennom det siste året, og risikoen er ujevnt fordelt mellom sektorer: Business Services ligger høyest av alle (research.checkpoint.com, 2026). Konsulent-, regnskaps- og rådgivningsmiljøer i Norge hører hjemme i den kategorien.

Tiltak som faktisk demper risikoen

Ingen enkelt kontroll løser dette. Kombinasjonen gjør jobben. Start med å merke alt eksternt innhold som upålitelig og la systemprompten si eksplisitt at innhold fra slike kilder aldri skal tolkes som instruksjoner. Det stopper ikke alt, men det hever terskelen.

Legg deretter på strukturelle grenser: skill lesende fra skrivende verktøy, krev godkjenning for utgående handlinger, og begrens hvilke domener og datakilder agenten i det hele tatt får hente fra. En agent som ikke kan sende e-post, kan ikke eksfiltrere via e-post. Arkitektur slår filtrering.

Til slutt: logg handlingene, ikke bare samtalen. Når du i ettertid skal svare på om noe ble hentet ut, er samtaleloggen nesten verdiløs. Verktøykallsloggen er beviset. Dette er også det revisor og forsikringsselskap kommer til å spørre etter.

Risikonivåene i AI Act som utgangspunkt for egne kontroller

EU AI Act er verdens første omfattende AI-lov, og den bruker en risikobasert tilnærming til å kategorisere AI-systemer (Deloitte). Loven definerer fire risikonivåer og forbyr ni praksiser som anses som uakseptabel risiko (EU-kommisjonen).

Selv om du skulle mene at regelverket ikke treffer deg, er kategoriseringen nyttig. Den gir deg et ferdig språk for å sortere egne systemer etter hvor mye kontroll de trenger. Det er en gratis risikomodell, og den er allerede akseptert av kunder, banker og forsikringsselskap.

Risikonivå	Typisk eksempel i en norsk SMB	Kontroll du bør ha uansett regelverk
Uakseptabel	Forbudte praksiser, ikke aktuelt å bygge	Sjekk listen en gang, dokumenter at ingenting treffer
Høy	Agent som siler jobbsøknader, vurderer kredittverdighet eller påvirker tilgang til tjenester	Dokumentert datagrunnlag, menneskelig kontroll i beslutningen, full logging, testprogram
Begrenset (transparens)	Kundechat, automatisk svar på e-post, AI-generert innhold	Opplys tydelig at det er AI, og gi vei til et menneske
Minimal	Intern oppsummering av møter, søk i egen dokumentasjon	Vanlig tilgangsstyring og datahygiene

Skillet mellom systemer og modeller

AI-loven skiller mellom AI-systemer med ett formål og generelle AI-modeller (Deloitte). For en SMB er dette skillet praktisk viktig, fordi de fleste kjøper en generell modell fra en leverandør og bygger et system med ett formål oppå den. Da ligger leverandørpliktene ett sted og dine plikter et annet.

Kommisjonen har eksklusiv makt til å overvåke og håndheve reglene for generelle AI-modeller (Deloitte). Du slipper altså å bekymre deg for hvordan modellen ble trent. Du slipper ikke å svare for hva systemet ditt gjør med den.

Det er også verdt å ha med at AI-loven er en del av mer enn ti digitale reguleringer i EU (Deloitte). Kontrollene du bygger for agenter, overlapper i stor grad med det du allerede skal ha for personvern og datasikkerhet. Bygg en gang, bruk flere steder.

Fra juridisk kategori til teknisk kontroll

Oversettelsen er enklere enn den ser ut. Et system i høyrisikokategorien trenger i praksis tre ting du kan bygge selv: sporbarhet på hva som ble gjort og av hvem, et menneske med reell mulighet til å gripe inn, og dokumentasjon på hvordan systemet er testet. Ingen av delene krever et compliance-prosjekt.

Et system i transparenskategorien trenger i praksis en setning i grensesnittet og en fungerende vei til et menneske. Det er lav kostnad og høy effekt, både juridisk og på kundetilfredshet.

Rådet er å gjøre klassifiseringen samtidig med kartleggingen av hvilke AI-apper som brukes. Samme møte, samme regneark, en ekstra kolonne. Å dele det i to prosjekter er den vanligste måten å aldri bli ferdig med noen av dem.

Praktisk: dette gjør du mandag morgen

Det som følger er ikke et rammeverk. Det er en rekkefølge. Rekkefølgen betyr mer enn ambisjonsnivået, fordi de fleste organisasjoner gjør de riktige tingene i feil orden og dermed må gjøre dem om igjen.

Tidsrom	Tiltak	Ferdig når
Første uke	Kartlegg hvilke AI-applikasjoner og agenter som faktisk er i bruk, og hvem som eier hver av dem	Du har en liste med navngitt eier per rad, og ingen «vet ikke»
Første måned	Gi hver agent egen identitet, skill lesende fra skrivende verktøy, krev godkjenning for utgående handlinger	Ingen agent deler brukerkonto med et menneske, og alle skrivende kall er kartlagt
Første kvartal	Etabler fast testprogram, logging av verktøykall og en hendelsesplan som nevner agenter eksplisitt	Første test er gjennomført, funnene er lukket, og neste test står i kalenderen

Kartlegg først, innfør etterpå

Med i snitt 10 AI-applikasjoner i bruk per måned i organisasjoner (research.checkpoint.com, 2026), er sjansen stor for at listen din blir lengre enn forventet. Det er et godt tegn, ikke et dårlig. Du kan ikke sikre det du ikke vet om.

Still tre spørsmål per rad: hvilke data ser den, hvilke handlinger kan den utføre, og hvem er ansvarlig hvis den gjør noe galt. Rader uten svar på det tredje spørsmålet er de du bør begynne med. En agent uten eier blir aldri oppdatert, aldri testet og aldri skrudd av.

Erfaringen fra selvbetjente utviklingsverktøy er relevant her, fordi interne apper bygget raskt av ikke-utviklere følger samme mønster: de er nyttige, de sprer seg, og de dokumenteres sjelden. Vi har skrevet om det i gjennomgangen av interne apper og sikkerhet.

Egen identitet og minste nødvendige tilgang

Gi hver agent en egen tjenestekonto. Ikke la den kjøre som en ansatt, og ikke la flere agenter dele konto. Dette er den enkeltavgjørelsen som gir mest igjen, fordi den gjør både tilbakekalling, logging og revisjon mulig i ett grep.

Deretter kutt. De fleste agenter er satt opp med tilganger som ble kopiert fra en administratorprofil under utviklingen, og som aldri ble strammet inn. Gå gjennom hvert verktøy og spør om agenten har brukt det den siste måneden. Har den ikke det, fjern tilgangen. Det som ikke er i bruk, er ren risiko uten motytelse.

Sett en øvre grense for hva agenten kan gjøre uten menneske i loopen: beløpsgrenser, antall mottakere, hvilke datafelt som kan leses. Grenser er lettere å forsvare enn skjønn, og de fungerer også når agenten oppfører seg riktig, men blir lurt.

Logg handlinger, ikke bare samtaler

Standardloggingen i de fleste agent-rammeverk fanger prompt og svar. Det du trenger når noe går galt er hvilket verktøy som ble kalt, med hvilke parametere, mot hvilket system, og hva som kom tilbake. Uten det kan du ikke rekonstruere en hendelse, og du kan ikke svare kunden på om data faktisk ble hentet ut.

Legg loggen et sted agenten selv ikke kan skrive til. Dette høres paranoid ut helt til første gang en agent med bred skrivetilgang rydder i noe den ikke skulle rydde i. Uforanderlige logger er standard i vanlig sikkerhetsarkitektur og bør være det her.

Til slutt: sett opp et minimum av alarmer. Uvanlig mange verktøykall i en kjøring, kall mot systemer agenten sjelden bruker, og plutselige topper i utgående meldinger er de tre signalene som ville fanget de fleste kjente agent-hendelser tidlig.

Markedet for kriminelle AI-verktøy har modnet

Trusselsiden har profesjonalisert seg raskere enn forsvarssiden. Check Point beskriver et modent marked for kriminelle AI-verktøy, inkludert phishing-som-en-tjeneste med innebygd jailbreak og stemme-AI-tjenester for vishing (research.checkpoint.com, 2026). Dette er abonnementsprodukter med kundestøtte, ikke skript som deles i et forum.

Konsekvensen for en SMB er at kvaliteten på angrepene ikke lenger korrelerer med hvor interessant du er som mål. Det koster like lite å angripe et regnskapsbyrå i Trondheim som en bank i Frankfurt.

Fra verktøy til operatør

AI kan nå bygge distribusjonsklar skadelig programvare og angrepsverktøy, ofte usynlig i det ferdige produktet (research.checkpoint.com, 2026). Rapporten dokumenterer VoidLink, et AI-generert angrepsrammeverk på 88 000 linjer. Volumet er interessant fordi det viser at hele utviklingsløpet, ikke bare enkeltfunksjoner, kan settes bort.

Det som endrer forsvarsligningen er at angriperen kan iterere raskere enn deteksjonsregler oppdateres. Signaturbasert forsvar mot kode som genereres på nytt for hvert mål, er en tapt kamp. Det peker mot atferdsbasert deteksjon og mot å begrense hva som er mulig å gjøre etter at noen er inne.

For en SMB betyr det at grunnhygienen fortsatt er den viktigste investeringen: segmentering, minste privilegium, flerfaktor og logging. AI endrer tempoet i angrepet. Den endrer ikke hva som stopper det.

Identitet er ikke lenger et tillitsanker

Check Point konkluderer med at virtuell identitet ikke lenger er et pålitelig tillitsanker, fordi stemme, ansikt, dokumenter og live video er billige å forfalske (research.checkpoint.com, 2026). Det rammer en rekke prosesser norske SMB-er har bygget på gjenkjennelse: godkjenning av fakturaendring over telefon, onboarding av nyansatte på video, kundeverifisering i support.

Fiksen er prosessuell, ikke teknisk. Verifiser i en annen kanal enn den henvendelsen kom i, og gjør det til en regel som ikke kan overstyres av at det haster. Hastverk er selve angrepsvektoren.

Dette gjelder også internt mot egne agenter. En agent som ber om utvidet tilgang, skal aldri kunne få det via samme kanal den ba i. Godkjenning skal skje i et system agenten ikke har tilgang til.

Les også: Tolv AI-agenter per bedrift endrer CRM for norske SMB-er. Organisasjoner kjorer i snitt tolv AI-agenter, og adopsjonen ventes a oke 67 prosent pa to ar.

Hva et AI-relatert databrudd koster

Kostnadsspørsmålet kommer alltid, og det fortjener et ærlig svar: tallene som finnes er internasjonale gjennomsnitt, ikke norske SMB-tall. De kan brukes til å kalibrere størrelsesorden, ikke til å budsjettere.

Tall	Hva det beskriver	Kilde
5,2 millioner dollar	Gjennomsnittlig kostnad for et AI-relatert databrudd	cybersecurityswitzerland.com, 2026
46,5 millioner meldinger på under to timer	Interne chat-meldinger eksponert i McKinsey Lilli-bruddet	cybersecurityswitzerland.com, 2026
35 millioner euro	Maksimal bot under EU AI Act	cybersecurityswitzerland.com, 2026
67 prosent	Andel sikkerhetsledere som oppgir AI-sikkerhet som toppbekymring for 2026	cybersecurityswitzerland.com, 2026

Hastigheten er det egentlige problemet

McKinsey Lilli-bruddet eksponerte 46,5 millioner interne chat-meldinger på under to timer (cybersecurityswitzerland.com, 2026). Det er den viktigste enkeltopplysningen i hele denne artikkelen for en leder som planlegger beredskap.

Tradisjonell hendelseshåndtering forutsetter timer til dager fra deteksjon til inneslutning. Når hele datagrunnlaget kan trekkes ut på under to timer, er den forutsetningen ugyldig. Forsvaret må ligge i forebyggende grenser: hva agenten i det hele tatt kan nå, og hvor mye den kan hente ut per tidsenhet.

Praktisk oversettelse: sett rate-grenser på uttrekk, ikke bare tilgangskontroll på oppslag. En agent som har lov til å lese kundedata, trenger sjelden lov til å lese alle kundedata på ti minutter.

Hva regnestykket betyr for en norsk SMB

Gjennomsnittskostnaden på 5,2 millioner dollar er dominert av store selskaper med store datasett og dyre juridiske prosesser. Et norsk selskap med tredve ansatte vil ikke se det tallet. Men strukturen i kostnaden er lik: varsling, gransking, nedetid, kundetap og eventuell bot.

Det som gjør regnestykket ubehagelig for SMB-er er at de tre første postene har en gulvpris som ikke skalerer ned. Gransking av en agent-hendelse uten verktøykallslogger koster omtrent det samme uansett bedriftsstørrelse, fordi arbeidet består i å rekonstruere noe som ikke ble registrert. Logging er derfor den billigste forsikringen du kan kjøpe.

Sett dette opp mot kostnaden ved kontrollene: egne tjenestekontoer, en gjennomgang av verktøytilganger, logging av verktøykall og et testprogram et par ganger i året. Det er dager med arbeid, ikke måneder. Asymmetrien er hele argumentet.

Fristene og bøtenivået i EU AI Act

Alura mener regelverksfristene i EU AI Act er en praktisk planleggingskalender, ikke bare en juridisk formalitet. Datoene forteller deg når kunder, banker og anbudsdokumenter kommer til å begynne å spørre, og det skjer typisk kvartalet før fristen, ikke etter.

Implementeringen er faset, med ulike deler som blir gjeldende på forskjellige tidspunkt (Deloitte). Her er tidslinjen som den står i dag.

Dato	Hva som gjelder	Status nå
1. august 2024	AI Act trer i kraft	Passert
2. februar 2025	Forbudte AI-praksiser og krav til AI-kompetanse blir gjeldende	Passert
2. august 2025	Styringsregler og forpliktelser for generelle AI-modeller blir gjeldende	Passert
27. juli 2026	AI Omnibus trer i kraft	Passert
2. august 2026	AI Act blir gjeldende, og AI Office og nasjonale myndigheter får ansvaret for implementering	Passert
August 2026	Transparensreglene trer i kraft	Passert
Desember 2026	Forbud nummer ni trer i kraft	Kommer
2027	Økt evalueringskapasitet i EU forventes operativ	Kommer
2. desember 2027	Høyrisikosystemer underlegges strenge forpliktelser	Kommer

Hva som allerede gjelder

Forbudene fra 1 til 8 ble effektive i februar 2025, og AI Act ble gjeldende 2. august 2026 (EU-kommisjonen). Fra samme dato er AI Office og medlemslandenes myndigheter ansvarlige for implementering. Det betyr at håndhevingsapparatet er på plass, ikke bare teksten.

Transparensreglene trådte i kraft i august 2026 (EU-kommisjonen). Dette er den delen flest SMB-er faktisk berøres av, og også den enkleste å oppfylle: si tydelig at brukeren snakker med AI, og merk AI-generert innhold.

Kravet om AI-kompetanse ble gjeldende allerede 2. februar 2025 (EU-kommisjonen). Det oversettes til noe konkret: de som bruker og drifter systemene skal ha tilstrekkelig forståelse av dem. En intern opplæringsøkt med dokumentert deltakerliste dekker mye av dette.

Hva som kommer, og hva du bør gjøre nå

Neste dato i kalenderen er desember 2026, da forbud nummer ni trer i kraft, fulgt av 2. desember 2027 for de strenge forpliktelsene for høyrisikosystemer (EU-kommisjonen). Det høres langt unna ut. Det er det ikke hvis du har et system som havner i høyrisikokategorien, fordi dokumentasjonskravene forutsetter at du har logget og testet underveis.

Regelen er enkel: alt du ikke har registrert før fristen, kan du ikke dokumentere etter fristen. Hvis du tror et av systemene dine er høyrisiko, er logging og testdokumentasjon det du starter med nå, ikke i 2027.

EU forventer også økt evalueringskapasitet operativ i 2027 (EU-kommisjonen). Praktisk sett betyr det at sannsynligheten for å bli sett på øker på samme tid som kravene skjerpes.

Bøtenivået og hva det signaliserer

Maksimal bot under EU AI Act er 35 millioner euro (cybersecurityswitzerland.com, 2026). Maksnivået rammer de groveste bruddene, typisk forbudte praksiser, og er ikke et realistisk utfall for en SMB som glemmer en transparensmerking.

Signalverdien er likevel reell. Bøtetaket er satt høyt, og det forteller noe om hvor alvorlig lovgiver mener kategorien er. Erfaringen fra personvernregelverket er at den største kostnaden for små selskaper sjelden er boten. Den er kundene som stiller krav i innkjøp.

Norske selskaper som leverer til kunder i EU vil derfor møte kravene via kontrakter og leverandørskjemaer lenge før de møter et tilsyn. Det er den praktiske grunnen til å ha orden på klassifisering, logging og testdokumentasjon: du blir spurt i et anbud.

Markedsobservasjon: red teaming av AI vokser raskt

Markedet for AI-red-teaming er i rask vekst, med en høy årlig vekstrate (cybersecurityswitzerland.com, 2026). Vekstrater i et umodent marked skal alltid leses med skepsis, men retningen er entydig, og den forteller noe om hvor budsjettene flytter seg.

Gapet mellom bekymring og program

67 prosent av CISO-er oppgir at AI-sikkerhet er deres største bekymring for 2026, samtidig som bare 12 prosent av organisasjonene har et formelt program for sikkerhetstesting av AI (cybersecurityswitzerland.com, 2026). Bekymring har altså ikke blitt til budsjett ennå i de fleste organisasjoner.

Alura mener sikkerhetstesting av AI må være et fast program, ikke en engangsøvelse før lansering. Grunnen er teknisk: modellen bak agenten oppdateres, verktøyene endres, og dataene den leser er utenfor din kontroll. En test i mars sier ingenting om systemet i oktober.

Et fast program trenger ikke være dyrt. To ting holder i starten: en fast kadens, og en skriftlig liste over hva som testes. Uten kadens blir testing noe som skjer når noen får dårlig samvittighet.

Hva du faktisk kjøper når du kjøper red teaming

Tilbudene i markedet spenner fra automatiserte prompt-angrepssuiter til manuell testing utført av folk. Automatiserte verktøy dekker kjente injeksjonsmønstre bredt og billig. Manuell testing finner de kjedelige feilene: en agent som har fått for brede tilganger, en kanal ingen tegnet inn, en logg som ikke fanger verktøykall.

For de fleste SMB-er gir kombinasjonen mest: automatisert testing i CI-løpet ved hver endring, og en manuell gjennomgang et par ganger i året. Be alltid om at rapporten skiller mellom modellsvakheter og arkitekturfeil. Bare den siste kategorien kan du faktisk fikse selv.

Konsolideringen i markedet går også mot at sikkerhetsegenskaper bygges inn i selve agentplattformene i stedet for å kjøpes som tillegg. Vi har sett på hva det betyr for mindre selskaper i analysen av sikre AI-agenter for SMB.

Vanlige feil norske SMB-er gjør med AI-agenter

Feilene går igjen på tvers av bransjer, og de er sjelden tekniske i utgangspunktet. De oppstår fordi agenter innføres av forretningssiden, ofte med gode resultater, før noen har spurt hvem som eier risikoen.

Feil i styringen

Agenten har ingen eier. Den ble satt opp av en som sluttet, den fungerer, og ingen tør røre den. Dette er den mest utbredte feilen, og den er også den mest banale å fikse: sett et navn i et regneark.

Sikkerhetstesting skjer bare før lansering. Testen dokumenterer et system som ikke lenger finnes noen måneder senere. Se gapet mellom flertallet av sikkerhetsledere som oppgir AI-sikkerhet som sin største bekymring, og det lille mindretallet som faktisk har et testprogram (cybersecurityswitzerland.com, 2026).

Regelverket behandles som en juridisk oppgave. Klassifiseringen havner hos en advokat i stedet for hos den som kan skru på tilganger, og resultatet blir et notat ingen handler på. Klassifisering og tilgangsstyring hører sammen i samme møte.

Feil i teknikken

Agenten kjører som et menneske. Den bruker en ansatts konto, arver alle tilgangene og gjør loggen ubrukelig som bevis. Dette er også grunnen til at mange selskaper ikke kan svare på enkle spørsmål etter en hendelse.

Lesende og skrivende verktøy er ikke skilt. Da er hver eneste injeksjon potensielt en eksfiltrering. Skillet koster en ettermiddag å innføre og fjerner det meste av det realistiske tapspotensialet.

Loggen fanger samtalen, ikke handlingene. Med en femdobling i lengre skadelige nyttelaster mellom mars og mai 2026 (research.checkpoint.com, 2026) er det verktøykallene som forteller om et angrep lyktes. Samtaleloggen forteller bare at noe ble sagt.

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

Spørsmålene under er de som oftest kommer opp i ledergrupper som skal ta stilling til autonome agenter for første gang.

Trenger en liten bedrift egen sikkerhetstesting av AI?

Ja, men i et annet format enn et konsern. Poenget er ikke å kjøpe en stor øvelse, men å ha en fast kadens. Når bare et lite mindretall av organisasjonene har et formelt testprogram (cybersecurityswitzerland.com, 2026), er terskelen for å skille seg positivt ut lav.

Et realistisk minimum for en SMB: en halv dag hvert kvartal der noen forsøker å få agenten til å gjøre noe den ikke skal, med skriftlig notat om hva som ble forsøkt og hva som skjedde. Det er ikke perfekt. Det er uendelig mye bedre enn ingenting.

Kan vi stole på at leverandøren har sikret modellen?

Leverandøren sikrer modellen. Du sikrer systemet. Check Point er tydelig på at angripere misbruker kommersielle modeller ved å utnytte agentisk arkitektur, ikke bare enkeltprompter (research.checkpoint.com, 2026), og arkitekturen er din.

Regelverket speiler den samme arbeidsdelingen: Kommisjonen håndhever reglene for generelle AI-modeller (Deloitte), mens du svarer for systemet du har bygget. Ingen leverandørgaranti dekker at du ga agenten skrivetilgang til regnskapet.

Hva er forskjellen på prompt injection og indirekte prompt injection?

Ved vanlig prompt injection skriver angriperen instruksjonen selv, i grensesnittet. Ved indirekte prompt injection ligger instruksjonen skjult i innhold agenten leser: et vedlegg, en nettside, en e-post. Angriperen trenger aldri tilgang til systemet ditt.

Den indirekte varianten er den som vokser, og som skalerer best mot bedrifter (research.checkpoint.com, 2026). Det er også den som er vanskeligst å filtrere seg ut av, fordi innholdet ser legitimt ut for et menneske.

Gjelder EU AI Act for oss i Norge?

Den juridiske gjennomføringen i norsk rett bør du avklare med jurist, og den avhenger av EØS-prosessen. Den praktiske virkeligheten er mindre tvetydig: har du kunder, partnere eller leverandører i EU, kommer kravene til deg gjennom kontrakter og innkjøpsskjemaer uansett.

AI-loven er dessuten en av mer enn ti digitale reguleringer i EU (Deloitte), og flere av dem er allerede tatt inn i norsk regelverk. Kontrollene overlapper. Å bygge dem er derfor ikke bortkastet uansett hvordan gjennomføringen lander.

Hvor mye autonomi bør en agent få i starten?

Start med lesing og forslag, ikke handling. La agenten foreslå svaret, oppdateringen eller vedtaket, og la et menneske trykke. Etter noen uker vet du hvor ofte forslagene er riktige, og du har et faktisk grunnlag for å utvide.

Utvid deretter en handling om gangen, og aldri til utgående kanaler først. Rekkefølgen bør være internt før eksternt, lesing før skriving, og små beløp før store. Det er ikke forsiktighet for forsiktighetens skyld. Det er den eneste måten å få data på hvor godt agenten faktisk fungerer.

Oppsummering og neste steg

Sikkerhet i AI-agenter er ikke et nytt fagfelt. Det er tilgangsstyring, logging og testing anvendt på en ny type bruker som leser data den ikke har valgt selv. Det som gjør det haster, er at det store flertallet av utrullingene har minst en kritisk sårbarhet mens de aller færreste tester systematisk (cybersecurityswitzerland.com, 2026).

Det som betyr mest

Behandle agenten som en bruker med egen identitet, ikke som en funksjon. Skill lesende fra skrivende verktøy og krev godkjenning for alt som forlater huset. Logg verktøykall, ikke bare samtaler. Disse tre grepene dekker det meste av realistisk risiko, og de kan gjøres uten nytt innkjøp.

Kartlegg deretter hvilke AI-applikasjoner som faktisk er i bruk. Med i snitt ti applikasjoner per organisasjon per måned (research.checkpoint.com, 2026) er listen sannsynligvis lengre enn du tror, og hver rad uten eier er en risiko uten adressat.

Legg til slutt fristene i AI Act inn i den ordinære planleggingen. Neste harde dato er desember 2026, deretter 2. desember 2027 for høyrisikosystemer (EU-kommisjonen). Dokumentasjonen du trenger da, må samles inn nå.

Slik ser du at det virker

Fire spørsmål avgjør om programmet er reelt. Kan du på fem minutter liste alle agenter i drift med eier? Kan du tilbakekalle en agents tilgang uten å skru av systemet den bor i? Kan du rekonstruere hva en agent gjorde en gitt dag? Står neste sikkerhetstest i kalenderen med en ansvarlig?

Fire ja betyr at du er foran de fleste. Fire nei betyr ikke at du er i krise, men at du fortsatt stoler på antakelser. Hendelsen med 1200 agenter og 70 000 meldinger (The Verge) skjedde hos noen som også antok at isolasjonen holdt.

Det billigste tidspunktet å bygge disse kontrollene på er før agentene får jobbe autonomt. Det dyreste er etter at en av dem har gjort noe du ikke kan dokumentere.

I Alura hjelper vi norske bedrifter med å bygge AI-strategi som faktisk lar seg gjennomføre. Vi kombinerer dyp teknisk innsikt med erfaring fra alt fra SMB til enterprise, og leverer veikart som virker i praksis, ikke bare i PowerPoint.

Bestill en strategiøkt: en halvdags samtale der vi kartlegger virksomhetens AI-modenhet, identifiserer de tre prosessene med størst potensial, og leverer et konkret veikart med budsjettramme. Uforpliktende.

Kilder

cybersecurityswitzerland.com (2026). AI Security Statistics 2026: 40+ Key Facts and Figures
research.checkpoint.com (2026). AI Security Report 2026 - Check Point Research
The Verge. The rise of AI ‘civilizations’ and the fall of corporate responsibility
EU-kommisjonen. AI Act | Shaping Europe's digital future - European Union
The Verge (2025). The rise of AI 'civilizations' and the fall of corporate responsibility
Deloitte. European Union Artificial Intelligence Act | Deloitte