You would never let a contractor into your systems without an identity, an owner and an end date. Most organisations are doing exactly that with agents, at speed.
Microsoft reported that active agents across the Microsoft 365 ecosystem grew roughly 15-fold year on year, rising to 18-fold in large enterprises. Whatever the precise number in your tenant, the direction is not in doubt.
Which raises a question most organisations have not answered. Every one of those agents can read data and take actions. Who is accountable for each of them, and how would you find out?
An agent is a privileged account.
This framing is not a metaphor,r and I would encourage taking it literally. An agent has credentials, reads data, calls systems, and in many cases writes to them. If a contractor had that access, you would know their name, their manager, their start and end dates, and exactly what they could reach.
The gap in that chart is the problem. Not because ungoverned agents are necessarily malicious or broken, but because you cannot answer basic questions about them. Which agents can see HR data. Which ones have not been used in six months. Which one belongs to the person who left in April.
Joiner, mover, leaver, applied to software
The useful realisation is that none of this requires inventing a discipline. Identity governance already has the answers for humans, and the same controls now extend to agents.
Microsoft Entra Agent ID gives each agent an identity for lifecycle and access management. Agent 365 provides registry- and tenant-level observability. Since 1 May 2026, it has been the unified control plane, with the agent registry moving out of Entra into Agent 365 in the Microsoft 365 admin centre. Entra ID Governance extends entitlement management to agents, which means scoped permissions, ownership accountability, and time-bound access, including for partner agents integrated through the Agent 365 SDK.
The capability is there. What is usually missing is anyone having decided it is their job.
The five questions
If you want a quick assessment of where you stand, try answering these about your own tenant. Most people can answer one or two.
- How many agents exist, including the ones built by individuals in Agent Builder?
- For each one, who is the named human owner, and does that person still work here?
- What can each agent reach, and was that access reviewed in the last quarter?
- What did the highest volume agent actually do last week, and what did it cost?
- If you needed to revoke an agent’s access this afternoon, what would you do and who would notice?
The second question is the one that elicits the most uncomfortable silence and matters most. An agent whose owner has left is an unmanaged privileged account with no one to ask about it.
For the practitioners
- Start with discovery, not policy. The Agent 365 registry in the Microsoft 365 admin centre gives you the catalogue. You cannot govern what you have not enumerated.
- Please make ownership a required field at creation rather than a retrospective cleanup exercise. Retrofitting owners onto two hundred existing agents is a genuinely miserable project.
- Apply time-bound access through Entra ID Governance entitlement management. Agents accumulate permissions exactly as service accounts always have, and nothing is ever removed unless it expires.
- Include agents in your leaver process. When a person leaves, their agents need a new owner or a retirement date, and this should be automatic rather than remembered.
- Watch cost as a signal, not just as a bill. An agent whose consumption jumps unexpectedly is telling you something about a loop, a prompt change or a misuse.
Why this gets deferred, and why that is a mistake
Agent governance always loses the prioritisation argument early on because, at ten agents, it feels like bureaucracy imposed on something that is working fine. The person proposing it sounds like they are slowing down the exciting part.
The trouble is that the cost of retrofitting scales with the number of agents, while the cost of doing it properly from the start is nearly fixed. At ten agents, requiring an owner and an expiry date is a five-minute conversation. At three hundred agents, it is a programme with a business case and a project manager.
There is also a compliance dimension that arrives whether you were ready or not. If an auditor asks which automated systems process personal data and who is accountable for each, the answer needs to exist. Building the registry after that question is asked is considerably less comfortable than building it before.
Where the unregistered agents come from
It is tempting to picture shadow agents as something reckless people do. Almost always, the opposite is true: they are built by capable, well-intentioned people solving a real problem with tools the organisation gave them and encouraged them to use.
- Someone in finance builds an assistant for their month-end checklist because the process is painful and the tooling is right there in their Microsoft 365 app.
- A project manager creates an agent that answers questions from a programme’s document library, shares it with the team, and then leaves the programme.
- A supplier or partner ships an agent as part of their product, which now operates inside your tenant under terms nobody in IT reviewed.
- A team builds something during an innovation week; it turns out to be genuinely useful and quietly becomes part of how the department works, with no supporting model behind it.
The last two are the ones that cause trouble. Partner agents integrated through the Agent 365 SDK can be brought under the same entitlement management as your own, which is worth knowing, but it may not be top of mind for everyone. And the innovation week agent is the classic orphan: valuable enough that removing it would cause complaints, unsupported enough that nobody can safely change it.
The policy response people reach for is restriction, and I would resist it. Making agent creation difficult does not reduce demand; it relocates it, usually to somewhere with less visibility than a governed environment. Registration is a far better lever than prohibition. Let people build, require that the thing has a name and an owner, and you keep both the innovation and the catalogue.
What to do in the next fortnight
If this all sounds like a programme you do not have budget for, it is worth saying that the first useful steps are small and mostly involve looking rather than building.
- Open the agent registry in the Microsoft 365 admin centre and count what is there. Most people are surprised, in one direction or the other.
- Pick the ten most used agents and find out who owns each one. Any that cannot be answered in five minutes is your priority list.
- Check whether ownership is a required field at creation in your environments. If it is not, make it one. This is a configuration change, not a project.
- Add a line to the leaver checklist covering agents. It costs nothing, and it prevents the most common orphan.
- Set a review date in the calendar for three months out, with a named person assigned. Governance that depends on someone remembering does not survive a busy quarter.
What to take away
- Treat every agent as a privileged account with a named human owner.
- Enumerate what exists before writing policy. Discovery first, governance second.
- Make owner and expiry mandatory at creation. Retrofitting is disproportionately expensive.
- Extend the leaver process to cover agents automatically
- Governance is cheapest at ten agents and painful at three hundred. The window is now.
