NEWSLETTER
Microsoft Is About to Make You Re-Register Every Agent. That Is Not the Same as Re-Authorizing Them.
June 2, 2026
NEWSLETTER
June 2, 2026
Microsoft's March 2026 Entra release notes state that the Agent registry and Agent collections blades in the Entra admin center retire on May 1, 2026, that Agent 365 becomes the unified registry and control plane while Entra Agent ID continues to provide the identity foundation, and that the existing registry Graph API will be deprecated and replaced by a new Agent 365-powered API, with agents registered via the current API needing to be re-registered. Microsoft has not published a deprecation date or re-registration deadline, stating only that details will follow. The governance observation is that re-registration touches the registry plane and does not, by anything Microsoft has published, force an organization to reopen what each agent is authorized to do, which lives on the separate identity plane. Sponsorship is a documented accountability construct, separating technical administration from business accountability, but when a sponsor leaves the organization Microsoft transfers their agents to the sponsor's manager automatically, meaning the accountable owner of record can change without any human deciding it should. A forced, tenant-wide re-registration is therefore the kind of event that NIST AI RMF ongoing review and the May 1 2026 Five Eyes agentic AI guidance would treat as a re-authorization trigger, while Saviynt's 2026 CISO AI Risk Report indicates most enterprises, with only 16 percent governing AI tool access effectively, will treat it as a continuity task instead.
At a regional lender, the deadline will arrive as a migration task, which is exactly why no one there will read it as anything else. Picture a platform engineer seeing the line in the change log: agents registered through the old registry API have to move to the new one before the legacy endpoint goes dark. She does what a competent engineer does. She scripts it, pointing the new registration calls at the existing configuration so that scope, permissions, and sponsor carry over untouched. Two hundred and forty agents, re-registered into the Agent 365 registry over a weekend, every record preserved exactly as it stood. The migration runs clean. Monday morning the inventory is green. The audit log shows two hundred and forty successful re-registrations. Not one of them recorded a decision.
The question underneath this is simple to ask and uncomfortable to answer. When a platform forces you to touch every agent you own, is that a technical event or a governance one, and who in your organization gets to decide which?
The touch is no longer theoretical. Microsoft's Message Center transition notice (MC1297981) states that the existing agent registry Graph API begins retirement on June 15, 2026, that the replacement Agent 365–powered registration API has been available since May 1, 2026, and that agents registered only through the old API and not re-registered before retirement will stop functioning. What the notice does not pin down is the precise day the last unmigrated agent goes silent. "Begins retirement" is not the same sentence as "everything breaks on the fifteenth," and Microsoft has often handled API retirements as a phased wind-down rather than a single-morning cutoff. The Azure AD Graph retirement, for one, ran as a staged process with extension windows. That ambiguity is the part worth sitting with, because a hard wall forces a decision and a soft ramp invites a deferral. There is a carve-out that narrows the blast radius: this does not apply to agents created through Copilot Studio or Foundry. It applies to the agents your platform teams stood up directly against the registry API, which in most regulated shops is precisely the population nobody has a clean inventory of. The clock starts June 15. The re-registration will happen, quietly, because a legacy endpoint winding down is the kind of thing platform teams handle without asking.
Re-registration moves the record of which agents exist. It does not reopen the record of what they are allowed to do.
The registry plane and the identity plane are separate by design. Agent 365 becomes the unified registry and control plane, while Microsoft Entra Agent ID continues to provide the identity foundation. So an enterprise can re-register all two hundred and forty agents correctly and never once ask whether agent number thirty-one still needs the write access it was scoped for in a different fiscal year, under a risk appetite the board has since revised, sponsored by someone who left in March. Thirty-one still posts adjustments to the ledger on its own, every day, against thresholds nobody has reviewed since they were set. It is not malfunctioning. It is doing exactly what it was authorized to do, and that is the problem, because what it was authorized to do stopped matching what the organization would authorize today. The migration succeeds. The authorization question is never raised. The platform did exactly what it was built to do.

The sponsor field makes this worse. Microsoft built real accountability into sponsorship. The governance documentation splits the agent's technical owner from its accountable sponsor and says the sponsor is accountable for the agent's purpose and lifecycle decisions. That is a genuine construct, not a metadata tag. But Microsoft also built in a convenience that can quietly defeat it. Its own release notes state that when a sponsor leaves the organization, sponsorship of their agents is automatically transferred to their manager, so that there is always a human accountable. Read that again with a governance eye. A manager can inherit dozens of agents they never personally scoped or approved and may not even know exist. The field stays populated. The accountability it was supposed to represent left with the original sponsor's badge.
A populated sponsor field is necessary. It is not proof that anyone reviewed anything.
So you have a migration with a soft edge instead of a hard wall, a registry move that does not reopen scope, and an ownership record that updates itself when the owner walks out the door. Three mechanisms, each reasonable on its own, combining into a system where every agent can be re-registered, currently sponsored, and fully logged, while the last real authorization decision recedes further into a past nobody is being asked to revisit.
This is what Governance Debt looks like when it compounds instead of clearing. The re-registration is the rare moment the platform hands you every agent record at once. It is the cheapest re-authorization opportunity you will ever get, because the work of touching each agent is already being done for you under a deadline. The soft edge makes it worse, not better: a wall would force the decision now, but a ramp lets the team migrate the minimum and tell themselves the review can wait until the endpoint actually breaks. It rarely waits well. The next time anyone looks closely at agent thirty-one will be when a regulator asks who authorized what it did, and the honest answer will be a script that ran one weekend to keep the lights on.
The outside world already expects better, which is the uncomfortable backdrop. NIST's AI Risk Management Framework calls for ongoing monitoring and periodic review of the risk management process and its outcomes, at a frequency defined in advance. The May 1, 2026 Five Eyes guidance on agentic AI calls for continuous monitoring, regular audits of identity and privilege changes, and active management of privilege drift as conditions change. None of these say re-authorization in those words. All of them describe the discipline a forced re-registration invites and that most organizations will skip when the deadline looks soft. Saviynt's 2026 CISO AI Risk Report puts a number on the skip: only 16 percent of organizations say they govern AI tool access effectively, 86 percent do not enforce access policies for AI identities at all, and 71 percent already let those agents reach systems like Salesforce and SAP.
The fix is not complicated, which is the final indignity, because cheap and simple things get skipped most reliably of all. Separate the migration from the renewal in your workflow even though the deadline blurs them together. Step one is registry continuity: the script, the green inventory, done before the endpoint winds down. Step two is four questions asked of every agent as it passes through. Is it still needed. Is its current scope still justified. Is the recorded sponsor still the right accountable human. Has the regulatory context changed since the last approval. An agent that cannot pass those four questions does not get re-registered as-is. It gets narrowed, re-sponsored, or retired. That is the difference between a migration and a governance event, and the only thing that decides which one you ran is whether anyone was allowed to say no while the script was running.
Microsoft built the moment and started the clock. It did not build the discipline to use it, and it was never going to. That part has your name on it.

The full Governance Debt framework, which shows how deferred authorization decisions compound into audit exposure, is here.
In your organization, when the re-registration script runs, who has the standing to stop a single agent from passing through unexamined, and does that person know the clock has already started?