It’s easy to be fascinated by how quickly we can build an agent. A subject-matter expert can get an idea in the morning and have a working agent before lunch.
But what happens six months later when that same expert leaves?
Who owns the agent then? Who knows what it has access to? Who is responsible for it continuing to exist? And who catches the agent in the offboarding process if HR, IT and the business unit don’t even know it exists?
This is where I think agent governance becomes far more interesting than the agent build itself.
Because this is not primarily a question of a button called Reassign Ownerless Agents. It’s a question of control across the entire lifecycle of a digital asset.
An agent isn’t just something an employee made
When we talk about documents, Teams, groups, or Power Platform solutions, most mature organizations have developed a sense for ownership and lifecycle. We know that access must be removed when someone leaves. We know that data needs an owner. We know that critical business processes shouldn’t depend on a single individual.
Agents should be treated the same way.
The problem is they’re often introduced as personal productivity tools: build something that helps you day to day. That’s perfectly natural at the start. But the moment the agent is shared with colleagues, gets access to enterprise data, or becomes part of a business process, it has moved from being a personal experiment to being a managed digital asset.
Then it’s no longer enough to know who built it.
You need to know who:
- owns the agent technically
- has business responsibility for the purpose
- is responsible for the accesses the agent uses
- will decide whether it should continue when the builder leaves
- can document why the agent should still have access to data and services
This is, in my view, the core of the compliance perspective. Not compliance as a list of product features, but the ability to answer who, what, why, and for how long.
Microsoft has now given us better mechanisms
Microsoft has put in place several ownership mechanisms when a builder leaves. That’s good. But they cover different agent types and different scenarios.
In the Microsoft 365 admin center you can now manually assign a new owner for agents of the types Microsoft 365 Copilot Agent Builder and Copilot Studio.[^agent-actions] It’s important to be precise here: this is not a common mechanism for all types of agents in the Microsoft ecosystem, only for the documented agent types.
For Agent Builder agents there is also a specific rule, Reassign Ownerless Agents, which can transfer ownership to the manager based on the manager field in the Microsoft Entra hierarchy.[^agent-settings] That rule applies only to Agent Builder agents, not Copilot Studio agents.
For ownerless Copilot Studio agents there is additionally an API-based process via the Power Platform API. It requires the correct admin role, a valid Entra token, and that the new owner is in the same tenant.[^orphaned-api]
The important thing is precisely that this isn’t a single offboarding flow. You must know what type of agent you have before you can know what control actually applies.
And this is where governance work starts long before anyone clicks Reassign.
Offboarding should start before the user is gone
In a traditional offboarding process we usually know what to look for: account, groups, mailbox, licenses, devices, and perhaps ownership of Teams or SharePoint sites.
Agents add a new question:
What digital business processes has this person built that others now depend on?
I think that should become an explicit item in offboarding.
A practical process could be, for example:
- Find agents the person owns or has built.
- Map who actually uses them.
- Assess what data, connectors and actions the agents have access to.
- Find a new technical owner if the agent is to live on.
- Confirm a business sponsor or responsible owner for the purpose.
- Remove the agent if no one can explain why it should continue to exist.
- Document the decision.
![TYPE=diagram | data={ “title”: “Practical offboarding for agents”, “steps”: [ “Identify agents”, “Map usage and dependencies”, “Assess data, connectors and actions”, “Appoint new technical owner”, “Confirm business sponsor”, “Continue or retire”, “Document the decision” ] }](/en/posts/reassign-ownerless-agents-kva-skjer-med-copilot-agenten-nar-byggjaren-sluttar/offboarding-agent-checklist.png)
The last point is important. An agent shouldn’t be allowed to live on just because no one made the decision to remove it.
That’s classic technical debt, only with access to data and actions on top.
Owner, sponsor and manager are three different things
Here the Microsoft model becomes more interesting, but also more confusing if you don’t separate the concepts.
An owner is the technical owner of the agent itself in the admin flow. A sponsor is tied to responsibility and lifecycle for the agent identity in Entra Agent ID and agent identity governance. A manager is the leader in the Entra hierarchy and may be the target for certain automatic transfers.[^agent-governance][^manage-agent-identities]
These can be the same person, but they don’t mean the same thing.
That matters in a control model. If we just say “owner”, we risk believing that a technical transfer has solved the entire governance problem.
It hasn’t necessarily.
A manager who automatically gets ownership of an agent doesn’t automatically know:
- what the agent actually does
- whether the agent still has a legitimate purpose
- what data the agent can reach
- whether the organization still wants the risk and cost
- who should stand behind the results the agent produces from a business standpoint
That’s why I think Reassign Ownerless Agents is a lifecycle mechanism, not a complete governance model.
In short: Microsoft 365 admin center handles technical ownership at the agent level, Agent 365 is the broader control plane for inventory and governance, while Entra Agent ID adds the identity layer. In particular, agent identity governance and the sponsor tasks in Lifecycle Workflows should here be read as preview and with separate licensing requirements.[^agent365-overview][^agent365-feature][^agent-governance][^agent-sponsor-tasks]
![TYPE=diagram | data={ “title”: “Lifecycle for an agent when the builder leaves”, “nodes”: [ “Builder creates agent”, “Agent is adopted”, “Builder leaves”, “Agent becomes ownerless or loses sponsor”, “Assessment of purpose, access and risk”, “New owner/sponsor or retirement” ] }](/en/posts/reassign-ownerless-agents-kva-skjer-med-copilot-agenten-nar-byggjaren-sluttar/agent-livslop-ownerless-agent.png)
Agent Builder, Copilot Studio and access
It’s also important not to overstate what Agent Builder actually is.
Agent Builder can be part of different product and billing models, and Copilot Studio follows its own models and flows. Therefore you should be cautious about presenting this as a single simple or common licensing path.[^governance-principles]
Microsoft also documents that Agent Builder agents respect existing Microsoft 365 rights and don’t gain new privileges on their own.[^governance-principles]
That’s good, but it’s not the same as governance happening by itself.
If an Agent Builder or Copilot Studio agent is used in a business process, you still need to know:
- what data sources it uses
- whether the connectors are still appropriate
- whether the current access level is defensible
- whether retention, logging and controls are actually set up the way the organization needs
My point is simple: that the agent doesn’t get new privileges doesn’t mean the risk is small. The risk can well lie in the combination of existing access, poor ownership and missing lifecycle control.
Agent 365 is the larger governance model
It’s in this context that Microsoft Agent 365 makes sense.
Microsoft documents Agent 365 as generally available (GA) for commercial from May 1, 2026, and as a separately per-user-licensed product.[^agent365-overview] At the same time, one must be precise that not everything is in the same base package: the feature matrix shows that basic agent inventory and certain governance actions are available in Microsoft 365 admin center for several Microsoft 365 plans, while policy templates, observability and tool control require Microsoft Agent 365 or Microsoft 365 E7.[^agent365-feature]
That’s a direction I think is sensible. As the number of agents grows, governance can’t depend on someone remembering where each agent was built.
But Agent 365 doesn’t replace the concrete ownership and offboarding flows. The control plane can help you see the problem. You still need a process for what the organization does about it.
And Agent 365 is not just a new free admin page either.
That means the more holistic governance model is also a cost decision.
It’s worth being explicit about, especially in the SMB market: you can have ownership transfer mechanisms without having purchased the entire Agent 365 control plane.
Entra Agent ID moves the discussion from app to identity
Microsoft Entra Agent ID is another important layer. Here the agent is treated as an identity that can be governed, sponsored and included in lifecycle processes.[^agent-governance]
It’s still important to scope the preview mention precisely: What’s documented as preview in this context is agent identity governance and the sponsor-related tasks in Lifecycle Workflows, not necessarily the entire Entra Agent ID layer as an idea or administrative pattern.[^agent-governance][^agent-sponsor-tasks] Microsoft also documents separate licensing prerequisites for these scenarios.[^agent-sponsor-tasks]
For me this is actually the most important development: the agent is no longer just “something inside Copilot Studio.” It gradually gets its own identity and lifecycle controls.
That also means the same principles we know from identity governance become relevant:
least privilege, clear responsibility, periodic review, and controlled retirement.
At the same time we should be sober: this isn’t a finished and simple regime that fits everyone today. When parts of the functionality are preview and the licensing picture is split between Agent 365 and Entra, the organization must be extra clear about what it is actually buying and what it actually gets.
Compliance is about being able to prove you’re in control
I think it’s easy to make compliance more complicated than it needs to be.
In this context it comes down to some quite simple questions:
- Can you find all your agents?
- Do you know who owns them?
- Do you know what they have access to?
- Do you know why they still exist?
- Do you have a process when the owner leaves?
- Can you document who made the decision to continue or retire?
If the answer to several of these is no, it doesn’t help much that Microsoft has made a Reassign button.
The button is a tool. Control is the process around it.
We see the same pattern again and again in Microsoft 365. We buy features and services, but the real security comes only when they are part of a defined process with ownership and follow-up.
What I would do in an SMB
I wouldn’t start by buying more technology.
I would start by getting an overview of what agents actually exist, who owns them and which business processes they support. Then I would add agents as a fixed control point in the joiner, mover and leaver processes.
Then I would define a few simple minimum requirements:
- no production-adjacent agent without a named owner
- no critical agent with only one person who understands the purpose
- documented assessment at ownership change
- access is reviewed when the agent gets a new owner
- agents without a legitimate purpose are retired, not just transferred
Only when volume and complexity demand it would I consider Agent 365 as the broader control plane.
That’s perhaps less exciting than starting with a new license. But in my assessment it gives much better control per dollar.
Honestly?
Microsoft has done real work to close a fairly obvious gap: agents can’t be left without an owner just because the person who built them leaves.
Manual ownership transfer in Microsoft 365 admin center, Reassign Ownerless Agents, the API flow for Copilot Studio, Agent 365 and Entra Agent ID show that Microsoft is now building a much more mature lifecycle model around agents.[^agent-actions][^agent-settings][^orphaned-api][^agent365-overview][^agent-governance]
But we shouldn’t confuse product features with governance.
An agent that has a new owner can still be misconfigured, have too much access, or have lost its business purpose.
So the question isn’t just:
Who owns the agent when the builder leaves?
The more important question is:
Does the organization have a process that ensures someone actually takes responsibility for what should happen to it?
That’s the difference between having a function in the admin center and having control.