Entra Agent ID i praksis: Valg af det rigtige mønster og opbygning af sikre standardindstillinger
16 februar, 2026
TL;DR: Det svære ved AI-agenter er ikke "hvordan får vi agenten til at fungere", men "hvordan holder vi den styrbar, når den spredes på tværs af teams, produkter og miljøer."
Skala er det virkelige problem
De fleste hold kæmper ikke med at skabe den første agent. De kæmper med at skabe den halvtredsindstyvende.
Den første agent er en build. Den halvtredsindstyvende er en identitetsbase. På det tidspunkt er den svære del ikke "hvordan får vi agenten til at fungere", men "hvordan holder vi den styrbar, når den spredes på tværs af teams, produkter og miljøer." Det er netop derfor, Microsoft beskriver agentimplementering som en livscyklus, hvor styring og sikkerhed kommer før build og drift.
Struktur slår heltehukommelse
I lille skala kan man huske, hvad der findes. I virksomhedsskala har man brug for struktur. Microsofts agentidentitetsplatform er designet til den struktur: blueprints, agentidentiteter og valgfrie agentbrugere. Målet er ikke nyskabelse, men gentagelighed med kontrol.
Dette er et skift fra "hvert team opfinder sit eget identitetsmønster" til en fælles model, der muliggør opdagelse, arv og ansvarlighed. Når agenter mangedobles, har man brug for en ensartet måde at besvare de samme spørgsmål hver gang: Hvad er denne agent, hvem står bag den, hvad har den adgang til, og hvordan deaktiverer vi den hurtigt, hvis den opfører sig forkert. Platformens design er der for at gøre disse svar standardiserede, ikke skræddersyede.
Plan først: Skab kontrolfladen
Start med blueprinten. I Microsofts model er en agentidentitetsblueprint den genanvendelige skabelon til agentidentiteter. Den registrerer fælles karakteristika og fungerer som en container, så administratorer kan anvende politikken én gang og få den til at påvirke alle identiteter, der oprettes ud fra den. Afgørende er det, at blueprints indeholder de legitimationsoplysninger, der bruges til godkendelse. Agentidentiteter i sig selv har ikke hver deres eget sæt legitimationsoplysninger. Det er et stort skift fra traditionel spredning af serviceprincipaler.
Microsoft er tydelig omkring mekanismerne: legitimationsoplysninger, der bruges til at godkende en agentidentitet, er konfigureret på blueprinten, og det er blueprinten, der anmoder om adgangstokens fra Entra. Dette reducerer det klassiske udbredelsesproblem, hvor hver instans ender med sin egen hemmelighed, sin egen rotationsgæld og sin egen langtidsholdbare adgang, som ingen ønsker at røre ved, fordi "den kan gå i stykker". Blueprinten er også et naturligt sted at standardisere politikarv og holde kontroller ensartede for en hel klasse af agenter.
Én agentidentitet pr. implementeret instans
Derefter opretter du en agentidentitet for hver implementeret instans. Microsoft definerer en agentidentitet som en særlig tjenesteprincipal, der er oprettet af og autoriseret til at blive efterlignet af blueprinten. Den kan bruges både til autonome operationer og til brugerdelegeringsscenarier, afhængigt af hvordan agenten fungerer.
To detaljer er vigtige her. For det første har en agentidentitet ikke sine egne legitimationsoplysninger, hvilket er tiltænkt. For det andet kan blueprinten erhverve tokens på vegne af agentidentiteten, når det rette samtykke foreligger. Det er sådan, Microsoft gør forælder-barn-forholdet håndhæveligt i praksis, ikke kun i dokumentation.
Agentbrugere er valgfrie
Opret kun en agentbruger, når det er nødvendigt. Microsoft er tydelig med, at agentbrugere er valgfrie og designet til scenarier, hvor agenten skal fungere som en digital medarbejder, herunder adgang til postkasser og chat, eller har brug for API'er, der kun er tilgængelige for brugeridentiteter. De modtager tokens med idtyp=user, kan tilføjes til grupper og kan tildeles licenser. Denne bekvemmelighed er netop grunden til, at du bør holde agentbrugere sjældne og kontrollerede.
Agentbrugere ændrer styringspositionen, fordi de ser ud og opfører sig som en person i lejeren. Det kan være nødvendigt for Microsoft 365-arbejdsgange, men det øger også behovet for livscyklusdisciplin, strammere omfang og tydeligere beviser. Når noget har en brugerlignende tilstedeværelse, har det en tendens til at sprede sig til samarbejdsflader og menneskevendte processer, hvilket gør ejerskab og gennemgang endnu vigtigere.
Den praktiske mønstervælger
Hvis agenten kører baggrundsopgaver og kalder API'er med apptilladelser, befinder du dig normalt i agentidentitetsområdet. Hvis agenten handler på vegne af en bruger, der er logget ind, befinder du dig i brugerdelegeringsområde, hvor brugerkonteksten skal forblive synlig i autorisationskæden. Hvis agenten skal behandles som et teammedlem i systemer, der kræver et brugerobjekt, træder du ind i agentbrugerområdet og accepterer den styringsoverhead, der følger med.
At vælge det forkerte mønster viser sig normalt senere som revisionsproblemer og operationel friktion. App-lignende agenter har brug for klare tilladelsesgrænser og indeslutning. Brugerdelegerede agenter har brug for sporbarhed, der bevarer brugerens intention. Digitale arbejdsagenter har brug for strengere livscykluskontroller, fordi de kan akkumulere menneskeligt tilstødende adgang over tid.
Hvor du vinder eller taber
Nu, sikre standardindstillinger.
I stor skala bliver standarder til kultur. Hvis "hurtig" betyder "overprivilegeret", vil du få overprivilegerede agenter overalt. Hvis "hurtig" betyder "standardiseret og styret", bevæger teams sig hurtigt inden for rækværk i stedet for hurtigt at bevæge sig uden om dem.
Ansvarlighed er ikke valgfri
Ansvarlighed er ikke valgfri i denne model. Sponsorer, ejere og ledere er førsteklasses administrative relationer. En sponsor er påkrævet, når man opretter en agentidentitet eller en agentplan. Det er vigtigt, fordi det forhindrer forældreløse identiteter via design, ikke via et policymemo.
Microsofts administrative model er eksplicit: sponsorer er påkrævet ved oprettelse af agentidentiteter og blueprints, mens blueprint-principaler er undtaget under oprettelsen, mens ejere og ledere er valgfrie. Denne adskillelse er praktisk. Ejere kan administrere. Sponsorer kan træffe beslutninger om forretningslivscyklus uden at have brug for tekniske rettigheder. Det er en indbygget mekanisme til at holde "hvorfor dette eksisterer" knyttet til identiteten, selv når teams ændres.
Legitimationsoplysninger er ikke bekvemmelighed
Legitimationsoplysninger bør behandles som et sikkerhedsprodukt, ikke en bekvemmelighed for udviklere. Microsofts vejledning til tokenanskaffelse advarer mod klienthemmeligheder i produktion og peger på stærkere tilgange som fødererede identitetslegitimationsoplysninger og certifikater. Din baseline bør være i overensstemmelse med dette, og derefter gøre undtagelser smertefulde.
Årsagen er enkel: Hemmeligheder spredes. De bliver kopieret ind i pipelines, scripts og tredjepartsværktøjer, og bliver derefter vanskelige at rotere uden at afbryde produktionen. Stærkere legitimationsoplysninger reducerer risikoen for, at én lækket hemmelighed bliver en varig adgangsvej. I en agentverden, hvor identiteter kan være langvarige og autonome, forværres denne risiko.
Entra Agent ID-styring
Styr dine agenter på samme måde, som du ville styre menneskelige identitetslivscyklusser.
Opdagelse og beviser
Planlæg endelig for opdagelse og bevismateriale. Microsoft beskriver et agentregister som et centraliseret arkiv af metadata og en opdagelsesmekanisme. Microsofts bredere styringsvejledning understreger synlighed i agenters adfærd og organisationsomfattende kontroller på tværs af datastyring, observerbarhed og sikkerhed. Hvis du ikke kan opdage agenter og bevise, hvad de gjorde, kan du ikke betjene dem sikkert.
Microsoft går videre end "opgørelse". Registreringsdatabasen beskrives som et samlet metadatalager, der kan give synlighed på tværs af Microsoft- og ikke-Microsoft-økosystemer, og de metadata, du angiver, bestemmer, hvordan andre systemer, agenter og brugere kan finde og interagere med din agent. Det gør synlighed til et sikkerhedsproblem, ikke en dokumentationsopgave.
Kontakt os
Brug for en sikker model for agentidentitet før implementeringsskalaer?
Fortytwo hjælper dig med at designe Entra Agent ID-styring med klart ejerskab, sponsormodeller, livscykluskontrol, adgangsgrænser og revisionsklar dokumentation.
