Det er lett å bli fascinert av kor raskt vi kan byggje ein agent. Ein fagperson kan få ein idé om morgonen og ha ein fungerande agent før lunsj.

Men kva skjer seks månader seinare når den same fagpersonen sluttar?

Kven eig agenten då? Kven veit kva den har tilgang til? Kven har ansvar for at den framleis skal eksistere? Og kven fangar opp agenten i offboardingprosessen dersom HR, IT og fagavdelinga ikkje ein gong veit at den finst?

Det er her eg meiner agent governance blir langt meir interessant enn sjølve bygginga av agenten.

For dette er ikkje først og fremst eit spørsmål om ein knapp som heiter Reassign Ownerless Agents. Det er eit spørsmål om kontroll gjennom heile livsløpet til ein digital ressurs.

TYPE=screenshot | human_required=true | Ekte skjermbilete frå Microsoft 365 admin center som viser agentoversikta, varsel om agentar utan eigar og inngangen til eigarhandtering.

Ein agent er ikkje berre noko ein tilsett har laga

Når vi snakkar om dokument, Teams, grupper eller Power Platform-løysingar, har dei fleste modne verksemder etter kvart fått eit forhold til eigarskap og livsløp. Vi veit at tilgangar skal fjernast når nokon sluttar. Vi veit at data må ha ein eigar. Vi veit at kritiske arbeidsprosessar ikkje bør vere avhengige av éin enkeltperson.

Agentar bør behandlast på same måte.

Problemet er at dei ofte blir introduserte som personlege produktivitetsverktøy: bygg noko som hjelper deg i kvardagen. Det er heilt naturleg i starten. Men i det augeblikket agenten blir delt med kollegaer, får tilgang til verksemdsdata eller blir ein del av ein arbeidsprosess, har den gått frå å vere eit personleg eksperiment til å bli ein forvalta digital ressurs.

Då held det ikkje lenger å vite kven som bygde den.

Du må vite kven som:

  • eig agenten teknisk
  • har fagleg ansvar for formålet
  • har ansvar for tilgangane agenten brukar
  • skal ta stilling til om den skal vidareførast når byggjaren sluttar
  • kan dokumentere kvifor agenten framleis skal ha tilgang til data og tenester

Dette er etter mitt syn kjernen i compliance-perspektivet. Ikkje compliance som ei liste med produktfunksjonar, men som evna til å kunne svare på kven, kva, kvifor og kor lenge.

Microsoft har no gitt oss betre mekanismar

Microsoft har fått på plass fleire mekanismar for eigarskap når ein byggjar sluttar. Det er bra. Men dei dekkjer ulike agenttypar og ulike scenario.

I Microsoft 365 admin center kan du no manuelt tildele ny eigar for agentar av typane Microsoft 365 Copilot Agent Builder og Copilot Studio.[^agent-actions] Det er viktig å vere presis her: dette er ikkje ein felles mekanisme for alle typar agentar i Microsoft-økosystemet, berre for dei dokumenterte agenttypane.

For Agent Builder-agentar finst det òg ein eigen regel, Reassign Ownerless Agents, som kan flytte eigarskap til manager basert på manager-feltet i Microsoft Entra-hierarkiet.[^agent-settings] Den regelen gjeld berre Agent Builder-agentar, ikkje Copilot Studio-agentar.

TYPE=screenshot | human_required=true | Ekte skjermbilete av Reassign Ownerless Agents-regelen med vilkår og handling synleg.

For eigarlause Copilot Studio-agentar finst det i tillegg ein API-basert prosess via Power Platform API. Han krev rett adminrolle, gyldig Entra-token og at ny eigar er i same tenant.[^orphaned-api]

Eigaroverføring av eigarlause Copilot Studio-agentar via API
Dokumenterer API-flyten, rollene og føresetnadene for eigaroverføring av eigarlause Copilot Studio-agentar.

Det viktige er nettopp at dette ikkje er éin felles offboardingflyt. Du må vite kva type agent du har før du kan vite kva kontroll som faktisk gjeld.

Og her byrjar governance-arbeidet lenge før nokon trykkjer på Reassign.

Offboarding bør starte før brukaren er borte

I ein tradisjonell offboardingprosess veit vi som regel kva vi skal leite etter: konto, grupper, postboks, lisensar, einingar og kanskje eigarskap til Teams eller SharePoint-område.

Agentar legg til eit nytt spørsmål:

Kva digitale arbeidsprosessar har denne personen bygd som andre no er avhengige av?

Det meiner eg bør bli eit eksplisitt punkt i offboarding.

Ein praktisk prosess kan til dømes vere:

  1. Finn agentar personen eig eller har bygd.
  2. Kartlegg kven som faktisk brukar dei.
  3. Vurder kva data, connectorar og handlingar agentane har tilgang til.
  4. Finn ein ny teknisk eigar dersom agenten skal leve vidare.
  5. Stadfest fagleg sponsor eller ansvarleg for formålet.
  6. Fjern agenten dersom ingen kan forklare kvifor den framleis skal eksistere.
  7. Dokumenter avgjerda.

TYPE=diagram | data={ “title”: “Praktisk offboarding for agentar”, “steps”: [ “Identifiser agentar”, “Kartlegg bruk og avhengigheiter”, “Vurder data, connectorar og handlingar”, “Peik ut ny teknisk eigar”, “Stadfest fagleg sponsor”, “Vidarefør eller avvikle”, “Dokumenter avgjerda” ] }

Det siste punktet er viktig. Ein agent bør ikkje få leve vidare berre fordi ingen tok avgjerda om å fjerne den.

Det er klassisk teknisk gjeld, berre med tilgang til data og handlingar på toppen.

Owner, sponsor og manager er tre forskjellige ting

Her blir Microsoft-modellen meir interessant, men også meir forvirrande om ein ikkje skil omgrepa frå kvarandre.

Ein owner er den tekniske eigaren av sjølve agenten i adminflyten. Ein sponsor er knytt til ansvar og livssyklus for agentidentiteten i Entra Agent ID og agent identity governance. Ein manager er leiaren i Entra-hierarkiet og kan vere mål for enkelte automatiske overføringar.[^agent-governance][^manage-agent-identities]

Desse kan vere same person, men dei betyr ikkje det same.

Det er viktig i ein kontrollmodell. Dersom vi berre seier «eigar», risikerer vi å tru at ein teknisk overføring har løyst heile styringsproblemet.

Det har den ikkje nødvendigvis.

Ein manager som automatisk får eigarskap til ein agent veit ikkje automatisk:

  • kva agenten faktisk gjer
  • om agenten framleis har eit legitimt formål
  • kva data agenten kan nå
  • om verksemda framleis ønskjer risikoen og kostnaden
  • kven som fagleg skal stå inne for resultatet agenten produserer

Det er derfor eg meiner Reassign Ownerless Agents er ein livsløpsmekanisme, ikkje ein komplett governance-modell.

Kort sagt: Microsoft 365 admin center handterer teknisk eigarskap på agentnivå, Agent 365 er det breiare kontrollplanet for inventar og styring, medan Entra Agent ID legg på identitetslaget. Det er særleg agent identity governance og sponsoroppgåvene i Lifecycle Workflows som her må lesast som preview og med eigne lisenskrav.[^agent365-overview][^agent365-feature][^agent-governance][^agent-sponsor-tasks]

TYPE=diagram | data={ “title”: “Livsløp for agent når byggjar sluttar”, “nodes”: [ “Byggjar opprettar agent”, “Agent blir teken i bruk”, “Byggjar sluttar”, “Agent blir eigarlaus eller mister sponsor”, “Vurdering av formål, tilgang og risiko”, “Ny eigar/sponsor eller avvikling” ] }

Agent Builder, Copilot Studio og tilgangar

Det er også viktig å ikkje overdrive kva Agent Builder faktisk er.

Agent Builder kan inngå i ulike produkt- og betalingsmodellar, og Copilot Studio følgjer eigne modellar og flytar. Difor bør ein vere varsam med å framstille dette som éin enkel eller felles lisensveg.[^governance-principles]

Microsoft dokumenterer òg at Agent Builder-agentar respekterer eksisterande Microsoft 365-rettar og ikkje får nye privilegium av seg sjølve.[^governance-principles]

Det er bra, men det er ikkje det same som at governance skjer av seg sjølv.

Dersom ein Agent Builder- eller Copilot Studio-agent blir brukt i ein arbeidsprosess, må du framleis vite:

  • kva datakjelder han nyttar
  • om connectorane framleis er rette
  • om dagens tilgangsnivå er forsvarleg
  • om retention, logging og kontrollar faktisk er sette opp slik verksemda treng

Poenget mitt er enkelt: at agenten ikkje får nye privilegium, betyr ikkje at risikoen er liten. Risikoen kan godt liggje i kombinasjonen av eksisterande tilgangar, dårleg eigarskap og manglande livsløpskontroll.

Agent 365 er den større styringsmodellen

Det er i denne samanhengen Microsoft Agent 365 gir meining.

Microsoft dokumenterer Agent 365 som generelt tilgjengeleg (GA) for kommersiell sektor frå 1. mai 2026, og som eit eige per-brukar-lisensiert produkt.[^agent365-overview] Samstundes må ein vere presis på at ikkje alt ligg i den same grunnpakka: funksjonsmatrisa viser at grunnleggjande agentinventar og enkelte governance-handlingar er tilgjengelege i Microsoft 365 admin center for fleire Microsoft 365-planar, medan mellom anna policy templates, observability og tool control krev Microsoft Agent 365 eller Microsoft 365 E7.[^agent365-feature]

Microsoft Agent 365
Microsoft si oversikt over Agent 365, inkludert kontrollplan, GA-status frå 1. mai 2026 og per-brukar-lisensiering.

TYPE=screenshot | human_required=true | Ekte skjermbilete frå Agent 365-oversikta med Agent registry, Connected platforms og Agents without owners synleg.

Det er ein retning eg meiner er fornuftig. Når talet på agentar aukar, kan ikkje governance vere avhengig av at nokon hugsar kvar kvar enkelt agent vart bygd.

Men Agent 365 erstattar ikkje dei konkrete eigarskaps- og offboardingflytane. Kontrollplanet kan hjelpe deg å sjå problemet. Du må framleis ha ein prosess for kva organisasjonen gjer med det.

Og Agent 365 er heller ikkje berre ein ny gratis adminside.

Det betyr at den meir heilskaplege styringsmodellen også er eit kostnadsval.

Det er verdt å vere tydeleg på, særleg i SMB-marknaden: du kan ha mekanismar for eigaroverføring utan å ha kjøpt heile Agent 365-kontrollplanet.

Entra Agent ID flyttar diskusjonen frå app til identitet

Microsoft Entra Agent ID er eit anna viktig lag. Her blir agenten behandla som ein identitet som kan styrast, få sponsor og inngå i livsløpsprosessar.[^agent-governance]

Administrer agentidentitetar i verksemda
Dokumenterer korleis agentidentitetar kan styrast i Entra, inkludert governance og sponsoroversikt.

Det er likevel viktig å avgrense preview-omtalen presist: Det som er dokumentert som preview i denne samanhengen, er agent identity governance og dei sponsorrelaterte oppgåvene i Lifecycle Workflows, ikkje nødvendigvis heile Entra Agent ID-laget som idé eller administrativt mønster.[^agent-governance][^agent-sponsor-tasks] Microsoft dokumenterer òg eigne lisensføresetnader for desse scenaria.[^agent-sponsor-tasks]

Styring av agentidentitetar
Dokumenterer agent identity governance, sponsoransvar og lisenskrav.

For meg er dette eigentleg den viktigaste utviklinga: agenten er ikkje lenger berre «noko inne i Copilot Studio». Den får etter kvart eigne identitets- og livsløpskontrollar.

Det betyr også at dei same prinsippa vi kjenner frå identitetsstyring blir relevante:

minste privilegium, tydeleg ansvar, periodisk vurdering og kontrollert avvikling.

Samtidig bør ein vere nøktern: dette er ikkje eit ferdig og enkelt regime som passar alle i dag. Når delar av funksjonaliteten er preview og lisensbiletet er delt mellom Agent 365 og Entra, må verksemda vere ekstra tydeleg på kva ho faktisk kjøper og kva ho faktisk får.

Compliance handlar om å kunne bevise at du har kontroll

Eg trur det er lett å gjere compliance meir komplisert enn det treng å vere.

I denne samanhengen handlar det om nokre ganske enkle spørsmål:

  • Kan du finne alle agentane dine?
  • Veit du kven som eig dei?
  • Veit du kva dei har tilgang til?
  • Veit du kvifor dei framleis eksisterer?
  • Har du ein prosess når eigaren sluttar?
  • Kan du dokumentere kven som tok avgjerda om vidareføring eller avvikling?

Om svaret på fleire av desse er nei, hjelper det lite at Microsoft har laga ein Reassign-knapp.

Knappen er eit verktøy. Kontrollen er prosessen rundt den.

Det same mønsteret ser vi igjen og igjen i Microsoft 365. Vi kjøper funksjonar og tenester, men den verkelege sikkerheita kjem først når dei blir sette inn i ein definert prosess med eigarskap og oppfølging.

Kva eg ville gjort i ei SMB-verksemd

Eg ville ikkje starta med å kjøpe meir teknologi.

Eg ville starta med å få oversikt over kva agentar som faktisk finst, kven som eig dei og kva forretningsprosessar dei støttar. Deretter ville eg lagt agentar inn som eit fast kontrollpunkt i joiner-, mover- og leaver-prosessane.

Så ville eg definert nokre enkle minimumskrav:

  • ingen produksjonsnær agent utan namngitt eigar
  • ingen kritisk agent med berre éin person som forstår formålet
  • dokumentert vurdering ved eigarskifte
  • tilgangar blir gjennomgått når agenten får ny eigar
  • agentar utan legitimt formål blir avvikla, ikkje berre overførte

Først når volumet og kompleksiteten krev det, ville eg vurdert Agent 365 som det breiare kontrollplanet.

Det er kanskje mindre spennande enn å starte med ein ny lisens. Men det gir etter mi vurdering mykje betre kontroll per krone.

Heilt ærleg?

Microsoft har gjort eit reelt arbeid med å tette eit ganske openbert hol: agentar kan ikkje bli ståande utan eigar berre fordi personen som bygde dei sluttar.

Manuell eigaroverføring i Microsoft 365 admin center, Reassign Ownerless Agents, API-flyten for Copilot Studio, Agent 365 og Entra Agent ID viser at Microsoft no byggjer ein langt meir moden livsløpsmodell rundt agentar.[^agent-actions][^agent-settings][^orphaned-api][^agent365-overview][^agent-governance]

Men vi bør ikkje forveksle produktfunksjonane med governance.

Ein agent som har fått ny eigar kan framleis vere feil konfigurert, ha for mykje tilgang eller ha mista det faglege formålet sitt.

Så spørsmålet er ikkje berre:

Kven eig agenten når byggjaren sluttar?

Det viktigaste spørsmålet er:

Har verksemda ein prosess som sørgjer for at nokon faktisk tek ansvar for kva som skal skje med den?

Der ligg forskjellen mellom å ha ein funksjon i admin center og å ha kontroll.

Kjelder

What is Microsoft Entra Agent ID?
Dokumenterer kva agentidentitetar er, og korleis dei kan styrast i Entra.
What are agent identities
Dokumenterer Microsoft Entra Agent ID og agentidentitetar i Entra.
Agent settings in Microsoft 365 admin center
Dokumenterer bulkregelen Reassign Ownerless Agents, avgrensa til Microsoft 365 Copilot Agent Builder og manager i Entra-hierarkiet.
Governance and Lifecycle actions for agents
Dokumenterer manuell Assign new owner for Agent Builder og Copilot Studio.
Reassign ownership of orphaned agents with the Power Platform API
Dokumenterer føresetnader, tenantkrav og avgrensingar for API-basert eigaroverføring.
Agent identity sponsor tasks in Lifecycle Workflows
Dokumenterer mover/leaver-taskar for sponsoransvar og lisenskrava for agent identity governance.