TL;DR
- Trusted agent registries, cryptographic agent identities and short-lived credentials are prescribed independently by CSA MAESTRO, the IETF agent auth draft and the NIST NCCoE concept paper. Convergence across three constituencies is a stronger signal than any single endorsement.
- A registry is not a list of names. It records identity, owner, purpose, reach, credential type, expiry and lifecycle state.
- Storage is trivial; discovery is the problem. The agents that matter are the ones nobody registered.
- Discover agents where they authenticate, not where they run.
- A registry that is not reconciled against reality on a schedule becomes a source of false assurance within one quarter.
Why registries keep being prescribed
CSA's MAESTRO threat model names agent impersonation as a distinct threat class: an adversary deceiving users or other agents by presenting as a legitimate agent. Its prescribed mitigations are trusted registries, cryptographic identities and short-lived credentials. The IETF individual draft on AI agent authentication assumes a registration model. The NIST NCCoE concept paper on software and AI agent identity frames agents as identifiable entities within enterprise identity systems rather than anonymous automation running under shared credentials.
Three efforts, three different constituencies, the same three controls. That is worth more than any one framework's endorsement, and it is the reason we treat the registry as foundational rather than as tooling preference.
What a registry must record
| Field | Why it is there |
|---|---|
| Stable identifier | Survives redeployment and version change. Without it, an agent's history restarts at every release. |
| Accountable owner | A named individual. A team name means nobody is accountable and offboarding never triggers. |
| Purpose | In one sentence a non-engineer can evaluate. If it cannot be written, the scope is not understood. |
| Reach | Which systems and data classes it can access, read versus write. This is the risk classification input. |
| Credential type and expiry | Attested workload credential or static secret, and lifetime. Static plus no expiry is the finding. |
| Delegation model | Does it act autonomously, for a specific user, or both? Determines what the logs must carry. |
| Human-in-the-loop conditions | Which actions require approval. Empty is an answer, and one worth reviewing. |
| Lifecycle state and review date | Proposed, active, suspended, retired. Without state, retirement never happens. |
| Provenance | Built in-house, vendor-supplied, or embedded in a SaaS product. Determines who can actually change its behaviour. |
Nine fields, most of which a team can complete in minutes at registration and almost none of which can be recovered accurately a year later. Capture at creation is worth more than any retrospective exercise.
The hard part is discovery
Any organisation can stand up a registry. Within a quarter it will be incomplete, because agents are created by people solving immediate problems and registration is a step they can skip.
The reliable approach is to discover agents where they authenticate rather than where they run:
- OAuth clients registered against your authorization server, particularly ones created for a proof of concept.
- Third-party app grants in SaaS admin consoles. Created by business users through consent screens and rarely in any security inventory.
- API gateway consumers that do not map to a known service.
- Model provider API keys and their billing records. Spend is an excellent agent detector; finance often knows about agents security does not.
- MCP servers reachable from your environment. See MCP security.
- Egress to model endpoints from workloads with no declared AI purpose.
Every one of these is a control point you already operate. None requires a new product.
Agents you did not deploy
Three categories consistently sit outside registries and carry disproportionate risk:
- Vendor agents inside SaaS products. Your CRM ships an assistant that reads customer records. You did not deploy it, you cannot inspect it, and it operates under a grant somebody accepted. This is the Salesloft/Drift shape.
- Developer-adopted tooling. Coding assistants and local MCP servers with repository access, adopted individually and invisible to procurement.
- Embedded automation. Workflow tools whose AI steps were enabled inside an existing integration, so no new grant appears.
None can be prevented by policy alone. Registering what you find, with reach and provenance recorded, is more achievable than preventing adoption and produces better decisions.
Keeping it true
A registry decays faster than most inventories because agents are cheap to create and invisible when idle. Three practices keep it honest:
- Reconcile against discovery on a schedule. Compare registered agents to authenticating agents and treat both directions as findings: unregistered agents, and registered agents that have not authenticated in ninety days.
- Expire registrations, not just credentials. A registration that requires renewal forces someone to confirm the agent should still exist.
- Publish the delta, not the total. "Fourteen agents registered" tells a governance forum nothing. "Six new, two retired, three unregistered found in discovery" is a decision-grade report.
Frequently asked questions
What is an AI agent registry?
An authoritative record of which agents exist in an organisation, what each is permitted to reach, who is accountable for it, and what lifecycle state it is in. It is the agent equivalent of a non-human identity inventory, with additional fields for delegation model and human-in-the-loop conditions. Trusted registries are prescribed independently by CSA MAESTRO, the IETF agent authentication draft and the NIST NCCoE concept paper.
What should an agent registry record?
Nine fields carry most of the value: a stable identifier surviving redeployment, a named individual owner, a one-sentence purpose, the systems and data classes it can reach with read versus write, credential type and expiry, delegation model, human-in-the-loop conditions, lifecycle state with a review date, and provenance indicating whether it was built in-house, supplied by a vendor, or embedded in a SaaS product.
How do you discover AI agents nobody registered?
Look where they authenticate rather than where they run: OAuth clients registered against your authorization server, third-party app grants in SaaS admin consoles, API gateway consumers that map to no known service, model provider API keys and their billing records, reachable MCP servers, and network egress to model endpoints from workloads with no declared AI purpose. Every one of these is a control point most organisations already operate.
What are shadow agents?
Agents operating in your environment that are not in any inventory. Three categories dominate: vendor agents embedded in SaaS products you did not deploy and cannot inspect, developer-adopted tooling such as coding assistants and local MCP servers with repository access, and AI steps enabled inside existing workflow integrations so that no new grant appears. Policy alone does not prevent any of them, which is why discovery matters more than prohibition.
How often should an agent registry be reconciled?
At least quarterly, and monthly where agents have production write access. Reconcile in both directions: agents authenticating that are not registered, and registered agents that have not authenticated in ninety days. Report the delta rather than the total, because a count of registered agents tells a governance forum nothing about whether the registry is true.
Can you reconstruct who authorised an agent action?
It is the question auditors have started asking and the one most deployments cannot answer. HumanAudit runs agent identity reviews that test delegation-chain reconstruction against your real logs.