Microsoft has just announced Agent 365, a control plane that gives organisations a registry of their AI agents, restricts their access, shows their connections to people and data, and monitors their behaviour. Microsoft Entra Agent ID is supplying the identity layer beneath it.

The announcement matters because agents have often inherited a person's account or relied on a service credential that says little about the job being performed. Microsoft proposed a distinct non-human identity to which it could attach access policy, monitoring, and revocation.

It was also a preview, not evidence that every organisation could suddenly discover and control every agent. Microsoft said Agent 365 would be available through its Frontier programme, while Microsoft expanded Entra Agent ID’s public preview. The direction was clear before the operating evidence was.

That distinction is useful because an identity can show which agent acted, but it can't show whether the action still serves an approved purpose.

The Need for an Agent Registry Has Arrived

Microsoft described five parts of Agent 365: a registry, access control, visualisation, interoperability and security. It said the service was designed to cover agents built with Microsoft tools, open-source frameworks and third-party platforms.

This is a practical response to a familiar problem. Non-human access tends to outlive the task it was created for. Owners change, projects end, and permissions remain because nobody can predict what removal will break. Agents add another complication: they may select tools, delegate work and act across several systems during one run.

A separate identity improves attribution and gives defenders a clean object to restrict or revoke. Yet the registry remains an inventory of technical actors. It does not determine whether an agent's original job is still needed, whether a new connection has changed its risk, or which person accepts the consequence of its decision.

Those questions sit with the organisation deploying the agent. For each identity, it should be possible to name the accountable owner, current purpose, permitted systems and a point at which authority expires or must be renewed.

The product announcement made identity easier to discuss. It did not transfer accountability to the identity platform.

Australia's AI Safety Capability

On 25 November, the Australian Government announced that it would establish an AI Safety Institute inside the Department of Industry, Science and Resources.

The stated remit was to evaluate emerging AI capabilities, share information, support regulators and coordinate timely action on risks. The government described the institute as a hub of AI safety expertise and said it would work with domestic and international partners.

That was an institutional commitment, not a new approval gate for every system deployed in Australia. Nor did the announcement establish that the institute had already tested particular models or could certify an organisation's use of them.

The signal was narrower and more useful: public policy was moving towards technical measurement and evaluation. Broad principles such as safety, transparency and accountability were being joined by a capability intended to examine what systems could do and how risks were changing.

Leaders face the same translation inside their organisations. A policy can state that an agent must be supervised. Assurance needs evidence: what was tested, which actions were observed, what changed after approval and who can stop the system if its behaviour crosses the agreed boundary.

OpenAI's Analytics Supplier Exposed the Edge of the System

On 26 November, OpenAI disclosed a security incident at Mixpanel, which it used for web analytics on the front end of its API product.

OpenAI said the incident occurred in Mixpanel's systems, not its own. The exported dataset contained limited customer-identifying and analytics information associated with some users, including names, email addresses and API-account metadata. OpenAI said chats, API requests, API usage data, passwords, credentials, API keys and payment details were not exposed.

That boundary is important. Calling this a breach of OpenAI's models or API would overstate what happened. Dismissing it because the most sensitive content and credentials were not taken would miss the operational lesson.

Names, addresses and account context can make phishing and social engineering more convincing. An analytics provider can therefore sit outside the main application while still holding information that changes the risk to its users. OpenAI said it had removed Mixpanel from its services and was expanding reviews across its vendor ecosystem.

An agent registry will not solve that problem. It can help identify which agent calls which service, but organisations also need to know what information crosses that connection and which supplier controls apply after it leaves the primary platform.

Final Perspective

The part I would insist on is revocation. A distinct agent identity matters because it gives the organisation a technical object it can restrict or disable. It earns its value only when someone accountable can decide that the agent's purpose no longer justifies its access and withdraw that authority without guessing what else will break.

Agent 365 and Entra Agent ID pointed in a useful direction, but an identity platform cannot make that business decision. If nobody can say when an agent's job has ended, the registry risks becoming a precise inventory of access that remains unmanaged.