According to Gartner’s 2026 Hype Cycle for Agentic AI, only 17% of organisations have deployed AI agents to date yet more than 60% expect to do so within the next two years. That gap is closing fast. What most of those organisations have not yet built is the governance infrastructure to match: specifically, a structured AI agent registry that documents who owns each agent, what permissions it holds, which tools it can reach, and when it was last reviewed.
Without that registry, agentic AI adoption generates a compliance liability as fast as it generates business value. An ISO 42001 audit, an EU AI Act conformity assessment, or a NIST AI RMF Govern function review all arrive at the same question: can you account for every AI agent operating in your environment?
This guide covers what belongs in a complete AI agent registry and how to make it audit-ready from day one.
An AI Agent Registry Is Not a Spreadsheet
Most governance teams start with a spreadsheet. That is an understandable first step and an inadequate final state.
A spreadsheet built once and forgotten will not survive 2026. Research compiled by Atlan in April 2026 notes that static lists go stale in weeks vendors push AI feature updates that quietly alter data access patterns while shadow agents accumulate in the gaps between review cycles. The registries that hold up are the ones plugged into the same observability and metadata systems that already show what is running in production.
An AI agent registry is a living, governed record of every AI agent deployed or authorised within an organisation. Each entry is not just a name and a description it is a structured record containing ownership accountability, permission boundaries, tool and data access, risk classification, lifecycle status, and the timestamp of the last formal review. That structure is what distinguishes a registry from a catalogue.
The distinction matters for a second reason. An AI model registry documents the models an organisation has trained or licenced. An AI agent registry documents the autonomous systems built on top of those models systems that plan, invoke tools, interact with external services, and take actions in the world. The governance obligation is meaningfully different. A model sitting in a repository cannot cause a data breach. An agent with misconfigured permissions can.
This is why Microsoft’s Cloud Adoption Framework for AI governance explicitly recommends maintaining an agent registry as a core control, noting that untracked or shadow deployments pose both security and cost risks.
The Five Fields Every Agent Record Must Contain
Registry design decisions are not arbitrary. Each field either maps to a compliance control or closes a governance gap that auditors will probe. These five are non-negotiable.
1. Owner and accountable role
Every agent record must identify a named owner a human being, not a team name or a cost centre. The owner is the person who accepts accountability for the agent’s behaviour, approves changes to its configuration, and signs off on each periodic review. When that person leaves the organisation, the record must be updated before their last day; an agent without a live owner is an agent without a control point.
ISO 42001 Clause 5.3 requires the assignment of responsibilities and authorities for AI-related roles. The registry owner field is where that clause lands operationally. In an audit, an ISO 42001 assessor will ask to see evidence of assigned accountability for each system in scope. A populated, timestamped owner field with role title and reporting line is that evidence.
2. Permissions schema
This field documents what the agent is authorised to do, expressed as a bounded set of capabilities rather than a broad mandate. It should cover: data sources the agent can read from and write to; external services or APIs it can call; actions it can initiate (file creation, email sending, record updates); and any escalation or approval pathways it can trigger.
The principle here is least privilege agents should hold only the permissions required for their defined function. Microsoft’s guidance on AI agent governance states this directly: grant agents access only to the specific data sources required for their function. The registry is where that policy becomes verifiable.
3. Tool manifest
Agentic systems are defined by their ability to use tools search, code execution, API calls, database queries, web browsing, calendar access, and more. Each tool an agent can invoke represents a capability boundary and, by extension, a risk surface.
The tool manifest documents every tool the agent can access, the version or endpoint in use, and whether that access has been reviewed and approved. This field is what makes the registry useful during an incident. When an agent takes an unexpected action, the tool manifest is where the investigation starts.
4. Risk classification
Not all agents carry equal risk. A scheduling agent with read-only calendar access operates in a different risk tier than a procurement agent that can issue purchase orders. The registry must capture both a risk level (typically high, medium, or low) and the basis for that classification.
Under EU AI Act Article 9 and Annex III, high-risk AI systems require documented risk management processes. If your agent meets the criteria for high-risk classification under Annex III for example, an agent operating in recruitment, credit assessment, or critical infrastructure contexts the registry record must reflect that, and the associated controls must be verifiable from the record.
5. Review status and next review date
A registry entry without a review timestamp is an unverified claim. Agents change: their underlying models are updated, their tool access expands, their owners change roles, their outputs drift from baseline behaviour. The review status field captures when the last formal review occurred, who conducted it, what was checked, and when the next review is scheduled.
This is not administrative overhead. It is the audit trail that distinguishes a governance programme from a governance document.
Ownership Accountability: More Than a Name in a Field
Assigning an owner to an AI agent sounds simple. In practice, it requires resolving three questions that most organisations have not answered before they need to.
Who is eligible to be an agent owner?
An agent owner must have the authority to approve changes to the agent’s configuration, the operational visibility to detect when the agent is not performing as intended, and the knowledge to assess the risk implications of what the agent can do. That profile typically rules out executives who lack operational context and junior developers who lack authority. It points toward product leads, senior engineers, or domain SMEs with direct line accountability for the function the agent serves.
What does ownership actually require?
Ownership is not passive. An agent owner is accountable for: reviewing the agent’s behaviour against its documented permissions on a scheduled cadence; approving any changes to the agent’s tool access or permission scope; escalating incidents where the agent takes actions outside its defined boundaries; and formally signing off on the registry record at each review cycle.
Some organisations formalise this through an AI agent ownership policy a short document that defines these obligations, maps them to ISO 42001’s leadership and responsibility requirements under Clause 5, and gives owners a clear checklist for their periodic review duties.
What happens when an owner leaves?
This is where governance programmes frequently fail. An agent’s owner changes role or leaves the organisation; the registry entry is not updated; the agent continues operating without a live accountability chain. When an audit arrives or an incident occurs the trail goes cold.
The registry must treat owner field changes as a critical event, not a routine update. NIST AI RMF’s Govern function (GV.OV) calls for defined roles and responsibilities across the AI lifecycle; a lapsed owner assignment is a direct gap against that requirement. Some organisations implement an automated alert that flags agent records where the assigned owner has left the IAM system a lightweight but effective control.
Permissions Management: Scoping What Agents Can Do
The permissions a registry documents are not merely technical configurations. They are governance decisions each one representing a deliberate judgement about what risk the organisation is willing to accept in exchange for the operational capability the agent provides.
Permissions drift is one of the most common and least-tracked risks in agentic AI environments. An agent is deployed with a narrow scope. Over time, its tool access expands incrementally a new data source here, an additional API there each change small enough that no individual decision triggers a formal review. Cumulatively, the agent’s effective permission surface is significantly broader than what the registry documents, and the registry record has become false.
The Cloud Security Alliance’s April 2026 report on shadow AI agents identifies permission scope creep as a defining characteristic of agents that cause compliance incidents. Unknown agents do not respect governance diagrams. If an agent is deployed outside approved processes, the safeguards may not engage at all.
Registry design should account for this through versioned permission records. Each change to an agent’s permission scope should generate a new registry entry version, timestamped and attributed to the approver. That version history is what an auditor will review to assess whether permission changes followed the organisation’s change management process which under ISO 42001 Clause 8.1 must be controlled and documented.
A practical starting point for structuring the permissions field is a three-column schema:
| Permission category | Scope | Approved by |
| Data access (read) | Customer records – anonymised only | [Owner name, date] |
| Data access (write) | None | N/A |
| External API calls | CRM system (read only) | [Owner name, date] |
| Action triggers | Email drafting (human approval required) | [Owner name, date] |
That structure makes the scope explicit and the accountability visible which is exactly what both ISO 42001 and EU AI Act conformity assessments require.
The Tool Manifest: Documenting What Agents Can Reach
An AI agent’s capability is defined by its tools. An agent that can only read from a knowledge base is a different governance problem than one that can call external APIs, execute code, write to databases, and send messages on behalf of users. The tool manifest field in the registry makes that distinction visible and verifiable.
For each tool in the manifest, the registry should capture:
- Tool name and type (search, API call, code execution, database read/write, messaging, file system access, etc.)
- Endpoint or integration version
- Data classification of what the tool can access (public, internal, confidential, restricted)
- Whether the tool integration has been security-reviewed and by whom
- Date of last review or version confirmation
This level of specificity matters in two contexts. The first is incident response. When an agent behaves unexpectedly, the tool manifest is the first place an investigator looks to understand how the agent could have accessed the data or triggered the action in question. A vague tool manifest (“internet access”) makes that investigation significantly harder.
The second context is third-party risk. Many agentic AI tools involve external service calls to SaaS APIs, to cloud AI providers, to data enrichment services. Each external tool in the manifest represents a data flow that may trigger obligations under GDPR, state privacy laws, or sector-specific regulations. The manifest is where those flows become visible to your privacy and legal teams.
AWS’s AgentCore registry, launched in April 2026, captures this directly: every record documents who published the agent, what protocols it implements, what it exposes, and how to invoke it. Enterprise registry design should follow the same principle the tool manifest is not a developer artefact, it is a governance control.
Risk Classification: Connecting Registry Records to Compliance Frameworks
Risk classification is where the AI agent registry connects to the compliance frameworks your organisation is accountable to. Without it, the registry is an inventory. With it, it is a governance instrument.
A tiered classification system works best in practice. Most organisations use three levels high, medium, and low with defined criteria for each, rather than a purely quantitative scoring model that creates false precision.
High-risk criteria (any of these triggers high classification):
The agent makes or significantly influences decisions affecting individuals (hiring, credit, benefits, medical) – The agent operates in safety-critical functions (infrastructure, physical systems, emergency services) – The agent has write access to production systems without mandatory human approval – The agent falls within EU AI Act Annex III risk categories
Medium-risk criteria:
The agent processes personal data in a non-automated-decision context- The agent can trigger actions with material financial implications (above a defined threshold)- The agent interacts with external parties on behalf of the organisation- The agent’s outputs are directly customer-facing without human review
Low-risk criteria:
The agent operates on internal, non-personal data only- All actions require human approval before execution- The agent has no external connectivity
This classification is not static. An agent reclassified from medium to high because its functionality expanded, because a new regulatory obligation came into force, or because the organisation’s risk appetite changed must have that reclassification documented in the registry with the triggering reason.
The EU AI Act creates a hard obligation for any agent meeting Annex III criteria: those systems require documented risk management under Article 9, a technical file under Annex IV, and post-market monitoring under Article 72. The registry classification field is where that obligation is first captured. It is also how your compliance team knows which agent records to prioritise for conformity assessment preparation.
Review Cadence: Building a Periodic Review Process That Survives Audits
The periodic review cycle is the mechanism that keeps the registry accurate over time. A registry entry written at deployment and never revisited is a record of what the agent was supposed to be, not what it is.
Two types of reviews should be built into the registry governance model.
Scheduled reviews occur on a fixed calendar cycle. For high-risk agents, quarterly reviews are appropriate. For medium-risk, semi-annual. For low-risk, annual is defensible if supplemented by automated drift detection. Each scheduled review should verify: that the owner field reflects a current employee, that the permission schema matches actual deployed configuration, that the tool manifest is complete and current, that the risk classification remains appropriate, and that no significant incidents have occurred since the last review.
The review record itself not just the review date must be stored against the registry entry. An auditor conducting ISO 42001 Clause 9.1 performance evaluation will want to see evidence of what was checked, not just a timestamp.
Trigger-based reviews are initiated by events rather than calendars. Events that should trigger an immediate registry review include: a change to the agent’s underlying model or prompt configuration; a new tool integration or data source; a change in the agent’s owner; a reported incident or near-miss; a new regulatory obligation that affects the agent’s risk classification; and any third-party security finding affecting an integrated tool.
The most effective governance programmes treat these two review types as complementary: the calendar cycle ensures nothing is forgotten, and the trigger-based cycle ensures the registry does not lag behind operational reality.
One practical note: the review process should produce a reviewable artefact, not just a checkbox. A short review summary two to four sentences documenting what was reviewed, what was confirmed, and any changes made is sufficient for most agents and provides the audit evidence that distinguishes a functioning governance programme from a formal one.
Connecting the Registry to ISO 42001, EU AI Act, and NIST AI RMF
An AI agent registry does not exist in isolation. It is a core operational control within the compliance frameworks most organisations are either working toward or already subject to.
ISO 42001 connections
ISO 42001 Clause 8.1 requires that an organisation plan, implement, control, and maintain the processes needed to meet AI system requirements, with documented information as evidence. The agent registry is the primary mechanism for meeting that requirement. Clause 8.4 addresses AI system operation, requiring that the organisation control its AI systems through documented information and operational procedures. The registry record with its owner, permissions, tools, risk classification, and review history is that documented information.
Annex A controls A.6.1 and A.6.2 specifically address policies and processes for the responsible use of AI systems and for managing AI suppliers and third parties. An agent that calls external APIs has a third-party dependency; the tool manifest in the registry is where that dependency is captured and reviewed.
EU AI Act connections
For any agent that meets the definition of a high-risk AI system under Annex III, the registry record maps directly to the technical documentation requirements of Annex IV. Section 1 of Annex IV requires a general description of the AI system including its intended purpose, the natural persons responsible for it, and its interaction with other systems. Sections 2 through 4 require detailed documentation of development data, capabilities, limitations, and risk management measures. A well-designed registry record contains the foundation of all of this.
NIST AI RMF connections
The NIST AI RMF’s Govern function establishes the organisational structures, policies, and processes that make AI risk management possible. GV.OV-01 specifically calls for roles and responsibilities for AI risk management. GV.OV-03 calls for organisational accountability. The registry is where the GOVERN function becomes operational rather than aspirational.
The MAP function which calls for categorisation of AI risks relative to context relies on having accurate, current information about each deployed system. A registry that captures risk classification, owner, tool access, and use context gives the MAP function the inputs it needs.
Govern365.ai’s AI model registry maps each deployed system to its applicable ISO 42001 clauses, EU AI Act risk categories, and NIST AI RMF functions reducing the manual work of maintaining these cross-framework mappings as regulatory obligations evolve.
Shadow AI and the Registry as a Detection Mechanism
Shadow AI agents and AI tools deployed outside approved governance processes is not a niche problem. Gartner research cited by Atlan found that 69% of cybersecurity leaders either suspect or have direct evidence that employees are using prohibited public AI tools. Almost none of those tools have ever been through a formal governance review.
A static registry does not solve this. A registry that is connected to infrastructure monitoring does.
Effective shadow AI detection requires that the registry serve two functions simultaneously: as a record of what is authorised and as a baseline against which observed deployments are compared. Any agent-like activity detected in network traffic, API logs, or endpoint telemetry that does not correspond to a registry entry is a candidate shadow agent.
The Cloud Security Alliance’s April 2026 analysis found that shadow agents most commonly appear in exactly the environments optimised for speed and decentralised problem-solving developer sandboxes, departmental automation tools, and third-party integrations. These are also the environments where governance teams have the least visibility.
Practical detection approaches include: integrating registry status checks into your CI/CD pipeline (any agent deployment without a registry entry fails the pipeline); scanning identity provider logs for non-human authentication patterns that do not correspond to registered agents; and reviewing API gateway logs for AI tool calls from unregistered services.
The registry cannot catch what it cannot see. But a registry designed as a governance instrument connected to infrastructure, actively compared against observed deployments, and reviewed on a cadence closes the gap between authorised AI and actual AI.
Frequently Asked Questions
What is an AI agent registry?
An AI agent registry is a centralised, governed record of every AI agent an organisation has deployed or authorised. Each entry documents the agent’s owner, permissions, tool access, risk classification, lifecycle status, and review history. It provides the audit trail and accountability structure that compliance frameworks including ISO 42001, the EU AI Act, and NIST AI RMF require for deployed AI systems.
How is an AI agent registry different from an AI model registry?
An AI model registry catalogues the machine learning models an organisation has trained or licenced — it documents model versions, training data provenance, and performance metrics. An AI agent registry documents the autonomous systems built on those models: who owns each agent, what it is permitted to do, which tools it can access, and what risk it carries. The governance obligations are different because agents act, while models are used.
Which ISO 42001 clauses does an AI agent registry support?
An AI agent registry supports ISO 42001 Clause 8.1 (operational planning and control, requiring documented information for AI system management), Clause 8.4 (AI system operation), Clause 5.3 (assigning responsibility and authority for AI roles), and Annex A controls A.6.1 and A.6.2 (responsible use policies and third-party AI supplier management). The registry is a primary evidence source in an ISO 42001 conformity assessment.
How often should AI agents be reviewed in the registry?
Review frequency should match risk level: quarterly for high-risk agents, semi-annually for medium-risk, and annually for low-risk systems (supplemented by automated drift detection). Beyond the calendar schedule, trigger-based reviews should occur whenever the agent’s configuration changes, its owner changes, an incident is reported, or a new regulatory obligation affects its risk classification. Each review should produce a documented record, not just an updated timestamp.
Does the EU AI Act require an AI agent registry?
The EU AI Act does not use the term ‘AI agent registry,’ but its documentation requirements effectively mandate one for high-risk AI systems. Annex IV requires a technical file containing the system’s intended purpose, responsible persons, risk management measures, and capability descriptions. Article 9 requires an ongoing risk management process. For any agent meeting Annex III risk criteria, a structured registry record is the most practical way to produce and maintain that documentation.
What should trigger an out-of-cycle review of an agent registry record?
Six events should trigger an immediate review outside the scheduled cycle: a change to the agent’s underlying model, prompt configuration, or system instructions; addition of a new tool, data source, or external integration; a change of the agent’s assigned owner; any reported incident or anomalous behaviour; a new regulatory obligation or guidance that affects the agent’s risk classification; and any third-party security finding affecting an integrated service the agent depends on.
How do you detect shadow AI agents without a registry?
You cannot detect what you have not defined. An effective shadow AI detection programme starts with a baseline registry of authorised agents, then compares observed behaviour against that baseline. Practical detection methods include CI/CD pipeline gates that fail deployments without a registry entry, identity provider log reviews for non-human authentication patterns, and API gateway scanning for AI tool calls from unregistered services. The registry is the reference point; detection tools measure deviation from it.
Conclusion
Every AI governance framework ISO 42001, the EU AI Act, NIST AI RMF – converges on the same foundational requirement: you cannot govern what you cannot see. An AI agent registry is how organisations make their agentic AI environment visible, accountable, and defensible under audit.
The five fields covered here owner, permissions, tool manifest, risk classification, and review status are not a complete governance programme on their own. They are the minimum structure that makes every other control possible: incident response, shadow AI detection, conformity assessment, and lifecycle oversight.
Start by registering every agent currently in production. Then build the review cadence. Then connect the registry to your infrastructure monitoring.
Start your 14-day free trial of Govern365.ai, by the Global AI Certification Council, and see how a purpose-built AI model registry maps your agents directly to ISO 42001 clauses, EU AI Act risk categories, and NIST AI RMF functions keeping your compliance posture current as your agentic AI environment grows.
