Agent registry

What is an agent registry?

An agent registry is a central list of every AI agent that runs in your organisation. Not just the ones your IT team built, but also the ones a supplier delivered and the ones a colleague put together in an afternoon because it made their job easier.

The idea is not new. You already keep a list of your servers, your applications and your service accounts, for exactly the same reason. What is new is how quickly the list grows. Building an agent no longer requires a development project. Somebody in finance can assemble one in Copilot Studio during a lunch break, connect it to a mailbox and a spreadsheet, and share it with the team.

The rule behind the registry fits in one sentence. You cannot govern something you do not know exists. Every other control you might want, permissions, monitoring, approval, an audit trail, assumes that you know the agent is there. That is why the registry comes first and not last.

What you record per agent

A useful registry entry has more in it than a name. The fields that turn out to matter are these.

• An owner. A person, not a team mailbox. Somebody who answers the question of whether this agent should still exist.

• A purpose. What the agent is for, written so that someone outside the department understands it. If nobody can write that sentence, that is already a finding.

• A risk level. An agent that summarises meeting notes and an agent that approves supplier invoices are not in the same category and should not get the same review.

• The tools and credentials it uses. Which systems it can reach, and under which identity. This is the field that tells you what a compromised agent could actually do.

• The data it touches. Which sources it reads, and whether personal data or commercially sensitive data is involved.

• The model and prompt version. When behaviour changes overnight, this is what lets you find out what changed.

Those last two are the ones people leave out, and they are the ones that turn an incident from a two-week investigation into a two-hour one.

Why the registry comes before everything else

There is a specific problem that a registry solves and nothing else does, and it has a name: agents nobody knows about.

An agent that was built outside your normal process still uses real credentials, still reads real data and still takes real actions. It does not show up in your application inventory, because it is not an application. It does not show up in your access reviews, because it often runs under someone's personal account. And when that person leaves the company, it either keeps running with a dead account or stops working and nobody knows why.

Microsoft groups the controls you want around agents into five things, and a registry is the first of them: an inventory covering sanctioned agents, third-party agents and the ones that appeared without asking. The other four, access control on the principle of least privilege, live visibility into behaviour, consistent governance across platforms, and detection of compromised agents, all read from that inventory. Without it, they have nothing to work on.

What this looks like in the Microsoft stack

Microsoft has built this out in more than one place, which is worth knowing so you do not start a spreadsheet you will regret.

Microsoft Entra Agent ID is the identity side. Agents get their own identity in Entra, and because that identity is a real directory object, the agent shows up where your other identities show up: in sign-in logs, in audit logs, in access reviews and in lifecycle workflows.

Microsoft Foundry keeps an inventory on the runtime side. You can register agents that run elsewhere, including in another cloud or on your own servers, and see their telemetry and apply policy centrally. The tools they use can be registered too.

The two together are what a registry looks like in practice: who the agent is, and what it does at runtime. A spreadsheet can be a decent way to start, but it is only ever a stopgap, because the one thing you need from a registry is that it is complete, and a manually maintained list stops being complete the week after you write it.

What to watch out for with an agent registry

Registering is not approving. A registry that only contains agents that went through a governance process is a list of your well behaved agents, which is not the list you need. Make registration easy and unconditional, and do the risk assessment afterwards.

A stale entry is worse than none. An agent whose owner left two months ago and whose entry still says otherwise gives you false comfort. Tie the entry to an actual process: joiners and leavers, or a periodic review.

Do not register only your own agents. The agent your supplier runs, which reaches into your data through an API, belongs in the list too. It is exactly the kind of access nobody reviews because it does not feel like an agent.

The list is only useful if someone reads it. A registry with no review moment is documentation. Put a recurring moment in the calendar where somebody actually goes through the high-risk entries and asks whether each one still needs to exist.