Nøkkelinnsikt

• AI-agenter må sikres, styres og revideres. Uten alle tre mister du kontrollen over autonome systemer
• Promptinjeksjon er den vanligste angrepsvektoren mot store språkmodeller, og agenter forsterker skaden fordi de handler selvstendig
• Hver agent trenger egen identitet, tidsbegrenset tilgang og en AI-brannmur som inspiserer både LLM- og MCP-trafikk

---

Kort fortalt

IBM og Anthropic ga nylig ut en felles guide for hvordan bedrifter kan bygge sikre AI-agenter med MCP (Model Context Protocol). Jeff Crume, IBM Distinguished Engineer og CTO for IBM Security Americas, går gjennom dokumentet i denne videoen. Han forklarer hvilke trusler AI-agenter står overfor, hvilke designprinsipper som bør ligge i bunn, og hvordan et komplett sikkerhetsrammeverk ser ut i praksis.

---

Hva er en AI-agent?

En AI-agent er et system som forstår sammenhengen den befinner seg i, vurderer mål og tar handlinger gjennom verktøy og tjenester. Crume beskriver det som «modeller som bruker verktøy i en løkke». Det som gjør agenter spesielt kraftige er at de jobber selvstendig, uten at et menneske må godkjenne hvert steg.

Men med den kraften følger risiko. Agenter må operere innenfor klare grenser, gi sporbare beslutninger og overholde organisasjonens retningslinjer.

Ifølge Crume må agenter oppfylle tre krav (0:43):

• Sikret: Agenten skal ikke lekke data eller bli kapret av en angriper
• Styrt: Agenten skal være pålitelig og holde seg innenfor det den skal gjøre
• Revidert: Det skal være mulig å gå tilbake og sjekke at agenten fulgte retningslinjene og regelverket

---

Paradigmeskiftet: Fra kode til evaluering

Crume peker på et grunnleggende skifte i hvordan vi tenker om programvare (1:22):

Det viktigste skiftet er fra tekniske detaljer til måling av resultater. Spørsmålet er ikke lenger «fungerer koden?» men «beveger resultatene seg mot det vi ønsker?»

---

Utviklingslivssyklusen for agenter

Crume presenterer en livssyklus med seks steg (2:44):

Hele syklusen bygger på DevSecOps-tankegangen (Development + Security + Operations). Det betyr at sikkerhet er med fra starten, ikke noe som boltes på i etterkant (3:27). Crume understreker at dette er forskjellen mellom DevOps (utvikling + drift) og DevSecOps: sikkerhet settes inn i begynnelsen, midten og slutten av prosessen.

---

De syv sikkerhetstruslene

Crume lister opp syv konkrete trusler som AI-agenter står overfor (4:06):

1. Utvidet angrepsflate

Angrepsflaten (attack surface) er alle steder en angriper kan forsøke å komme inn. Hver ny teknologi legger til flere slike steder. AI-agenter legger til to nye angrepspunkter: selve AI-modellen og MCP-protokollen (4:13). MCP (Model Context Protocol) er protokollen som lar agenter snakke med verktøy og tjenester.

2. Overdreven tilgang

Agenten har mer tilgang enn den faktisk trenger. Crume kaller dette «excessive agency» (4:37).

3. Privilegieeskalering

Agenten tar det på seg selv å utvide sine egne rettigheter, noe som er uønsket med mindre det var planlagt (4:43).

4. Datalekkasje

Agenten lekker sensitiv informasjon til uautoriserte mottakere (4:48).

5. Promptinjeksjon

Den vanligste angrepsvektoren mot store språkmodeller (LLM-er). Noen injiserer kommandoer inn i systemet og tar på den måten kontroll over agenten utenfra (4:54).

6. Angrepsforsterking

Fordi agenter handler på egen hånd og i høy hastighet, kan en kapret agent forsterke skaden enormt (5:10). Det er forskjellen mellom en innbryter som går gjennom et hus manuelt og en som har tilgang til alle nøkler og kan jobbe i lysets hastighet.

7. Etterlevelsesdrift

Over tid kan agenten drifte bort fra regelverket og organisasjonens retningslinjer (5:27).

---

Systemkontroller og designprinsipper

Tre systemkontroller

Crume beskriver tre grunnleggende kontroller (5:39):

• Begrenset operasjon: Agenten må operere innenfor tydelige grenser
• Rollebasert tilgangsstyring (RBAC — Role-Based Access Control): Tildel roller til agenter, akkurat som til ansatte. Crume nevner også en alternativ tolkning: risikobasert tilgangsstyring, der risikofylte oppgaver krever strengere godkjenning (6:07)
• Sandkasse (sandboxing): La agenten operere i et isolert miljø slik at skaden begrenses hvis noe går galt (6:18)

Ni designprinsipper

Crume legger frem ni prinsipper som bygger på disse kontrollene (6:30). De kan grupperes i tre kategorier:

Grenser — hva agenten kan og ikke kan:

1. Akseptabel agens: Definer hva agenten skal og ikke skal gjøre
2. Prinsippet om minste privilegium (Least Privilege): Gi agenten kun den tilgangen den trenger for å gjøre jobben, og fjern den med en gang den ikke trengs lenger (7:47)
3. Sikkerhet fra starten: Sikkerhet som boltes på i etterkant fungerer dårlig
4. Risikoreduksjon: Ny teknologi introduserer ny risiko. Begrens den så mye som mulig

Observasjon — innsyn i hva agenten gjør:

5. Kontinuerlig observasjon: Ha innsyn i hva agenten gjør, fordi den jobber selvstendig (7:26)
6. Ytelsesmål (KPIer): Mål om agenten leverer det virksomheten trenger

Mennesker og organisasjon — rammene rundt agenten:

7. Menneske i løkken (Human in the Loop): Behold menneskelig kontroll og tilsyn (8:19)
8. Forretningstilpasning: Agenten må passe med organisasjonens mål
9. Interoperabilitet: Agenten må fungere med mange verktøy, men du må kjenne risikoen hvert verktøy skaper

Prinsippet om minste privilegium har ifølge Crume aldri vært viktigere enn nå, nettopp fordi agenter jobber selvstendig.

---

Sikkerhetsrammeverket i praksis

Crume går gjennom fire hovedelementer i et komplett sikkerhetsrammeverk.

1. Identitets- og tilgangsstyring

Agenter er ikke-menneskelige identiteter (nonhuman identities) og trenger egne unike påloggingsdetaljer (8:36). Akkurat som ansatte ikke skal dele passord, skal ikke agenter dele legitimasjon. Hvis noe går galt, må du kunne spore det tilbake til nøyaktig hvilken agent som var ansvarlig (8:55).

Tre konkrete tiltak:

• Tidsbegrenset tilgang (just-in-time access): Gi agenten tilgang kun når den trenger det, og fjern den etterpå. Det kan være minutter, timer eller en dag (9:12)
• Rollebasert tilgangsstyring: Tildel roller til agenter slik du gjør med brukere (9:22)
• Revisjon: Gå tilbake og verifiser at alle kontrollene fungerte som de skulle (9:35)

2. AI-brannmur for data og modell

I stedet for å la brukere snakke direkte med AI-modellen, anbefaler Crume å sette en AI-brannmur (AI firewall / gateway) mellom brukeren og modellen (10:01).

Denne brannmuren gjør to ting:

• Inspiserer innkommende trafikk til LLM-en for å oppdage promptinjeksjoner
• Inspiserer utgående trafikk via MCP-kall for å fange opp datalekkasjer (10:46)

Poenget er at samme brannmur kan beskytte både LLM-kommunikasjonen og MCP-trafikken.

3. Trusseldeteksjon

Crume beskriver tre lag av trusseldeteksjon (11:03):

4. Overvåking og drift

Det siste elementet handler om å oppdage endringer over tid (12:31):

• Konfigurasjonsdrift (configuration drift): Agenter som jobber med systemet kan endre sine egne parametere uten at noen ba om det. For eksempel: en agent som opprinnelig bare kunne lese filer, gir plutselig seg selv skrivetilgang
• Modelldrift (model drift): AI-modellens oppførsel endrer seg over tid på uventede måter. En agent som i januar svarte konservativt på spørsmål, kan i mars begynne å ta snarveier den ikke ble bedt om
• Tilgangsmønster-analyse: Hva gjør agenten faktisk, og gjør den de riktige tingene? Overvåk om agenten plutselig begynner å hente data den aldri har trengt før

---

Sjekkliste: Vanlige feil ved sikring av AI-agenter

• Deler agentene legitimasjon? Hver agent trenger sin egen unike identitet. Delt legitimasjon gjør det umulig å spore problemer tilbake til kilden
• Har agenten mer tilgang enn den trenger? Bruk prinsippet om minste privilegium. Gi kun den tilgangen som kreves for oppgaven, og fjern den etterpå
• Mangler du en AI-brannmur? Uten et mellomledd mellom brukere og AI-modellen har du ingen mulighet til å fange opp promptinjeksjoner eller datalekkasjer
• Er sikkerhet boltet på i etterkant? DevSecOps betyr at sikkerhet er med fra planleggingsfasen. Sikkerhet som legges til etter bygging er langt mindre effektivt
• Overvåker du bare reaktivt? Kombinasjon av sanntidsovervåking (reaktivt) og trusseljakt (proaktivt) gir bedre dekning enn bare alarmer
• Glemmer du etterlevelsesdrift? Agenter kan drifte bort fra retningslinjer over tid. Regelmessig revisjon og overvåking av konfigurasjon og modell er nødvendig

Praktiske implikasjoner

For nybegynnere

Start med de tre søylene: sikret, styrt og revidert. Før du gir en agent tilgang til verktøy, spør deg selv: «Hva er det verste som kan skje hvis denne agenten blir hacket?» Begrens agentens tilgang til kun det den trenger, og logg alt den gjør.

For team som bygger produksjonsagenter

Sett opp DevSecOps-livssyklusen fra dag én. Gi hver agent en unik identitet med tidsbegrenset tilgang. Plasser en AI-brannmur mellom brukere og AI-modellen for å fange opp promptinjeksjoner og datalekkasjer. Bruk RBAC til å styre hva agentene kan gjøre.

For organisasjoner med regulatoriske krav

Last ned IBM og Anthropics guide og kartlegg de ni designprinsippene mot organisasjonens egne retningslinjer. Sett opp revisjon som kan verifisere at kontrollene fungerer, og overvåk for konfigurasjonsdrift og modelldrift over tid.

Test deg selv

1. Overføring: Crume snakker om AI-agenter i bedriftsmiljøer. Hvordan ville de samme sikkerhetsprinsippene sett ut for en personlig AI-assistent som styrer smarthuset ditt?
2. Avveining: Prinsippet om minste privilegium sier at agenten kun skal ha tilgang til det den trenger. Men streng tilgangsstyring kan gjøre agenten mindre effektiv. Når ville du akseptert mer risiko for å få mer nytte?
3. Arkitektur: Design et overvåkingssystem for en AI-agent som håndterer kundedata. Hvilke alarmer ville du satt opp, og hvordan ville du balansert reaktiv overvåking med proaktiv trusseljakt?
4. Atferd: Crume anbefaler «menneske i løkken». Hvordan kan kravet om menneskelig tilsyn endre måten team organiserer arbeidet med AI-agenter?
5. Overføring: IBM og Anthropic fokuserer på MCP som protokoll. Hvordan ville rammeverket endret seg hvis agentene brukte en helt annen protokoll for verktøykommunikasjon?

---

Ordliste

---

Kilder og ressurser