Agent registry
also called AI agent inventory · AI system inventory · agent catalogue
Most organisations discover their agent estate twice: once in a spreadsheet assembled for an audit, and once in an incident. The spreadsheet lists the agents somebody remembered. The incident involves the one they did not. That gap is structural rather than careless, and it is the reason the interesting property of a registry is not what it contains but what reads it. A list that the gateway resolves on every request cannot drift from what is running, because there is only one list; a list exported nightly into a governance tool is a photograph of a moving thing.
The fields worth arguing about are the ones a regulator or an incident will ask for. A named human owner, because accountability for something that is not a human has to land on somebody, and a team alias is not a person. A declared purpose written as a sentence, because most of the obligations that apply to a deployed AI system reduce to using it in accordance with its intended purpose, which requires a stated purpose to compare behaviour against. A lifecycle status, because suspension has to be a state change rather than a redeployment. Beyond those: risk tier, team and tags for scoping rules, permitted roles, spend and rate ceilings, and data-handling requirements such as no-training or region pinning.
The design test for every additional field is whether some part of the request path reads it. A field nothing consults is documentation, and documentation drifts. That test also settles arguments about granularity: a risk tier that nothing enforces against is a label, so rules that must bite on high-risk agents are written against a tag the enforcement path actually matches on, and the tier is carried for review rather than pretended to be a control.
A registry has two enforcement couplings that separate a working one from a decorative one. The first is that lifecycle is checked inline: a suspended agent is refused on its next call, with a typed error naming the state, rather than continuing until something redeploys. The second is referential integrity at write time — a role id that does not resolve should be refused when the record is saved, because a dangling grant silently reduces the agent to deny-by-default, and an agent failing every call reads as a deliberate policy decision rather than as the typo it is.
The limit to state beside the claim is that a registry records what somebody registered. It does not discover anything. An agent calling a provider directly, a developer with a personal subscription, a workflow tool with its own key: none of them appears, and none of them is governed by anything scoped to the registry. This is why coverage claims need a denominator from a different source entirely — an estate where forty agents route through a governed endpoint and an unknown number do not is not fully governed, and the honest form of that sentence has a number on both sides. Discovery is a separate discipline with a separate failure mode, and its cardinal rule is that a dead evidence feed must never look the same as a clean estate.
The four fields somebody has to fill in
Registering a support triage agent requires a name, an owner email, a team and a declared purpose — “draft first-response replies to customer tickets for a human to send” — before anything else is decided. Status defaults to draft, so the record can exist while the decision to run it is still being taken. Everything optional that gets added afterwards is read by some step of the request path: the roles decide which tools and models it may reach, the tags decide which policies select it, the budget decides when it is cut off, and the data policy decides which providers it may be routed to. When somebody later suspends it, the change lands on the agent’s next call rather than at the next deployment, because the gateway resolves this record rather than a copy of it.
What agent registry is routinely confused with
- Model registry
- A model registry versions trained models and their artefacts — weights, evaluation runs, lineage — and its subject is a model. An agent registry’s subject is a deployed actor with an owner, a purpose and a permission set, which may call several models and any number of tools. The two answer different audit questions and neither substitutes for the other.
- CMDB or service catalogue
- A configuration management database records services and their dependencies for change and incident management, and is reconciled periodically. An agent registry has to be resolved synchronously in the authorisation path, which rules out reconciliation lag: a suspension that takes effect at the next sync is not a suspension.
- Observability inventory
- An observability tool lists the agents it has seen traffic from, which is discovery rather than registration, and it lists them after the fact. A registry is the deliberate act of a named person declaring an agent’s purpose and owner before it runs, and it is what an unregistered agent is measured against.
Related terms
Agent identity
Agent identity is what establishes which AI agent is making a given call: a credential the agent presents, and a registered record that credential resolves to, carrying the agent’s owner, declared purpose, permissions and lifecycle status. It is a different thing from the identity of the human the agent is acting for and from the identity of the workload the agent runs inside, and treating any two of the three as interchangeable is the most common source of authorisation error in agent systems.
Agent recertification
Agent recertification is a periodic attestation by a named person that a specific AI agent’s configuration — its owner, declared purpose, permissions, limits and lifecycle status — is still appropriate, recorded against the exact configuration that was reviewed. Its value depends entirely on that binding: a review that records which roles an agent held, rather than what those roles granted, certifies nothing the moment somebody edits the role.
Deny by default
Deny by default is an authorisation model in which an action is refused unless some permission explicitly allows it, and in which an explicit deny overrides every allow. An agent holding no roles, a role with an empty permission list, and a resource no permission names all produce the same answer — refused — so the failure mode of a misconfiguration is a blocked request somebody notices rather than a standing grant nobody does.
Action-level permissions
Action-level permissions authorise a specific operation on a specific named resource — one tool on one server, or one model — rather than granting access to a system as a whole. The unit is what matters: an agent granted a system inherits every operation that system exposes, including the ones next to the operation it actually needed.
Where Token Observe does this
The definition above is the field's, not the product's. This is the part of the product that implements it, for a reader who wants to see one.
Agent registry
One record per agent, and it is the record the gateway enforces against.
An overdue review never suspends the agent itself
Shadow AI radar
Five evidence sources for AI activity that never touched the gateway, and a coverage model that refuses to call a dead feed a clean estate.
No billing, network or IAM access — you send the export
The terms next to this one
What it means for an agent to be allowed to do something, and why the answer stops being obvious the moment one agent can ask another.
Definitions are the easy part.
The glossary is written to be useful whether or not you ever buy anything. If you have got to the point of deciding how to implement one of these in your own estate, say what your agents do and you will get a straight answer about what it would actually take.
no form · no qualification step · no sales desk · the other three ways in