Building an AI Registry: Models, Agents, MCP Servers
Last Updated: September 9, 2026 | By Mihail Sebastian | Agentic AI
An AI registry is your organization's living inventory of approved models, agents, and MCP servers. Here is how to build one that teams actually use.
If a regulator, a customer, or your own board asked for a complete list of the AI systems your organization runs, could you produce it by Friday? For most organizations the honest answer is no. There is a spreadsheet somewhere, half a procurement trail, and a Slack message where someone approved something once.
An AI registry closes that gap: a living inventory of your approved AI assets, each recorded with an owner, a risk class, and a review date. This article covers why you need one now, what goes in it, what a good entry looks like, and how to keep the whole thing from dying quietly in a shared drive.
Why You Need One Now
You cannot govern what you cannot list. Every control in AI governance presumes a known set of systems to apply it to: risk classification needs systems to classify, human oversight needs systems to oversee, incident response needs to know what broke. Without the inventory, policy is commentary.
Shadow AI thrives in exactly that gap. Where no registry exists, “approved” has no definition, so every tool is equally unofficial and nobody sees a reason to ask. We wrote about why banning tools fails; the registry is the constructive half of that argument, because it gives disclosure somewhere to land.
Regulation pushes the same direction. The EU AI Act expects organizations to know which AI systems they operate and to classify them by risk, and sector rules in finance and healthcare rest on the same assumption. When an AI audit arrives, internal or external, the registry is its starting list, and the alternative is reconstructing your inventory under deadline pressure.
There is a plainer payoff too. A searchable registry stops teams from putting the same vendor through procurement twice, and it tells the third team with the same problem that an approved solution already exists.
What Belongs in It
The instinct is to catalog models and stop. That misses most of the risk, because the model is only one layer of what your organization actually runs.
Models. The foundation models and APIs you consume, plus anything fine-tuned in house. Two teams calling the same provider under different contracts are two entries, because the data terms differ.
AI applications. Products with AI inside: the vendor tool with a copilot feature, the internal chatbot, the summarizer bolted onto your CRM. Vendors add AI features to products you approved years ago, and each addition deserves its own row.
Agents. Systems that act rather than just generate: they call APIs, write to databases, send messages. An agent’s blast radius is defined by its permissions, not its model, so the entry must record what it is allowed to do.
MCP servers and tools. The current addition to the list. An MCP server is third-party code your agents call with real permissions: it reads files, queries systems, executes actions. A developer who wires an unvetted server into an editor has installed an unreviewed dependency with live credentials, and the registry is where that vetting gets recorded.
The scope rule is short: if it touches company data or acts on company systems, it belongs in the registry.
The Anatomy of an Entry
Six fields do most of the work. Skip any of them and the inventory degrades into a list of names that answers no useful question.
Owner. A named person, not a team, who answers for the asset. A registry without owners is a spreadsheet: rows of metadata with nobody attached, useless the day something goes wrong.
Purpose. The approved use case, stated narrowly. “Contract summarization for the legal team” survives review; “general productivity” is a blank check that makes the risk class meaningless.
Risk class. Where the asset sits in your classification scheme, which decides how much scrutiny it gets at intake and how often it comes back for review. A meeting-notes summarizer and an agent that adjusts customer pricing do not deserve the same process.
Data touched. What goes in: public content, internal documents, customer records, regulated data. This field drives more approval conditions than any other, because most AI incidents are data incidents.
Approval status. Approved, approved with conditions, or rejected, with the conditions spelled out. “Internal data only” and “human review of outputs” are the two that appear most.
Review date. When the entry comes back for another look. An entry without one is approved forever, and nothing about AI deserves that.
The owner field carries the most weight. When the vendor changes terms, when the model behind an API is swapped, when the use case drifts past its purpose statement, one person’s name is on the answer.
The Intake Path
The path from “I want to use this” to a decision has three steps: request, risk-based review, decision. Everything else is elaboration.
The request is a short form: what tool, what purpose, what data, who owns it. If the form takes longer than fifteen minutes, people will not file it, and your inventory starts incomplete.
The review scales with risk. A low-risk tool that touches no sensitive data gets a checklist and an answer within days; an agent with write access to customer systems gets a real assessment of vendor terms, data flows, permissions, and failure modes.
One process for both is the classic failure. It wastes reviewer time on the easy cases, starves the hard ones, and teaches requesters that the queue is arbitrary.
The decision is recorded with its reasons, including rejections. A trail of past decisions gives the next reviewer precedent to work from, and it makes an appeal a conversation about facts rather than a fight about process.
Conditions are the tool that keeps the answer from being binary. “Approved for internal documents, through the gateway, with logging on” says yes to the work while it says no to the risk, and most requests that would otherwise be rejected fit some version of it.
Speed is the anti-shadow-AI feature, not a nice-to-have. Your intake path competes directly with “just use it and tell no one,” and it competes on turnaround time. An intake queue measured in days keeps the registry honest; one measured in quarters guarantees the inventory describes a fiction.
Keeping It Alive
Registries rarely die by decision; they die by neglect, one unrecorded change at a time, until nobody trusts the record enough to consult it. Three practices keep it matched to reality.
Re-review on a cadence set by risk class. Low-risk entries get an annual confirmation that the owner still exists and the purpose still holds. High-risk entries come back more often, because vendors change models, terms, and data practices without asking your permission.
Calendar dates are the floor, not the whole trigger. An owner who leaves, a vendor acquisition, a new data source wired into an agent: each of these should reopen the entry ahead of schedule.
Deprecate deliberately. Entries must be able to leave: the pilot that ended, the tool the team abandoned, the MCP server nobody has called in six months. Dead entries are not harmless clutter; they hide the live risks in a longer list and erode trust in every other row.
Enforce what is not listed. A registry consulted only by the people already inclined to follow it changes little. The AI gateway is the enforcement arm: the registry decides what is approved, the gateway applies that decision to live traffic, and anything absent from the registry gets no credentials and no route.
That pairing is the whole design. The registry is where your organization’s AI decisions live; the gateway is what makes them real on every request.
Build the first without the second and you have documentation. Build both, keep the intake fast, and the list on file is finally the same as the AI you actually run.
