Capability
AI agent registry
An agent registry is the authoritative list of every autonomous system your organisation runs, what each one is permitted to do, and who answers for it. The hard part is not creating one. It is that a registry describes a population that changes faster than the people maintaining it, and a registry nobody trusts is worse than none — it produces confident answers to questions it can no longer answer.
What a registry entry has to carry
A list of names is not a registry. The test is whether someone who has never met the agent can answer three questions from the record alone: what it is allowed to do, what happens if it does something wrong, and who to call.
| Field | Why it earns its place |
|---|---|
| Named human owner | Not a team, not a mailbox. An agent with a team as its owner has no owner — it is the field that decays first and the one everything else depends on |
| Identity it authenticates as | The service principal, workload identity or key. Without this the registry cannot be reconciled against what your logs actually show |
| Tools and systems it can reach | Not a description — the actual grants. This is the field that answers "what is the worst it could do" |
| Whether it acts or only reads | The single most load-bearing distinction. A retrieval agent that goes wrong is an embarrassment; an acting agent that goes wrong is an incident |
| Trigger | Human-invoked, scheduled or event-driven. This sets how many wrong actions happen before anyone looks |
| Last verified | A date, not a status. "Verified 2026-04-11" is honest; "Active" is a claim nobody re-checks |
Two fields people add that rarely survive: business justification, which becomes boilerplate within a quarter, and risk rating, which is better derived from the other fields than stored as an opinion.
Why registries decay, and the only fix that holds
Every manually-maintained registry is accurate on the day it is built and degrades from then on. The degradation is not carelessness. It is that creating an agent takes minutes and updating a registry takes a deliberate act by someone who gains nothing from doing it.
The three decay paths
New agents that never get entered. Someone stands one up to solve a problem this week. It works. Nobody files it.
Permission drift. The entry is accurate about what the agent was granted in March and silent about the three scopes added since.
Orphaned owners. The named owner changes role. The agent keeps running. The record keeps naming them.
The fix is reconciliation, not discipline
A registry maintained by hand is a snapshot; a registry reconciled against discovery is a record. The difference is whether something independently observes what is actually authenticating and flags the delta.
That reframes the work. You are not asking people to be more diligent. You are asking two lists to be compared on a schedule, and treating the gap between them as the finding — agents running that nobody registered, and registry entries for agents that no longer exist.
Registry, inventory and CMDB
Three words get used interchangeably and they are not the same thing.
| Term | Answers | Kept current by |
|---|---|---|
| Inventory | What exists right now | Discovery — observation, continuous |
| Registry | What is sanctioned, and on what terms | People, reconciled against discovery |
| CMDB | How infrastructure relates to services | Existing ITSM process |
Most organisations try to make the CMDB do all three and end up with a record that is structurally correct and factually behind. An agent registry is worth keeping separate for one reason: its entries change on a different clock.
Where Agent Trust Cloud fits
A registry is only as good as what feeds it, which is why the product treats discovery and the record as two halves of one thing rather than as a feature and a database.
| Need | What the platform does |
|---|---|
| Find agents nobody registered | Agent Trust Discover surfaces agents and workloads that are authenticating, so the registry can be reconciled against observed behaviour rather than trusted |
| Tie an entry to a real identity | Machine Identity gives each agent an identity the record can be keyed on, rather than a name someone typed |
| Keep the grants field honest | Access Governance holds what each agent is permitted to reach, so permissions are read from policy rather than re-described in a spreadsheet |
| Decide who owns an agent | Nothing here. Ownership is an organisational decision and no tool can infer it. The platform can tell you an entry has no owner; it cannot tell you who it should be |
| Stop teams creating agents | Also not a software problem. Discovery shortens how long an unregistered agent stays invisible. It does not prevent one existing |
Common questions about AI agent registry
Is an AI agent registry the same as an AI agent inventory?
No, and the difference is who maintains them. An inventory is produced by observation — it answers what is running right now and is kept current by discovery. A registry is maintained by people and answers what is sanctioned, by whom, on what terms. You need both, and the gap between them is the finding: agents running that nobody registered, and registered agents that no longer exist.
How often should an agent registry be reconciled?
More often than quarterly, which is where most governance calendars put it. Agents are created in minutes and permissions drift continuously, so a quarterly reconciliation means a finding can be ninety days old before anyone sees it. Continuous reconciliation against discovery is the goal; monthly is a defensible floor if the comparison is manual.
Can a CMDB serve as an agent registry?
It can hold the records, but it usually will not keep them current. A CMDB is maintained on a change-management clock designed for infrastructure that changes deliberately. Agents change faster and often without a change ticket. If your CMDB is already reconciled automatically against what is actually running, extending it is reasonable; if it is maintained by hand, a separate registry will decay more slowly.
What is the minimum viable registry?
Four fields: the agent's identity, a named human owner, whether it acts or only reads, and the date the entry was last verified. That is enough to answer who to call and how worried to be. Everything else is useful but can be added once the record exists and is trusted.
Who should own the registry itself?
Whoever owns the consequence of an agent acting wrongly — usually security or risk, rather than the platform team that runs the infrastructure. The distinction matters because the registry's value is in the questions it answers during an incident, and the person answering those questions should be the one maintaining it.