An agent registry is the list of every AI agent your organisation runs, with its owner, purpose, access and rules. Without it, nothing else in agent security can be checked.
This page covers what to record, how to keep it true, and how each entry links to the web rules an AI agent allow list enforces.
The word is used in several ways. On this page it means the governed list of agents an organisation actually runs.
An AI agent registry is a maintained record of every agent, with the facts needed to govern it: who owns it, what it may do, and how it is checked.
It is the source of truth other controls read from.
Agent inventory usually means the discovered list. Agent registry usually means the governed list with owners and rules.
Four changes in how agents are built and used have turned the registry from paperwork into a basic control.
Teams build them in hours. Vendors switch them on in products you already use.
Keys, tokens and sessions that outlive the projects that created them.
Signups, orders and posts on other sites carry your company's identity.
"Show me every AI agent and who approved it" is becoming a standard request.
The fields follow the life of an agent: who it is, what it may touch, how it is checked, and when it ends.
Required fields are marked. Start with those, and add the rest as each agent is assessed.
| Field | What it holds | Why it matters |
|---|---|---|
| agent_id (required) | Stable ID, such as AG-0001 | The same ID in logs, policies and tickets |
| agent_name (required) | Short readable name | How people refer to it |
| purpose (required) | One sentence on what it does | Defines normal behaviour |
| owner (required) | One named person | Accountability |
| status (required) | proposed, pilot, production, paused, retired | Shows what is really running |
| agency_tier (required) | 1 to 4 | Sets the strength of controls |
| review_by (required) | Next review date | Catches drift |
| team | Owning team | Reporting by team |
| risk_score, risk_band | From the risk assessment | Prioritises work |
| tools_and_mcp_servers | Every tool it can call | Defines what it can touch |
| credentials, credential_lifetime | Its identity and token lifetime | Links to identity controls |
| data_classes | Kinds of data it handles | Links to data protection duties |
| web_policy_file | Path to its per-agent web policy | Links the entry to enforcement |
| unclassified_destinations | deny or allow_reads | Shows how strict its web access is |
| exceptions | Narrow permissions for action pages | Makes every exception visible |
| hosted_by | in-house or vendor | Vendor agents need contract controls |
| model | Model in use | Model changes trigger reassessment |
| last_assessed | Date of the last risk assessment | Shows freshness |
| decision_log_location | Where its verdict logs live | Evidence for audits and incidents |
| retired_on | Date access was removed | Proves retirement happened |
| notes | Anything else | Context for reviewers |
A readable view of one entry. The download buttons give you the template, the schema and the matching policy file.
Start rough and improve. A partial registry today is worth more than a perfect one next year.
Ask every team lead to list the agents they run or have switched on. Accept rough answers.
Compare against logs, proxy traffic and SaaS settings. See agent discovery.
Seven fields per agent. Pause anything without an owner.
Give each agent a web policy file and record its path.
No agent reaches production without an entry. Enforce it in the deployment pipeline.
Every registry starts accurate. Within a few months, most drift unless something forces updates.
The strongest control is enforcement that reads the registry. If the egress proxy only knows agents with entries, an unregistered agent simply cannot reach the web.
The registry earns its keep when enforcement reads it.
web_policy_file: policies/vendor-research.json
Requests from AG-0001 are judged against that file only.
Page type from 40M+ domains: pricing allowed, signup denied.
decision_log_location tells auditors where to find it.
The right home depends on how many agents you run and who maintains the entries.
| Option | Good for | Watch out for |
|---|---|---|
| Spreadsheet from the template | First 20 agents, fast start | No enforcement link, easy to forget |
| Files in a repository | Engineering-led teams, pull-request reviews | Harder for non-engineers to read |
| IT service management tool | Organisations with an existing asset register | Web policy fields may need custom fields |
| Dedicated AI governance platform | Many agents, many regulations | Still needs a link to enforcement points |
The JSON Schema works with all four. Use it to check entries whatever tool holds them.
Whichever you choose, keep the agent ID identical everywhere it appears: registry, policy file, credentials and logs.
Vendor agents often outnumber in-house ones. Four habits keep them visible.
So reviewers know controls sit partly in a contract.
Browsing and actions can often be disabled per tenant.
Store the questionnaire next to the entry.
The person who switched it on, or who manages the vendor.
Report these monthly to the committee that owns agent risk.
Registered agents divided by discovered agents.
Entries with a named person as owner.
Entries reviewed before their review date.
Entries with a web policy file in force.
Retired entries with no traffic after the retirement date.
Short definitions for readers new to agent governance.
The raw list of agents found, before anyone has checked or owned them.
The governed list, with owners, rules and review dates.
How far an agent may act alone, from answers only to fully autonomous.
The per-agent file that says which pages it may open.
The record of every allow and deny for the agent's requests.
Removing every credential, tool approval and network path on one date.
A composite of common rollouts, not one specific customer.
Team leads listed 14 agents. Security expected about ten.
Proxy logs and SaaS settings showed 31 agents, including vendor agents switched on by individual staff.
Every agent got a named owner. Six had nobody willing to own them and were paused.
Each remaining agent got a web policy file. Action pages were denied for all of them.
The deployment pipeline began refusing agents without an entry.
The egress proxy began denying web traffic from unregistered agent IDs. Two forgotten agents surfaced within a day.
The gap between 14 and 31 is typical. Surveys find the agents people remember, discovery finds the rest.
Clear roles keep entries accurate without a central team doing all the work.
| Activity | Agent owner | AI platform team | Security | Risk and compliance |
|---|---|---|---|---|
| Create an entry | Does it | Checks tools | Informed | Approves tier |
| Update tools or model | Does it | Approves | Informed | Informed |
| Set the web policy | Proposes | Reviews | Approves | Consulted |
| Quarterly review | Does it | Consulted | Consulted | Owns the process |
| Retire an agent | Requests | Removes tools | Removes access | Records it |
Five short agenda items keep the registry honest and current.
Compare the registry with the latest discovery results. Every new agent needs an entry or a pause.
List entries past their review date and assign each a new date this quarter.
Read every active exception. Renew, narrow or remove each one.
Agents with rising denied action attempts get a closer look.
Confirm retired agents sent no traffic after their retirement date.
Resistance is normal in the first month. These answers usually settle it.
Seven required fields take ten minutes. Fixing an unowned agent after an incident takes weeks.
If a script uses a model to choose its next step, it is an agent and belongs in the registry.
The vendor runs the agent. You remain responsible for what it does with your data and your name.
Good. Add agent fields to it, especially the web policy file and review date.
No single law requires an "agent registry" by that name. Several frameworks require things a registry makes easy to show.
Risk management, record keeping and human oversight duties for high-risk uses all start with knowing which systems exist.
The AI management system standard expects an inventory of AI systems and their risks.
The Govern and Map functions ask for documented AI systems with owners and contexts.
Records of processing are easier to keep when every agent's data classes are listed.
This is general information, not legal advice. Your legal team decides which duties apply.
Each integration turns a field in the registry into a decision somewhere else. Start with the pipeline and the proxy.
Refuses agents without an entry or with an expired review.
Loads each agent's web policy file by agent ID.
Issues credentials only to registered agents, and revokes them on retirement.
Allows each agent only the tools in its entry.
Enriches alerts with the agent's owner and purpose.
Opens a task when a review date approaches.
The honest fine print — the same two assumptions we publish, plus two operational ones
Free template, then connect each entry to an enforced web policy.
