OBO token exchange til multi-tenant

En typisk agent-arkitektur består af flere lag: en frontend-agent modtager en brugerforespørgsel, kalder derefter et eller flere værktøjer via en gateway, og de værktøjer kalder igen underliggende systemer som databaser, API'er eller andre agenter. Hvis hvert lag bare videresender den originale bruger-token uændret, ender man med et system, hvor et kompromitteret værktøj lige pludselig har adgang til alt, hvad brugeren har adgang til, og ofte mere end det.

I en multi-tenant kontekst, hvor flere kunder eller organisationer deler den samme agent-infrastruktur, bliver problemet akut. En fejl i isoleringen mellem tenants kan betyde, at agent A ved en fejl kan læse data tilhørende tenant B, fordi tokenet, den fik videregivet, ikke var afgrænset til den rette kontekst. OBO token exchange løser det ved at give hvert led i kæden sit eget, snævert afgrænsede token, udstedt specifikt til det formål, det skal bruges til.

AgentCore Gateway understøtter OBO-flowet ved at integrere med en ekstern identitetsudbyder, for eksempel Okta, som håndterer selve token-udstedelsen. Flowet starter med, at brugeren autentificerer sig som normalt og modtager et JWT-token fra identitetsudbyderen. Når agenten skal kalde et værktøj via gatewayen, sender den det oprindelige token med til gatewayen sammen med en angivelse af, hvilket værktøj eller hvilken ressource den ønsker adgang til.

Gatewayen udveksler derefter det oprindelige token mod et nyt, mere snævert token via en token exchange-anmodning til identitetsudbyderen. Det nye token bærer de samme grundlæggende identitetsoplysninger om brugeren, men er begrænset til den specifikke audience, altså det specifikke værktøj eller den specifikke API, kaldet gælder for. Opsætningen kræver, at man registrerer gatewayen som en betroet klient hos identitetsudbyderen, og at man definerer, hvilke audience-værdier der er gyldige for hvilke værktøjer. Det er konfiguration, ikke kode, hvilket gør det muligt at ændre adgangsregler uden at redeploye agent-logikken.

Det centrale i OBO-flowet er, hvordan claims i JWT-tokenet transformeres for hvert hop. Det oprindelige token indeholder typisk brugerens identitet, hvilken tenant brugeren tilhører, og hvilke roller eller rettigheder brugeren har. Når gatewayen udveksler tokenet, bevarer den identitets- og tenant-claims, men indsnævrer audience-claimet til det specifikke mål og kan samtidig fjerne eller nedskalere rettigheds-claims, der ikke er relevante for det pågældende kald.

Det betyder i praksis, at hvis en agent har adgang til at læse og skrive i en database, men det konkrete værktøjskald kun har brug for læseadgang, kan det udvekslede token begrænses til kun at bære læse-rettigheden. Skulle det udvekslede token blive lækket eller misbrugt, er skaden begrænset til præcis det, tokenet var udstedt til, og intet mere. Denne granularitet er svær at opnå, hvis man bare propagerer det originale token uændret gennem hele kæden, og det er her OBO-mønsteret adskiller sig fra en simpel token-videresendelse.

Ud over selve token-udvekslingen bygger sikkerheden i høj grad på audience-binding. Hvert token bliver bundet til en specifik audience-værdi, som identificerer det system, tokenet er gyldigt for. Et system, der modtager et token med en forkert audience, skal afvise det, selv hvis signaturen er gyldig og tokenet i øvrigt ikke er udløbet.

I en multi-tenant arkitektur fungerer audience-binding som et forsvar i dybden, der supplerer tenant-isolation på infrastrukturniveau. Selv hvis der skulle opstå en fejl i routing eller i tenant-kontekst et sted i kæden, vil et forkert bundet token blive stoppet af den modtagende tjeneste, fordi audience ikke matcher. Det er en simpel, men effektiv kontrol, fordi den ikke afhænger af, at alle mellemliggende systemer har logikken korrekt implementeret. Den sidste linje af forsvar sidder hos den tjeneste, der rent faktisk udfører handlingen.

Hos Agent Enterprise, hvor jeg selv bygger og drifter agent-operationen, var spørgsmålet om identitet og adgangsstyring det første, vi måtte løse, da vi flyttede fra proof-of-concept til produktion. Det er ikke tilfældigt. Det er netop i overgangen fra prototype til drift, at manglende adgangskontrol holder op med at være en teoretisk bekymring og bliver en reel risiko.

For danske virksomheder, der bygger agent-løsninger med adgang til kundedata på tværs af afdelinger eller kunder, giver OBO-mønsteret en konkret måde at overholde både interne sikkerhedskrav og lovgivning som GDPR på. Adgang bliver sporbar og afgrænset til det enkelte formål. Det gør det langt nemmere at dokumentere, hvem der har haft adgang til hvad, og hvorfor. Det handler ikke kun om at undgå fejl, men om at kunne vise en revisor eller en tilsynsmyndighed, at systemet er bygget med adgangskontrol som en designbeslutning, ikke en eftertanke.