WorkOS vil have os til at stoppe med at uddele rå API-nøgler til agenter. God idé. Med auth.md foreslår de et åbent, OAuth-baseret format og et sæt discovery-regler, så autonome agenter kan registrere sig, få scoped adgang og blive auditeret uden, at en person sidder og kopierer hemmeligheder rundt. Timingen giver mening. Det, der slog mig, er hvor stramt flowet er omkring korte, ikke-fornybare tokens i det verificerede spor. Det har tydelige driftskonsekvenser.
Kernen i nyheden er enkel: auth.md er en lille Markdown-fil, som en tjeneste udgiver på en kendt adresse, typisk https:\/\/service.com\/auth.md, der beskriver hvordan agenter registrerer sig, hvilke scopes de kan bede om, og hvordan nøgler udstedes, auditeres og tilbagekaldes. Under motorhjelmen bruger forslaget OAuths kendte discovery-endpoints. Det gør det både læsbart for mennesker og maskinvenligt for agenter. Hvis du har haft ondt i maven over hvem der egentlig handler på vegne af hvem i dine logs, forstår du, hvorfor vi hæfter os ved det her.
Hvad auth.md egentlig er
Auth.md er ikke endnu en gateway. Det er en kontrakt. Filen i klartekst peger agenter ind i et to-hop discovery-forløb: først til \/.well-known\/oauth-protected-resource, som beskriver den beskyttede ressource, og derfra til Authorization Server metadata på \/.well-known\/oauth-authorization-server. I den anden ligger en agent_auth-blok med de felter, en agent har brug for: register_uri, claim_uri, revocation_uri og identity_types_supported. WorkOS’ beskrivelse går metodisk igennem strukturen, så her står vi på solidt grundlag.
En praktisk detalje: på et 401-svar fra API’et anbefales det at returnere en WWW-Authenticate-header med Bearer og et resource_metadata-link. Så kan agenten starte discovery uden at læse dokumentation først. Det lyder banalt, men i POC’er har vi set netop den bootstrap mangle – og så ender man i manuelle særregler.
Registreringsflowene kort og præcist
Protokollen skitserer to hovedflows. En applikation kan understøtte det ene eller begge. Det interessante er det såkaldte agent verified-flow. Her attesterer agentens identitetsudbyder – f.eks. OpenAI, Anthropic eller Cursor, hvis de vælger at støtte det – brugerens identitet ved registrering. Agenten beder sin udbyder om en audience-specifik ID-JAG, poster den til tjenestens \/agent\/auth-endpoint, og tjenesten verificerer signaturen via udbyderens JWKS og validerer claims som kid, alg, jwks, aud, exp, iat, jti og client_id. Når alt stemmer, udstedes credentials synkront.
En vigtig kant: tokens udstedt via ID-JAG-verifikation må ikke have refresh tokens. For at forlænge adgang skal agenten præsentere en ny, frisk ID-JAG. Det øger sikkerheden og gør delegationer kortlivede og målbare, men betyder også hyppigere fornyelser og mere trafik mod udbydernes nøgler. I vores testopsætning så vi netop den belastning stige. Ikke dramatisk, men mærkbart.
Det brugervendte spor og hvorfor det findes
Det andet flow er user claimed. Her kan en agent registrere sig uden at involvere en agentudbyder. Brugeren bekræfter registreringen via en engangskode sendt på mail. To endpoints styrer det: \/agent\/auth\/claim til at udløse mailen og \/agent\/auth\/claim\/complete til at indsende koden. Der er to varianter. Enten får agenten en minimal credential ved anonym start, som senere kan opgraderes ved at gennemføre OTP-ceremonien. Eller også kræver tjenesten en email ved start og holder alt tilbage, indtil OTP er gennemført.
Pointen er ikke kun brugervenlighed. Det er også drift: i anonyme starter kan man give snævre scopes til baseline-aktiviteter og først åbne op, når bindingen sker. Og nøglens identitet kan opdateres uden rotation. For nogle domæner er det rigtigt; for andre vil man nægte for-claim brug helt. Det vigtige er, at valget er eksplicit.
Hvorfor det er bedre end rå API-nøgler
I dag bruger mange stadig én eller flere statiske API-nøgler per agent. De er uscope’de, svære at auditere per session og umulige at tilbagekalde selektivt. Det er ikke kun teori. Vi har i flere POC’er set, at forskellen mellem en menneskelig session og en agenthandling forsvinder i logs, når alt kører på samme nøgle. En sikkerhedschef ringede os op efter en hændelse, hvor vi måtte rodfæste adskillige sessions manuelt. Enkelt var det ikke.
Auth.md flytter os til fine-grained scopes, kortlevende credentials og klare delegation-records per kombination af issuer, subject og audience. Det er præcis det, revisorer og driftsteams efterspørger. Og fordi verifikationen bygger på gængs OAuth-mekanik, er det teknisk realistisk for de fleste platforme at omstille sig – bare ikke uden arbejde.
Drifts- og udviklingskonsekvenser
Vil man understøtte auth.md, er der nogle konkrete ændringer. Først discovery: eksponér \/.well-known\/oauth-protected-resource og opdater \/.well-known\/oauth-authorization-server med en valid agent_auth-blok. Dernæst livscyklus: indfør korte tokenlevetider, ingen refresh i verificeret flow, klare revocation-endpoints, der accepterer logout-tokens fra udbydere. Og til sidst logging: standardiserede felter i access-logs, der bevarer iss, sub, aud, jti og client_id.
Tre lavpraktiske trin til engineering-teams: 1) Byg et 401-bootstrap-testsetup. Verificér at WWW-Authenticate-headeren altid peger korrekt til resource metadata, og at agenter kan komme i gang uden docs. 2) Implementér selective revocation og test en fuld kæde fra udbyders logout-token til lukket adgang inden for sekunder, ikke minutter. 3) Udvid jeres audit-model med delegation records per iss-sub-aud, og sørg for, at I kan hente et revisionssikkert snapshot for et givent tidsrum. Det lyder kedeligt. Det redder jer den nat, en agent går i selvsving kl. 03.17.
Leverandører, gateways og SDK’er
Et følsomt punkt er, om identitetsudbydere vil udstede ID-JAGs og eksponere stabile JWKS-ender. WorkOS nævner navne som OpenAI og Anthropic som mulige udbydere i det verificerede flow, men ingen af dem har offentligt forpligtet sig i materialet, vi har set. Indtil videre må man regne med et blandet landskab. API-gateways og tredjeparts-SDK’er skal også lære de nye discovery-trin, ellers ender teams med at klippe og klistre selv.
Risikoen er fragmentering, hvis større platforme vælger varianter eller slet ikke prioriterer det. Det er ikke første gang; OAuth-økosystemet har levet med mange fortolkninger. Forskellen her er, at agent-scenarier rammer drift hårdere, når ting ikke matcher. Det pragmatiske råd er at implementere fuld standarddiscovery – og samtidig holde en kompatibilitetsvej for de vigtigste partnere, indtil adoptionen er klar.
Sikkerhed og compliance
Fra et sikkerhedsperspektiv er der klare plusser: kortlevende credentials, tydeligt scope og selektiv revokering nedbringer blast radius. Delegation records per iss, sub og aud giver revisorer et konkret spor. Ingen refresh tokens i det verificerede flow reducerer risikoen for langtidsmisbrug, men skubber kompleksitet over i klienters tokenhåndtering og øger antallet af signaturtjek mod udbyders JWKS.
Hvad bør revisorer spørge om i piloter? 1) Kan I dokumentere, hvem der delegerede hvad til hvilken agent på et givent tidspunkt – med hvilke scopes? 2) Kan revokering ske selektivt uden at slå human sessions ihjel? 3) Kan I demonstrere fuld sporbarhed fra et API-kald tilbage til aud og jti i loggen, med tidsstempler, der ikke kan rodes ved? Mangler bare én af de tre, bliver audit dyr.
Fra Snillds maskinrum
Vi har en kundecase, hvor et sæt skrive-agenter fik for brede nøgler. Da en agent loopede efter en timeout, endte den med at overskrive kladder på tværs af flere kundeteams. Det tog timer at rulle præcist tilbage, fordi vi ikke kunne skelne på credential-niveau. Med auth.md-tilgangen kunne vi have givet pr. agent scopes og revokeret kun det pågældende iss-sub-aud-par på minutter. Det er ikke bagklogskab – det er kalkylen, vi laver fremadrettet.
Vi testede også idéen i en POC med JIT-provision via OIDC-lignende kobling og kortlivede tokens. Én ting virkede knivskarpt: audit-sporet. Én ting drillede: manglen på refresh tokens i verificeret flow betød hyppigere fornyelser, og vi måtte cache JWKS med omtanke for ikke at tæske udbyderen med fetches. Lydsporet fra serverrummet den aften var små ventilatorer, der lige fik lidt mere at lave. Vi tuner stadig, hvor ofte vi henter nøgler.
Begrænsninger og åbne spørgsmål
Der er huller. Vi har ikke set måltal for, hvordan ID-JAG-verifikation skalerer ved spidsbelastning, og der er ingen offentlig roadmap for, om auth.md søger formel standardisering eller bliver de-facto praksis. Hvad gør man, når flere tjenester deler ansvar for den samme agent gennem en kæde? Hvem ejer livscyklussen og trust-listen i midten? Der er også bagudkompatibilitet at tænke på, så eksisterende OAuth-servers ikke bryder klienter, når agent_auth-blokken dukker op.
Skeptikere vil sige, at vi bare kan bruge kundespecifikke OAuth-klienter med snævre scopes. Delvist rigtigt. Problemet er stadig registreringen for en ikke-menneskelig aktør – og at gøre den sporbar uden menneskelig UX og manuelle nøgler. Auth.md skærer ind til benet med discovery, veldefinerede flows og en eksplicit revocation-historie. Google kan nogle gange overdesigne; her er WorkOS mere jordnær end gennemsnittet. Det siger jeg sjældent.
Hvem bør prioritere det nu
Hvis jeres produkt allerede har mange agenthandlinger på vegne af brugere, bør I kigge på auth.md tidligt. SaaS-platforme med stor integrator-økonomi kan bygge en pilot, hvor de mest risikofyldte operationer kræver verificeret flow, og resten kører user claimed. Virksomheder med høj regulatorisk risiko kan starte i læse-scopes og først åbne skrivning, når audit og revokering er på plads. Jeg ville ikke vente, til en hændelse tvinger beslutningen.
En simpel roadmap: pilotér discovery og 401-bootstrap på en mindre ressource. Indfør selective revocation først, før I åbner bredt for agentbrug. Byg governance-workshops, hvor sikkerhed, produkt og drift tager stilling til scopes og levetider pr. agenttype. Og læg konkrete SLO’er for verifikation og revokering ind i monitoreringen, f.eks. 95.-percentil under to sekunder for verificeret udstedelse og under ti sekunder for fuld revokeringseffekt.
Hvad det ændrer i hverdagen
Hverdagen i drift ændrer sig. Incident response får en ny knap at trykke på, når en agent opfører sig mærkeligt. Udviklingsteams skal forholde sig til jti og aud i forretningslogik – ikke kun user_id. Support kan endelig svare på spørgsmålet “hvem gjorde hvad på vegne af hvem?” uden at løbe hele dagen. Og ja, nøgler roterer oftere. Man vænner sig til det, ligesom da vi gik fra langlivede sessions til short-lived JWTs.
Lad os også være ærlige: Der vil være modstand fra teams, der har bygget håndsyede tokenflows. Det her gør nogle ting mere firkantede. Netop den firkant gør adfærden forudsigelig og lader to systemer, der aldrig har mødt hinanden, alligevel tale sikkert sammen. Forskellen mærkes først, når man sidder med det i hænderne.
Kilder og hvem vi ringer til
Tekniske beskrivelser og flowdetaljer er krydstjekket mod WorkOS-materialet om auth.md, inklusive discovery-endpoints, agent_auth-felter, de to registreringsflows samt 401-bootstrap med WWW-Authenticate. Vores praktiske vurderinger bygger på erfaring fra POC’er hos Snilld, som ikke udgør officiel dokumentation, men som forklarer driftsmæssige konsekvenser. Vi mangler fortsat udtalelser fra større agent- og ID-udbydere om udstedelse af ID-JAGs, og vi har ikke set uafhængige performance-målinger af JWKS-verifikation i stor skala.
Næste skridt i afdækning: Vi vil række ud til WorkOS for at forstå governance og versionering. Vi vil også spørge tekniske repræsentanter hos OpenAI og Anthropic om deres planer for agent-attestation og JWKS-stabilitet. To danske cloud-leverandører med store API-gateways står også på listen for at forstå, hvordan de vil integrere discovery og revokering. En erfaren CISO med revisionsbaggrund kan sætte ord på, hvilke kontrolmål der er realistiske i en første implementering.
