Private Key JWT i AgentCore Identity

Private Key JWT er en kendt OAuth-mekanisme. Jeg har set den brugt til mennesker i årevis, nu bruger AWS den samme model til agenter. Den vender autentificeringen på hovedet sammenlignet med en klassisk client secret. Agenten sender ikke en hemmelighed direkte til serveren. Den signerer selv et JWT-token med en privat nøgle, den aldrig deler med nogen. Modtageren verificerer signaturen med den tilhørende offentlige nøgle. Ingen hemmelighed rejser over netværket. Der er derfor intet at opsnappe undervejs.

Det praktiske resultat er, at selve autentificeringsbeviset ikke længere er en statisk streng, man kan kopiere og genbruge. Et JWT signeret med en privat nøgle er bundet til en bestemt anmodning og et bestemt tidsvindue. Selv hvis nogen ser tokenet i en log, kan de ikke genbruge det til at udgive sig for at være agenten senere. Det er præcis den type lækagerisiko, jeg har set gå galt hos kunder, en delt nøgle havner i en fejlrapport eller et gammelt config-repo, og pludselig kan hvem som helst bruge den.

Sådan lægger AWS flowet op i AgentCore Identity: man genererer et asymmetrisk nøglepar, typisk via AWS KMS. Den private nøgle eksporteres aldrig fra KMS. Den bruges kun til at signere tokens on demand, mens den offentlige nøgle registreres hos den identity provider, agenten skal autentificere sig overfor.

Det betyder i praksis, at man opretter en formel tillidsrelation, før agenten nogensinde sender sin første anmodning. Identity provideren, det kan være en intern OAuth-server eller en ekstern tjeneste, der understøtter Private Key JWT som client-autentificeringsmetode, kender agentens offentlige nøgle på forhånd. Den kan derfor verificere hvert signeret token uden at skulle stole på en delt hemmelighed, der potentielt kunne være kompromitteret.

Den adskillelse mellem nøglegenerering og nøgleregistrering er kernen i modellen, og det er også den del, jeg selv insisterer på hos mine kunder. Den private nøgle forlader aldrig et kontrolleret miljø, og selve signeringen sker inde i KMS, ikke i agentens egen kode. Det fjerner en hel klasse af fejl, hvor en udvikler ved et uheld committer en hemmelighed til et repository eller lægger den i en miljøvariabel, der havner i en fejlrapport.

Når nøgleparret og identity provideren er på plads, konfigureres selve grant flowet i AgentCore Identity gennem AWS Management Console. Her opretter man en credential provider, der binder agentens identitet sammen med den konkrete OAuth-grant, agenten skal bruge for at hente et adgangstoken.

Det er her, agenten reelt får sin adgang formaliseret. Credential provideren definerer, hvilket scope agenten kan bede om, hvilken token-endpoint der skal bruges, og hvordan det signerede JWT skal sendes som en del af token-anmodningen. AgentCore Identity håndterer selve signeringen og udvekslingen, så agentens egen kode kun skal forholde sig til at bede om adgang, ikke til at implementere kryptografien selv.

Når jeg drifter flere agenter på tværs af forskellige systemer, er det præcis den slags centrale konfigurationsflade, jeg efterspørger. Man kan se og administrere, hvilke agenter der har hvilke tilladelser, uden at skulle spore hemmeligheder rundt i separate konfigurationsfiler eller secrets managers for hver enkelt integration.

Den underspillede fordel ved denne model er sporbarheden, og det er også den del, jeg bruger mest tid på at forklare kunder. Fordi hver autentificering går gennem en registreret identity provider og en defineret credential provider, kan AWS CloudTrail logge, hvornår en given agent anmodede om et token, hvilket scope der blev tildelt, og om anmodningen lykkedes.

Det giver et revisionsspor, der er langt mere granulært end det, man typisk får med en delt API-nøgle, hvor alt, man kan se, er, at nøglen blev brugt, ikke nødvendigvis af hvilken specifik agent-instans eller til hvilket formål. Med Private Key JWT er hver signeret token knyttet til en bestemt agentidentitet. Det gør det muligt at opdage unormal adfærd, for eksempel hvis en agent pludselig anmoder om et scope, den normalt ikke bruger, eller anmoder om tokens langt hyppigere end forventet.

Det er den type logning, der bliver afgørende, når agentiske systemer bevæger sig fra enkeltstående eksperimenter til at operere ved siden af hinanden i produktion, hvor flere agenter kan have overlappende adgang til de samme ressourcer.

Det reelle skift her er ikke bare en ny protokol. Det er en anden tillidsmodel for agentisk infrastruktur. Delte hemmeligheder har altid krævet et kompromis: enten skal de rotere ofte og skabe driftsbesvær, eller de ligger stille i lang tid og bliver en stigende risiko for hvert år, de ikke skiftes ud. Private Key JWT fjerner det dilemma, fordi selve autentificeringsbeviset genereres dynamisk for hver anmodning, uden at den underliggende private nøgle nogensinde eksponeres.

For virksomheder, der bygger flere agenter, der taler sammen eller trækker på de samme datakilder, betyder det en mere skalerbar sikkerhedsmodel. Man behøver ikke opfinde sin egen rotationsstrategi for hver ny integration. Man registrerer en identitet og lader AgentCore Identity håndtere resten.

Det peger samtidig mod en bredere tendens, jeg ser hos stort set alle mine kunder lige nu: efterhånden som agentiske arbejdsgange får adgang til flere systemer med reelle konsekvenser, fra betalinger til kundedata, bliver identitetshåndtering en forudsætning, ikke en eftertanke. Private Key JWT i AgentCore Identity er et konkret eksempel på, hvordan den infrastruktur begynder at modnes, og hvorfor det for mange virksomheder giver mening at tænke agentidentitet ind i arkitekturen fra starten frem for at lappe det på senere.