Autentificering til agentisk AI: Funhouse-spejlet af maskinidentitet

Fra maskinidentitet til nøglespredning: En kærlighedshistorie

Der var engang – et sted mellem fremkomsten af mikrotjenester og den femte CI/CD-omskrivning – besluttede vi, at enhver ikke-menneskelig proces havde brug for sin egen hemmelighed. Så vi forpligtede os. CI-pipelines, serveruafhængige funktioner, iscenesættelsesmiljøer og din praktikants testscript har alle tokens, API-nøgler, OAuth-flow og YAML-forvrængninger. Nogle gange hårdkodet. Nogle gange injiceret. Altid lidt skitseagtig.

Naturligvis tog entropien over. Tasterne spredte sig. Hemmeligheder lækket. Poletter udløb stille og roligt. Knusede glaskonti blev den nye normal. Hemmelige administratorer som Vault og AWS Secrets Manager var en god start, og de er modnet betydeligt med funktioner som dynamiske hemmeligheder og IAM-integrerede adgangskontroller. Men i mange organisationer forbliver de legitimationskirkegårde: Du roterede hemmeligheder, roterede derefter rotatorerne og hyrede til sidst nogen til at styre rotationsplanen. Og alligevel var der nogen, der begik en .env-fil til GitHub i sidste uge.

Cloud-leverandører trådte til med arbejdsbelastningsidentitetsføderation – flygtige, infrastrukturudstedte legitimationsoplysninger, der skulle erstatte langvarige hemmeligheder. Den er elegant på papiret og robust i greenfield-opsætninger. Men i praksis er adoptionen ujævn. Selvom AWS IAM-roller for tjenestekonti, GCP Workload Identity Federation og Azure Managed Identities er lovende, er implementering på tværs af hybride eller ældre miljøer stadig kompleks. Værktøjer forudsætter ofte, at du er fuldt cloud-native og velsignet med uendelige DevOps-timer.

Ind i agenterne: Nu med 10 gange mere identitetsoverflade

Som om dette ikke var kaotisk nok, kommer agentisk AI: LLM-drevne softwareenheder, der planlægger, ræsonnerer, kæder opgaver og i stigende grad improviserer på tværs af API'er, SaaS-værktøjer, skyer og interne systemer. Alt sammen med den strategiske impulskontrol fra en golden retriever på en tennisboldfabrik.

Disse midler virker autonomt. De henter kontrakter fra SharePoint, scanner Box, opdaterer Salesforce og planlægger Zoom-opkald. I én kæde. På tværs af fem systemer. På en søndag. Denne vision er stadig ambitiøs for de fleste organisationer, men tidlige implementeringer fra projekter som AutoGPT, Adept og CrewAI er på vej i den retning.

Hver interaktion kræver identitet. Så hvad giver vi disse midler? Langlivede tokens? Bredt udvidede API-nøgler? Nogens Okta-login fra 2019?

Agenter udvider ikke bare identitetsfladen; de omformer den. De udgiver sig for at være, krydser domæner og har brug for just-in-time-adgang for at gøre noget, så glemme, at de nogensinde har eksisteret. Det er ikke IAM længere. Det er improvisationsteater med OAuth som rekvisitskab.

Hvorfor din IAM-leverandør stille og roligt går i panik

Traditionelle IAM- og PAM-løsninger – Okta, Ping, CyberArk – blev bygget til mennesker og velopdragne backend-tjenester. Nogle leverandører vover sig nu ind i maskinidentitet og automatisering (f.eks. Okta Workflows, samlede tjenestekonti), men bed dem om at ræsonnere om en LLM-agent, der vågner kl. 3 om natten og beslutter sig for at kalde en ny SaaS API, og de rammer arkitektoniske grænser. Disse platforme mangler typisk dynamisk politikunderstøttelse, kontekstbevidsthed under kørsel og skalerbare delegeringsmodeller.

Hemmelige administratorer fungerer stadig som bunkere fra den kolde krig fra den kolde krig: fremragende til lagring, forbedrer håndhævelse af politikker, men ikke designet til dynamiske runtime-beslutninger om, hvorvidt din AI-agent skal kalde Salesforces API'er med høje privilegier (Tænk slet_bruger, nulstil_Fakturering_konfiguration) kl. 2 om natten

Og selv hvis du kobler det hele sammen med Terraform-, YAML-, ACL'er og OAuth-flows, ender du med en skør anordning, der går i stykker i det øjeblik, agenten farver uden for linjerne.

Lad os tale om, hvad der faktisk er svært

Dette er ikke bare en genstart af maskingodkendelse. De svære problemer er dybt praktiske:

• Flygtige godkendelsesstrømme: Agenter er opgaveomfattede. Det burde deres akkreditiver også være. Men kortvarige, snævert afgrænsede creds øger orkestreringskompleksiteten. Mist tokenet, mist konteksten. Pålidelig styring af denne livscyklus er en løbende ingeniør- og forskningsudfordring (se f.eks. SPIFFE/SPIRE).
• Tillid på tværs af cloudmiljøer: En helpdesk-medarbejder kan starte i Azure, hoppe til GCP og derefter lande i AWS. De fleste organisationer er ikke konfigureret til live fødereret identitet på tværs af alle tre. OIDC formodes at hjælpe, men implementeringshuller, token-publikumsfejl og mangel på standardiserede metadata gør dette alt andet end glat. Federation-understøttelse varierer: AWS STS og GCP-identitetsforbund spiller ikke altid pænt.
• Risiko for efterligning: Agenter laver ikke MFA. De sender ikke e-mails til it, når loginmønstre ændres. Hvis nogen stjæler en token eller forfalsker en identitet, er der intet menneske at lægge mærke til. Nye løsninger som f.eks. kontinuerlig godkendelse og registrering af adfærdsmæssige uregelmæssigheder (f.eks. Stack Identity, Panther) lovende, men endnu ikke udbredt.
• Håndhævelse af nultillid: Vi siger "stol aldrig på, bekræft altid", men mener ofte "bekræft én gang, og glem så, at det skete." De fleste politikker følger ikke agenter på tværs af domæner. Og mens der findes logfiler (AWS CloudTrail, GCP-revisionslogfiler)er værktøjer som OpenTelemetry og eBPF-baseret sporing kun lige begyndt at gøre fortællinger om flere skyer observerbare i realtid.
• Protokol spaghetti: OAuth 2.1 (stadig i draft fra midten af 2025) Forenkler nogle flows, men avancerede mønstre som på vegne af delegering og tokenudveksling er dårligt standardiserede. Udviklere ender med at skrive skrøbelig limlogik mellem udbydere som Google, Microsoft og brugerdefinerede SaaS API'er.

Så hvad kan egentlig fungere?

Hos Venture Guides har vi udforsket primitiver, der bevæger sig ud over hemmelige bokse og skrøbelige tjenestekonti – fordi det ikke gør det sikkert at bolte MFA på en YAML-fil. Hvis agenter skal operere autonomt, skal deres identitetsmodel være lige så dynamisk: flygtig, kontekstuel og styret i realtid.

En lovende tilgang gentænker identitet ikke som en statisk klat, der gives til agenten, men som en runtime-kontrakt, der forhandles i farten. I stedet for at indsætte legitimationsoplysninger på forhånd – i miljøvariabler, hemmelige lagre eller din CI-pipelines ottende trin – præger systemet omfangsbegrænsede, kortvarige adgangstokens baseret på, hvad agenten laver, hvor den kører, og hvad den forsøger at røre ved. Tænk på det som IAM som en streaming-API, ikke en CSV-eksport.

I denne model har agenter aldrig langvarige hemmeligheder. De anmoder om adgang under kørsel, og infrastrukturen – cloud, orkestrator, hvad som helst – fungerer som kilden til sandheden. Identitet tildeles ikke, fordi agenten kender en nøgle; Det gives, fordi systemet kender agenten.

Vi har også set modeller, hvor proxyer sidder mellem agenter og måltjenester, der fungerer som realtidsmæglere. Disse ledsagere kan håndhæve politik, logge hensigt og tilbagekalde adgang på stedet. I modsætning til traditionelle API-gateways eller servicenet fungerer disse højere oppe i stakken – på identitets- og tilladelseslaget, ikke kun TCP- eller JWT-headere. Det handler ikke om at videresende anmodninger. Det handler om at filtrere, hvem der overhovedet får lov til at spørge.

Og ja, service mesh-verdenen tilbyder nyttig inspiration. SPIFFE/SPIRE, Envoy med OPA og zero-trust-netværk giver alle et fingerpeg om, hvad der er muligt. Men de fokuserer ofte på øst-vest-trafik i homogene miljøer. Agentiske systemer bryder med den antagelse: de er improvisatoriske, grænseoverskridende og lejlighedsvis vilde.

I naturen ser vi et par tidlige tegn på liv:

• Middleware, der abstraherer OAuth-flows og tokenjonglering, så agenter slet ikke behøver at ræsonnere om godkendelse.
• Identitetsmæglere, der udsteder omfattede, flygtige legitimationsoplysninger, der er knyttet til kontekst i realtid – ingen statisk konfiguration, ingen rester af legitimationsoplysninger.
• Arbejdsbelastningsbevidste tillidssystemer, der behandler infrastruktur som roden til identitet – præger adgang på kanten af udførelsen, ikke begyndelsen af udrulningen.

Mønsteret her er ikke hemmelig rotation. Det er undgåelse af legitimationsoplysninger. Identitet som beregning, ikke konfiguration.

Politik, ikke gaffatape. Ræsonnement, ikke tilbagekaldelse.

Dette er ikke kun sikkerhed. Det er arkitektur.

Løsning af agentidentitet er ikke kun en defensiv foranstaltning. Det er en forudsætning for skala. Gjort rigtigt, dine agenter:

• Arbejd med færrest rettigheder
• Efterlad rene revisionsspor
• Godkend på tværs af systemer uden skøre scripts
• Fejler med nåde, når der nægtes adgang

Og du får:

• Færre advarsler
• Mindre limkode
• Mere konsekvente politikker
• Færre sikkerhedsgennemgange, der blokerer for lanceringer

Det er arkitektonisk hygiejne. Identitet bliver kontrakten mellem AI og infrastruktur.

Kamp om fremtiden

Agentisk AI er her (eller i det mindste vil være nært forestående). Det samme er det identitetsrod, det slæber bagefter. Men vi har været her før – med skyen, med containere, med mikrotjenester. Lektien er den samme: Du kan ikke tape dig vej gennem et paradigmeskift.

Den næste bølge af infrastruktur vil ikke handle om at gemme flere hemmeligheder. Det vil handle om at have brug for færre af dem. Om systemer, der forstår Hvem spørger, Hvorforog for Hvor længe.

Policy-as-code-rammer som Rego/OPA, Cedar (fra AWS)og Zanzibar-lignende modeller (fra Google) Giv et tip om, hvad der er muligt, når identitet behandles som en dynamisk, forespørgselsbar konstruktion i stedet for en statisk tilladelsesblob. Selvom de er forskellige i tilgang – Cedar fokuserer på finkornet håndhævelse af politikker og Zanzibar, der modellerer relationel adgang – repræsenterer begge et skift mod identitet som en realtidsberegning.

Så ja, byg fremtiden. Bare sørg for, at dine agenter ikke ved et uheld sletter det.