Every new employee, contractor, or system that gets access to your organization's data goes through some kind of onboarding. We know who they report to, what they're responsible for, what they can access, and when that access will be reviewed.
AI agents are now getting that same access. Often without any of that onboarding.
And agents are not chatbots. A chatbot answers a question. An agent takes action. It reads your files, calls your systems, updates the record, sends the email, and sometimes hands the task over to another agent. It does all of this with credentials that someone granted it. That someone may have since moved on to another project, or another organization.
In my article on the 6 layers of AI governance, I wrote that AI governance starts with visibility, and that its first layer is the AI inventory. For agents, that inventory needs a more detailed form of its own: the AI agent register. In this article, I'll walk you through what an AI agent register is, why you need one now, what it should capture, how to classify your agents, and how to keep the register current.
Spoiler: I'm offering a free AI Agent Register template at the end of this article.
What is an AI agent register?
An AI agent register is a single, maintained list of every AI agent operating in your organization. For each agent, it records who owns it, what it's for, how autonomous it is, which identity and permissions it uses, what data it can reach, how risky it is, which controls are in place, and when it was last reviewed.
I like to think of it as the agent's employee file. If you've ever built a data sources inventory or a business glossary, the idea will feel familiar: one place, one accountable owner per entry, and a review cycle that keeps it honest.
You may already have two related inventories. Here's how the agent register fits next to them:
Inventory | What it tracks | The question it answers |
|---|---|---|
AI use case register | Business uses of AI | Where are we using AI, and why? |
Model registry | Models and their versions | Which model is this, and how was it validated? |
AI agent register | Agents that take actions | What can this agent do, with what access, and who is accountable for it? |
One use case can involve several agents, and one model can power dozens of them. That's why I recommend giving agents their own register, linked back to the use case and the model, rather than squeezing them into either one.
Why you need one now
Agents are being added to organizations faster than most governance programs can keep track of them. Here are four reasons I wouldn't wait.
1. Agents show up without asking for permission. Your CRM, productivity suite, ticketing tool, and data platform are all adding agent features. Business users can build their own agents with low-code tools in an afternoon. If the only agents you know about are the ones your IT team built, your register is already incomplete.
[George: a short real-world example would land well here, such as the first time you came across an agent or AI feature nobody had told the governance team about.]
2. Agents carry identities and permissions. An agent acts through a service account, an API key, or a person's delegated access. The OWASP Top 10 for Agentic Applications, announced in December 2025, lists identity and privilege abuse as one of its ten core risks: an agent using its own or another agent's credentials to gain access beyond its permissions. You can't right-size access you can't see.
3. Someone has to be accountable. In January 2026, Singapore's IMDA launched the Model AI Governance Framework for Agentic AI. Among other things, it calls on organizations to make humans meaningfully accountable, to limit an agent's access to tools and systems at the design stage, and to put identity management and access controls in place so agent actions are traceable. Every one of those starts with knowing which agents exist and who owns them.
4. Agents get orphaned. The person who built the agent changes roles. The pilot ends, but the agent keeps running. The vendor updates the underlying model. Without a register and a review date, nobody notices until something goes wrong.
The key point: an agent you don't know about is an agent nobody is governing.
What to capture in your AI agent register
A useful register answers six questions for every agent: who owns it, how was it built, what can it do, what can it reach, how risky is it, and when was it last checked. Here are the fields I recommend, grouped by those six questions.
Group | Fields | Why it matters |
|---|---|---|
Identity & ownership | Agent ID, name, purpose, business owner, technical owner, department, linked AI use case, status | Every agent needs a named person who answers for it. "The AI team" is not an owner. |
Build & platform | Build type (in-house, vendor-embedded, user-built low-code, third-party), platform or vendor, underlying model and version | Vendor-embedded and user-built agents are the ones most likely to be missing from your inventory. |
Autonomy & actions | Autonomy level, actions it can take, tools and systems connected, calls other agents (Y/N), irreversible actions (Y/N) | What an agent can do is the biggest driver of its risk. |
Access & identity | Agent identity type (service account, API key, delegated user access), permission scope, data accessed, data classification, personal information (Y/N) | This is where data governance and AI governance meet. |
Risk & controls | Suggested risk tier, risk tier override, human oversight model, how to stop it, logging enabled (Y/N), guardrails and notes | Controls should match the risk tier, and "how to stop it" should never be blank. |
Lifecycle | Approved by, approval date, last review date, review frequency, next review due, review status | Without review dates, the register slowly turns into a list of good intentions. |
Yes, some agent platforms keep their own list of agents. But each platform only sees its own agents. Your register needs to see all of them, across every platform and vendor.
You also don't need every field on day one. If you're starting from zero, I recommend capturing these five first:
- Agent name
- Business owner
- Autonomy level
- Systems it connects to
- Data it can access
You can fill in the rest as the register matures.
How to classify agents: autonomy levels and risk tiers
Not every agent needs the same level of scrutiny. An agent that summarizes meeting notes and an agent that issues refunds should not go through the same review. Two classifications help keep governance proportional: how much the agent does on its own, and how much harm it could cause.
Autonomy levels
Level | Name | What the agent does | Example |
|---|---|---|---|
L0 | Assist | Suggests. A person does the work. | Recommends a reply to a customer email |
L1 | Draft | Prepares the action. A person approves every one. | Drafts a purchase order for sign-off |
L2 | Act with checkpoints | Acts on routine tasks; a person approves defined high-impact actions | Updates CRM records, but asks before deleting any |
L3 | Act and report | Acts within set boundaries; people review after the fact | Triages and closes routine IT tickets |
L4 | Autonomous | Acts, chains tools and other agents, with minimal human involvement | Runs a multi-step procurement workflow end to end |
One word of caution on L1 and L2. Having a person approve an agent's actions only works if that person has the time, context, and authority to say no. In my conversation with Dr. Fern Halper on the Lights On Data Show, we talked about how often "human in the loop" ends up being just a checkbox. Record the oversight model in your register, but also check that it's real.
Risk tiers
The template suggests a risk tier for each agent by scoring five factors:
- Autonomy level
- Data classification
- Whether it handles personal information
- Whether it can take irreversible actions
- Whether it calls other agents
You can override the suggestion, and you should, whenever you know something the score doesn't. Here's what I recommend for each tier:
- High: approval before high-impact actions, a tested way to stop the agent, full logging, and a review every 3 months.
- Medium: human review of outputs or actions, logging, and a review every 6 months.
- Low: monitoring and a review every 12 months.
One rule overrides the score: any agent that can take irreversible actions at L3 or above is high risk. Ex: sending payments, deleting records, or emailing customers on its own. That's not something you want to discover during an audit.
How to build your register and keep it alive
Building the first version can take a few weeks. Keeping it accurate is the real work. Here's the approach I recommend.
- Assign an owner for the register itself. This is usually the AI governance lead or the data governance office, with your data governance council or AI governance committee overseeing it. Without an owner, the register becomes a one-time project.
- Discover what's already running. Start with your vendors' agent features, your low-code platforms, and your identity and access management system. Service accounts and API keys created in the past year are a great place to find agents nobody mentioned.
- Position it as discovery, not policing. Ask teams which agents they use and why. People will hide agents from a crackdown, but they'll gladly tell you about them if you're helping them use agents safely.
- Capture the minimum, then enrich. Start with the five fields above. Add risk and controls next.
- Connect it to your existing gates. No agent gets production credentials without a register entry. Tie the register to your procurement, access request, and change management processes.
- Review on a cadence. Let the risk tier set the review frequency, and check permissions at every review. Agents tend to collect access over time, just like people do.
- Retire on purpose. When an agent is switched off, revoke its credentials and mark it as Retired. Keep the row though. It's part of your audit trail.
Common mistakes to avoid
Some common traps I'd watch out for:
- Only registering the agents IT built. Vendor-embedded and user-built agents can easily outnumber them.
- Listing a team as the owner. Accountability needs a person's name.
- Recording what the agent is for, but not what it can do. Purpose tells you the intent. Permissions tell you the risk.
- Letting agents borrow a person's credentials. If an agent acts as "Sarah," your logs can't tell Sarah's actions apart from the agent's.
- Leaving "how to stop it" blank. If nobody knows how to switch an agent off, find out before you need to.
- Treating the register as a one-time inventory. Agents, models, and permissions change. Without review dates, the register goes stale within months.
- Deleting retired agents. Keep them, marked as Retired, with the date their credentials were revoked.
Free AI Agent Register template:
So you don't have to start from a blank spreadsheet, I've put together an AI Agent Register template in Excel. It includes:
- All the fields above, with dropdowns so entries stay consistent
- An automatic risk tier suggestion, with room to override it
- Review dates that calculate from the risk tier and flag agents that are overdue or due soon
- A dashboard showing your agents by risk tier, autonomy level, status, and build type, plus the gaps that need attention
- An example entry to show you what a complete row looks like
If you haven't already, pair it with the free AI Governance Self-Assessment from my 6 layers of AI governance article to see how your agent inventory fits into the bigger AI governance picture.
Frequently Asked Questions
What is an AI agent register?
It's a single, maintained list of every AI agent operating in an organization, with its owner, purpose, autonomy level, identity and permissions, data access, risk tier, controls, and review status.
How is an AI agent register different from an AI use case register?
A use case register tracks where and why AI is used. An agent register tracks the agents that take actions: what each one can do, what it can access, and who is accountable for it. One use case can involve several agents.
What should an AI agent register include?
At a minimum: the agent's name, business owner, autonomy level, the systems it connects to, and the data it can access. A mature register also covers identity type, permission scope, risk tier, human oversight, how to stop the agent, and review dates.
How often should an AI agent register be reviewed?
Base it on risk. The template suggests every 3 months for high-risk agents, every 6 months for medium, and every 12 months for low, and you can adjust these to your organization's risk appetite.
Final thought
We would never give a new hire access to our systems without knowing who they report to, what they're allowed to do, and when we'll review that access. Agents are getting that kind of access today, often with less oversight than we'd give an intern.
The AI agent register is how you close that gap. Start with the agents you know about. You might be surprised how quickly you find the ones you didn't.
