Microsoft wants an inventory of your agents. Build the registry before your CISO asks for one
The most useful thing at Microsoft Build this week was not a model. It was a registry that finds the agents already running on your staff's laptops, gives each one an identity, and puts policy checks inside the loop. You do not need to buy it to copy the idea, and you should copy it this month.
Microsoft Build ran on 2 and 3 June in San Francisco, and the headline was agents rather than models: Microsoft Scout, an always-on work agent built on OpenClaw; Windows 365 for Agents, which gives an agent its own locked-down cloud PC; a redesigned Copilot; and Frontier Tuning, for training agents on a company's own workflows.
The announcement I would send to a CISO is quieter. Agent 365, which went generally available on 1 May, now has an Agent Registry that discovers unmanaged agents across a company's estate using signals from Defender, Entra and Intune. It recognises more than twenty kinds of local agent, including coding agents, AI desktop apps and both local and remote MCP servers. Every agent it manages runs under its own Entra identity rather than a shared service account. Purview can now apply data-loss prevention to an agent's prompts at runtime, and Intune can block the common ways an unmanaged OpenClaw agent gets started.
Two open-source projects came alongside it. The Agent Control Specification is a portable manifest that says where in an agent's loop a policy gets checked, with eight defined interception points, independent of which framework or policy engine you use. ASSERT turns a written spec for an agent into executable evaluations.
Strip away the product names and Microsoft has described the four controls every company running agents needs: an inventory, an identity per agent, policy checks inside the loop, and tests derived from what the agent is supposed to do. You can buy all four from Microsoft if you live in their estate. You can also build the first one this week with a spreadsheet, and you should.
Why the inventory comes first
You cannot govern what you cannot list. That is the whole argument, and it is why the registry matters more than any model update this year.
Verizon's 2026 Data Breach Investigations Report found unauthorised AI activity in data-loss-prevention datasets had grown fourfold year on year. That figure is mostly people pasting documents into chatbots. The next version of the problem is worse, because the tools people are installing now do not only read. A coding agent on a developer's laptop with a GitHub token can push. An MCP server someone configured to "try out" against the CRM can update records. A scheduled script wrapping a model API and running on a forgotten VM can spend money every hour until somebody notices.
Shadow IT was software the company did not know about. Shadow agents are software the company does not know about that can click buttons. The difference in consequence is the difference between a leak and an action.
The first control, before identity, before policy, before evals, is a list.
What a registry needs to record
Five fields, and a status. Anything more elaborate will not get filled in.
Name and owner. A human who answers for it. Agents without an owner get switched off at the next review.
Identity. Which credentials it uses. If the answer is "the developer's own token" or "the shared integration account", that is a finding, and the fix is a credential that belongs to the agent and can be revoked without touching a person's access.
Permissions, in three words. What it can read, what it can write, and what it can spend. Most agents should have a blank in at least one column.
Where it runs and what it is built on. A laptop, a server, a vendor's cloud. Claude Agent SDK, OpenClaw, Copilot Studio, a LangGraph script, a vendor product. This is the field that tells you which agents are affected when a vendor changes its terms or a framework ships a security fix.
Trigger. Whether a person starts it or whether it runs on a schedule or an event. Unattended agents get a stricter review.
Each entry also carries a status (proposed, approved, running, retired) and a review date.
Building it without buying anything
A registry is a discovery exercise before it is a document. Three sources will find most of what is running.
Your identity provider knows about OAuth grants and service accounts. Pull the list of applications your staff have authorised against Google Workspace or Microsoft 365 in the last year, and the list of service accounts created in the same period. Every AI tool that touches mail, calendar or files shows up here.
Your API vendors know about keys. Every Anthropic, OpenAI and Google AI key issued under the company's account, who created it, and what it spent last month. Keys with spend and no owner are agents.
Your people know about the rest. A one-question form, sent to every team: "list anything you have set up that uses AI to do a task without you watching it". Frame it as an amnesty. The purpose is to find the agents, not to punish the people who built them, because the people who built them are usually your most useful early adopters.
An afternoon of that produces a first registry. It will be embarrassing. That is the point.
Policy inside the loop, in plain terms
The Agent Control Specification's idea, that policy should be checked at defined points inside an agent's run rather than only at the door, translates to any stack. For every agent in the registry, decide what happens at four moments.
Before a tool is called, check that the tool is on the agent's allowed list. Before a write, check that the record, the amount or the recipient sits inside the boundary the owner signed off. Before any spend, compare the running total for the task against its cap. And at output, scan for anything that must not leave, such as personal data or credentials.
Those checks can be a policy engine, or they can be forty lines of code in the agent's harness. What matters is that they are deterministic and that they fail closed. A model asked to police itself will do so most of the time, which is a useless guarantee.
Tests from the spec
ASSERT's premise is that if you wrote down what the agent is meant to do, you can generate tests from that document. We have made the same argument about evaluation harnesses for two years. The registry entry is the seed: the permissions column becomes a set of tests that try to exceed each permission, and the trigger column becomes a test that the agent refuses to run outside its schedule. An agent that passes those tests before every change is an agent you can let run.
When to buy the Microsoft version
If your estate is Microsoft 365, Entra and Intune, Agent 365 is the sensible purchase, and from 1 July the agent-security features for Copilot Studio and Foundry agents require an Agent 365 licence anyway. The registry, the per-agent identity and the runtime DLP arrive configured for the tools your staff already use.
If your stack is mixed, or mostly not Microsoft, the ideas port and the products mostly do not. Build the registry in whatever your team already keeps lists in, put agent identities in your existing identity provider, and put the four policy checks in the agent code. This is what our governance engagement does in its first two weeks, and the registry is always the deliverable that surprises the client most.
Frequently asked
What is the Agent 365 Agent Registry? A feature of Microsoft Agent 365, announced at Build on 2 June 2026, that discovers agents running across a company's devices and cloud using signals from Microsoft Defender, Entra and Intune. It recognises more than twenty types of local agent, including coding agents, AI desktop applications and MCP servers, and brings them under management with their own Entra identity.
What is the Agent Control Specification? An open specification and reference implementation from Microsoft, released at Build 2026 as part of the Agent Governance Toolkit. It defines a portable manifest that says where, when and how policies are evaluated during an agent's run, across eight interception points, independent of the agent framework or policy engine.
How do you build an AI agent inventory without Agent 365? Pull OAuth grants and service accounts from your identity provider, list every AI API key under the company account with its owner and last month's spend, and ask each team to declare anything they run that uses AI unattended. Record name, owner, identity, permissions (read, write, spend), platform and trigger for each, with a status and a review date.
Related reading
- The AI governance checklist for enterprise teams
- Gemini Spark works while your laptop is closed
- Building evaluation harnesses for production AI systems
Microsoft built a product to find the agents you do not know you have. Whether or not you buy it, the finding is the part you cannot skip.