AI-agenter blir anställda. Är du redo?
Från piloter till produktion
AI-agenter går från experiment till infrastruktur. De läser, beslutar och agerar. Ibland som svar på en människa. Ibland på egen hand.
Hastigheten är funktionen.
Hastigheten är också risken.
Det som förändras när agenter blir "infrastruktur" är att de slutar vara ett enda teams verktyg och börjar bli ett delat beroende. De berör identitet, data, samarbetsytor och operativa arbetsflöden. I det ögonblick en agent kan utlösa åtgärder över system är frågan inte längre "fungerar det" utan "kan vi kontrollera det i stor skala". Microsofts riktlinjer för implementering av AI-agenter är tydliga gällande sekvensen: planera för agenter, styr och säkra agenter, bygg agenter och driftsätt sedan agenter. Om du vänder på den ordningen får du vanligtvis implementering före kontroll.
Varför agenter är svårare än appar
Microsofts Cloud Adoption Framework beskriver agenter som programvara som kan resonera kring indata, använda verktyg och vidta åtgärder, med stöd av instruktioner, hämtning, åtgärder och minne. Den kombinationen är det som gör agenter användbara och det som gör dem svårare att styra än traditionella appar. Du distribuerar inte bara kod. Du distribuerar beslutsslingor med räckvidd in i data och system.
I praktiken betyder ”verktyg” API-åtkomst, arbetsflödesutlösare, filoperationer, identitetssökningar, ärendeautomatisering och administrativa åtgärder. ”Hämtning” betyder att agenten kan hämta information från interna källor och syntetisera den till utdata och beslut. ”Minne” betyder att den kan bära kontext mellan interaktioner, vilket är kraftfullt, men också ökar risken för att data lagras, återanvänds eller dyker upp på fel plats om kontrollerna är svaga. Det är därför Cloud Adoption Framework knyter agentstyrning till mer än IAM: datastyrning, observerbarhet, säkerhetskontroller och utvecklingspraxis måste fungera tillsammans.
Genom samarbete med Fortytwo, pensjonerte Bufdir dets aldrende «Mine Ansatte»-oppsett och gick över till en ny tillgångsmodell byggd på CheckID och «Lederportalen».
Skillnaden var omedelbar: introduktionen av nyanställda och tillfälliga anställda blev renare och säkrare; manuella rutiner sållades bort och organisationen hade äntligen en grund för korrekta åtkomstgranskningar och en tydlig färdplan mot lösenordsfri autentisering.
Vad som går sönder först
Det första som går sönder i de flesta organisationer är inte modellen. Det är ägarskapet.
Ägarskap misslyckas eftersom agentidentiteter ser bedrägligt bekanta ut. De skapas som "ytterligare en appidentitet" och blir sedan snabbt operativa aktörer. När en agent kan köras kontinuerligt överlever den sprinten som skapade den. När den överlever sprinten behöver den en livscykel. När den behöver en livscykel behöver den en verklig ansvarig part med förnyelsebehörighet, inte bara någon som en gång skrev koden.
Varför detta nu är ett ämne för chefer
Det är därför agentidentitet nu är ett ämne för chefer. Om man behandlar agentidentiteter som vanliga app-appidentiteter får man samma felläge som under det senaste decenniet med tjänsteprincipaler, bara med mer autonomi och större yta.
Riskkurvan förändras eftersom agenter minskar friktion. Minskad friktion är poängen. Det innebär också att fler åtgärder sker automatiskt och att fler system kan kedjas samman. En enda identitet med överbehörigheter kan bli en genväg genom annars väl utformade kontroller. När något går fel händer det snabbare och sprider sig vidare, eftersom agenten är byggd för att driva arbetet framåt utan att vänta på godkännanden i varje steg.
Agentspridning är hur du förlorar kontrollen
Microsoft kallar det agentspridning: agenter dyker upp i fickor av verksamheten, förökar sig snabbt och överlever projektet som skapade dem. Behörigheterna är oftast för breda eftersom "det var enklare", och sedan kommer ingen tillbaka för att minska dem. När något ser misstänkt ut i loggarna finns det ingen ansvarig person som frågar vad agenten ska göra. Det är så små automatiseringar blir säkerhetsincidenter.
Spridning handlar inte bara om "för många agenter". Det handlar om för många agenter utan en gemensam standard för namngivning, metadata, risknivåer och granskning. Det handlar om agenter som skapats i olika produkter, av olika team, med olika antaganden om dataåtkomst, operativa gränser och övervakning. Man får identiteter som kan autentisera, anropa API:er och vidta åtgärder, medan organisationen kämpar med att svara på grundläggande frågor som vad agenten är till för, vilka data den kan beröra och om någon granskade dess behörigheter under det senaste kvartalet. Microsofts riktlinjer pekar uttryckligen på behovet av organisationsomfattande styrning och säkerhetsrutiner för agenter eftersom team-för-team-styrning inte håller när agenter sprider sig.
Microsofts riktning: styrning först, sedan skalning
Microsofts svar inom Entras ekosystem är att skapa förstklassiga identiteter för agenter genom Entra Agent ID, och att placera agentstyrning i en implementeringslivscykel som börjar med planering och styrning, inte verktyg. Du planerar, du styr och säkrar, du bygger, du driver. Om du inverterar den sekvensen får du skalning före kontroll.
Det praktiska skiftet här är standardisering. Istället för att varje team ska uppfinna sitt eget identitetsmönster, går man mot repeterbara identitets- och styrningsbyggstenar. I Entra Agent ID behandlas även identifiering som ett förstklassigt problem genom Agent Registry, som beskrivs som en centraliserad metadataförvaring och identifieringsmekanism för distribuerade agenter i hela organisationen. Det är viktigt eftersom styrning börjar med att veta vad som finns, inte att gissa.
Hur bör ett verkställande mandat se ut?
Den ska vara kort, genomförbar och byggd för verkligheten. Verkligheten inkluderar omorganisationer, leverantörsbyten, upptagna team och projekt som avslutas. Mandatet ska definiera hur agenter får existera i din hyresgäst, hur de ägs och hur de stängs ner.
Ansvarsskyldighet som överlever organisationsförändringar
Börja med ansvarsskyldighet som överlever organisationsförändringar. Entra Agent ID introducerar administrativa relationer som separerar teknisk kontroll från affärsansvar, inklusive sponsorer. En sponsor krävs när man skapar en agentidentitet eller en agentplan. Det är en inbyggd tvångsfunktion: varje agent måste ha en människa eller en grupp som kan förklara varför den finns och bestämma när den ska förnyas eller tas bort.
Denna separation är viktig eftersom tekniska administratörer inte ska behöva vara de som rättfärdigar affärssyftet, och företagare ska inte behöva administratörsbehörighet för att vara ansvariga. Sponsorer fattar livscykelbeslut och håller "varför"-frågan vid liv. Ägare hanterar teknisk administration. Detta undviker den klassiska fällan där ansvarsskyldigheten finns i ett Jira-ärende eller en avgången anställds inkorg.
Livscykel som standard, inte som undantag
Kräv sedan livscykel som standard. Tillfälliga agenter bör inte bli permanenta invånare. Din baslinje bör inkludera utgångsdatum, regelbunden granskning och ett register som låter dig upptäcka vad som finns och varför. Microsoft beskriver uttryckligen ett centraliserat agentregister som en upptäcktsmekanism med metadata om registrerade agenter. Det är så du förhindrar att osynliga agenter ackumulerar osynliga privilegier.
Ett register är inte byråkrati. Det är grundläggande operativ kontroll. Det bör innehålla tillräckligt med metadata för att snabbt kunna fatta beslut, såsom syfte, sponsor, miljö, dataomfattning och när det senast granskades. Utan det blir "åtkomstgranskning" gissningslek. Med det blir förnyelse ett beslut istället för en ritual. Microsofts agentregister är positionerat exakt för denna synlighet och organisation i stor skala, inklusive vägledning om agentmetadata och synlighetsmönster.
Gränser som begränsar explosionsradien
Slutligen, sätt gränser för var agenter kan köras och vad de kan vidröra. Cloud Adoption Framework-styrningsvyn knyter samman datastyrning och efterlevnad, observerbarhet, säkerhetskontroller och utvecklingspraxis. Detta är inte bara ett IAM-problem. Det är Purview och datakontroller, det är övervakning och kostnadssynlighet, det är hotskydd och det är säkra byggmönster.
Det är här många organisationer underinvesterar. De fokuserar på autentisering och glömmer att agentens värde kommer från tillgång till data och förmågan att agera. Om du inte kopplar ihop identitetskontroller med datakontroller och övervakning kommer du inte att se skillnaden mellan "upptagen agent" och "komprometterad agent" förrän det redan är dyrt. Cloud Adoption Frameworks styrnings- och säkerhetsriktlinjer är tydliga med att dessa kontroller måste vara konsekventa i hela organisationen, inte återuppfinnas per team.
Fortytwo se
AI-agenter bör behandlas som digitala medarbetare med ett striktare kontrakt än människor. Människor har kontext och omdöme. Agenter har snabbhet. Ditt jobb är att se till att hastigheten inte överträffar avsikten.
Ett ”striktare kontrakt” innebär att agenten aldrig får vara vag. Det har ett syfte som får plats i en mening, en sponsor som är ansvarig, gränser som upprätthålls och en livscykel som slutar om den inte förnyas. Det är så man behåller autonomin användbar istället för riskabel.
Resultatstandarden som håller dig ärlig
Om du vill ha ett praktiskt resultat för ledningen, sikta på detta: varje aktör är identifierbar, tillskrivbar, granskningsbar och hållbar. Om du inte kan göra dessa fyra saker har du ingen styrning. Du har hopp.
Identifierbar betyder att du kan hitta den och förstå vad den är till för utan arkeologi.
Tillskrivbar innebär att det finns en sponsor som kan förnya eller dra tillbaka den.
Granskningsbar innebär att tillstånd och omfattning regelbundet godkänns på nytt baserat på aktuell verklighet, inte förra årets antaganden.
Innehållsbar innebär att policyer och gränser begränsar skador när något går fel, så att incidenter inte blir hyresgästövergripande problem.