Sikre AI-agenter før LLMjacking koster 46.000 dollar daglig
Sysdig anslår 46.000 dollar i daglig AI-regning for ofre for LLMjacking, og 48 prosent av AI-agentene i produksjon kjører usikret. Her er tiltakene som stopper regningen før den kommer.

Nøkkelpunkter per 30. oktober 2026:
- 48 prosent av AI-agentene i produksjon kjører uten sikring, mens agentbestanden i virksomheter omtrent doblet seg på fire måneder (gravitee.io, 2026).
- 46.000 dollar per dag er Sysdigs anslag for hva LLMjacking koster ofre som får toppmodellene sine misbrukt av andre (ZDNet).
- Bare et lite mindretall har en navngitt person med formelt ansvar for hva AI-agentene gjør, samtidig som 81 prosent kjenner press på å rulle ut raskt (gravitee.io, 2026).
- Hver femte organisasjon melder minst ett agentbrudd, oftest prompt-injeksjon eller datalekkasje, og 40 prosent anslår tap på 1 til 10 millioner dollar (cdn.lawreportgroup.com, 2026).
- AI Act kjenner ingen juridisk kategori som heter agent, regelverket treffer AI-systemer, og harmoniserte standarder siktes mot Q4 2026 (arXiv).
Hva LLMjacking er og hvordan angriperne kommer inn
LLMjacking er enkelt forklart at noen andre bruker AI-kraften du betaler for. Kriminelle skaffer seg legitimasjon eller API-nøkler til bedriftens AI-kontoer og kjører egne arbeidslaster på din regning (ZDNet). Det er ikke et dataangrep i klassisk forstand: ingen krypterer filene dine, ingen sender et løsepengekrav. Du oppdager det i fakturaen, eller ikke i det hele tatt.
For en norsk SMB er dette en ny type eksponering. Virksomheten har sannsynligvis god kontroll på hvem som har tilgang til regnskapssystemet, men mindre kontroll på hvor mange API-nøkler som ligger i miljøvariabler, Git-historikk, automatiseringsverktøy og en utviklers laptop. Google Threat Intelligence Group har sett en betydelig økning i LLMjacking gjennom 2026, og den økningen skjer parallelt med at AI-nøkler sprer seg i organisasjoner som ikke har et register over dem.
API-nøkkelen er den nye inngangsdøren
Angrepsveien er lav-teknologisk. En nøkkel havner i et offentlig repo, i en delt dokumentmappe, i en chatlogg eller hos en underleverandør. Derfra trenger angriperen ingen sårbarhet i modellen: nøkkelen er autorisasjonen. Kriminelle skaffer legitimasjon eller API-nøkler nettopp for å få tilgang til bedrifters AI-kontoer, og stjålne påloggingsdetaljer kan selges videre på det illegale markedet (ZDNet).
Det gjør nøkkelhygiene til et sikkerhetstiltak på linje med tofaktor. En nøkkel uten utløpsdato, uten rate limit og uten eier er en åpen fakturakonto. Alura mener at minste privilegium og rotasjon av API-nøkler koster lite sammenlignet med en uke med misbrukt AI-kapasitet. Det er ikke et avansert tiltak, det er en opprydding de fleste kan gjennomføre på noen timer.
Svartmarkedet selger tilgang med 97 prosent rabatt
Det som gjør LLMjacking lønnsomt er prisgapet. Sikkerhetsteamet som ZDNet snakket med har sett ulovlig tilgang til AI-modeller fra blant annet Anthropic, Google og OpenAI tilbudt til sterkt reduserte priser, med en rabatt på 97 prosent mot listepris (ZDNet). Når noen andre dekker nittisyv prosent av kostnaden, er det ikke overraskende at det finnes kjøpere.
Konsekvensen er asymmetrisk. Kriminelle kan bruke stjålet AI-kraft til å få en økonomisk fordel i angrep, mens forsvarere betaler fulle token-kostnader for sine egne deteksjons- og analyseverktøy. Det er en strukturell ubalanse, ikke en forbigående bølge, og den forsvinner ikke før tilgangen blir vanskeligere å stjele og lettere å stenge.
Hvorfor misbruket er vanskelig å se
LLMjacking ser ut som normal bruk. Trafikken går mot samme endepunkt, med gyldig nøkkel, ofte med forsøk på å holde volumet under det som utløser varsler. Uten per-nøkkel-logging og et tak på forbruk har du ingen baseline å måle mot. Da blir faktureringssyklusen ditt deteksjonsverktøy, og den har en ledetid på en måned.
Dette er grunnen til at utgiftstak og logging er sikkerhetstiltak, ikke økonomitiltak. Et tak begrenser skaden mens du finner ut hva som skjedde. Logging per nøkkel og per agent gjør at du i det hele tatt kan svare på spørsmålet «hvem brukte dette». Vi har tidligere gått gjennom kritiske sårbarheter i agenter mer i detalj.
Skynet-agenten som kjører 100.000 steg uten et menneske
Høsten 2026 fikk et konkret eksempel mye oppmerksomhet. Sikkerhetsselskapet Symantec hevder å ha oppdaget en AI-agent kalt «Skynet», som opererer med svært høy grad av autonomi og fungerer ved å kapre andre AI-modeller (Digi.no). Overskriften oppgir at agenten kan utføre 100.000 steg uten menneskelig involvering.
Symantec sier de fant agentens instruksjonssett via en honningkrukke i løpet av sommeren, altså et system som utgir seg for å være et ubeskyttet AI-system for å tiltrekke seg angripere (Teknisk Ukeblad). Det er en funnmetode som sier noe viktig om trusselbildet: et ubeskyttet AI-endepunkt blir funnet fordi det er ubeskyttet, ikke fordi noen har lett etter deg spesielt.
Hva saken faktisk dokumenterer, og hva den ikke gjør
Vær presis på hva som er bekreftet. Kilden er et sikkerhetsselskaps egen rapportering, formidlet gjennom en artikkel som i hovedsak ligger bak betalingsmur. Det vi har er påstanden om høy autonomi, kapringen av andre modeller, honningkrukken som funnsted og tallet på hundre tusen steg. Hvor effektiv agenten er i praksis, hvor mange den har rammet og hvor mye av stegene som er nyttig arbeid, står ikke i det tilgjengelige materialet.
Det betyr ikke at saken er irrelevant. Den viser en retning: angrepsverktøy som selv er agenter, og som behandler andres AI-kapasitet som en ressurs å høste. Alura mener leverandørenes egne sikkerhetsrapporter er nyttige, men at tallene må leses med kildens kommersielle interesse i bakhodet. Et sikkerhetsselskap som finner en skremmende agent selger også produkter mot skremmende agenter.
Autonomi flytter forsvarslinjen
Et menneske som misbruker en stjålet nøkkel jobber i menneskelig tempo og med menneskelige pauser. En agent som kjører titusenvis av steg gjør ikke det. Den prøver kombinasjoner, holder seg under terskler, gjentar og justerer. Forsvar som bygger på at noen rekker å reagere innen arbeidsdagen er ute, treffer ikke denne motstanderen.
Praktisk konsekvens: tiltakene må være automatiske og forhåndsinnstilte. Et hardt tak på forbruk, en nøkkel som utløper av seg selv, et varsel som går til en navngitt person, en agent som ikke har tilgang til mer enn den trenger. Dette er samme logikk som bak de fem sikkerhetskravene vi anbefaler før en agent kobles til driften.
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.
Tallene som viser gapet mellom utrulling og sikring
To uavhengige undersøkelser fra 2026 peker i samme retning: virksomheter ruller ut AI-agenter raskere enn de sikrer dem. Gravitee har spurt 750 senior teknologiledere i Storbritannia og USA, og NeuralTrust har spurt over 160 CISO-er og sikkerhetsledere globalt. Begge er leverandørrapporter, og begge bør leses med det i minnet, men funnene overlapper på en måte som er vanskelig å avvise.
| Nøkkeltall | Verdi | Kilde |
|---|---|---|
| AI-agenter i produksjon som kjører usikret | 48 % | gravitee.io, 2026 |
| Organisasjoner med sikkerhets- eller personvernhendelse siste år | 54 % | gravitee.io, 2026 |
| Navngitt person med formelt ansvar for agentatferd | Et lite mindretall | gravitee.io, 2026 |
| Har implementert eller skalerer AI-agenter | 72 % | cdn.lawreportgroup.com, 2026 |
| Rapporterer omfattende sikkerhetskontroller | 29 % | cdn.lawreportgroup.com, 2026 |
| Organisasjoner med minst ett agentrelatert brudd | Hver femte | cdn.lawreportgroup.com, 2026 |
Usikrede produksjonsagenter er normalen, ikke unntaket
Gravitees hovedfunn er at 48 prosent av AI-agentene i produksjon kjører uten sikring, og at bare et mindretall av respondentene sier alle agenter er fullt sikret og styrt før de går live (gravitee.io, 2026). Gjennomsnittlig overvåkningsdekning ligger på 52 prosent, og bare 9,5 prosent sikrer størstedelen av agentene sine.
Les det siste tallet en gang til. Ni av ti organisasjoner har en betydelig andel agenter de ikke har kontroll på. Det er ikke et spørsmål om modenhet i toppsjiktet, det er normalsituasjonen. NeuralTrusts tall peker samme vei: 72 prosent har implementert eller skalerer agenter, men bare 29 prosent rapporterer omfattende sikkerhetskontroller (cdn.lawreportgroup.com, 2026).
Hendelsene har allerede skjedd
Dette er ikke et fremtidsscenario. 54 prosent av organisasjonene har opplevd eller mistenkt en sikkerhets- eller personvernhendelse knyttet til AI-agenter det siste året, og en mindre andel bekrefter en hendelse uten forbehold (gravitee.io, 2026). Differansen mellom «mistenkt» og «bekreftet» er i seg selv interessant: den forteller hvor mange som ikke har nok logging til å avgjøre saken.
I NeuralTrusts materiale melder hver femte organisasjon minst ett agentrelatert brudd, hovedsakelig fra prompt-injeksjon eller datalekkasje. Samtidig er 73 prosent av CISO-ene svært eller kritisk bekymret for AI-risiko, mens bare 30 prosent har modne sikkerhetstiltak. Bekymringen er på plass. Tiltakene er ikke.
Nesten ingen har en navngitt eier
Det enkleste funnet er også det mest avslørende: bare et lite mindretall har en navngitt person med formelt ansvar for AI-agenters atferd (gravitee.io, 2026). Alt annet i denne artikkelen blir vanskeligere når ingen eier problemet. Hvem roterer nøkkelen? Hvem setter taket? Hvem får varselet klokken to om natten?
Samtidig sier 81 prosent at de kjenner press på å deployere AI-agenter raskt, selv uten full sikkerhet på plass. Det er kombinasjonen som er farlig: høyt tempo, uklart eierskap. Alura mener ingen AI-agent bør gå i produksjon uten navngitt eier, logging og et tak på hvor mye den kan bruke. Tre krav, ingen av dem dyre, alle tre mulige å innføre før neste agent går live.
Tre modenhetsnivåer for sikring av AI-agenter
Modenhet er nyttigere enn en sjekkliste, fordi det forteller deg hvilket neste steg som er realistisk. NeuralTrust deler respondentene i nivåer og finner at 46 prosent er reaktive, 29 prosent er styrte, og at færre enn 10 prosent når proaktiv governance (cdn.lawreportgroup.com, 2026). Finn ditt eget nivå først, så blir prioriteringen enklere.
| Nivå | Andel | Kjennetegn | Første grep |
|---|---|---|---|
| Reaktivt | 46 % | Agenter finnes, ingen samlet oversikt, kontroller settes inn etter hendelser | Lag et register over nøkler, endepunkter og agenter |
| Styrt | 29 % | Overvåking og tilgangskontroll på plass, men ujevn dekning | Mål dekningsgrad per agent, ikke gjennomsnittlig |
| Proaktivt | Under 10 % | Eierskap, testing og grenser er definert før utrulling | Adversarial testing og validering av forsyningskjeden |
Reaktivt: dere oppdager det når regningen kommer
Dette er det største segmentet. Kjennetegnet er ikke manglende kompetanse, men manglende oversikt: agenter og integrasjoner er bygget av ulike team, til ulike tider, med ulike nøkler. Ingen kan svare på hvor mange LLM-endepunkter virksomheten har mot internett, eller hvilke nøkler som fortsatt er gyldige hos en konsulent som sluttet i fjor.
Veien ut av reaktivt er kjedelig og effektiv: et register. En enkel liste med hvilke agenter som kjører, hvilken nøkkel de bruker, hvem som eier dem, hva de har tilgang til og hva de koster. Det er ikke et verktøykjøp. Det er et regneark og en ettermiddag, og det flytter deg mer enn noe annet enkelttiltak.
Styrt: kontroller finnes, dekningen er ujevn
På dette nivået har virksomheten valgt kontroller, men bruker dem flekkvis. Gravitees tall om 52 prosent gjennomsnittlig overvåkningsdekning beskriver nettopp dette: det ser greit ut i snitt, og snittet skjuler at halve bestanden er blind (gravitee.io, 2026). En angriper trenger ikke gjennomsnittet, den trenger den ene agenten som ikke logges.
Det som flytter deg videre er å slutte å måle gjennomsnitt. Mål per agent: logges den, har den tak, har den eier, er nøkkelen rullert siste kvartal? Fire ja eller nei per agent gir en tabell som ledelsen faktisk kan styre etter, og som gjør det synlig når en pilot har sneket seg inn i produksjon.
Proaktivt: under ti prosent kommer hit
Det proaktive nivået kjennetegnes av at sikkerhet skjer før utrulling, ikke etter. Her finner du de kontrollene som er sjeldne i markedet: adversarial testing brukes av 19 prosent og validering av forsyningskjeden av 16 prosent (cdn.lawreportgroup.com, 2026). For en SMB er dette ikke urealistisk, men det bør komme etter registeret og grensene, ikke før.
En nyttig test på om dere er proaktive: kan noen rulle ut en ny agent i morgen uten at den får eier, tak og logging automatisk? Hvis svaret er ja, er dere styrte i beste fall. Proaktivt betyr at det ikke er mulig å gjøre feil ved et uhell.
Tiltakene du kan sette i gang denne uken
Ingen av tiltakene under krever budsjett, anskaffelsesprosess eller ny plattform. De krever at noen får mandat og en uke. Rekkefølgen er valgt slik at hvert steg gjør det neste lettere, og slik at du etter dag to har redusert den største eksponeringen: gyldige nøkler med for brede rettigheter.
| Dag | Tiltak | Ferdig når |
|---|---|---|
| Mandag | Kartlegg alle API-nøkler, LLM-endepunkter og agenter i drift | Du har en liste med eier og formål per linje |
| Tirsdag | Fjern rettigheter ingen bruker, del opp delte nøkler | Hver agent har egen nøkkel med minste privilegium |
| Onsdag | Roter alle nøkler, sett utløpsdato | Gamle nøkler er ugyldige, ikke bare ubrukte |
| Torsdag | Sett hardt utgiftstak og varsling per nøkkel | Et avvik stopper av seg selv, uten manuell inngripen |
| Fredag | Slå på logging per agent, utpek navngitt eier | Navn står i registeret, ikke i et møtereferat |
Finn alle nøkler, endepunkter og agenter
Start bredere enn du tror er nødvendig. Nøkler ligger i kodebaser, CI-systemer, automatiseringsverktøy som Zapier og Make, regneark, notatapper og hos leverandører. Endepunkter ligger bak API-gatewayer, i serverless-funksjoner og i interne verktøy noen bygde på en fredag. Spør hvert team direkte, og søk i Git-historikken, ikke bare i gjeldende kode.
Registeret trenger fem kolonner: hva det er, hvem eier det, hva det har tilgang til, hva det koster, når nøkkelen sist ble rullert. Når bare et lite mindretall har en navngitt ansvarlig for agentatferd, er det å fylle ut eierkolonnen i seg selv et tiltak som skiller deg fra flertallet (gravitee.io, 2026).
Minste privilegium og rotasjon
ZDNet oppsummerer rådet kort: innfør prinsippet om minste privilegium for å redusere risikoen for misbruk av admin-kontoer (ZDNet). I praksis betyr det at en agent som skal lese fra en innboks ikke skal kunne sende, at en agent som skal oppsummere dokumenter ikke skal kunne slette dem, og at ingen agent skal dele nøkkel med en annen.
Rotasjon er det andre grepet. En nøkkel uten utløpsdato er en permanent tilgang gitt til en tilstand som ikke lenger finnes: ansatte slutter, leverandører byttes, repoer blir offentlige. Sett utløp, automatiser fornyelsen, og gjør rotasjon til noe som skjer uten at noen må huske det. Alt som krever at et menneske husker, glemmes i andre kvartal.
Utgiftstak, logging og navngitt eier
Et hardt tak per nøkkel er den billigste forsikringen du får mot LLMjacking. Taket skal stoppe, ikke varsle: en terskel som bare sender e-post, stopper ingenting om natten. Legg taket der normal bruk har god margin, og aksepter at en legitim arbeidslast av og til må få hevet grensen manuelt. Det er en bedre feil enn den motsatte.
Logging gir deg etterforskningsevne, og den må være per agent og per nøkkel for å være verdt noe. Eieren gir deg beslutningsevne. Dette er tre krav, og de kan stå i et kort dokument som gjelder for alle agenter i virksomheten. Tempoet taler for å gjøre det nå: agentbestanden i virksomheter har omtrent doblet seg siden desember 2025, og et klart flertall kjenner press på å deployere raskt (gravitee.io, 2026).
Prompt-injeksjon og datalekkasje er de vanligste bruddene
Når brudd faktisk skjer, er mønsteret tydelig. Blant organisasjonene som rapporterer minst ett AI-agentrelatert brudd, kommer de hovedsakelig fra prompt-injeksjon eller datalekkasje (cdn.lawreportgroup.com, 2026). Det er to ulike feil med samme rot: agenten behandler data den møter som instruksjoner den skal følge.
Prompt-injeksjon: instruksjonen kommer utenfra
En agent som leser e-poster, nettsider, PDF-er eller kundehenvendelser leser også tekst som noen andre har skrevet. Hvis den teksten inneholder en instruksjon, og agenten ikke skiller mellom instruksjon og innhold, utfører den instruksjonen. Det er prompt-injeksjon i kjernen, og den trenger ingen teknisk sårbarhet: den utnytter at modellen er bygget for å følge språk.
Forsvaret er arkitektonisk, ikke språklig. Du kan ikke skrive en systemprompt som gjør agenten immun. Det du kan gjøre er å begrense hva agenten har lov til å gjøre etter at den har lest ukjent tekst: ingen irreversible handlinger uten godkjenning, ingen utgående nettverkskall til vilkårlige adresser, ingen tilgang til hemmeligheter den ikke trenger for oppgaven.
Datalekkasje gjennom agentens egne verktøy
Datalekkasje i agentsammenheng skjer sjelden ved at noen bryter seg inn i en database. Det skjer ved at agenten har legitim tilgang til kundedata og legitim mulighet til å sende noe ut, og at de to kombineres på en måte ingen designet. En oppsummering som havner i en ekstern tjeneste. Et feltnavn med personopplysninger i en loggfil. Et verktøykall som sender hele konteksten videre.
Dette er grunnen til at tilgangsgrensen bør settes per agent og per verktøy, ikke per bruker. Spørsmålet er ikke «har denne ansatte lov til å se dette», men «trenger denne agenten å se dette for å løse oppgaven». Svaret er oftere nei enn folk tror, og hver gang svaret er nei krymper skadeomfanget ved et brudd.
Kontrollene folk faktisk bruker
Det er verdt å se hva markedet velger først, fordi det avslører hvor forsvaret er tynnest. Overvåking, tilgangskontroll og DLP dominerer, mens testing mot angrep og kontroll av forsyningskjeden er sjeldne. Med andre ord: de fleste ser etter hendelser, få prøver å finne feilene før de blir hendelser.
| Sikkerhetskontroll | Andel som bruker den | Hva den fanger |
|---|---|---|
| Overvåking | 42 % | Avvik etter at de har begynt |
| Tilgangskontroll | 38 % | Omfanget av et brudd |
| DLP | 31 % | Data på vei ut |
| Adversarial testing | 19 % | Prompt-injeksjon før produksjon |
| Validering av forsyningskjede | 16 % | Risiko i tredjeparts modeller og verktøy |
Tallene er NeuralTrusts (cdn.lawreportgroup.com, 2026). For en SMB er den praktiske lesningen at de tre øverste er nødvendige, og at det fjerde punktet gir uvanlig mye igjen for innsatsen: en time der noen bevisst prøver å lure agenten med instruksjoner i innhold, avdekker mer enn en måneds overvåking.
Hva et misbrukt AI-endepunkt koster i regning og tap
Kostnaden kommer i to former. Først den direkte regningen for kapasitet andre har brukt, deretter de indirekte tapene: nedetid, utredning, varsling, eventuelle brudd på personvern. Tallene i de to kategoriene er av helt ulik størrelsesorden, og de krever ulike tiltak.
Regningen kommer først
Sysdig anslår at LLMjacking kan koste ofre 46.000 dollar per dag når det er toppmodellene som misbrukes (ZDNet). Tallet beskriver et høyt scenario, ikke et snitt, og det er verdt å behandle det som en øvre ramme snarere enn en prognose for din virksomhet. Poenget er likevel tydelig: kostnaden påløper per døgn, og den stopper ikke av seg selv.
Det gjør deteksjonstiden til den viktigste variabelen du kontrollerer. En virksomhet med hardt tak per nøkkel taper det taket tillater. En virksomhet uten tak taper det angriperen rekker til neste faktura. Forskjellen mellom de to er ikke teknologi, det er en innstilling noen har satt eller ikke satt.
Tapsanslagene fra sikkerhetslederne
Sikkerhetslederne selv anslår større summer når de vurderer et reelt agentbrudd. 40 prosent anslår økonomiske tap på 1 til 10 millioner dollar, og 13 prosent forventer mer enn 10 millioner (cdn.lawreportgroup.com, 2026). Dette er anslag fra respondenter i større virksomheter, og de skal skaleres ned for en norsk SMB, men forholdet mellom tiltakskostnad og tapspotensial holder seg.
Sett det opp mot hva tiltakene i denne artikkelen koster: noen dagers arbeid, et register, noen innstillinger i leverandørportalen. Det er her regnestykket blir utrivelig enkelt, og det er her de 46 prosentene som ligger på reaktivt nivå taper mest. De betaler ikke for sikring, de betaler for hendelser.
Les også: Sikre AI-agenter rykker nærmere SMB-bruk etter Ona-oppkjøp. OpenAI kjøper Ona for å gi AI-agenter sikre, vedvarende miljøer.
Markedet beveger seg fra 37 agenter til 150.000
Volumet er den faktoren som gjør dagens løse praksis uholdbar. Gravitee oppgir at organisasjonene i snitt hadde rundt 37 agenter i desember 2025, og at bestanden omtrent doblet seg i løpet av fire måneder. I april 2026 hadde 38 prosent over hundre agenter (gravitee.io, 2026).
Prognosene strekker seg langt videre. Gartner anslår 150.000 agenter i en gjennomsnittlig Fortune 500-virksomhet innen 2028, mens NeuralTrusts respondenter forventer at en av tre virksomheter opererer over 500 agenter i 2028, og at 56 prosent behandler agenter som et kjerneoperativt lag innen 2030. Tallene gjelder store selskaper, men retningen gjelder alle.
Doblingen på fire måneder
Fra 37 agenter til et tresifret antall på et halvt år er ikke en teknologisk endring, det er en organisatorisk. Agenter oppstår fordi de er billige å lage og fordi de løser små, konkrete irritasjoner i hverdagen. Ingen behandler den første som et IT-system. Når antallet går forbi hundre, er summen av dem et IT-system uansett hva noen kaller det.
Det er derfor sikringen må være en standard, ikke en vurdering per agent. Du kommer ikke til å risikovurdere 150 agenter manuelt. Du kommer til å sette krav som gjelder alle, og håndheve dem i plattformen. Hvordan antallet agenter per bedrift endrer arbeidsflyten har vi sett nærmere på i sammenheng med agenter i CRM.
Hva volumet gjør med styringen
Styring som fungerer for ti agenter bryter sammen ved hundre. Manuelle godkjenninger blir en flaskehals folk går rundt. Oversikter i regneark blir utdaterte. Varsler som alle går til samme person blir ignorert. Det som skalerer er automatisk utstedelse av nøkler med innebygde grenser, og et register som fylles ut av systemet, ikke av et menneske.
Samtidig øker forventningen om spesialisert kompetanse. NeuralTrusts respondenter oppgir at 24 prosent har dedikerte AI-sikkerhetsspesialister i 2026, mot 51 prosent i 2028 og 74 prosent i 2030 (cdn.lawreportgroup.com, 2026). For en SMB betyr ikke det en ny stilling, men at ansvaret må plasseres eksplisitt hos noen som har tid til det.
AI Act regulerer AI-systemer, ikke agentarkitektur
Mange ledere venter på at regelverket skal si noe spesifikt om agenter. Det gjør det ikke. En gjennomgang av EU-retten på området konkluderer med at AI Act ikke definerer begrepet «agent» som en juridisk kategori, og at forordningen regulerer AI-systemer, ikke arkitekturmønstre (arXiv). Forordningen det er snakk om er 2024/1689.
Per tidlig 2026 hadde AI Office ikke publisert veiledning spesifikt om AI-agenter. Det betyr at plikten din må utledes fra hva systemet brukes til, ikke fra hvordan du har bygget det. Alura mener AI Act treffer agenter gjennom bruksområdet, ikke arkitekturen, så risikoklassifisering må gjøres per bruksområde.
Ingen juridisk kategori som heter agent
Konsekvensen er praktisk og litt kontraintuitiv. Å kalle noe «en agent» gir deg ingen egen plikt, og å kalle det «bare en automatisering» fjerner ingen. Analysen er tydelig på at en agent som screener CV-er faller inn under Annex III punkt 4(a) og er høyrisiko uavhengig av hvordan leverandøren karakteriserer teknologien (arXiv).
Det samme gjelder i motsatt retning. En teknisk avansert multi-agent-oppsetning som sorterer interne møtenotater havner ikke i høyrisiko fordi den er avansert. Arkitektur er et sikkerhetsspørsmål. Bruksområde er et reguleringsspørsmål. Blander du dem, ender du med å dokumentere feil ting.
Bruksområdet avgjør risikoklassen
Et enkelt beslutningsløp holder for de fleste SMB-er. Gå gjennom hver agent, ikke hver teknologi, og svar på spørsmålene i rekkefølge. Dokumenter svaret, også når svaret er «ingen særlige krav», for dokumentasjonen er det som gjør vurderingen etterprøvbar senere.
| Steg | Spørsmål | Hvorfor det avgjør |
|---|---|---|
| 1 | Hva brukes agenten konkret til, hos hvem? | Regelverket treffer AI-systemer gjennom bruksområdet, ikke arkitekturen |
| 2 | Treffer bruksområdet et punkt i Annex III? | CV-screening er høyrisiko uansett hva leverandøren kaller teknologien |
| 3 | Er vi bruker eller leverandør av systemet? | Rollen bestemmer hvilke plikter som faller på dere |
| 4 | Har vi finjustert en modell vi ikke har laget? | Omfattende finjustering kan gjøre dere til leverandør |
| 5 | Hva logger og dokumenterer vi i dag? | Uten logg kan ingen plikt etterleves i praksis |
Steg fire er det som overrasker flest. Kommisjonens retningslinjer for GPAI fastsetter en terskel på mer enn en tredjedel av opprinnelig treningsberegning for at finjustering gjør deg til leverandør (arXiv). For en SMB som finjusterer på egne data er det langt unna, men terskelen bør være kjent før noen setter i gang et større treningsløp.
Standardene er forsinket, plikten er ikke
De harmoniserte standardene som skal gjøre etterlevelse konkret er ikke ferdige. CEN-CENELEC har iverksatt tiltak for å akselerere arbeidet, inkludert direkte publisering etter positiv avstemning for seks av de mest forsinkede utkastene, med mål om ferdigstillelse i Q4 2026 (arXiv). Over 1.000 eksperter bidrar til CEN/CENELEC JTC 21.
Det er også grunn til å dempe forventningene til hva standardene løser. Future Society konkluderte med at de tekniske standardene under utvikling sannsynligvis ikke vil håndtere risiko fra agenter fullt ut. GPAI Code of Practice ble publisert i juli 2025, og GPAI-modeller med systemisk risiko er de som er trent over 10^25 FLOP eller utpekt av Kommisjonen, en terskel som i praksis treffer modellutviklere, ikke SMB-er som bruker modellene.
At regelverket er umodent er ikke et argument for å vente. Det samme arbeidet som gjør deg trygg mot LLMjacking, altså register, eierskap, logging og grenser, er også det du trenger for å dokumentere etterlevelse senere. Et klart mindretall mener dagens regulering er tilstrekkelig for AI-agentrisiko (gravitee.io, 2026), og det tilsier at kravene blir strengere, ikke løsere.
Les leverandørrapportene om agentsikkerhet med kritisk blikk
Mye av det best tilgjengelige tallmaterialet om agentsikkerhet kommer fra selskaper som selger agentsikkerhet. Det gjør ikke tallene ubrukelige, men det former dem. Alura mener disse rapportene er nyttige, men at tallene må leses med kildens kommersielle interesse i bakhodet.
Hvem tjener på tallet
Gravitees rapport bygger på 750 senior teknologiledere og markedsfører samtidig selskapets egne løsninger for håndtering av AI-agenter (gravitee.io, 2026). NeuralTrusts rapport bygger på over 160 CISO-er og sikkerhetsledere og peker mot samme type produktkategori (cdn.lawreportgroup.com, 2026). Begge utvalg er små, selvrapporterte og trukket fra Storbritannia, USA og globale respondentlister, ikke fra norske SMB-er.
Det betyr at retningen er mer pålitelig enn desimalene. At en stor del av agentene i produksjon står usikret, er et funn du kan planlegge etter. At tallet er presist 48 og ikke 44, er det ikke. Behandle prosentene som indikasjoner på gap, og bruk dem til å stille spørsmål internt, ikke som referansepunkt du skal måles mot.
Slik bruker du rapportene likevel
Tre grep gjør leverandørdata brukbar. Se etter funn som gjentas i uavhengige utvalg: her peker to rapporter med helt ulike respondentgrupper mot samme gap mellom utrulling og sikring. Se etter tall som går mot avsenderens interesse, for eksempel at bare 19 prosent bruker adversarial testing, som er et pinlig tall for en bransje som har solgt det lenge. Og skill prognose fra måling.
Prognosene er den delen som bør leses med minst vekt. NeuralTrusts fremskrivning om at 80 prosent vil falle under AI-spesifikk regulering innen 2030, mot 27 prosent i 2026, er respondentenes forventning, ikke en vedtatt plan. Den er likevel nyttig som planforutsetning: ingen av de spurte tror styringskravene blir mindre.
Vanlige feil når norske SMB-er setter agenter i produksjon
Feilene under er ikke tekniske. De handler om hvordan beslutninger faktisk tas i en virksomhet med femti ansatte og mye å gjøre. Alle fire er billige å rette før agenten går live, og dyre å rette etterpå.
Piloten blir produksjon uten at noen bestemmer det
En agent lages for å teste en tanke. Den fungerer. Noen begynner å bruke den fast. Seks måneder senere er den en del av kundeprosessen, med nøkkelen fra testoppsettet og uten at noen har gjort en vurdering. Dette er den mest utbredte feilen, og den forklarer hvorfor så mange produksjonsagenter kjører uten sikring: de gikk aldri gjennom en beslutning om å gå i produksjon.
Motgiften er en lav terskel for å passere en liten port. Tre spørsmål, ikke tretti: har den eier, logges den, har den tak? Hvis en agent brukes av noen andre enn den som bygde den, er den i produksjon, og da gjelder de tre. Vi har sett tilsvarende mønster i hvordan team organiserer multi-agent koding.
En nøkkel til alt
Delte nøkler er praktisk på kort sikt og ødeleggende på lang sikt. Du kan ikke se hvem som brukte hva, du kan ikke stenge en agent uten å stenge alle, og du kan ikke sette meningsfulle tak. Når en delt nøkkel lekker, har angriperen alt som nøkkelen har tilgang til, ikke bare den ene agentens arbeidsområde.
Dette er den konkrete grunnen til at minste privilegium er mer enn en floskel. Egen nøkkel per agent, med bare de rettighetene agenten faktisk bruker, gjør at et brudd blir en avgrenset hendelse i stedet for en virksomhetssak. Det er også forutsetningen for at logging gir svar.
Ingen leser loggene
Logging som ingen ser på er dokumentasjon, ikke deteksjon. Gapet mellom dem som bekrefter en hendelse og de 54 prosentene som har opplevd eller mistenkt en, er i praksis et gap i evnen til å avgjøre hva som skjedde (gravitee.io, 2026). Mistanke uten logg blir aldri konklusjon.
Det som virker er få og skarpe varsler: forbruk over tak, kall fra ukjent IP-område, verktøybruk utenfor normalmønster. Tre varsler som går til en navngitt person slår tretti dashbord ingen åpner. Og varslene må testes, for et varsel som aldri har utløst er et varsel du ikke vet om fungerer.
Spørsmål og svar om sikring av AI-agenter
Spørsmålene under er de som oftest kommer opp hos ledere som skal ta en beslutning denne måneden, ikke neste år.
Hvordan vet jeg om vi allerede er utsatt for LLMjacking?
Se på forbruksmønsteret per nøkkel, ikke på totalen. Uventede topper, aktivitet utenfor arbeidstid, kall fra geografiske områder dere ikke opererer i, og bruk av modeller ingen i teamet har valgt, er de tydeligste signalene. Mangler du per-nøkkel-data, er svaret at du ikke vet, og det er i seg selv funnet.
Sjekk deretter om noen av nøklene har havnet et sted de ikke skal være: offentlige repoer, Git-historikk, delte dokumenter, tredjeparts integrasjoner. Stjålne påloggingsdetaljer og API-nøkler selges videre på det illegale markedet, så en nøkkel som har vært eksponert bør anses som kompromittert selv om du ikke ser misbruk ennå (ZDNet).
Hva koster det å sikre agentene våre?
De tiltakene som fjerner mest risiko koster arbeidstid, ikke lisenser: register, nøkkelrotasjon, minste privilegium, tak og logging. For en SMB med en håndfull agenter er det en ukes innsats for en person som har tilgangene. Verktøykjøp bør komme etter denne ryddejobben, ellers kjøper du styring av noe du ikke har oversikt over.
Sett det mot alternativet. Sysdigs anslag på 46.000 dollar per dag beskriver et toppscenario, men den direkte regningen løper per døgn, og sikkerhetsledere anslår tap i millionklassen ved reelle agentbrudd (cdn.lawreportgroup.com, 2026). Forholdet mellom kostnad og eksponering er ikke et tett regnestykke.
Må vi risikoklassifisere agentene under AI Act?
Du må vurdere hvert bruksområde, og du kan ikke finne svaret ved å beskrive teknologien. AI Act definerer ikke «agent» som en juridisk kategori og regulerer AI-systemer, ikke arkitekturmønstre, så klassifiseringen følger av hva systemet brukes til og hvem det påvirker (arXiv).
Praktisk: lag en linje per bruksområde, skriv ned hva agenten gjør, hvem den påvirker, om bruken treffer et høyrisikoområde, og om dere er bruker eller leverandør. Agenter i HR, kredittvurdering og tilgang til tjenester krever ekstra oppmerksomhet. Agenter som jobber på interne, ikke-personopplysninger krever mindre, men vurderingen bør likevel skrives ned.
Er det nok å stole på leverandørens sikkerhet?
Nei, fordi den vanligste feilen ikke ligger hos modellleverandøren. Den ligger i hvordan nøkkelen er distribuert, hvilke rettigheter agenten har fått, og om noen ser på loggene. Modellleverandøren kan ikke vite at agenten din ikke burde ha skrivetilgang til kundedatabasen.
Samtidig flytter markedet seg i retning av mer innebygd styring, og det gjør det enklere for mindre virksomheter over tid. Vi har skrevet om hva Ona-oppkjøpet betyr for SMB-tilgangen til sikre agentmiljøer. Inntil den styringen er standard, er ansvaret for grenser og eierskap ditt.
Oppsummering og neste steg
Bildet fra 2026 er konsistent på tvers av kilder: agenter rulles ut raskt, sikringen henger etter, og angriperne har funnet en forretningsmodell i å bruke andres AI-kapasitet. Store deler av agentbestanden i produksjon kjører usikret, hver femte organisasjon har hatt et brudd, og bare et lite mindretall har en navngitt ansvarlig for hva agentene gjør. Dette er ikke en varsling om fremtiden, det er en beskrivelse av nåtilstanden.
Det gode er at tiltakene som monner er de kjedelige og billige. Minste privilegium, rotasjon av nøkler, hardt utgiftstak, logging per agent, en navngitt eier. Ingen av dem krever at du forstår modellarkitektur. Alle fem krever at noen får mandat og en uke, og at kravene gjelder alle agenter, også den noen bygde på en fredag og glemte å nevne.
De tre tingene som gir mest denne uken
Først: skriv registeret. Alle nøkler, alle endepunkter, alle agenter, med eier og formål. Du kan ikke sikre det du ikke vet om, og de 46 prosentene som ligger på reaktivt nivå mangler nesten alltid nettopp dette (cdn.lawreportgroup.com, 2026).
Deretter: sett et hardt tak og roter nøklene. Taket skal stoppe, ikke varsle. Rotasjonen skal ha utløpsdato, ikke en kalenderpåminnelse. Til sist: skriv et navn i eierkolonnen for hver agent, og la den personen eie varslene. Med en agentbestand som omtrent doblet seg på fire måneder, er dette den siste måneden det er enkelt å gjøre (gravitee.io, 2026).
Om tre måneder måler du fire ting per agent: har den eier, logges den, har den tak, er nøkkelen rullert. Fire ja eller nei, ikke et gjennomsnitt. Gjennomsnittet er det som skjuler den ene agenten angriperen finner.
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
- gravitee.io (2026). State of AI Agent Security Report 2026 | Gravitee
- ZDNet. LLMjacking can run up your business’ AI bill fast - how to stop it - ZDNET
- cdn.lawreportgroup.com (2026). The State of AI Agent Security 2026 - cdn.lawreportgroup.com
- arXiv. AI Agents Under EU Law A Compliance Architecture for AI Providers
- Digi.no. Security firm reports new attack method that hijacks AI models to run 100,000 steps without human involvement
- Teknisk Ukeblad. Security firm reports new attack method that hijacks AI models to run 100,000 steps without human involvement
Alura
Praktisk kunnskap om AI-automatisering og effektivisering for norske bedrifter.
Les neste
AI-agenter utførte 76 av 95 angrepskommandoer i test
I et forsøk med 95 oppgaver utførte en ubeskyttet AI-agent 76 angrepskommandoer. Her er kontrollene og leverandørspørsmålene som bør være på plass før norske SMB-er ruller ut agenter.
Agents API fjerner infrastrukturen men ikke leverandørlåsen
OpenAI hoster nå agent-harnesset selv, og det koster kun tokens og verktøy. Men leverandørlåsing, manglende Zero Data Retention og AI Act gjør avgrensning til det viktigste valget.
AI-agenter trenger fem grenser før de slippes løs
Wikimedia mener OpenAI-agenter gjorde millioner av automatiserte forespørsler. Her er grensene norske SMB-er bør sette før de slipper egne agenter mot eksterne tjenester.
48 prosent av AI-agentene i produksjon kjører usikret
Agentflåtene dobles, men nesten halvparten av agentene i produksjon kjører usikret. Her er kravene du bør stille til egen organisasjon og til leverandøren før neste agent går live.

