Zylos Research’s 2026 AI agent governance analysis found that 82 percent of organizations have discovered at least one AI agent or workflow their security team did not previously know existed, and only 13 percent believe their governance is adequate.
That gap is not a monitoring problem. It is an inventory problem. Most organizations that rolled out AI agents through 2025 tracked them the way they tracked models, one row per system, one owner listed as “the AI team.” An agent is not a model. It calls tools, holds credentials, and takes actions without anyone clicking submit, so its registry entry needs four things a model inventory never required: a named owner, a permission scope, a tool catalog, and a log a regulator can actually read.
This piece breaks down what belongs in each of those four fields and how they map to ISO/IEC 42001, the EU AI Act, and NIST AI RMF.
What an AI agent registry actually tracks
An AI agent registry is a live, authoritative record of every autonomous agent running in production, not a snapshot taken during a security review.
TrueFoundry’s guide to enterprise agent registries describes the concept as a centralized catalog that lets agents discover each other and lets governance teams see what exists, similar to a phone book that also enforces who is allowed to call whom.
A model inventory answers a static question: which models exist, and what were they trained on? An agent registry answers a dynamic one: which identities are currently authorized to act, on what systems, and who is accountable if one of them acts incorrectly.
Promethium’s 2026 enterprise data governance playbook puts the underlying principle plainly: every AI agent has to be treated as a distinct principal with its own credentials, permissions, and documented lifecycle, not as an invisible extension of whichever developer or end user set it up.
Four fields separate a working agent registry from a spreadsheet that looks like one. Owner: a named individual accountable for the agent’s behavior. Permissions: the specific systems and data the agent can touch, scoped to what its task actually requires.
Tools: every API, database, and Model Context Protocol connection the agent can invoke. Logs: an automatic, tamper-evident record of what the agent did, when, and under whose authority. Miss any one of the four and the registry stops being useful the moment an incident happens, because the question that matters after an incident is never “which model was this,” it is “who authorized this action and can we prove it.”
Assigning an accountable owner to every agent
Skip the team alias. “Platform Engineering” cannot answer a compliance question at 6pm on a Friday, and it cannot sign an incident report. Every registry entry needs one named person.
At larger organizations, ownership works on two levels. A named business or engineering owner handles day-to-day accountability for a specific agent’s scope and behavior. Above that, a Chief AI Officer or an Agentic AI Committee approves new agent deployments and any change to an existing agent’s authority.
Zylos Research’s synthesis of 2026 governance practices describes the CAIO role as increasingly centered on maintaining the agent registry, setting delegation authority policy, and chairing the committee that signs off on new agent deployments.
That two-level structure matters because agent ownership is not a one-time assignment. An agent’s permission scope changes when someone connects it to a new tool, and each change needs the same approval discipline as the original deployment. A registry entry with an owner field but no record of who approved the last scope change is only half accountable.
What most people get wrong: teams often list the agent’s creator as the owner by default, even after that person has moved to a different project. Ownership should transfer explicitly, with a logged handoff, the same way a service account transfers when an engineer leaves a team.
Scoping permissions with least privilege
An agent that inherits its permissions from the human who built it will eventually have access to something it never needed. That is not a hypothetical risk, it is the default failure mode of agent deployment.
Promethium’s data governance playbook recommends separate service accounts per agent specialization: a support agent and a financial reporting agent should never share API keys or database credentials, even inside the same organization, because a compromised credential in one context should not open a path into another.
Most mid-market teams will not need that level of infrastructure on day one, but the underlying pattern scales down: define what an agent’s task requires before you provision access, not after, and record read-versus-write access, transaction or spending limits, and delegation authority as distinct fields rather than a single free-text “permissions” column.
Cataloging every tool and API connection
The “tools” field is where most registries fall apart, because it requires visibility into connections that individual employees can create without a deployment ticket.
An agent’s tool catalog needs, at minimum, the tool or API name, its scope of access, any rate limit or spending cap, and a kill switch that someone can flip without redeploying the agent. Model Context Protocol servers are the fastest-growing blind spot here: an employee can point a coding assistant at an internal MCP server in minutes, and unless that connection is registered, it is invisible to governance.
Microsoft’s Build 2026 announcements are a useful signal of how seriously platform vendors now take this problem. The company’s Agent 365 Registry, built on its existing Defender, Entra, and Intune stack, is designed to surface unmanaged local agents an organization did not know were running, and Microsoft says it recognizes more than 20 kinds of local agents including coding assistants and MCP servers.
You do not need a specific vendor’s stack to apply the same discipline. What you need is a rule: no agent goes into production with a tool connection that is not already a row in the registry, and no new tool connection gets added to a live agent without updating that row the same day.
The registry also needs to capture the controls around the tools and APIs an agent can access, particularly where human approval is required for sensitive actions.
Building the audit log layer regulators will actually accept
Article 12 of the EU AI Act requires high-risk AI systems to allow for automatic recording of events over the system’s lifetime, and it is explicit that manual documentation does not satisfy this. The logging capability has to be built into the system itself.
For an agent specifically, that means the log needs to capture more than a model’s inference log would: which tool was called and with what parameters, what data was read or written, whether a human reviewed or overrode the action, and the correlation ID linking a multi-step agent workflow back to a single originating request. “Who, what, when, and under whose authority” is the test every log entry should pass.
Mapping the registry to ISO 42001, the EU AI Act and NIST AI RMF
Most published agent governance checklists treat these three frameworks as three separate to-do lists. They are not. A single registry field, built correctly once, typically satisfies a clause in all three at the same time, which is the entire point of building the registry around the four fields above rather than around whichever framework happens to be top of mind that quarter.
The table below maps each registry field to its closest anchor point in each framework. ISO/IEC 42001 clause and Annex A control numbers are marked for editorial verification against the licensed standard text before publication; the EU AI Act article numbers and NIST AI RMF subcategory codes are drawn directly from the published regulation and framework.
| Registry field | ISO/IEC 42001 | EU AI Act | NIST AI RMF 1.0 |
|---|---|---|---|
| Owner & accountability | Clause 5.3, Annex A.3 | Article 26 (deployer obligations) | GOVERN 1.1, GOVERN 4.1 |
| Permission scope | Annex A.4 Resources for AI systems | Article 9 risk management system | MAP 4.1, MANAGE 1 |
| Tool & API catalog | Annex A.4, Annex A.9 third-party | Article 25 (third-party components) | MAP 4.1, GOVERN 6.1 |
| Audit logs | Annex A.5 AI system life cycle | Article 12 record-keeping | MEASURE 2.11, MANAGE 4.1 |
| Review cadence | Clause 9.1 monitoring & measurement | Article 72 post-market monitoring | MANAGE 4.1 |
| Decommissioning | Annex A.5.5 | Article 18 (10-year documentation retention) | MANAGE 4.2 [VERIFY] |
Two mismatches are worth calling out directly, because they are where most cross-framework guides go generic instead of specific. First, NIST AI RMF has no fixed retention period, ISO 42001 leaves retention to organizational risk appetite documented in the Statement of Applicability, and only the EU AI Act sets a hard floor at six months under Article 26(6). If your registry’s retention policy is built to the NIST or ISO documentation alone, it will not clear the EU bar by default.
Second, decommissioning is the field every framework treats as an afterthought and every audit treats as a first question. Article 18 of the EU AI Act requires deployers to keep technical documentation accessible for ten years after a high-risk system is withdrawn from service, which is a materially longer retention window than the operating logs the system generated while active.
Govern365.ai‘s AI model registry applies this same four-field structure automatically: every system entered is mapped to its applicable ISO 42001 clauses and EU AI Act risk category on entry, rather than requiring a compliance team to rebuild the mapping by hand for every new agent.
Finding the agents you do not know about yet
The 82 percent figure from the introduction is not an edge case. It describes the median enterprise. Shadow agents accumulate for an ordinary reason: registering an agent takes a governance ticket, and connecting a coding assistant to an internal API takes ten minutes and no ticket at all.
A useful discovery sweep looks in four places: cloud and SaaS admin consoles for agent-enabled features that were switched on by default, browser extension inventories across managed devices, API gateway logs for non-human traffic patterns, and MCP server enumeration across development environments. None of these require a dedicated platform to start; they require someone assigned to run the sweep and a registry ready to receive what it finds.
Pro tip: run the first sweep as an amnesty, not an audit. Teams that expect discovery to trigger discipline will hide agents rather than disclose them. A 30-day window where any discovered agent gets registered without penalty, followed by enforcement afterward, surfaces far more of the shadow inventory than a punitive rollout does.
Once discovered, an agent goes through the same four-field intake as any new deployment: assign an owner, scope its permissions down from whatever it currently has to what it actually needs, catalog its tools, and turn on logging before it is allowed to keep running unsupervised.
Operationalizing the registry: review, retirement and audit readiness
A registry that is accurate on the day it launches and stale six months later is worse than no registry, because it gives auditors and executives false confidence.
Set a quarterly review cadence for every agent’s permission scope and tool connections, with an immediate out-of-cycle review triggered whenever an agent’s access, data scope, or delegation authority changes. Annual reviews cannot keep pace with how often a live agent gets reconfigured between planned audits.
Decommissioning deserves its own documented procedure, not an assumption that deleting the agent’s code deletes its access. Credentials need explicit revocation, tool connections need to be closed on the provider side, and the registry entry needs to move to a retired state with a timestamp and reason, rather than simply disappearing from the active list.
Arthur.ai’s 2026 comparison of AI governance platforms notes that Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027 due to escalating costs and inadequate risk controls, a figure that tracks closely with how many organizations built agents first and governance infrastructure second.
Govern365.ai’s audit evidence vault keeps registry snapshots, approval records, and log exports in one exportable package, so a review that would otherwise take a compliance analyst several days of manual collection is ready before the auditor asks for it.
AI Agent Registry Checklist
- Assign one named owner per agent, not a team distribution list. [ISO 42001 Clause 5.3 [VERIFY]]
- Record the agent’s permission scope: systems, data classes, and action types, following least privilege. [NIST AI RMF GOVERN 1.1]
- Issue separate credentials per agent rather than sharing a service account across multiple agents. [NIST AI RMF MAP 4.1]
- Catalog every tool, API, and MCP connection the agent can invoke, with a scope and rate limit per tool. [ISO 42001 Annex A.4]
- Enable automatic, tamper-evident event logging covering every decision, tool call, and override. [EU AI Act Article 12]
- Retain logs for a minimum of six months, longer where sector rules require it. [EU AI Act Article 26(6)]
- Run a quarterly shadow-agent discovery sweep across cloud, browser, and MCP infrastructure. [NIST AI RMF MAP 1.1]
- Document a decommissioning procedure that revokes credentials and closes the registry entry. [ISO 42001 Annex A.5]
- Route new agent registrations and scope changes through a named approval authority. [NIST AI RMF GOVERN 4.1]
- Log every human override or escalation with the reviewer’s identity and stated reason. [EU AI Act Article 14]
Frequently Asked Questions
What is an AI agent registry?
An AI agent registry is a centralized, authoritative record of every autonomous AI agent operating inside an organization, along with its owner, permissions, connected tools, and audit logs.
Unlike a general software asset list, it treats each agent as a distinct non-human identity with its own credentials and action history, not as an extension of the developer or team that built it.
How is an AI agent registry different from an AI model inventory?
A model inventory tracks static assets: model versions, training data, and intended use.
An agent registry tracks a running identity that calls tools, holds credentials, and takes actions on its own, so it needs live permission scopes and event logs that a model card never requires. Most organizations need both, linked by system ID.
Who should own an AI agent in the registry?
Every agent needs one named individual, not a team alias, accountable for its scope, review schedule, and incident response.
Larger deployments typically route new registrations and scope changes through an Agentic AI Committee or a Chief AI Officer, but day-to-day accountability still sits with a named business or engineering owner.
What permissions data belongs in an agent registry entry?
Each entry should record the specific systems, data sources, and action types the agent can access, scoped to least privilege rather than inherited from a human user’s account.
That includes read versus write access, spending or transaction limits, delegation authority, and whether the agent can invoke other agents or sub-agents.
Does the EU AI Act require an AI agent registry?
The AI Act does not name AI agents specifically, but Article 12 requires automatic event logging for any high-risk AI system, and a registry is the practical way to prove which systems that requirement applies to.
High-risk obligations under Annex III now apply from December 2, 2027 following the Digital Omnibus, but Article 50 transparency duties remain effective from August 2, 2026.
How often should an AI agent registry be reviewed?
Most governance programs review agent permissions and scope quarterly, with an immediate review triggered any time an agent’s tool access, data scope, or delegation authority changes.
Annual reviews are too slow for agents that are reconfigured or given new tool connections between planned audits.
What is a shadow AI agent?
A shadow AI agent is an autonomous system operating in production that the security or governance team did not approve, register, or know existed.
These commonly appear as coding assistants, browser extensions, or Model Context Protocol connections that individual employees set up without going through a formal deployment process.
Does NIST AI RMF require an agent registry?
NIST AI RMF 1.0 does not mandate a specific registry format, but its GOVERN and MAP functions call for documented AI actors, third-party components, and internal risk controls for every system, which an agent registry directly supports.
NIST’s Center for AI Standards and Innovation opened an AI Agent Standards Initiative in February 2026 to address gaps the original 2023 framework left for autonomous systems.
Conclusion
An AI agent registry earns its keep the moment someone asks a question no spreadsheet built for models can answer: who approved this agent’s access to this system, and can you prove the log wasn’t altered after the fact. Four fields, owner, permissions, tools, and logs, are what make that question answerable on demand rather than reconstructed under deadline pressure.
Start with the agents already in production. Assign a named owner to each one this week, then scope its permissions down to what its task actually requires.
Govern365.ai, by the Global AI Certification Council, builds this four-field structure and its ISO 42001, EU AI Act, and NIST AI RMF mapping directly into the platform. Start your 14-day free trial to register your first agent today.
