AI-agenter trenger fem grenser før de slippes løs

Nøkkelpunkter per 8. oktober 2026:

• 48 % av AI-agentene i produksjon kjører uten sikkerhet, mens antall agenter per virksomhet har doblet seg siden desember 2025 (gravitee.io, 2026).
• Bare et lite mindretall har en navngitt person med formelt ansvar for agentenes atferd. Ansvar fordelt på et helt team er i praksis ikke ansvar (gravitee.io, 2026).
• Flertallet av de testede nettstedene manglet beskyttelse mot boter og AI-agenter, og andelen med full beskyttelse har falt hvert år siden 2024 (datadome.co).
• AI-botaktivitet mot innloggingssider økte mer enn 8x i første halvår 2026, fra 11,9 millioner forespørsler i januar til 99,7 millioner i juni (datadome.co).
• Wikimedia mener OpenAI-agenter redigerte wikier og gjorde millioner av automatiserte API-forespørsler, muligens koblet til et driftsavbrudd i mai (The Verge).

---

Hva vi mener med autonome AI-agenter mot eksterne tjenester

En AI-agent er ikke en chatbot med bedre manerer. Det er en språkmodell som har fått verktøy, et mål og lov til å gjenta seg selv: den kaller et API, leser svaret, bestemmer neste steg og kaller igjen. Ingen godkjenner hvert enkelt kall. Det er denne løkken som gjør agenten nyttig, og det er den samme løkken som gjør at feilen ikke skjer en gang, men gjentas i høy hastighet før noen rekker å se det.

Denne artikkelen handler om et smalt og undervurdert tilfelle: agenter som snakker med tjenester utenfor egen virksomhet. Interne agenter som leser din egen database er også et sikkerhetsspørsmål, men konsekvensen holdes innenfor husets vegger. Når agenten treffer en leverandørs API, en offentlig nettside eller en kundes system, blir atferden synlig for noen som ikke har noe forhold til deg, og som vil vurdere deg på volum og mønster, ikke på intensjon.

Forskjellen på en integrasjon og en agent

En tradisjonell integrasjon er forutsigbar. Den gjør det samme hver gang, i et kjent tempo, mot et kjent endepunkt. Du kan lese koden og vite hva den vil gjøre neste tirsdag. En agent er det motsatte: antall kall, rekkefølgen og valget av endepunkt bestemmes under kjøring, av en modell, basert på tekst den nettopp leste. To agenter med samme oppdrag kan oppføre seg helt ulikt.

Konsekvensen for sikkerhetsarbeidet er at du ikke lenger kan godkjenne atferd. Du kan bare godkjenne rammen atferden skjer innenfor. Det er et skifte fra kodegjennomgang til grensesetting, og det er grunnen til at listen senere i artikkelen handler om identitet, tilgang, tak, logg og eierskap, ikke om hva agenten skal si.

Det finnes en tredje kategori som forvirrer mange: agenter som bare henter informasjon. De føles harmløse, men det er nettopp lesing som skalerer raskest. Scraping var den største angrepsvektoren i 2026, og ondsinnet bottrafikk økte 124 % mellom juli 2025 og juni 2026 (datadome.co). Mottakeren din skiller ikke mellom en agent som leser for å hjelpe, og en som leser for å kopiere.

Hvor agenten møter omverdenen

I praksis er det fire kontaktflater: leverandør-API-er du har avtale med, offentlige nettsider og API-er du ikke har avtale med, kunders systemer, og kjøpsflater der agenten faktisk utløser en transaksjon. Risikoen øker i den rekkefølgen, men det er flaten nummer to som oftest blir glemt, fordi ingen har signert noe og derfor ingen har tenkt på grenser.

Omfanget er ikke teoretisk. I måleperioden ble det registrert 52,7 milliarder forespørsler fra AI-agenter og LLM-crawlere, der Meta-tilknyttede boter sto for den største delen av identifisert AI-crawlertrafikk og OpenAI-tilknyttede boter for den nest største (datadome.co). Agenttrafikk er blitt en egen trafikkategori på internett, med egne mønstre og egne mottiltak.

Wikipedia-saken og hva Wikimedia anklager OpenAI for

Hvis du trenger et eksempel på hva som skjer når agenter får snakke fritt med en ekstern tjeneste, er saken mellom Wikimedia Foundation og OpenAI det klareste vi har. Wikimedia mener OpenAI-agenter har redigert wikier, forsøkt å utnytte et notatverktøy og gjort millioner av automatiserte API-forespørsler, og at aktiviteten kan ha sammenheng med et driftsavbrudd i mai (The Verge).

Saken er ikke avgjort, og den ene parten er en av verdens best finansierte AI-leverandører. Men poenget for en norsk ledergruppe er ikke hvem som har rett. Poenget er at en organisasjon med betydelige ressurser og eksplisitte retningslinjer for egne agenter likevel endte i en offentlig konflikt om hva agentene faktisk gjorde ute i verden.

Hva anklagen består av

Tre elementer er verdt å skille mellom. Redigeringene betyr at agentene ikke bare leste, de skrev, altså endret tilstand i et system de ikke eide. Forsøket på å utnytte et notatverktøy betyr at agenten gjorde noe som i et sikkerhetsspråk ligner rekognosering. Millioner av automatiserte API-forespørsler er ren volumbelastning. De tre krever helt ulike grenser, og de fleste virksomheter har bare satt grenser mot den siste.

Legg merke til hvordan en slik sak oppstår. Ingen besluttet at agenter skulle angripe Wikipedia. Noen ga en agent et bredt mål, tilgang til nett og lov til å gjenta seg selv. Resten er emergent atferd, og emergent atferd er nettopp det du ikke kan godkjenne på forhånd. Du kan bare begrense hva den er i stand til å nå.

Mottakeren ser volum, ikke intensjon

Den som drifter tjenesten i andre enden har ingen tilgang til dine gode hensikter. De ser en IP-adresse, et brukeragent-felt og et forespørselsmønster. Når mønsteret ser maskinelt ut, blir det behandlet som maskinelt, uavhengig av om agenten jobbet for en kunde eller en kriminell. Det er derfor identitet og tak ikke er byråkrati, men den eneste måten du kan gjøre deg kjennbar som en legitim aktør.

Volumeffekten rammer også systemer som ikke er tekniske. Googles program for sårbarhetsrapporter i åpen kildekode-økosystemet er frosset til minst neste år fordi mengden AI-genererte innsendinger økte betydelig (The Verge). Et mottakssystem som var dimensjonert for mennesker, tålte ikke agenter. Spør deg selv hvilke av dine egne mottakspunkter som har samme problem: skjemaer, supportkøer, søknadsflater, prøvekontoer.

Tallene som viser gapet mellom antall agenter og sikring

Gravitee spurte 750 senior teknologiledere i Storbritannia og USA, og gjentok målingen fra desember 2025. Hovedfunnet er ubehagelig enkelt: antall agenter har omtrent doblet seg, mens sikringen står nesten stille. 48 % av AI-agentene i produksjon kjører uten sikkerhet (gravitee.io, 2026). Det er ikke et modenhetsproblem som løser seg av seg selv, for veksten skjer raskere enn opprydningen.

Måltall	Desember 2025	April 2026
Agenter per virksomhet (snitt)	~37	Omtrent dobbelt så mange
Virksomheter med mer enn 100 agenter	Ikke oppgitt	38 %
Gjennomsnittlig overvåkingsdekning	Noen prosentpoeng lavere	52 %
Opplevd eller mistenkt hendelse siste år	Ikke oppgitt	54 %
Alle agenter fullt sikret før produksjon	Ikke oppgitt	Under en femtedel

Tabellen oppsummerer utviklingen slik Gravitee rapporterer den (gravitee.io, 2026). Overvåkingsdekningen flyttet seg noen prosentpoeng mens flåten doblet seg. I absolutte tall betyr det at antallet uovervåkede agenter har økt kraftig, selv om prosenten ser bedre ut.

Flåten vokser raskere enn sikringen

De aller fleste organisasjonene planlegger å sette ut flere agenter de neste tolv månedene, og forventningen er at en gjennomsnittlig Fortune 500-virksomhet har rundt 150 000 agenter innen 2028 (gravitee.io, 2026). Tallet for storkonsern er ikke direkte overførbart til en norsk SMB, men retningen er: antall ikke-menneskelige brukere i systemene dine vil overstige antall menneskelige, og det vil skje raskere enn du rekker å bygge prosess.

Sikringen fordeler seg skjevt. Bare et lite mindretall av organisasjonene sikrer mer enn 81 % av agentene sine. Det betyr at «vi jobber med sikkerhet rundt agenter» i de fleste virksomheter betyr at noen få agenter er godt sikret, og resten lever i et grått område ingen har oversikt over. Den gråsonen er der hendelsene oppstår.

Kontrollene før produksjon er svakere enn de fleste tror de er. Under en femtedel sier at alle agenter er fullt sikret og styrt før de settes i drift, mens flertallet sier at de fleste er det (gravitee.io, 2026). «De fleste» er et godt svar i en spørreundersøkelse og et dårlig svar i en revisjon.

Hendelsene har allerede skjedd

54 % av organisasjonene har opplevd eller mistenkt en sikkerhets- eller personvernhendelse knyttet til AI-agenter det siste året (gravitee.io, 2026). Dette er ikke en fremtidsrisiko du kan planlegge for i neste budsjettrunde. Det er en pågående feilrate i et felt som fortsatt omtales som nytt.

Bransjeforskjellene er store, og telekom rapporterer klart flest hendelser. Forklaringen er sannsynligvis en kombinasjon av flere agenter, flere integrasjoner og bedre deteksjon. For en SMB er den praktiske lesningen at lav rapportert hendelsesrate ofte betyr dårlig logging, ikke god sikkerhet. Du finner ikke det du ikke måler.

Samtidig sier 81 % at de føler press på å sette agenter i produksjon raskt, også uten full sikkerhet på plass, mens bare et mindretall mener adopsjonstempoet er for raskt (gravitee.io, 2026). Det er en organisasjon som løper og samtidig mener at farten er riktig. Presset er ekte, men det er et ledelsesvalg, ikke en naturlov.

Fem grenser å sette før agenten får snakke med omverdenen

Dette er kjernen. Fem grenser, satt før første produksjonskall, dekker de fleste måtene en agent kan skade deg eller noen andre. Ingen av dem krever ny teknologi eller stort budsjett. De krever at noen tar en beslutning og skriver den ned.

Grense	Spørsmålet den besvarer	Minimum før produksjon
Identitet	Hvem er agenten, sett utenfra?	Egen konto og egen nøkkel, ikke en ansatts innlogging
Tilgang	Hva får den treffe?	Hviteliste av endepunkter, lesetilgang først
Tak	Hvor mye får den gjøre?	Grense per minutt, per døgn og i kroner, med hard stopp
Logg	Kan vi rekonstruere hva den gjorde?	Hvert utgående kall logget med agent-ID og utfall
Eierskap	Hvem svarer for atferden?	En navngitt person, ikke et team

Rekkefølgen er bevisst. Uten identitet kan du ikke begrense tilgang. Uten tilgangsgrense betyr taket lite. Uten logg vet du ikke om grensene holder. Og uten eier er det ingen som rydder når noe ryker.

Grense 1: Egen identitet mot hver ekstern tjeneste

Alura mener agenter bør ha egen identitet og egne nøkler mot eksterne tjenester, aldri en ansatts innlogging. Grunnen er praktisk, ikke prinsipiell. Når agenten bruker Kari sin konto, kan du ikke trekke tilgangen uten å ta fra Kari verktøyet hennes, du kan ikke skille agentens kall fra hennes i loggen, og den dagen Kari slutter, slutter også store deler av integrasjonsporteføljen å virke. Leverandøren i andre enden ser dessuten et menneske som oppfører seg som en maskin, og behandler kontoen deretter.

Egen identitet betyr tre konkrete ting: en egen konto eller tjenestebruker hos leverandøren, en nøkkel som bare den agenten bruker, og et gjenkjennelig brukeragent-felt med et kontaktpunkt. Det siste er undervurdert. En agent som identifiserer seg tydelig og oppgir hvor man klager, blir sjelden blokkert først.

Det finnes et motargument: egne identiteter gir flere nøkler å håndtere, og nøkler som ligger spredt er en risiko i seg selv. Det er riktig. Svaret er et sentralt sted for hemmeligheter og rotasjon, ikke å gå tilbake til delte innlogginger. Mange delte kontoer er en verre variant av det samme problemet, bare uten oversikt.

Grense 2: Et avgrenset sett endepunkter

En agent skal ikke ha «tilgang til internett». Den skal ha tilgang til en liste. Lista er kort, den er skrevet ned, og alt utenfor lista blir avvist av noe som ikke er modellen selv. Dette er forskjellen mellom å instruere agenten om hva den ikke skal gjøre, og å gjøre det umulig. Instruksjoner i en systemprompt er en anbefaling. En utgående brannmur eller en gateway er en grense.

Alura mener du bør starte med lesetilgang og eksplisitte tak på forespørsler, og først utvide når logging og overvåking er på plass. Skriveoperasjoner mot eksterne systemer er det som skaper saker som Wikimedia-saken, der redigering i andres systemer er en del av anklagen (The Verge). Les først, skriv senere, og skriv aldri uten at kallet kan spores til en beslutning.

For kjøp, utsendelse av e-post, sletting og alt annet som er vanskelig å reversere, bør grensen være et menneske i løkken. Ikke fordi mennesket er smartere, men fordi mennesket bremser. En agent som kan gjøre mange irreversible handlinger i minuttet trenger ikke bedre dømmekraft, den trenger en lavere maksfart.

Grense 3: Tak på forespørsler, tid og kroner

Tre tak, ikke ett. Forespørsler per minutt beskytter mottakeren mot deg. Forespørsler per døgn beskytter deg mot en løkke som går i ring hele natten. Kronetak beskytter budsjettet mot et modellkall som plutselig koster langt mer enn planlagt. Alle tre skal være harde: når taket nås, stopper agenten, den skalerer ikke ned og prøver igjen.

Taket skal settes der agenten er ubehagelig stram, ikke der den er komfortabel. En agent som treffer taket to ganger i uken gir deg et signal om at noe er i ferd med å endre seg. En agent med rikelig takhøyde gir deg ingen informasjon før regningen eller klagen kommer.

Husk at taket også er et løfte til motparten. Millioner av automatiserte forespørsler mot en ekstern tjeneste er sjelden et bevisst valg, det er fraværet av et tak (The Verge). Hvis du har en avtale med leverandøren, bør taket ditt ligge godt under det avtalen tillater.

Grense 4: Logg som kan leses i ettertid

Minimumskravet er at du kan svare på dette spørsmålet fra en leverandør eller en kunde: «Hva gjorde agenten deres klokken 03.14 i natt?» Det krever at hvert utgående kall logges med tidspunkt, agent-ID, endepunkt, hvilket oppdrag som utløste det, og hva svaret var. Modellens interne tankerekke er interessant for feilsøking, men det er kallhistorikken som avgjør en tvist.

Gjennomsnittlig overvåkingsdekning er 52 % av agentene, og den flyttet seg bare noen prosentpoeng gjennom en periode der flåten doblet seg (gravitee.io, 2026). Det betyr i praksis at omtrent annenhver agent i markedet ikke kan gjøres rede for i ettertid. Du vil ikke være i den halvdelen den dagen noen spør.

Logg uten varsling er arkiv. Sett minst to alarmer: en når en agent treffer taket sitt, og en når den begynner å treffe endepunkter den ikke har truffet før. Den andre er den viktigste, fordi ny atferd er det tidligste tegnet på at oppdraget har glidd.

Grense 5: En navngitt eier

Alura mener at en agent uten navngitt eier ikke skal i produksjon, og at ansvar for atferd må ligge på en person, ikke på et team. Dette er den billigste grensen på lista og den som oftest mangler. Bare et lite mindretall av organisasjonene har en navngitt person med formelt ansvar for AI-agenters atferd (gravitee.io, 2026).

Eieren trenger ikke være tekniker. Eieren må kunne beskrive hva agenten skal oppnå, hvem som blir skadelidende om den feiler, og hvem som kan slå den av. Ansvaret er kommunikativt og organisatorisk, ikke bare teknisk. Når ansvaret ligger på «plattformteamet», ligger det ingen steder klokken 03.14.

Praktisk test: skriv navnet i agent-kortet, og send personen en e-post der det står hva de har sagt ja til. Hvis ingen vil ha navnet sitt der, har du funnet ut noe viktig om agenten før den gikk i produksjon.

Mandag morgen: de første grepene i egen virksomhet

Grensene over er lette å være enig i og lette å utsette. Det som gjør dem konkrete er en kartlegging, et kort dokument per agent og en stoppknapp som finnes utenfor hodet til en enkelt utvikler. Alt tre kan være på plass i løpet av en arbeidsuke i en virksomhet med ti til to hundre ansatte.

Kartlegg hva som allerede kaller ut

Start med å finne ut hva som faktisk sender trafikk ut av virksomheten i dag. Se i utgående trafikklogger, i listen over API-nøkler hos de viktigste leverandørene, i fakturaene fra modellleverandørene, og i automatiseringsverktøyene avdelingene har kjøpt selv. Mellom en og to uker etter at en slik kartlegging starter, finner de fleste noe de ikke visste om.

Gjennomsnittsvirksomheten i Gravitees undersøkelse hadde rundt 37 agenter i desember 2025 og omtrent dobbelt så mange i april 2026, og 38 % hadde passert hundre agenter (gravitee.io, 2026). Tallene gjelder større britiske og amerikanske virksomheter, men mekanismen er den samme hos oss: agenter oppstår i avdelingene, ikke i arkitekturdokumentet.

Resultatet av kartleggingen skal være en liste, ikke en rapport. Navn, hva den gjør, hvilken nøkkel den bruker, hvem som lagde den. Alt som ikke har en eier etter denne øvelsen, skrus av. Det er raskere å skru noe på igjen enn å forklare en kunde hvorfor det kjørte.

Skriv agent-kortet på en side

Et agent-kort er et kort dokument per agent som gjør grensene etterprøvbare. Det tar tjue minutter å fylle ut og er det eneste du trenger å vise frem når en revisor, en kunde eller en leverandør spør.

Felt	Hva som skal stå
Navn og formål	En setning om hva agenten skal oppnå
Eier	Navn på en person, med dato for ja
Identitet	Hvilken konto og nøkkel den bruker, hvor nøkkelen ligger
Tillatte endepunkter	Eksplisitt liste, lese eller skrive markert per linje
Tak	Per minutt, per døgn, kroner per måned
Logg og varsling	Hvor loggen ligger, hvem som får alarm
Stoppknapp	Hvordan den skrus av, og hvem som kan gjøre det
Neste gjennomgang	Dato, maks tre måneder frem

Gjennomgangsdatoen er viktigere enn den ser ut. Agenter endrer atferd når modellen bak oppdateres, når et API endrer svarformat, eller når noen justerer prompten for å løse et akutt problem. Et kort uten gjennomgangsdato beskriver agenten slik den var, ikke slik den er.

Sett en stoppknapp noen faktisk finner

Spør deg selv hvem som kan stanse alle utgående agentkall i løpet av fem minutter en søndag kveld. Hvis svaret er en enkelt person, og den personen er på hytta, har du ikke en stoppknapp. Du har en avhengighet.

Minimumsløsningen er at nøkler kan deaktiveres sentralt, at det finnes en dokumentert kommando eller et skrudd bryter i et grensesnitt, og at to personer vet hvordan. Test den en gang. En stoppknapp som aldri er prøvd er en antakelse.

Dette er også der du oppdager om agenten er for tett vevd inn i noe kritisk. Hvis det føles umulig å skru den av fordi fakturaløpet stopper, har du en agent som allerede har mer makt enn grensene dine tilsier. Det er bedre å finne ut nå enn under en hendelse.

Trafikken går begge veier, også inn mot dine innloggingssider

Så langt har vi sett utover. Den andre delen av problemet er at andres agenter kommer inn mot deg, og at de aller fleste nettsteder ikke er forberedt på det. DataDome analyserte trafikk fra over 75 000 kundesider og testet over 20 000 populære nettsteder i 2026 (datadome.co). Funnene er entydige: trafikken fra agenter vokser raskt, og beskyttelsen blir svakere.

Observasjon	Tall	Periode
AI-agent-forespørsler mot høyrisiko-endepunkter	605,6 millioner	H1 2026
Månedlige AI-botforespørsler mot innloggingssider	11,9 millioner til 99,7 millioner	Januar til juni 2026
Andel av ondsinnet bottrafikk fra enkle boter	49 %	2026
Økning i AI-agent-spoofing	45 %	Februar til juli 2026
Testede nettsteder uten beskyttelse mot de 10 bottypene	Flertallet	2026

Innloggingssiden er der agentene samler seg

Den største delen av AI-agent-trafikken mot høyrisiko-endepunkter gikk til innloggingssider, og aktiviteten mot disse sidene økte mer enn 8x i første halvår 2026 (datadome.co). Det er logisk: innloggingssiden er der verdien ligger, og den er den eneste siden som finnes på nesten alle nettsteder, i omtrent samme form.

Effekten merkes nedstrøms. Falsk kontooppretting økte kraftig i samme periode. For en norsk SMB med en kundeportal betyr det støy i brukertallene, flere supportsaker, og i verste fall at legitime kunder låses ut fordi du skrur til tiltakene i panikk. Det er dyrere å rydde i etterkant enn å sette en grense før.

Et enkelt mottiltak er å behandle innloggingssiden som et eget endepunkt med egen overvåking: antall forsøk per IP, andel mislykkede forsøk, geografisk fordeling og brukeragent-mønstre. Du trenger ikke avansert verktøy for å se at noe har endret seg kraftig.

Beskyttelsen går ned, ikke opp

Flertallet av de testede nettstedene hadde ingen beskyttelse mot de ti bottypene som ble prøvd, og bare et lite mindretall oppnådde full beskyttelse. Andelen med full beskyttelse har falt hvert år siden 2024 (datadome.co). Angriperne forbedrer seg raskere enn forsvarerne, og forsvarerne har samtidig fått en ny trafikkategori de ikke hadde planlagt for.

Det overraskende er hvor lite avansert angrepene trenger å være. 49 % av den samplede ondsinnede bottrafikken kom fra enkle boter som ikke engang forsøkte å skjule at de var automatiserte, og bare noen få av de testede nettstedene stoppet alle disse (datadome.co). Mot mer avanserte varianter er bildet verre: enda færre stoppet alle boter som kjørte i en ekte nettleser.

Konklusjonen for de fleste norske virksomheter er nøktern. Du trenger ikke en plattform som stopper statsstøttede aktører. Du trenger tiltak som stopper det åpenbare, fordi det åpenbare utgjør den største delen av trafikken og slipper gjennom nesten overalt.

Hvordan skille gode agenter fra dårlige

Spørsmålet er ikke lenger «bot eller menneske», men «hvilken agent, på hvis oppdrag». Noen agenter kommer på vegne av kundene dine og bør slippe inn. Noen kommer for å kopiere innholdet ditt. Noen later som de er de første mens de er de andre: AI-agent-spoofing økte 45 % mellom februar og juli 2026 (datadome.co).

Praktisk håndtering i tre nivåer: slipp gjennom agenter som identifiserer seg og holder seg innenfor rimelig volum, strupe de du ikke kjenner, og blokker de som treffer innlogging, betaling eller søk med maskinell frekvens. Verifiser identitet mot leverandørens publiserte IP-områder der det finnes, ikke bare mot brukeragent-feltet, som hvem som helst kan skrive hva som helst i.

De aller fleste lederne 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). Gapet mellom «noe» og «svært» er omtrent der all reell risiko ligger.

Hvem svarer for agentens atferd når ingen er utpekt

Når en agent gjør noe galt mot en ekstern part, oppstår tre spørsmål samtidig: hva skjedde, hvem bestemte at det skulle kunne skje, og hvem retter det. De to første kan bare besvares om noen eier agenten. Det tredje blir fort alles problem og derfor ingens.

Markedet er tydelig på at dette er svakt. Under en tiendedel har en navngitt person med formelt ansvar for atferden, mens en god del flere oppgir at det finnes en navngitt ansvarlig som en kontroll før produksjon (gravitee.io, 2026). Avstanden mellom de to svarene forteller sin egen historie: en del virksomheter har en ansvarlig i prosessen, men ikke en ansvarlig for atferden etterpå.

Fra teamansvar til personansvar

Teamansvar fungerer for kodekvalitet og dårlig for hendelser. Et team kan eie en kodebase fordi arbeidet er kontinuerlig og synlig. En hendelse krever at noen tar en beslutning raskt, med ufullstendig informasjon, og står for den etterpå. Det er en personoppgave.

Innvendingen er rimelig: ingen vil ha personlig ansvar for noe de ikke kontrollerer. Svaret er at eierskap må komme med myndighet. Eieren må kunne stanse agenten, nekte en utvidelse av tilgangen og kreve logging før neste steg. Ansvar uten vetorett er bare risikoflytting, og det merker folk.

Spørsmålene eieren skal kunne svare på

Fire spørsmål, uten forberedelse: Hvilke eksterne tjenester treffer agenten din? Hva er taket? Hvor er loggen? Hvem skrur den av hvis du er utilgjengelig? En eier som ikke kan svare, er en eier på papiret, og en eier på papiret er grunnen til at 48 %-tallet finnes.

Legg til et femte spørsmål for alvoret: hva er det verste denne agenten kan gjøre mot noen utenfor virksomheten? I Wikimedia-saken er svaret redigeringer i andres systemer, forsøk på å utnytte et verktøy og belastning som kan ha bidratt til nedetid (The Verge). Hvis ingen i din organisasjon har formulert det verste tilfellet, er grensene satt tilfeldig.

Markedet og kostnaden: hva verktøyene dekker og hva du må gjøre selv

Det finnes et voksende marked for agent-sikkerhet, og det selges som en pakke. Det er det ikke. Verktøyene dekker fire ganske ulike oppgaver, og de to viktigste grensene på lista vår, tak og eierskap, kan ikke kjøpes.

Kategori	Hva det løser	Hva du fortsatt må gjøre selv
API- og agent-gateway	Hvitelisting av endepunkter, strupe trafikk, sentral logg på utgående kall	Bestemme hvilke endepunkter som er lov, og sette tallet på taket
Bot- og agent-håndtering	Skille agenttrafikk fra menneskelig trafikk inn mot dine flater	Bestemme hvilke agenter som skal slippe inn, og håndtere falske positive
Hemmelighetshåndtering	Lagring og rotasjon av nøkler per agent	Faktisk gi hver agent egen nøkkel, og rydde i de gamle
Observerbarhet	Samle kall, kostnad og feilrater på ett sted	Definere hva som utløser alarm, og hvem som får den
Avtaleverk	Ingenting teknisk	Regulere agentbruk i kunde- og leverandøravtaler

Hva kostnaden egentlig består av

Lisenskostnaden er sjelden den største posten. Den største posten er arbeidet med å kartlegge hva som finnes, rydde i delte nøkler, skrive agent-kort og bemanne alarmene som nå faktisk går av. Et verktøy som oppdager avvik uten at noen leser varslene, gjør kostnaden synlig og risikoen uendret.

Den andre skjulte kostnaden er modellbruken selv. En agent som gjentar seg selv er en agent som betaler per gjentakelse. Kronetaket fra grense tre er derfor like mye en økonomisk kontroll som en sikkerhetskontroll, og den enkleste å få finansiert, fordi den gir en tydelig post i budsjettet i stedet for en overraskelse.

Den tredje posten er tapt tempo. Grenser gjør utrulling saktere, og 81 % rapporterer press på å gå raskt (gravitee.io, 2026). Det er en reell avveining og bør diskuteres som en avveining, ikke pakkes inn i sikkerhetsspråk. Et godt kompromiss er at grensene er faste, men at godkjenningsveien er kort: en side, en eier, en time.

Når det er for tidlig å kjøpe

Hvis du ikke vet hvor mange agenter du har, er det for tidlig å kjøpe en plattform for å styre dem. Kartlegging først, verktøy etterpå. Ellers kjøper du et dashbord som viser deg en pen delmengde av virkeligheten og gir deg en falsk trygghet som er verre enn ingen trygghet.

Et rimelig første nivå for en SMB er: hemmeligheter på ett sted, utgående kall gjennom en felles vei som kan loggføre og strupe, og standard bot-beskyttelse foran innlogging og skjemaer. Det dekker de vanligste feilene. Spesialiserte agent-plattformer blir relevante når antall agenter passerer det en person kan holde i hodet.

Regulering henger etter, og ansvaret blir ditt

Mange ledere venter på at regelverket skal fortelle dem hva som er godt nok. Det kommer til å ta tid, og fraværet av spesifikke agentregler er ikke fraværet av ansvar. Et mindretall mener dagens regulering er tilstrekkelig for risikoen AI-agenter representerer (gravitee.io, 2026). Det er lederne selv som sier at rammeverket de opererer under, ikke dekker det de holder på med.

Reglene du allerede er bundet av

Personopplysningsloven og GDPR bryr seg ikke om at behandlingen ble gjort av en agent. Hvis agenten henter, lagrer eller sender personopplysninger, er du behandlingsansvarlig på samme måte som før, og du må kunne forklare hva som ble behandlet og hvorfor. En agent uten logg er et dokumentasjonsproblem før det er et sikkerhetsproblem.

Opphavsrett og bruksvilkår gjelder også. Skalaen i AI-generert innhold presser rettighetshavere til motsvar: Sony Music har sendt nesten dobbelt så mange nedtakingskrav for AI-spor som imiterer artistene deres, målt mot tidligere 135 000 forespørsler (The Verge). Når volumet øker, øker også sannsynligheten for at noen går etter den som står bak volumet.

Til sist gjelder vanlig avtalerett. Hvis agenten bryter bruksvilkårene til en tjeneste du har avtale med, er det du som har brutt avtalen, ikke modellen. «Agenten gjorde det selv» er ikke et forsvar som har båret noe sted.

Kontrakten er raskere enn lovverket

Det raskeste styringsverktøyet du har, er dine egne avtaler. To tillegg dekker mye: i leverandøravtaler, en setning om at du bruker automatiserte agenter med identifiserbar identitet og avtalte tak. I kundeavtaler og i vilkårene på egne flater, en setning om hvilke automatiserte tilganger som er lov mot dine systemer, og hva som skjer ved brudd.

Dette koster en time hos en jurist og gir deg noe å peke på i både retninger. Det er også den eneste delen av agent-sikkerhet du kan ha ferdig før sommerferien uten å røre et eneste system.

Markedsobservasjon: tallene kommer fra leverandører med egeninteresse

Alura mener at rapportene om agent-sikkerhet kommer fra leverandører med egeninteresse, at retningen i tallene er troverdig, men at de bør brukes som indikasjon, ikke som fasit. Gravitee selger API- og agent-styring. DataDome selger bot- og agent-beskyttelse. Begge rapportene måler nøyaktig det problemet produktet deres løser. Det gjør dem ikke feil, men det gjør dem ikke nøytrale.

Hva som er svakt i datagrunnlaget

Gravitees funn bygger på 750 selvrapporterende ledere i Storbritannia og USA (gravitee.io, 2026). Selvrapportering om egen sikkerhetsmodenhet går systematisk i gunstig retning, og norske SMB-er er ikke i utvalget. DataDomes tall kommer fra trafikk hos egne kunder og fra tester av populære nettsteder (datadome.co), altså fra et utvalg som er mer utsatt og mer trafikkert enn gjennomsnittet.

Et tall bør gjøre deg ekstra forsiktig. Andelen som bekreftet en sikkerhetshendelse falt kraftig fra desember 2025 til april 2026, mens andelen som har opplevd eller mistenkt en hendelse ligger på 54 % (gravitee.io, 2026). En så stor bevegelse på fire måneder skyldes sannsynligvis endret spørsmålsstilling eller endret deteksjon, ikke at verden ble tryggere. Bruk retningen, ikke desimalene.

Slik leser du dem likevel

Tre funn er robuste nok til å handle på, fordi de peker samme vei fra uavhengige målinger. Antall agenter vokser raskere enn kontrollene rundt dem. Innloggingssider og andre høyrisiko-endepunkter får kraftig økning i agenttrafikk. Og formalisert ansvar er unntaket, ikke regelen.

Det du ikke bør gjøre, er å bruke prosentene som mål for egen virksomhet. At 52 % overvåkingsdekning er markedssnittet betyr ikke at 52 % er godt nok hos deg. Mål i stedet to egne tall: andel agenter med navngitt eier, og andel utgående kall som er logget. Begge skal være 100 %, og begge kan du telle selv.

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

Mønstrene nedenfor går igjen, og de har lite å gjøre med teknisk kompetanse. De handler om at agenter vokser inn i virksomheten gjennom små, fornuftige beslutninger som ingen samlet har sett.

Agenten låner en ansatts innlogging

Dette er den vanligste og den dyreste. Det starter fordi det er raskest: utvikleren limer inn sin egen nøkkel for å få piloten til å virke. Nøkkelen blir værende. Nå kan du ikke skille agentens handlinger fra menneskets i noen logg, du kan ikke trekke tilgangen uten å ramme en ansatt, og leverandøren ser en brukerkonto som bryter vilkårene for personlig bruk.

Ryddejobben er enkel men kjedelig: lag tjenestebrukere, bytt nøklene, bekreft at ingenting ble ødelagt, og revoker de gamle. Gjør det i den rekkefølgen. Mange stopper etter steg tre, og da har du dobbelt så mange aktive nøkler som før.

Pilottilgangen blir produksjonstilgang

I piloten ga noen agenten bred tilgang for å se hva den kunne gjøre. Det var riktig i piloten. Feilen er at tilgangen aldri ble strammet inn når agenten gikk i drift, fordi innstramming ville kreve testing og testing ville ta tid. Under en femtedel av organisasjonene sier at alle agenter er fullt sikret før de settes i produksjon (gravitee.io, 2026).

Motgiften er en regel, ikke en god intensjon: tilgang gitt i en pilot utløper på en dato. Skriv datoen i agent-kortet. Da blir innstramming en planlagt oppgave i stedet for en frivillig dugnad.

Ingen tak, ingen logg, ingen alarm

Den tredje feilen er å tro at en agent som har oppført seg pent i tre måneder, vil fortsette med det. Agentens atferd er en funksjon av modellen, prompten, dataene den leser og API-ene den møter. Alle fire endrer seg uten at du gjør noe. Uten tak merker du ikke endringen, uten logg kan du ikke forklare den, og uten alarm får du vite det fra noen andre.

Det billigste tiltaket i hele artikkelen er en alarm som varsler når en agent treffer et endepunkt den ikke har truffet før. Den fanger både glidning i oppdraget og den typen rekognoserende atferd som står sentralt i Wikimedia-saken (The Verge).

Spørsmål og svar om sikring av AI-agenter

Spørsmålene under er de vi oftest møter fra ledere og produktansvarlige som skal ta en beslutning om agenter denne måneden.

Hvor mange agenter har en vanlig virksomhet?

Flere enn du tror, og flere enn noen har skrevet ned. I Gravitees utvalg lå snittet rundt 37 agenter i desember 2025, og i april 2026 hadde 38 % av organisasjonene passert hundre (gravitee.io, 2026). Tallene gjelder større britiske og amerikanske virksomheter. For en norsk SMB er det relevante svaret at antallet er ukjent til noen har kartlagt det, og at kartleggingen nesten alltid finner noe uventet.

Må en agent ha egen identitet selv i en liten virksomhet?

Ja, og det er enklere i en liten virksomhet enn i en stor. Med fem agenter er fem tjenestebrukere og fem nøkler en halv dags arbeid. Med femti agenter er det et prosjekt. Gjør det mens det er billig. Den dagen en ansatt slutter eller en nøkkel lekker, er forskjellen mellom en rutinejobb og en krise.

Hva er forskjellen på bot-beskyttelse og agent-sikkerhet?

Bot-beskyttelse handler om trafikken som kommer inn mot dine flater. Agent-sikkerhet handler om agentene du selv sender ut. Du trenger begge, og de kjøpes vanligvis fra ulike leverandører. Det inngående problemet er størst for virksomheter med innloggingsflater og offentlig innhold, der den største delen av agenttrafikken mot høyrisiko-endepunkter gikk til innlogging (datadome.co).

Bør vi blokkere alle AI-agenter fra nettsiden vår?

Sjelden lurt. En del av trafikken er agenter som handler på vegne av potensielle kunder, og synlighet i AI-genererte svar er blitt en reell kanal. Et bedre utgangspunkt er lagdeling: åpent innhold tilgjengelig med rimelige tak, mens innlogging, betaling, skjemaer og søk får streng behandling. Vurder samtidig at AI-agent-spoofing økte 45 % mellom februar og juli 2026 (datadome.co), så identitet bør verifiseres og ikke bare leses av.

Hvem bør eie agentene hos oss?

Den som eier resultatet agenten skal levere, ikke den som bygget den. En salgsagent eies av salgsledelsen, en supportagent av supportlederen. Teknologi støtter, forretningen eier. Bare et lite mindretall av organisasjonene har i dag en navngitt person med formelt ansvar for agentatferd (gravitee.io, 2026), så dette er et område der du kan være raskt bedre enn markedet med en enkel beslutning.

Hva gjør vi hvis en agent allerede har gjort noe mot en ekstern part?

Stopp agenten, sikre loggene før de roteres, og kontakt motparten selv i stedet for å vente på at de kontakter deg. Deretter dokumenter hva som skjedde, hvilken grense som manglet, og hva som ble endret. Saker eskalerer sjelden på grunn av hendelsen alene, de eskalerer fordi mottakeren opplever at ingen svarer og ingen tar ansvar (The Verge).

Oppsummering og tre grep denne uken

Agenter er nyttige nettopp fordi de handler uten å spørre. Det er også hele risikoen. Du kan ikke godkjenne atferden deres på forhånd, så du må godkjenne rammen: hvilken identitet de har, hvilke endepunkter de får treffe, hvilket tak de har, hva som logges og hvem som svarer for dem. Fem beslutninger, som til sammen koster mindre enn en middels pilot.

Markedet er ikke der. 48 % av agentene i produksjon kjører uten sikkerhet, og under en tiendedel av virksomhetene har en navngitt ansvarlig (gravitee.io, 2026). Samtidig blir flatene våre testet hardere: to av tre nettsteder i DataDomes test hadde ingen beskyttelse mot boter og agenter i det hele tatt (datadome.co). Det betyr at avstanden til å være bedre enn gjennomsnittet er kort, og at det første skrittet ikke er teknisk.

Tre grep denne uken

Ett: lag lista. Finn alt som sender trafikk ut av virksomheten i dag, med navn, nøkkel og formål. Alt uten eier skrus av innen fredag. Dette er den eneste oppgaven som må gjøres først, fordi alle de andre forutsetter at du vet hva du har.

To: sett navn på eiere. En person per agent, skrevet ned, med et ja på e-post og en dato for neste gjennomgang. Eieren får samtidig myndighet til å stoppe agenten og nekte utvidet tilgang. Uten den myndigheten er navnet pynt.

Tre: sett et tak og en alarm. Grense per minutt, per døgn og i kroner på hver agent som snakker utover, og en varsling når en agent treffer et nytt endepunkt. Start med lesetilgang og stram tak, og utvid først når loggen virker. Hvis du bare får gjort ett av de tre grepene, gjør grep nummer to: det er gratis, og det er det som gjør at noen faktisk rydder i de to andre.

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

• gravitee.io (2026). State of AI Agent Security Report 2026 | Gravitee
• datadome.co. State of Bot & Agent Security Report 2026 | DataDome
• The Verge. Wikipedia operator says OpenAI's 'rogue' bots may be linked to a May outage