Problemet ingen snakker høyt om
Bedrifter ruller ut AI-agenter raskere enn de rekker å styre dem. Det er ikke en påstand – det er et målt funn. En fersk undersøkelse fra sikkerhetsselskapet Gravitee fant at bare rundt 22 prosent av virksomheter behandler agenter som egne identiteter med egen livssyklus. Resten lar agentene gjenbruke delte API-nøkler, menneskelige innloggingsdetaljer eller generiske tjenestekontoer. 88 prosent av de spurte hadde hatt en bekreftet eller mistenkt sikkerhetshendelse knyttet til en agent det siste året.
Ikke-menneskelige identiteter – tjenestekontoer, API-nøkler, og nå AI-agenter – overgår allerede antall menneskelige brukere med et sted mellom 45 og over 100 til én i mange virksomheter. Ifølge KPMG-tall vokste antall maskin-identiteter per virksomhet fra rundt 50 000 til 250 000 mellom 2021 og 2025. Agenter er ikke bare enda en versjon av det samme problemet. De er verre, fordi de i motsetning til en statisk tjenestekonto kan be om ny tilgang dynamisk, kjede sammen handlinger autonomt, og bli opprettet raskere enn en IT-avdeling rekker å registrere dem.
Dette er ikke et hypotetisk problem. Det er allerede dokumentert i praksis.
Hendelsen som viser hva som faktisk kan gå galt
- mars 2026 publiserte Palo Alto Networks' trusseletterretningsteam Unit 42 en rapport kalt «Double Agents». Den viste at Google Vertex AI Agent Engine ga hver agent en standard tjenestekonto på prosjektnivå med langt mer tilgang enn nødvendig. En kompromittert eller manipulert agent kunne lese alle Google Cloud Storage-buckets i prosjektet, bevege seg videre inn i Googles egen infrastruktur, og hente ut private container-images fra registre som skulle vært sperret. Googles svar var å anbefale kundene å sette opp en egen, avgrenset tjenestekonto i stedet for standardvalget.
Det interessante er ikke at Google gjorde noe unikt dårlig. Det er at standard-oppsettet – bred tilgang, gitt automatisk, uten tidsbegrensning – er nøyaktig det mønsteret de fleste plattformer fortsatt lener seg på.
Teleports undersøkelse blant 205 sikkerhetsledere og arkitekter i 2026 satte tall på konsekvensen: virksomheter som ga AI-agenter bred tilgang hadde 76 prosent sannsynlighet for en sikkerhetshendelse. Virksomheter som begrenset tilgangen til den konkrete oppgaven, hadde 17 prosent. Det er over fire ganger så høy risiko med bred tilgang – og 61 prosent av hendelsene involverte eksponering av sensitive data.
Dette er grunnen til at Gartner har plassert «identitets- og tilgangsstyring tilpasset AI-agenter» blant sine viktigste sikkerhetstrender for 2026, og samtidig advarer om at over 40 prosent av agentiske AI-prosjekter vil bli skrinlagt innen 2027 – delvis fordi risikostyringen ikke var på plass fra start.
Hva Microsoft Entra Agent ID faktisk er
Microsofts svar er å gi hver AI-agent en egen, styrbar identitet i Entra – ikke ulikt en tjenesteprinsipal, men bygget spesifikt for agenter. Entra Agent ID ble allment tilgjengelig i april 2026, og Microsoft Agent 365 – styringslaget rundt det – ble allment tilgjengelig 1. mai samme år.
Modellen består av fire objekttyper. En agentIdentityBlueprint er malen: den definerer hva slags agent det er, og hvilke rettigheter den arver ved opprettelse. En agentIdentityBlueprintPrincipal er malens tilstedeværelse i en gitt leietaker – relevant for agenter som brukes på tvers av flere organisasjoner. agentIdentity er selve autentiseringsidentiteten agenten bruker. Og agentUser er en valgfri, lenket brukerkonto for agenter som skal opptre mer som en kollega enn et bakgrunnsverktøy – med egen e-postboks og Teams-tilstedeværelse.
Identitetene opprettes ikke manuelt av en admin i de fleste tilfeller – de opprettes av plattformen agenten kjører på. Microsoft Foundry oppretter automatisk en mal og en dedikert identitet for hver publiserte agent. Copilot Studio kan gjøre det samme (i forhåndsversjon). Teams-utviklere oppretter maler via Developer Portal.
Et poeng verdt å merke seg: owner og sponsor er to separate, eksplisitte felt i Entra – ikke det samme. Sponsor er den formelle ansvarsrelasjonen: et menneske som er ansvarlig for beslutninger om agentens tilgang og livssyklus, får varsel når tilgang nærmer seg utløp, og kan godkjenne eller avslå forlengelse.
Access Packages: mekanikken som gjør tilgangen styrbar
Dette er selve kjernen i modellen – og grunnen til at vi mener det er alfa og omega for trygg agent-bruk.
En Access Package er en pakke med ressurser – sikkerhetsgrupper, katalogroller, eller API-tillatelser – som kan tildeles gjennom en styrt forespørsel-godkjenning-utløp-prosess. Det som er nytt, er at denne mekanismen nå gjelder agent-identiteter, ikke bare mennesker.
Tilgang kan bes om på tre måter: agenten kan be om det selv, programmatisk, via Graph API. Sponsoren kan be om det på agentens vegne gjennom My Access-portalen. Eller en admin kan tildele det direkte. Forespørselen går gjennom én til tre konfigurerbare godkjenningstrinn – typisk ressurseier, IT-admin, eller begge.
Én begrensning er verdt å kjenne til før dere planlegger et oppsett: kun sikkerhetsgrupper, katalogroller og API-/OAuth-tillatelser kan legges til som ressurser i en agent-pakke. Applikasjonsroller, SAP-roller og SharePoint Online-siderollertilgang kan ikke legges til direkte. Skal en agent ha tilgang til et konkret SharePoint-sted, er løsningen å opprette en sikkerhetsgruppe, legge den til i pakken, og deretter gi den gruppen tilgang på SharePoint-siden – en indirekte vei, men en fungerende én.
Tidsbegrensningen er ikke en detalj – den er poenget
Når tilgangen er godkjent, er den tidsbegrenset med en definert start- og sluttdato. Det er et hardt kutt: når fristen løper ut uten at sponsoren handler, mister agenten tilgangen. Sponsoren varsles i forkant og kan be om forlengelse – men det utløser en helt ny godkjenningsrunde, ikke en stille fornyelse. Det finnes ingen automatisk «bare fortsett»-vei.
Dette er forskjellen mellom vanlig minste-privilegium og det sikkerhetsmiljøet kaller null stående privilegium (Zero Standing Privilege). Minste-privilegium handler om å begrense hvor mye tilgang en identitet har til enhver tid. Null stående privilegium stiller et strengere spørsmål: bør denne identiteten ha noen tilgang i det hele tatt akkurat nå, mellom oppgaver? Med null stående privilegium har en agent ingenting å stjele når den er inaktiv. En stjålet API-nøkkel med permanent tilgang er utnyttbar døgnet rundt. En agent-identitet uten tilgang mellom oppgaver er det motsatte.
Vi må være ærlige om én ting forskningen vår ikke kunne bekrefte presist: hva som skjer med en pågående oppgave i det øyeblikket tilgangen utløper midt i arbeidet. Det generelle mønsteret i Entra er at autorisasjon evalueres når et token utstedes eller fornyes, med Continuous Access Evaluation som muliggjør nær sanntids-tilbaketrekking for støttede ressurser – men dette er ikke eksplisitt dokumentert for akkurat denne situasjonen. Det er verdt å teste selv før dere stoler blindt på at en pågående jobb stopper pent.
Betinget tilgang og identitetsbeskyttelse – laget over laget
Fra tidlig juli 2026, med ferdigstillelse forventet i begynnelsen av august, ruller Microsoft ut to nye tjenesteplaner: Betinget tilgang for agenter og Identitetsbeskyttelse for agenter. Skriver vi dette mens utrullingen fortsatt pågår i enkelte leietakere – sjekk tilgjengelighet i egen tenant før dere lover det til en kunde.
Betinget tilgang kan rettes mot agent-identiteten selv (app-only-flyt), agentens tilknyttede brukerkonto, eller malen – der policyen arves av alle agenter avledet fra den. Det kan ikke rettes mot «alle brukere» som samlekategori; agenter må adresseres eksplisitt.
Identitetsbeskyttelse for agenter oppdager blant annet admin-bekreftet kompromittering, ondsinnet aktivitet tidlig i en agents levetid, katalog-rekognosering, mislykkede tilgangsforsøk, treff mot Microsofts trusseletterretning, uvanlige innloggingstopper og tilgang til uvante ressurser. En «læringsmodus» demper falske positiver for nye eller lite brukte agenter. Handlingsrommet er å bekrefte kompromittering, avvise som ufarlig, eller deaktivere agenten helt.
Det ærlige bildet: hva som fortsatt mangler
Ingen ny plattform er feilfri, og det er ikke troverdig å late som Entra Agent ID er det.
Microsofts eget FAQ-dokument, oppdatert 26. juni 2026, lister flere kjente begrensninger: standard admin-samtykke-flyt fungerer ikke for agent-identiteter ennå – admin må gi tillatelser direkte. Det finnes ikke støtte for dynamiske grupper for agent-brukerkontoer, bare manuelt tildelte. Godkjennes en mal i en annen leietaker, kommer det ikke noe varsel – det må sjekkes manuelt mot Graph API. Og agent-identiteter kan ikke bruke vanlige SSO-, OIDC- eller SAML-innloggingssider.
Vi fant heller ingen offentlige kundecase for Entra Agent ID eller Access Packages ennå – verken norske, nordiske eller internasjonale, utover Microsofts egne demonstrasjoner. Det er ikke i seg selv et argument mot å ta det i bruk, men det er verdt å vite: dere er tidlig ute, ikke sent ute, hvis dere setter dette opp nå.
Én god nyhet, spesielt relevant for oss: tredjepartsplattformer som n8n og AWS Bedrock er faktisk støttet, via Entra Auth SDK eller arbeidsbelastnings-identitetsføderasjon med OAuth2/OIDC. Det betyr at agent-automasjon bygget utenfor Microsofts eget økosystem fortsatt kan styres gjennom samme identitets- og tilgangsrammeverk – noe som gjør hele modellen langt mer relevant for virksomheter som blander Microsoft 365 med egne automasjonsverktøy.
Hva det faktisk koster
Microsoft Agent 365 selges som eget tillegg til 15 dollar per bruker per måned, eller som del av Microsoft 365 E7 til 99 dollar per bruker per måned – en pakke som også inkluderer M365 E5, Copilot og Entra Suite, med om lag 15 prosent rabatt sammenlignet med å kjøpe alt separat. Access Packages krever i tillegg Entra ID Governance P1.
Det er ikke priset som et rent enterprise-produkt utilgjengelig for mellomstore virksomheter – det er priset per bruker, som de fleste M365-tillegg. Men Microsofts egen anbefaling er å lisensiere «alle som samhandler med, administrerer eller sponser» en agent, noe som fort kan blåse opp brukerantallet i en organisasjon som tar governance seriøst fra start. Det er nettopp den typen kalkyle vi hjelper kunder med å gjøre riktig, før den blir en overraskelse på fakturaen.
Hvorfor vi mener dette er alfa og omega
Vi bygger allerede RBAC-oppsett inn i hver eneste leveranse – det er ikke noe vi legger til i etterkant. Det Entra Agent ID og Access Packages gir oss, er den konkrete mekanismen som gjør det mulig å si det samme om agenter som vi alltid har sagt om mennesker: tilgang skal være begrunnet, tidsbegrenset, og noen skal stå ansvarlig for den.
Det er ikke fordi teknologien er ufeilbarlig. Vi har nettopp listet opp det den ikke gjør ennå. Det er fordi alternativet – agenter med stående, ubegrenset tilgang fordi ingen tok seg tid til å sette opp noe bedre – er nøyaktig mønsteret som ga Google Vertex AI-hendelsen, og nøyaktig mønsteret Teleports tall viser er over fire ganger så risikabelt. Access Packages er ikke den eneste tingen som gjør en agent trygg å bruke. Men uten dem har dere ingen reell måte å bevise, i etterkant, at agenten bare hadde tilgang til det den faktisk trengte, i det tidsrommet den faktisk trengte det.
Det er forskjellen mellom å stole på en agent fordi dere håper det går bra, og å stole på den fordi dere kan vise nøyaktig hvorfor.
AI starter ikke med teknologi. Den starter med struktur.