Sikkerhet og kontroll i AI-agenter

Hva endrer seg når AI-en går fra å svare til å handle

I artikkelen om å koble AI til egne data forklarte vi hvordan koblingen gjøres; her tar vi kontroll-spørsmålet på alvor. En AI som svarer på spørsmål har begrenset skadepotensial. En AI-agent som handler, gjør mer. Den sender e-post, oppdaterer poster og kjører kommandoer på tvers av systemene dine.

Anthropic beskriver agenter som systemer som skriver og kjører kode, håndterer filer og fullfører oppgaver på tvers av flere programmer, og peker på at nettopp autonomien som gjør dem nyttige, også skaper en rekke nye risikoer.

To ting følger. For det første jobber en agent med mindre menneskelig tilsyn, og da er det mer rom for at den mistolker hva du mente. For det andre er et verktøykall i praksis kjøring av kode. Agenten utfører kommandoer med de rettighetene den er gitt.

Prompt injection er angrepet en SMB må forstå

Det viktigste angrepet å forstå kalles prompt injection. Det er ondsinnede instruksjoner skjult i innholdet agenten blir bedt om å behandle. Teksten lurer agenten til å gjøre noe annet enn du ba om.

Det finnes to varianter. I den direkte er brukeren selv angriperen, mest relevant for tjenester som er åpne for publikum. Den indirekte er den en SMB må forstå. Agenten behandler tredjepartsinnhold som nettsider, e-poster, dokumenter og verktøyresultater, med skjulte instruksjoner i seg.

En angriper som kan påvirke noe agenten leser (en innkommende e-post, en nettside eller resultatet av et verktøykall) kan plassere instruksjoner der som forsøker å omdirigere agenten. Anthropic understreker at verktøy-output er en angrepsflate selv når selve verktøyet er betrodd. Du kan stole fullt ut på systemet agenten henter data fra, og fremdeles få inn fiendtlig innhold gjennom dataene det returnerer. Rådet «bruk bare pålitelige verktøy» løser derfor bare halve problemet.

Hvilke kontrollmekanismer som faktisk finnes

Konkrete, veletablerte mekanismer for å holde agenten i sjakk finnes, og de fleste ligger i laget rundt modellen, i MCP og integrasjonene mot egne data. MCP-spesifikasjonen stiller kravene; implementasjonen må levere samtykke, sandkasse og minste privilegium i praksis. Kontroll er noe leverandøren bygger.

Godkjenningsdialoger alene er heller ikke nok. Da Claude Code ba om tillatelse ved hver handling, godkjente brukerne rundt 93 % av forespørslene rutinemessig, ifølge Anthropics egen telemetri. Ber man om godkjenning på alt, slutter folk å lese; kontroll må reserveres for handlingene som fortjener en vurdering. De sentrale mekanismene er disse:

• Samtykke før handling. Klienten viser en tydelig dialog med den nøyaktige, uforkortede kommandoen før noe kjøres. Du ser hva som skal skje, og godkjenner det.
• Tillatelsesnivåer per handling. Handlinger kan settes til «alltid tillat», «krever godkjenning» eller «blokker». Rutinehandlinger går glatt; de som fortjener et menneskelig blikk, stopper opp.
• Lese- versus skrivetilgang. En agent med kun lesetilgang kan tas i bruk langt bredere enn en som skriver til produksjonssystemene dine. Et vanlig oppsett tillater lesing og krever godkjenning for skriving, kjøring av kommandoer og nettverkstilgang.
• Sandkasse og minste privilegium. Verktøy kan kjøres i et innelukket miljø med minimale rettigheter og begrenset tilgang til filsystem, nettverk og øvrige ressurser. Tilgang gis smalt og gradvis.
• Screening av det agenten leser. Verktøy-output kan sjekkes av en lettvektsmodell før agenten handler på den. Med Anthropics ord er det to lag med forsvar, ett for hva agenten leser og ett for hva den gjør.
• Passord og nøkler utenfor agentens grense. De holdes utenfor miljøet agenten kjører i, og kan dermed ikke lekke gjennom agenten selv.
• Logging. Alt agenten gjør bør registreres, slik at det kan ettergås.

Hva norske myndigheter sier, anvendt på agenter

To norske kilder gir rammeverket du slipper å finne opp selv.

Først NSMs grunnprinsipper for IKT-sikkerhet. Det er generelle prinsipper som lar seg anvende direkte på agenter, og som med NSMs egne ord er «en nyttig, første byggestein». Tre er umiddelbart relevante.

Kartlegg tilgangsbehov (grunnprinsipp 1.3) handler om å ha oversikt over hvem som trenger tilgang til hva. NSM påpeker at overtilgang forsterker skade: «Hvis alle brukere har tilgang til for mye vil kompromittering av én bruker kunne kompromittere hele IKT-systemet.» En agent er i denne sammenhengen én slik «bruker».

Minste privilegiums prinsipp (grunnprinsipp 2.6) skiller eksplisitt mellom lese- og skriverettigheter: «ikke gi … flere privilegier enn nødvendig. Alle trenger ikke tilgang til alt. Og hvis man trenger tilgang så holder det ofte med lese-rettigheter, alle trenger ikke rett til å skrive, slette og kjøre.» Myndighetene og mekanismene over sier altså det samme.

Sikkerhetsovervåkning (grunnprinsipp 3.2) er den myndighetsforankrede begrunnelsen for logging fra dag én. Poenget er å samle inn data som avslører hendelser, for «angripere kan skjule tilstedeværelse, handlinger og aktiviteter».

Så personvernet. Behandler agenten personopplysninger, gjelder regelverket fullt ut, og Datatilsynet stiller fire krav som er praktisk viktigst.

Dataminimering gjelder all behandling av personopplysninger: «Begrens mengden personopplysninger … til det som er relevant og nødvendig for formålet.» Innebygd personvern og personvern som standard betyr at den behandlingsansvarlige skal «bygge personvern inn i løsningene sine og sørge for at personvernet er ivaretatt i standardinnstillingene», gjennom alle utviklingsfaser og i daglig bruk.

En personvernkonsekvensvurdering (DPIA) kreves når en behandling «sannsynligvis vil utgjøre en høy risiko for enkeltpersoners rettigheter og friheter». Kan ikke risikoen reduseres tilstrekkelig, skal man ha forhåndsdrøftelser med Datatilsynet. Og dokumentasjonsplikten: «Dokumenter hvordan kravene i personvernregelverket oppfylles». Kundene deres kommer til å spørre etter dette.

Restrisikoen og hvordan leve ansvarlig med den

Ingen seriøs leverandør lover at prompt injection er borte; den kan reduseres, men ikke elimineres. Anthropic oppgir fra egne tester at Claude Opus 4.7 holdt angrepssuksessen på rundt 0,1 % ved enkeltforsøk, men rundt 5–6 % etter 100 tilpassede forsøk. Tallene er produkt- og modellspesifikke, men mønsteret er det viktige. En tålmodig angriper som får prøve mange ganger, kommer nærmere.

Det praktiske svaret er lagdeling: smal tilgang (helst lesetilgang først), et menneske i sløyfen der det teller, screening av det agenten leser, og logging som lar deg oppdage og ettergå. En leverandør som sier dette høyt, er mer å stole på enn en som lover null risiko.

Hva en SMB bør ha på plass og spørre om

Å bygge dette er leverandørens jobb. Din jobb er å vite hva som skal være på plass, og hva du skal spørre om.

Fem ting bør være på plass før dere tar en agent i bruk. Start med lesetilgang, en agent som leser og foreslår, og utvid skrivetilgangen bevisst senere. Hold et menneske i godkjenningssløyfen for skrivehandlinger, reservert for det som betyr noe, så godkjenning ikke blir refleks. Og logg fra dag én, slik at alt agenten gjør kan ettergås.

Avgrens dessuten formålet. Agenten skal løse en definert oppgave, ikke ha åpent mandat. Dette henger sammen med problem-, datagrunnlags- og eierskapstesten fra vurderingen av når AI-agenter lønner seg. Er personopplysninger involvert, trengs en vurdering av personvernkonsekvensene og dokumentasjon av hvordan kravene oppfylles.

Still deretter leverandøren disse spørsmålene. Klarer de ikke å svare konkret, er det i seg selv et svar:

• Kjører agenten med lese- eller skrivetilgang, og hvordan skilles de to?
• Hvilke handlinger krever menneskelig godkjenning, og hvilke går automatisk?
• Hvordan håndteres indirekte prompt injection? Screenes verktøy-output, og har dere selv testet agenten med bevisste injection-forsøk (red teaming)?
• Hvor lagres passord og nøkler, og kan agenten selv nå dem?
• Logges alt agenten gjør, og hvem kan gå gjennom loggene?
• Er det gjort en personvernkonsekvensvurdering, og finnes dokumentasjonen kundene deres kan be om?

Slik jobber Agnito

Vi behandler sikkerhet og kontroll etter samme prinsipp som Datatilsynet stiller til personvern, bygget inn i løsningen og ivaretatt gjennom alle utviklingsfaser og i daglig bruk. Vi bygger agenter og automasjon integrert med systemene dere allerede bruker, med tilgangsstyring, logging, GDPR og datasuverenitet som del av selve designet.

Før vi bygger noe, vurderer vi problemet, datagrunnlaget og eierskapet, og vi sier fra tidlig hvis noe ikke bør bygges. Det er ofte det mest verdifulle vi gjør. Les mer under drift og sikkerhet og AI-agenter.