Agent registry and tool catalog solutions for enterprise AI governance

An agent registry is the record of every AI system a company runs. Trained models, agents bought from vendors, internal copilots, and the AI features a SaaS platform quietly switched on in the background: all of it belongs in there. Each entry answers a fixed set of questions. Who owns this thing? What data feeds it? Which tools can it call? How risky is it? Where does it stand with internal approval and outside regulators?

A shared spreadsheet is not a registry, and most companies that think they have one actually have a list someone updates when they remember to. That habit fails an audit the moment someone asks a real question. Four things separate the real thing from that spreadsheet.

Version control comes first. Every change to an agent's configuration, scope, or tool access gets tracked with a timestamp and an owner attached. Access scoping comes second: who can find the agent, who can invoke it, who can change it, enforced by the registry itself, not assumed because someone wrote it down in a wiki once. Third, the registry has to work as a machine-readable surface, because its main users are often other agents querying it programmatically at runtime, not a person clicking through a dashboard. Fourth, it needs real lifecycle states, things like approved, restricted, dormant, pending retirement, so it functions as something a system actually checks against instead of a static list gathering dust.

A working catalog serves two audiences at once. Human developers and domain experts use a UI to publish and find skills, while AI agents query that same catalog programmatically to figure out what they're allowed to call, before they act.

The closest precedent is the API gateway. Microservices became governable at scale once companies had dozens of services talking to each other and needed one place to enforce who could call what. The registry does the same job for agents, and companies that treat agent-to-tool connectivity as infrastructure, the way they'd treat a gateway or a network, will out-scale and out-govern the ones that bolt it on as an app feature. That gap shows up first in the audit, not in the demo.

Discovery has to cover the unsanctioned stuff too, not just the agents IT explicitly signed off on: OAuth grants nobody remembers approving, API keys sitting in a config file, MCP server connections, non-human identities with permissions nobody's reviewed in a year.

There's a regulatory payoff buried in all this bookkeeping. When an auditor asks a company to demonstrate compliance with the EU AI Act, NIST's AI Risk Management Framework, or ISO/IEC 42001, the registry is where those answers live. Without it, the answers don't exist at all, no matter how well-intentioned the AI program is.

How the Model Context Protocol turned tool integration from a custom problem into a standardized one

Before late 2024, every connection between an agent and a tool was a one-off job. A GitHub integration built for one agent runtime wouldn't work on another. A Slack connector built for one LLM broke the moment the company swapped in its successor. Engineers kept rebuilding the same plumbing for different pipes, over and over.

That's the N×M problem: N agents times M tools equals an integration surface that grows quadratically. Add one new agent, and every existing tool needs a new connector. Add one new tool, and every existing agent needs the same thing in reverse.

Anthropic introduced the Model Context Protocol in late 2024 to fix exactly this. MCP defines a standard JSON-RPC interface and treats tools, resources, and prompt templates as shared building blocks that any compliant client can call through any compliant server. BCG called it "a deceptively simple idea with outsized implications," and the math backs that up: MCP turns N×M into N+M. Integration effort grows in a straight line as agents multiply, instead of exploding.

The adoption curve since then reads like infrastructure settling into place. MCP server downloads went from roughly 100,000 in November 2024 to over 8 million by April 2025. The public server ecosystem grew from about 50 servers at launch to somewhere between 8,000 and 12,000 distinct servers by the second quarter of 2026. SDK downloads across Python and TypeScript hit 97 million a month by March 2026. Governance of the protocol moved to the Agentic AI Foundation in December 2025, so no single company controls the roadmap anymore. OpenAI, Google, Microsoft, and AWS have all adopted it.

Here's what falls out of that standardization directly: a registry only works at scale because every tool now speaks the same language. When every server follows the same protocol, one central catalog can list, version, and control access to all of them the same way, instead of needing a custom integration for every combination.

Standardization cuts both ways, though, and this is the part most teams underrate badly. With thousands of public MCP servers out there, a developer can wire an agent to some external service nobody's vetted in a matter of minutes. That ease of integration is exactly what makes an unmonitored environment dangerous. The registry's job is to sit in front of that surface as the actual gate, not a suggestion posted in a wiki nobody reads.

Why a tool catalog is not the same thing as a list of approved integrations

Plenty of teams have an "approved tools" spreadsheet somewhere. It records which integrations exist. It rarely says what those integrations are allowed to do, who's cleared to invoke them, or when the approval behind them expires. A list isn't a catalog, no matter how tidy it looks, and confusing the two is the single most common governance mistake on this whole topic.

A tool catalog that actually governs anything does three things a list can't.

First, it scopes access at the capability level, not just the server level. A vetted MCP server can push an update next month that adds a new write capability nobody reviewed when the server was first approved. The catalog has to catch that change, not wave it through because the server was already on the approved list.

Second, it enforces rather than advises. Access decisions made inside the catalog have to reach runtime and take effect there; they can't depend on a developer remembering a policy from a training deck six months back.

Third, it reflects the permissions a user already has in the systems underneath. If someone doesn't have access to a particular record in the CRM, an agent acting on their behalf shouldn't be able to pull that record either, no matter which tool the agent used to try.

Underneath all three sits the credential problem, and it's the one most teams skip past. Picture ten agents sharing one API key: when something goes wrong at 2am, there's no way to tell which of the ten made the call, because the logs all point to the same credential. Each agent needs its own identity, with scoped permissions and a documented date for when someone last reviewed that access. That per-agent identity is what makes least-privilege enforcement, conditional access, and clean revocation possible in the first place. Skip it, and governance amounts to a policy on paper, nothing more.

The catalog also works as a policy surface in its own right. An admin sets whether a new capability from an upstream server gets enabled automatically or requires sign-off, and different teams run under different thresholds depending on how much risk they're allowed to carry.

There's a simple test for whether a company has a catalog or just a list dressed up nicely. Ask, right now, which agents have write access to the CRM, when that access was last reviewed, and who signed off on it. If the answer takes more than a few minutes to pull together, there's no catalog yet, whatever anyone's calling it internally.

The virtual server model for scoping tools to teams without rebuilding permissions from scratch

The default setup at most companies that adopt MCP without thinking about scope is one shared environment where every team sees every tool. Any developer can call anything. Permissions don't get enforced tool by tool, and audit trails blur into one undifferentiated stream nobody can untangle later. That default is a mistake, and it's the one virtual servers exist to correct.

Virtual servers fix the structure, not just the policy. A virtual server presents a curated, access-controlled slice of the full tool catalog to one team, one role, or one specific use case. Clients connect to a single URL, and a virtual layer sitting behind it decides which upstream tools that client can actually see and call. A finance team might get ERP tools in read-only mode. An operations team works in its own environment wired to supply chain workflows. Neither team can see, let alone call, the other's tools.

SCIM-based provisioning ties membership in these environments directly to identity provider groups. When someone joins a team, their tool access shows up automatically; when they leave, it disappears the same way, no manual ticket required.

The governance payoff is concrete: separate audit trails per environment, isolation that can be proven in front of a compliance reviewer, and the ability to pull a tool away from one team without touching anyone else's setup.

This also solves a quieter problem: duplicate work. Without scoped sharing inside one registry, teams end up rebuilding the same prompts and the same workflows independently, because nobody can see what another team already built. Scoped environments make existing work findable and reusable across the company, instead of every team reinventing the same integration from scratch.

Underneath that sits an ownership principle worth naming directly. Teams should publish and manage the skills relevant to their own domain without routing every change through central IT. The registry supplies the governance rails; the team supplies the context. That division of labor keeps the system usable instead of turning into a bottleneck everyone routes around.

What enterprises should evaluate when selecting or building registry infrastructure

The market in 2026 splits into a few categories: purpose-built MCP registries, AI governance platforms that bolted on agent inventory features, cloud-provider-native tools, and open-source projects. They don't offer the same depth of governance, and the open-source route in particular costs more than it looks like it does upfront. Skip the open-source stack unless there's a dedicated team ready to own it indefinitely, because the sticker price of "free and open-source" hides the salary of the person who ends up maintaining it.

Start with discovery completeness. Does the tool find agents nobody registered, including ones a SaaS vendor turned on and local MCP server connections nobody logged? Microsoft's Agent 365 registry, for example, surfaces unmanaged agents automatically through Defender, Entra, and Intune, covering more than 35 known agent types, including coding agents, AI desktop apps, and both local and remote MCP servers.

Next, look at permission inheritance. Does access control pull automatically from the systems underneath, or does someone have to redefine it by hand every time a new tool gets added? Redefinition drifts out of sync fast; inheritance keeps what an agent can reach lined up with what the human behind it could already reach.

Then check version control and change history. Is every change to an agent's configuration or tool access logged, with a timestamp and a name attached? Without that, "who approved this and when" has no answer, and a registry that can't answer that question can't support an audit, no matter how good its dashboard looks.

Model and surface portability matters more than it looks at first glance. Business context, permissions, and guardrails need to travel with the company, not stay locked to one model vendor. A registry that only works with one LLM provider creates lock-in exactly where a company can least afford it: the governance layer, the part meant to outlast whichever model happens to be popular this year. The same registry should serve Claude, ChatGPT, Cursor, Slack, and internal tools without rebuilding access rules separately for each one.

Last, auditability needs to be a built-in feature, not a log export someone stitches together after the fact. Can the system answer, on demand, which human started a request, which agent carried it out, and which tool got called, without pulling logs from five different places? Runtime enforcement, layered on top of after-the-fact logging, is what separates real governance from governance theater. Most vendors sell the second thing while calling it the first.

The same N+M logic that makes MCP efficient applies to governance tooling too. Assembling a registry from scattered open-source pieces means someone on staff maintains that stack indefinitely. That's a permanent headcount line, not a one-time setup cost, and most teams underestimate it badly.

How department-specific use cases reveal whether registry governance is working in practice

The real test isn't whether a registry exists somewhere in the company. It's whether teams actually reach for it to find and reuse existing skills instead of quietly building the same thing twice.

Sales and RevOps show this clearly. CRM-connected agents that surface deal context, draft follow-up emails, or pull pipeline numbers are common now. The governance question underneath is simple: does the agent only retrieve what the requesting rep is already allowed to see in the CRM, or does it reach into everything? A registry that inherits CRM permissions automatically passes that test without anyone having to configure it agent by agent.

Engineering runs into a related version of the same problem. Coding agents, tools like Claude Code and Cursor, query the registry at runtime to figure out which tools they're cleared to call in a given environment. A well-built registry stops a tool meant for a dev environment from getting invoked against production, because access gets scoped to the environment at the catalog level, not left to whoever wrote the agent's prompt.

Support teams face a different edge. A support agent needs access to customer records and case history to do its job, but it shouldn't be able to issue a refund or change account settings without a human signing off first. Tool-level capability scoping, read access granted, write capabilities blocked or gated behind approval, is what makes that boundary real instead of aspirational.

Watch for this tell across all three departments: if two teams have separately built agents doing basically the same thing against the same data source, something's broken. Either the registry isn't being used for discovery, or its scoped sharing isn't working the way it should. That's a governance failure, not wasted engineering time dressed up as something smaller, and it deserves to be treated that way instead of shrugged off as ordinary redundancy.

Working registry governance looks like this in practice: a new team finds an existing skill in the registry, checks its owner and approval status, and deploys it into their own scoped environment without rebuilding a single line of it. Credal, for instance, structures its agent registry around exactly this model, with version control and audit logging built into each deployment. That deployment gets logged, versioned, and stays revocable if anything changes later.

The implementation sequence that makes registry adoption stick across an organization

The most common mistake, and the costliest one, is building an elaborate registry architecture before doing the discovery work underneath it. A company can't govern what it hasn't inventoried. Skipping straight to architecture just means building a polished system on top of inaccurate data, and no amount of good UI design fixes that later.

Phase one has to be inventory, no exceptions. Enumerate every agent-like system running in the environment: OAuth grants, API keys, MCP server connections, AI features SaaS vendors turned on without asking, non-human identities carrying broad permissions nobody's checked recently. Then classify each one by risk. What data does it touch? What actions can it actually take? Is it approved, or is it shadow AI nobody signed off on?

Phase two is identity and ownership, and it comes before adding a single new tool, not after. Every agent gets a unique identity, a named owner, and a permission set scoped to what it actually needs, not what's convenient to grant. Skip this step, and the registry ends up governing a pile of anonymous service accounts instead of accountable systems, which defeats the purpose before the rollout even finishes.