Bedrifters tilgangsstyring hviler på én antakelse: hver identitet tilhører et menneske med en ansettelsespost, en leder og en sluttdato. Hele apparatet er bygget rundt tre overganger, det The Hacker News beskriver som joiner, mover og leaver, der HR-systemet er den autoritative kilden som utløser tildeling, endring og fjerning av tilgang. KI-agenter har ingen av delene, og der begynner problemet.
En agent ankommer ikke via HR. Den opprettes av en utvikler, et orkestreringslag som LangChain eller AWS Bedrock Agents, eller en automatisk utrulling, og lander i produksjon med den legitimasjonen utvikleren tildelte ved opprettelsen, eller det plattformen ga som standard. Ingen tildelingshendelse treffer styringsverktøyet. Verre: agentens tilgang vokser i kjøretid, når den via verktøykall eller RAG-oppslag ender med å spørre APIer den aldri ble tildelt. Modellen ble laget for tilgang som defineres ved oppstart og justeres ved kjente overganger, ikke for rekkevidde som utvider seg mens agenten jobber.
Konsekvensene rammer hvert stadium. Ved tildeling er over-privilegering standard, fordi utvikleren gir bred nok tilgang til at oppgaven lykkes og skyplattformenes minste motstands vei er permissiv. Ved gjennomgang finner rutinglogikken ingen eier, siden agenten mangler leder-attributt. Og ved avvikling finnes ingen leaver-hendelse: når en agent tas ut av drift, blir en API-nøkkel med produksjonstilgang liggende gyldig i secrets-lageret, uten eier, uten utløp og uten gjennomgangshistorikk.
For deg som bygger med agenter betyr det at hver agent du ruller ut, legger igjen legitimasjon som ingen HR-utløst prosess vil rydde opp i. Å utvide tilgangsstyringen til å dekke dem handler ikke om å tvinge HR-arbeidsflyter på en identitetstype de aldri var ment for, men om å oppdage agent-legitimasjon på tvers av hver utrullingsflate og knytte den til en eier og en utløpsdato.