Slik sikrer du AI-agenter under kjøring

Nøkkelinnsikt

• Hardkodede API-nøkler i AI-agenter er en tikkende bombe: én vellykket prompt-injeksjon gir angriperen full tilgang til alle tilkoblede tjenester
• Dynamiske legitimasjoner snur sikkerhetsmodellen: i stedet for permanent tilgang får agenten midlertidige nøkler som utløper automatisk etter sesjonen
• CIBA-standarden gjør telefonen til en godkjenningsknapp for sensitive operasjoner, og fanger opp uautoriserte handlinger selv om agenten er kompromittert

Kort fortalt

Tyler Lynch fra IBM tar tak i et problem de fleste utviklere ikke tenker over: AI-agenter trenger tilgang til databaser, LLM-er og SaaS-tjenester, men sikkerheten rundt disse tilgangene er som regel satt opp på gammeldags vis. Hardkodede API-nøkler (Application Programming Interface, hemmelige koder som lar ett program snakke med et annet) betyr at én angriper kan ta over alt. Lynch presenterer tre lag av sikkerhet som til sammen utgjør det han kaller "agentic runtime security."

Problemet med statiske nøkler

En AI-agent er egentlig et program. Det kan være skrevet i Python, TypeScript, Java eller noe annet. Agenten kjører et sted i skyen, kanskje på en skytjeneste som AWS Lambda eller i en container (en isolert pakke med alt programmet trenger for å kjøre), og for å gjøre noe nyttig må den koble seg til ting: en database, en stor språkmodell (LLM), en SaaS-tjeneste (skybasert programvare du leier) som Salesforce.

Den tradisjonelle måten å gi agenten tilgang på er å hardkode en statisk legitimasjon, altså en permanent API-nøkkel som ligger bakt inn i koden. Det er nettopp denne praksisen Lynch advarer mot.

"We actually recommend against that," sier han. Han bruker begrepet "non-human identity" om den digitale identiteten en AI-agent har, til forskjell fra en menneskelig bruker.

Problemet er ikke at nøklene eksisterer, men at de er permanente. Lykkes noen med en prompt-injeksjon (en skjult instruksjon i tekst som lurer agenten til å gjøre noe utilsiktet), har angriperen umiddelbart full tilgang til alt agenten kan nå: databasen, e-posten, CRM-systemet (kundeoppfølgingssystemet).

---

Lag 1: Dynamiske legitimasjoner

Den første løsningen er å bytte ut de permanente nøklene med midlertidige. Lynch kaller dette "just-in-time credentials": nøkler som opprettes akkurat når de trengs og slettes automatisk når sesjonen er over.

Tilgangsperioden kan være to minutter eller to sekunder. Det spiller liten rolle. Poenget er at det ikke finnes noe permanent å stjele. Selv om noen klarer å hente ut en nøkkel, er den allerede ugyldig.

Dette er det samme prinsippet som brukes i moderne skysikkerhet, der konseptet kalles zero-trust: gi bare akkurat den tilgangen som trengs, akkurat når den trengs. Nå tas det i bruk for AI-agenter.

---

Lag 2: Brukeridentitet via OAuth

AI-agenter brukes som regel av mennesker. Det åpner et nytt spørsmål: hvem er det egentlig som ber om tilgang?

Her kommer identitetsleverandøren inn. En identitetsleverandør (IDP) er en tjeneste som vet hvem du er, som Okta eller IBM Verify. Agenten kobler seg til IDP-en og arver brukerens identitet og rettigheter, i stedet for å ha sine egne permanente tilganger.

Dette er grunnlaget for single sign-on (SSO), altså at du logger inn én gang og har tilgang til alt du trenger. Det bygger på en standard kalt OAuth 2.0. Du har sannsynligvis sett den i praksis: når du klikker "Logg inn med Google" og ser en side som spør om du vil gi appen tilgang til profilen din, er det OAuth.

---

Lag 3: Godkjenning på telefonen for sensitive operasjoner

Noen handlinger er så sensitive at to lag ikke er nok. Tenk på en HR-applikasjon der agenten kan ansette eller si opp ansatte. Det er reelle konsekvenser for ekte mennesker.

For slike operasjoner anbefaler Lynch en standard kalt OAuth 2.0 CIBA (Client-Initiated Backchannel Authentication), der en app ber om godkjenning via en separat kanal. Han beskriver det som "passkeys for agents."

Slik fungerer det: når agenten ønsker å gjøre noe sensitivt, sender den en forespørsel til IDP-en, som igjen sender et push-varsel direkte til brukerens telefon. Utenfor nettleseren. Utenfor agentens rekkevidde. Du ser hva som skal skje, og godkjenner eller avslår.

Det er et kraftig vern mot prompt-injeksjon. Som Lynch sier: "If there was a prompt injection that said off-board all employees, I would get a notice for each one of those to my phone."

---

Hvorfor dette er viktig nå

De fleste som bygger AI-agenter i dag er ikke sikkerhetseksperter. De er flinke til å sette sammen fungerende prototyper, men kunnskap om identitetssikkerhet mangler som regel.

Resultatet er agenter som virker, men som er sårbare på måter utviklerne ikke ser. En hardkodet API-nøkkel er usynlig i koden inntil noen finner den.

De tre lagene Lynch beskriver er ikke nye ideer. Dynamiske legitimasjoner, OAuth og push-godkjenning er kjente teknikker fra skysikkerhet og mobil autentisering. Det nye er at de nå må tas i bruk for AI-agenter spesielt, fordi agenter handler på vegne av brukere og organisasjoner på en måte vanlige programmer ikke gjør.

---

Ordliste

---

Kilder og ressurser