AI Agent Registry Template: The Fields Every Enterprise Should Track

An AI agent registry is the system of record for every AI agent your organization runs or pilots: what each agent is for, who answers for it, whose authority it acts with, which tools and data it can reach and when it was last reviewed. This template lists the fields worth recording, grouped so different teams can own different parts, with a filled-in example and the practices that keep the registry accurate. It is the companion to our guide on AI agent governance, where the registry is the first of seven control areas.

Why an agent registry is different from an AI inventory

Most enterprises already keep some list of AI systems. An AI agent registry is stricter because agents act. A model that scores a loan application produces an output that a person reviews. An agent that updates the loan record, emails the applicant and opens a task in the servicing system has taken three actions with someone’s permissions.

That changes what you need to know about each system. The inventory question is “what is this and how risky is the use case?” The registry adds “what can it do right now, as whom, within what limits, and how do we stop it?” Those answers have to be current to the hour, not to the last quarterly review, because they are what security reads during an incident.

A practical rule: everything in your AI inventory gets a basic record, and anything that can call a tool with write access gets a full registry entry. Keep both in the same system so there is one place to look. Our AI model inventory template covers the basic record for every AI system, including vendor and embedded AI, and treats this registry as its detailed view for agents.

The template at a glance

The registry template below has eight groups of fields. Each group has a natural owner, which matters more than the exact field names. A registry fails when one team is expected to know everything.

Group	What it answers	Usually maintained by
1. Identity of the entry	What is this agent and where does it run?	Platform team
2. Ownership	Who answers for it?	Business owner
3. Purpose and scope	What is it for, and what is out of scope?	Business owner
4. Risk and autonomy	How much harm could it do, and how much can it do alone?	Risk, with the architecture review board
5. Identity and access	Whose authority does it act with?	Security / identity team
6. Tools and data	What can it read and change?	Platform team, with data owners
7. Models and configuration	What is actually deployed?	Engineering, populated by the pipeline
8. Controls, evidence and lifecycle	What limits apply, where are the logs, when is the next review?	Platform team and risk

The detail for each group follows. Mark fields as required or optional for your organization. A short list of required fields that are always filled beats a long list that is half empty.

The fields, group by group

1. Identity of the entry

• Agent ID. A unique, stable identifier. It should appear in every log line, credential and trace the agent produces.
• Name and one-line description. Written for a non-specialist: “Drafts and sends shipping-delay notices to customers.”
• Status. Proposed, pilot, production, suspended or retired.
• Environment and runtime. Where it runs: the orchestration platform, the cloud account, the low-code tool or the vendor product.
• Build type. Built in-house, configured in a platform, or supplied inside a vendor product.

2. Ownership

• Accountable business owner. A named person, not a team. They answer for the agent’s outcomes and approve changes to its scope.
• Technical owner. The person or team who maintains it. For a vendor agent, the vendor, with an internal contact.
• On-call or escalation contact. Who is paged when it misbehaves at 2 a.m.
• Business process. The process the agent sits in, linked to that process’s own owner where you track one.

3. Purpose and scope

• Intended use. What the agent is meant to do, in two or three sentences.
• Out of scope. What it must not do, stated plainly. This field is the one reviewers read first.
• Users and audience. Who interacts with it: employees, customers, partners, or nobody (event-driven agents).
• Trigger. How a run starts: a user request, a schedule, an event or another agent.

4. Risk and autonomy

• Use-case risk tier. From your AI governance framework, based on the harm a wrong outcome could cause.
• Autonomy tier. How much the agent may do without a person, from assist-only through acting on consequential matters. The tier follows the most consequential tool the agent holds, not its usual behavior.
• Decisions about individuals. Whether it affects a person’s rights, money, access or opportunities. This often decides the review path on its own.
• Regulatory notes. Any framework that applies to the process, such as model risk guidance in banking or a high-risk category under the EU AI Act, with the date someone last checked.

5. Identity and access

• Directory identity. The agent’s own service identity. Never a shared account and never a person’s credentials.
• Delegation mode. Acts as itself, acts on behalf of a signed-in user, or both. When it acts for users, record that their entitlements are passed through and enforced.
• Credential type and lifetime. Short-lived tokens from a token service are the target. Note any long-lived key as an exception with an expiry date.
• Permission scope. The roles or scopes granted, linked to where they are defined in your identity system.

6. Tools and data

• Tools. Each tool from your approved catalog, with its classification: read, reversible write or irreversible write.
• Tool limits. The caps enforced at the tool: maximum value per action, records per call, calls per hour, spend per day.
• Data sources. Each source the agent retrieves from, with its sensitivity classification and data owner.
• External connectors. Third-party integrations, including Model Context Protocol servers, with the version or source approved.
• Outbound communication. Whether it can send email, messages or posts outside the company, and to whom.

7. Models and configuration

• Models and versions. Each model the agent calls, with provider and version or deployment name.
• Prompt and configuration version. A pointer to the version-controlled system prompt and agent configuration.
• Orchestration logic version. The code or workflow definition deployed, by commit or release.
• Evaluation suite. A link to the test suite the agent must pass, and the result of the last run.

Fill this group automatically from the deployment pipeline. Hand-entered model versions are out of date within a month.

8. Controls, evidence and lifecycle

• Approval rules. Which actions need a person to approve them, and who that person is.
• Kill switch. How the agent is stopped (disable the identity, revoke tools, halt the orchestrator) and the date the stop was last tested.
• Trace location. Where its run traces are stored and their retention period.
• Incidents. Links to any incidents involving the agent.
• Review history. Date of the last review, who reviewed it and the outcome.
• Re-review triggers. The changes that reopen the review: a new write tool, a new data source, a model change, higher limits, a new user group.
• Next review date. A fixed date, so nothing stays approved forever by default.

A worked example entry

The entry below is illustrative. The agent, systems and limits are invented to show how the fields read when filled in.

Field	Example value
Agent ID	agt-ops-0142
Name	Shipping delay notifier
Description	Detects late shipments and drafts delay notices to the affected customers
Status	Production
Runtime	Orchestration service in the operations cloud account
Business owner	Director of Customer Operations (named person)
Technical owner	Operations platform team
Intended use	Notify customers of delays over one business day, with a new estimated date
Out of scope	Refunds, credits, order changes, any message to a customer with an open dispute
Trigger	Event: shipment status changes to delayed
Use-case risk tier	Moderate (customer communication)
Autonomy tier	3, act within limits
Directory identity	svc-agt-ops-0142, its own service identity
Delegation mode	Acts as itself; no user context
Tools	Order lookup (read), shipment lookup (read), customer email send (irreversible write)
Tool limits	500 emails per day; one notice per order per 48 hours
Data sources	Order system (confidential), carrier feed (internal)
Models	One hosted model, version pinned in configuration
Approval rules	None per message; a person approves the template set quarterly
Kill switch	Disable service identity; tested 30 days ago
Traces	Central trace store, retained per customer-communication records rules
Re-review triggers	Any new tool, any change to the email templates, limits above 500 per day
Next review	Six months from last review

Notice what the example makes visible. The agent holds an irreversible write tool (sending email), so it sits at tier 3 even though most of its work is reading. The out-of-scope line about open disputes is the kind of rule a reviewer would otherwise have to dig out of the prompt.

Keeping the registry accurate without policing it

A registry is only useful if it is true. Manual upkeep fails, so make accuracy a side effect of how agents are deployed.

1. Make registration a condition of deployment. The release pipeline refuses to deploy an agent whose ID has no approved entry.
2. Issue credentials only to registered IDs. The token service and the LLM or tool gateway check the registry before granting access. An unregistered agent simply cannot act.
3. Populate technical fields from the pipeline. Models, prompt versions, tool lists and evaluation results are written by automation on each release, not typed in.
4. Reconcile against reality. Compare the registry with what the gateway actually saw this week: agent IDs, tools called, models used. Any difference is a finding.
5. Expire entries. An entry past its review date drops to suspended unless the owner renews it. Owners renew things that have a deadline.
6. Offer a fast path for low-tier agents. Business teams build agents in productivity and automation tools. A five-minute registration for assist-only agents brings them into view. A slow process drives them underground.

Where an LLM gateway already sits in front of model traffic, it is the natural enforcement point. Our LLM gateway architecture guide covers the pattern, and the Model Context Protocol guide covers the same check for tool servers.

Common mistakes

• One owner field. Recording only a team name means nobody is accountable. Separate the business owner from the technical owner and name people.
• Tools without classifications. A list of tool names says nothing about risk. Read versus write, and reversible versus irreversible, is what drives the tier.
• Free-text model versions. If engineers type them, they drift. Pull them from configuration.
• No retired state. Deleting an entry loses the history that an auditor or incident review will ask for. Retire it, revoke its identity and keep the record.
• Vendor agents left out. Agents inside SaaS products act on your data with scopes your administrators granted. They belong in the registry with the vendor recorded as technical owner.
• A registry nobody reads. If the architecture review board and the security team do not query it, it will decay. Put it on the agenda of every AI architecture review board meeting.

Mapping the registry to the frameworks

The registry is not a new obligation. It is how several existing ones become concrete.

• NIST AI RMF 1.0. The Map function asks you to establish context and categorize AI systems. The registry is where that context is recorded and kept current.
• ISO/IEC 42001:2023. An AI management system needs documented information about the AI systems in scope. Registry entries and their review history are that record for agents.
• EU AI Act. Where an agent forms part of a high-risk system, obligations on record keeping, human oversight and risk management apply. The registry shows which agents fall in scope and where their evidence lives. Check current timelines, since they have been subject to change.

Where to start

You can stand up a first version in a few weeks.

1. Agree the required fields: start with groups 1 to 6 and the kill switch.
2. Inventory existing agents, including pilots, low-code builds and vendor agents.
3. Fill entries with each business owner in short working sessions, not by email survey.
4. Wire the deployment pipeline to write group 7 automatically.
5. Make the gateway or token service refuse unregistered agent IDs.
6. Set review dates and run the first weekly reconciliation.

How we help

We design the agent registry as part of the platform, so registration, credentials and tool access are enforced by the architecture rather than by reminders. That work sits within our AI governance and risk and agentic AI architecture services. If you are moving agents into production and want the registry in place first, talk to an architect.