AI-agenter blir ansatte. Er du klar?
Fra piloter til produksjon
AI-agenter beveger seg fra eksperimenter til infrastruktur. De leser, bestemmer og handler. Noen ganger som svar på et menneske. Noen ganger på egenhånd.
Hastigheten er egenskapen.
Hastigheten er også risikoen.
Det som endrer seg når agenter blir «infrastruktur», er at de slutter å være et enkelt teams verktøy og begynner å bli en delt avhengighet. De berører identitet, data, samarbeidsflater og operative arbeidsflyter. I det øyeblikket en agent kan utløse handlinger på tvers av systemer, er spørsmålet ikke lenger «fungerer det», men «kan vi kontrollere det i stor skala». Microsofts veiledning for implementering av AI-agenter er eksplisitt om rekkefølgen: planlegg for agenter, styr og sikre agenter, bygg agenter, og drift deretter agenter. Hvis du snur den rekkefølgen, får du vanligvis implementering før kontroll.
Hvorfor agenter er vanskeligere enn apper
Microsofts Cloud Adoption Framework beskriver agenter som programvare som kan resonnere over inndata, bruke verktøy og utføre handlinger, støttet av instruksjoner, henting, handlinger og minne. Denne kombinasjonen er det som gjør agenter nyttige, og det som gjør dem vanskeligere å styre enn tradisjonelle apper. Du distribuerer ikke bare kode. Du distribuerer beslutningsløkker med rekkevidde inn i data og systemer.
I praksis betyr «verktøy» API-tilgang, arbeidsflytutløsere, filoperasjoner, identitetsoppslag, automatisering av billett og administratorhandlinger. «Henting» betyr at agenten kan hente informasjon fra interne kilder og syntetisere den til utdata og beslutninger. «Minne» betyr at den kan bære kontekst på tvers av interaksjoner, noe som er kraftig, men øker også risikoen for at data blir beholdt, gjenbrukt eller dukket opp på feil sted hvis kontrollene er svake. Dette er grunnen til at Cloud Adoption Framework knytter agentstyring til mer enn IAM: datastyring, observerbarhet, sikkerhetskontroller og utviklingspraksis må fungere sammen.
Gjennom samarbeid med Fortytwo, pensjonerte Bufdir dets aldrende «Mine Ansatte»-oppsett og gikk over til en ny tilgangsmodell bygget på CheckID og «Lederportalen».
Forskjellen var umiddelbar: onboardingen av nyensatte og midlertidig ansatte og vikarer ble renere og tryggere; manuelle rutiner ble luket ut, og organisasjonen hadde endelig grunnlag for skikkelige tilgangsrevisjoner og et klart veikart mot passordløs autentisering.
Hva går i stykker først
Det første som går i stykker i de fleste organisasjoner er ikke modellen. Det er eierskap.
Eierskap mislykkes fordi agentidentiteter ser villedende kjente ut. De opprettes som «en annen appidentitet», og blir deretter raskt operative aktører. Når en agent kan kjøre kontinuerlig, overlever den sprinten som skapte den. Når den overlever sprinten, trenger den en livssyklus. Når den trenger en livssyklus, trenger den en reell ansvarlig part med fornyelsesmyndighet, ikke bare noen som en gang skrev koden.
Hvorfor dette nå er et ledertema
Dette er grunnen til at agentidentitet nå er et ledertema. Hvis du behandler agentidentiteter som vanlige app-appidentiteter, ender du opp med samme feilmodus som det siste tiåret med tjenesteprinsipaler, bare med mer autonomi og større overflateareal.
Risikokurven endres fordi agenter reduserer friksjon. Redusert friksjon er poenget. Det betyr også at flere handlinger skjer automatisk, og flere systemer kan lenkes sammen. En enkelt identitet med overprivilegier kan bli en snarvei gjennom ellers godt utformede kontroller. Når noe går galt, skjer det raskere og sprer seg mer, fordi agenten er bygget for å drive arbeidet fremover uten å vente på godkjenninger i hvert trinn.
Agentspredning er hvordan du mister kontroll
Microsoft kaller det agentsprad: agenter dukker opp i lommer av virksomheten, multipliserer seg raskt og overlever prosjektet som opprettet dem. Tillatelser er vanligvis for brede fordi «det var enklere», og så kommer ingen tilbake for å redusere dem. Når noe ser mistenkelig ut i loggene, er det ingen ansvarlig person som spør hva agenten skal gjøre. Det er slik små automatiseringer blir sikkerhetshendelser.
Spredthet er ikke bare «for mange agenter». Det er for mange agenter uten en felles standard for navngiving, metadata, risikonivåinndeling og gjennomgang. Det er agenter opprettet i forskjellige produkter, av forskjellige team, med forskjellige antagelser om datatilgang, driftsgrenser og overvåking. Du ender opp med identiteter som kan autentisere, kalle API-er og iverksette tiltak, mens organisasjonen sliter med å svare på grunnleggende spørsmål som hva agenten er til for, hvilke data den kan berøre, og om noen har gjennomgått tillatelsene dens i forrige kvartal. Microsofts veiledning peker eksplisitt på behovet for organisasjonsomfattende styring og sikkerhetspraksis for agenter fordi team-for-team-styring ikke holder mål når agenter sprer seg.
Microsofts retning: styring først, deretter skalering
Microsofts svar innenfor Entra-økosystemet er å gjøre agenter til førsteklasses identiteter gjennom Entra Agent ID, og å plassere agentstyring i en adopsjonslivssyklus som starter med planlegging og styring, ikke verktøy. Du planlegger, du styrer og sikrer, du bygger, du driver. Hvis du inverterer den sekvensen, får du skalering før kontroll.
Det praktiske skiftet her er standardisering. I stedet for at hvert team finner opp sitt eget identitetsmønster, beveger man seg mot repeterbare identitets- og styringsbyggesteiner. I Entra Agent ID behandles også oppdagelse som et førsteklasses problem gjennom Agent Registry, som beskrives som et sentralisert metadatalager og oppdagelsesmekanisme for distribuerte agenter på tvers av organisasjonen. Det er viktig fordi styring starter med å vite hva som finnes, ikke å gjette.
Hvordan bør et utøvende mandat se ut?
Den bør være kort, håndhevbar og bygget for virkeligheten. Virkeligheten inkluderer omorganiseringer, leverandørskifter, travle team og prosjekter som avsluttes. Mandatet bør definere hvordan agenter får lov til å eksistere i leietakeren din, hvordan de eies og hvordan de legges ned.
Ansvarlighet som overlever organisasjonsendringer
Start med ansvarlighet som overlever organisasjonsendringer. Entra Agent ID introduserer administrative forhold som skiller teknisk kontroll fra forretningsansvar, inkludert sponsorer. En sponsor er nødvendig når man oppretter en agentidentitet eller en agentplan. Det er en innebygd påtvingende funksjon: hver agent må ha et menneske eller en gruppe som kan forklare hvorfor den eksisterer og bestemme når den skal fornyes eller fjernes.
Denne separasjonen er viktig fordi tekniske administratorer ikke trenger å være de som rettferdiggjør forretningsformålet, og bedriftseiere ikke trenger administratorrettigheter for å være ansvarlige. Sponsorer tar livssyklusbeslutninger og holder «hvorfor»-spørsmålet levende. Eiere håndterer teknisk administrasjon. Dette unngår den klassiske fellen der ansvarlighet ligger i en Jira-sak eller innboksen til en avgått ansatt.
Livssyklus som standard, ikke som unntak
Krev deretter livssyklus som standard. Midlertidige agenter bør ikke bli permanente innbyggere. Grunnlinjen din bør inkludere utløp, periodisk gjennomgang og et register som lar deg oppdage hva som finnes og hvorfor. Microsoft beskriver eksplisitt et sentralisert agentregister som en oppdagelsesmekanisme med metadata om registrerte agenter. Det er slik du forhindrer at usynlige agenter akkumulerer usynlige rettigheter.
Et register er ikke byråkrati. Det er grunnleggende driftskontroll. Det bør inneholde nok metadata til å ta raske beslutninger, for eksempel formål, sponsor, miljø, dataomfang og når det sist ble gjennomgått. Uten det blir «tilgangsgjennomgang» gjetting. Med det blir fornyelse en beslutning i stedet for et ritual. Microsofts agentregister er posisjonert nøyaktig for denne synligheten og organiseringen i stor skala, inkludert veiledning om agentmetadata og synlighetsmønstre.
Grenser som begrenser eksplosjonsradiusen
Til slutt, sett grenser for hvor agenter kan kjøre og hva de kan berøre. Styringsperspektivet i Cloud Adoption Framework knytter sammen datastyring og samsvar, observerbarhet, sikkerhetskontroller og utviklingspraksis. Dette er ikke bare et IAM-problem. Det er Purview og datakontroller, det er overvåking og kostnadssynlighet, det er trusselbeskyttelse og det er sikre byggemønstre.
Det er her mange organisasjoner investerer for lite. De fokuserer på autentisering og glemmer at agentens verdi kommer fra tilgang til data og evnen til å handle. Hvis du ikke kobler identitetskontroller med datakontroller og overvåking, vil du ikke se forskjellen mellom «opptatt agent» og «kompromittert agent» før det allerede er dyrt. Cloud Adoption Frameworks styrings- og sikkerhetsveiledning er tydelig på at disse kontrollene må være konsistente på tvers av organisasjonen, ikke gjenoppfinnes per team.
Fortytwo utsikt
AI-agenter bør behandles som digitale kolleger med en strengere kontrakt enn mennesker. Mennesker har kontekst og dømmekraft. Agenter har fart. Din jobb er å sørge for at farten ikke overgår intensjonen.
En «strengere kontrakt» betyr at agenten aldri får lov til å være vag. Den har et formål som får plass i én setning, en sponsor som er ansvarlig, grenser som håndheves, og en livssyklus som slutter med mindre den fornyes. Slik holder du autonomien nyttig i stedet for risikabel.
Resultatstandarden som holder deg ærlig
Hvis du ønsker ett praktisk resultat for ledelsen, sikt mot dette: hver aktør er identifiserbar, tilskrivbar, gjennomgåbar og kontrollbar. Hvis du ikke kan gjøre disse fire tingene, har du ikke styring. Du har håp.
Identifiserbar betyr at du kan finne den og forstå hva den er til for uten arkeologi.
Tilskrivbar betyr at det finnes en sponsor som kan fornye eller pensjonere den.
Gjennomgåbar betyr at tillatelser og omfang med jevne mellomrom godkjennes på nytt basert på gjeldende virkelighet, ikke fjorårets antagelser.
Inneslutningsbar betyr at retningslinjer og grenser begrenser skade når noe går galt, slik at hendelser ikke blir problemer for hele leietakeren.