Slik sikrer du tillitskjeden i agentbasert AI

Nøkkelinnsikt

• Den største sikkerhetsrisikoen i agentbasert AI er ikke modellen i seg selv, men identitetskjeden som kobler bruker, agent og verktøy. De fleste AI-sikkerhetsdiskusjoner handler om modellsikkerhet, mens infrastrukturnivåets tillit blir oversett.
• Agenter trenger egne verifiserbare identiteter, ikke bare arvede brukertokens. En uautorisert agent kan utgi seg for enhver bruker dersom systemet bare sjekker brukerlegitimasjon og aldri autentiserer selve agenten.
• Send aldri identitetstokens til språkmodellen. Den trenger dem ikke, og prompt-injeksjon kan hente dem ut. En enkel regel som mange tidlige implementeringer bryter.

Kort fortalt

AI-agenter får stadig tilgang til ekte verktøy, API-er og databaser. Det skaper et tillitsproblem: hvordan sikrer du at kjeden fra bruker til agent til verktøy ikke brytes på noe punkt? Grant Miller, Distinguished Engineer hos IBM, går gjennom de fire hovedrisikoene i agentbaserte systemer og token-arkitekturen som håndterer hver enkelt. Sikkerhetsprinsippene er ikke nye (de første standardene dukket opp allerede i 1985), men agentbaserte systemer bringer unike utfordringer fordi AI-oppførsel er ikke-deterministisk.

Den agentbaserte flyten

Miller starter med å tegne opp en typisk agentbasert flyt: en bruker snakker med et chat-grensesnitt, som sender forespørsler til en orkestrator. Orkestratoren delegerer arbeid til én eller flere AI-agenter, som kommuniserer med MCP-servere (Model Context Protocol, en standard for å koble AI-modeller til eksterne verktøy), og disse serverne kobler seg videre til de faktiske verktøyene og datakildene.

Store språkmodeller sitter ved siden av denne flyten, ikke inni den. De hjelper chat-grensesnittet med å forstå brukerens intensjon, hjelper orkestratoren med å planlegge arbeidsflyten, og hjelper de enkelte agentene med å bestemme hvordan de skal svare. Men språkmodellene er rådgivende. Det faktiske arbeidet beveger seg gjennom kjeden.

En identitetsleverandør autentiserer brukeren ved start og utsteder et token. Det tokenet skal føres videre gjennom hele kjeden slik at hver komponent vet hvem brukeren er og hva de har lov til å gjøre. Problemet er at denne videreføringen kan brytes på minst fire måter.

Risiko 1: Legitimasjonsavspilling

Den første risikoen er legitimasjonsavspilling (credential replay), der en angriper stjeler et autentiseringstoken og bruker det på nytt for å få uautorisert tilgang. Miller beskriver to måter dette skjer på. I det ene scenarioet inkluderer utviklere ved et uhell brukerens token i prompter som sendes til språkmodellen. En ondsinnet aktør kan da bruke prompt-injeksjon (inndata formulert for å lure modellen til å avsløre informasjon) til å hente ut tokenet. I det andre scenarioet avlytter et man-in-the-middle-angrep tokens mellom komponenter fordi forbindelsene ikke er kryptert.

Løsningen er todelt. Bruk TLS eller mTLS (gjensidig TLS, der begge sider av en forbindelse verifiserer hverandre) gjennom hele kommunikasjonsflyten, og krypter alle lagrede legitimasjoner. Den andre delen er enda enklere: ikke send identitetsinformasjon til språkmodellen. Den trenger det ikke. Språkmodellens jobb er å forstå oppgaven, ikke å vite hvem som spør. Holder du tokens borte fra prompter, eliminerer du en hel klasse av angrep.

Risiko 2: Uautoriserte agenter

Den andre risikoen er uautoriserte agenter som utgir seg for å være legitime agenter. En ukjent agent dukker opp, påstår den er del av arbeidsflyten, og ber om tilgang til verktøy eller data som er ment for den ekte agenten.

Løsningen speiler hvordan bedrifter allerede håndterer menneskelige brukere: gi agenter egne identiteter gjennom en identitetsleverandør, og autentiser dem. Når agent én sender arbeid videre til agent to, kan agent tos identitet valideres mot leverandøren. Den samme sjekken skjer hos MCP-servere. Kan ikke en agent bevise identiteten sin, får den ikke tilgang. Dette er et skifte fra tradisjonelle autentiseringssystemer, som forutsetter at hver aktør er et menneske.

Risiko 3: Identitetstyveri gjennom delegering

Selv om du vet at en agent er autentisk, trenger du fortsatt bevis for at den faktisk handler på vegne av en bestemt bruker. Uten det beviset kan enhver autentisert agent påstå å representere enhver bruker. Miller kaller dette identitetstyveri (impersonation), og løsningen er delegeringstokens.

Et delegeringstoken kombinerer to opplysninger: subjektet (brukeren) og aktøren (agenten). Når brukeren autentiserer seg og en agent autentiserer seg separat, utsteder identitetsleverandøren et kombinert token som binder dem sammen. Når dette tokenet beveger seg gjennom flyten, kan enhver komponent verifisere både hvem brukeren er og hvilken agent som handler på deres vegne. Ingen agent kan påstå sin egen delegering. Den må valideres og utstedes av identitetsleverandøren.

Token-utveksling skjer ved hvert hopp. Ved hvert steg i kjeden utveksles det innkommende tokenet mot et nytt gjennom identitetsleverandøren. Dette sikrer at tilliten verifiseres kontinuerlig, ikke bare ved inngangspunktet.

Risiko 4: For brede tilganger

Den fjerde risikoen er agenter som har bredere tilgang enn de trenger. En bruker kan ha tillatelser på tvers av mange verktøy og datakilder, men for en gitt oppgave er bare et lite utvalg relevant. Det samme gjelder agenter.

Millers svar er tokens med begrenset omfang og minste privilegium (least privilege) ved hvert utvekslingspunkt. Når tokens utveksles ved hvert hopp, begrenses scopene til bare det som trengs for neste steg. Agent én kan snakke med agent to, og det er alt tokenet tillater. Agent to kan koble seg til et spesifikt verktøy gjennom MCP, og ingenting mer. Dette forhindrer at en kompromittert agent får tilgang til ressurser utover sin umiddelbare oppgave.

Siste etappe: MCP til verktøy

Den siste brikken er det Miller kaller siste etappe: forbindelsen mellom en MCP-server og det faktiske verktøyet den skal kommunisere med. Frem til dette punktet flyter alt gjennom tokens. Men selve verktøyet krever ofte egne API-legitimasjoner, databasepassord eller andre hemmeligheter.

Å lagre disse legitimasjonene på MCP-serveren er feil tilnærming. Det skaper ett enkelt eksponeringspunkt. I stedet anbefaler Miller en sikker hvelving (vault) som forvalter verktøyets legitimasjoner og utsteder midlertidige, kortlivede legitimasjoner til MCP-serveren ved behov. Agenten presenterer sitt delegeringstoken, hvelvingen verifiserer det, og leverer tilbake en midlertidig legitimasjon begrenset til den spesifikke verktøyinteraksjonen. Når interaksjonen er over, utløper legitimasjonen.

Fire pilarer

Miller avslutter med en oppsummering av de fire pilarene som gjør et agentbasert system tillitsverdig. Autentisering verifiserer hvem som opererer i flyten: både brukere og agenter. Autorisasjon kontrollerer hva hver aktør kan gjøre gjennom scopede tokens og minste privilegium. Delegering binder agenter til brukerne de representerer, verifisert av en uavhengig identitetsleverandør. Og propagering sørger for at all denne informasjonen beveger seg sikkert gjennom hvert hopp i kjeden.

Ingen av disse konseptene er nye. Token-utveksling, mTLS, hvelvinger og scopede tilganger har vært del av bedriftssikkerhet i årevis. Det som er nytt er behovet for å anvende dem på AI-agenter som handler selvstendig, tar ikke-deterministiske beslutninger og kobler seg til ekte verktøy med reelle konsekvenser.

Ordliste

Kilder og ressurser