Enterprise AI Platforms With Versioned Centralized Agent Instruction Registries

A governed AI agent skill registry for enterprises is a shared control plane for publishing, finding, versioning, and auditing the instructions agents use. It lets authorized teams reuse skills without rebuilding their logic or bypassing permissions. For enterprises evaluating AI platforms, the central test is whether that governance works across teams, models, and tools before production begins.

Why so few enterprise AI pilots survive contact with production

Download charts show adoption. An enterprise can have agents running while still lacking an approval workflow, an audit layer, or a clear record of who authorized their write access. Those gaps show that the organization cannot yet control the task reliably. As deployments multiply, duplicated instructions and unclear ownership make that problem harder to resolve.

The NSA stated in a May 2026 report that MCP’s rapid proliferation had outpaced the development of its security model. A working connection to enterprise data does not establish who may use it, what an agent may change, or who answers for the result. These are infrastructure questions, and leaving them unanswered is the structural failure that prevents pilots from becoming governed services.

What a versioned, centralized agent instruction registry actually is

Skills, prompts, and tool configurations are published there with explicit versions, ownership, access scope, and an approval workflow. Teams with permission can find them, and changes can still be audited. A shared wiki may describe those arrangements, but it does not enforce them when an agent runs. The distinction is between documenting a rule and making execution subject to it.

Four capabilities make the registry a control plane rather than a document store. Central identity binding ties agents to scoped user permissions, while a catalog records the agents and tools in use. Real-time policy enforcement governs invocation. Version tracking records the author and timestamp of each change, so teams can tell which instructions they are reviewing even as the prompt changes.

MCP makes this architecture concrete because an MCP server is a deployable unit of capability. The registry makes those units discoverable, reusable, and auditable. The server provides access to a capability. The registry governs how that capability is published and shared, and who may invoke it. That separation becomes more important as the protocol moves governance decisions into the surrounding infrastructure.

Why the 2026-07-28 MCP specification changes what the registry must do

The 2026-07-28 MCP specification replaces protocol-level session tracking with a stateless core. Each request includes protocol version, client identity, and capabilities in a _meta parameter, allowing it to reach any server instance behind a plain load balancer. Governance does not disappear with the session. The registry and gateway must support routing, authorization, and auditability without relying on the protocol to retain that state.

The specification also introduces Mcp-Method and Mcp-Name headers, allowing gateways and WAFs to act without parsing JSON bodies. For the team governing agents, that creates a practical place to apply routing, rate limits, and authorization decisions. Multi Round-Trip Requests, or MRTR, take the place of streams that previously had to stay open for server-to-client elicitation. The protocol now directly supports human approval as a first-class pattern. Meanwhile, cache hints and deterministic ordering let registries serve stable tool catalogs across reconnects without fetching upstream on every invocation.

The same specification formalizes an extensions framework that includes MCP Apps, Enterprise Managed Authorization, and Tasks. EMA gives organizations centralized control over which servers users may access, replacing per-server consent prompts with an identity-provider flow. Anthropic, Microsoft, and Okta adopted EMA at launch. The specification also deprecates Dynamic Client Registration in favor of Client ID Metadata Documents, so teams need a way to move their existing provisioning designs to the replacement. Its general feature lifecycle policy establishes a minimum twelve-month deprecation window, giving buyers a planning horizon for the change.

The security vulnerabilities that an ungoverned registry leaves open

MCP servers can hold credentials for more than one enterprise system. If a server is compromised, it can therefore expose more than one application and put credentials beyond that server at risk. Scope is the first line of containment. An enforced tool allowlist limits each agent’s available tools, while OAuth 2.1 identity binding lets it inherit scoped user permissions.

Data exfiltration exposes a different boundary. A public security advisory identified a link-unfurling vulnerability in Anthropic’s Slack MCP implementation. Slack’s native DLP inspects messages and files as posted, but does not see MCP tool calls. Message-level protection is therefore not enough on its own. A governed registry needs DLP enforcement at the tool-response layer, where that separate flow can be controlled.

Command injection and destructive actions require more than a catalog of approved servers. A centralized MCP gateway gives security teams one inventory, while per-agent allowlists constrain the tools an agent may invoke. Human approval provides another necessary boundary for irreversible actions such as database deletions and financial transactions. These controls serve different purposes.

What a production-grade registry must do — the evaluation criteria

The first buying requirement is automatic permission inheritance. An agent should access only what the requesting user is authorized to see in the source systems, with permissions synchronized across tools and deployments. A complete agent and tool inventory is equally foundational because unknown deployments cannot be governed centrally. Model quality cannot compensate for either omission.

The next requirement is versioned change history with authorship. Every edit to an instruction, prompt template, or tool configuration needs a record of who changed it and when. Published skills also need scoped access, with discovery and execution treated as separate permissions. For database deletions, financial transactions, and bulk record changes, the registry must also enforce human approval.

Portability comes after those core controls. Business logic defined once should work across Claude, ChatGPT, Cursor, and Slack without being redefined for each surface. The same MCP server specification should produce consistent behavior from Claude Desktop, Cursor, VS Code with GitHub Copilot, or Slack. Otherwise, teams that reuse the logic end up with competing versions of it. Model-agnostic deployment keeps business context and guardrails attached to the organization.

How Microsoft, AWS, and Salesforce have approached centralized agent registries

Microsoft Foundry’s Toolbox exposes tools through a single MCP-compatible endpoint and centralizes authentication, governance, and versioning. Observability is an Agent Service component separate from Toolbox. This distinction is useful during evaluation. A unified endpoint and a complete operational audit are related requirements, but one should not be mistaken for the other.

AWS launched Agent Registry through the Bedrock AgentCore console as a dedicated governance product, generally available across nine AWS regions. AWS describes its purpose in terms of missing visibility, weak governance, and duplicated tools across teams. Those are the same structural problems that undermine pilots. Its framing makes inventory and governance explicit product responsibilities.

Salesforce Hosted MCP Servers became generally available in April 2026 for Enterprise Edition and above, are meant for customers with Flex Credits, and may carry charges for server usage. Administrators authorize an AI client to work with an existing organization without buying a separate connector. Salesforce reported use at scale, with tens of millions of tool calls on Slack’s MCP server after its April 2026 launch.

Across the three approaches, the common pattern is centralized inventory, identity federation through EMA or an equivalent mechanism, and gateway-level routing. A central endpoint or an inventory on its own still leaves departments without a governed way to publish skills for other departments to use. A RevOps agent built in AWS still needs custom work before its skill can become something a support team discovers and reuses.

Department-specific registry deployments that show the reuse problem in practice

Department-level MCP deployments can deliver useful access without solving organization-wide reuse. Clari and Salesloft’s MCP server opens live revenue intelligence to AI tools, giving RevOps a department-specific capability. Engineering has a different starting point. GitHub MCP provides repository history, PR discussions, issues, and code search within the repositories and organizations available to the authenticated token. Paired with Sentry, it lets an agent read a bug report, find related files, inspect recent PRs, and propose a fix.

Intercom Fin AI Agent autonomously resolves more than half of customer support conversations for leading companies including Anthropic. The Intercom MCP server addresses another part of support work by making conversation data available to users with the appropriate Intercom permissions. Engineers can use Cursor or Claude Code to query conversation history and user data when diagnosing issues. That is useful access across departmental boundaries. It is not, by itself, a shared registry of the instructions and configurations that make the workflow useful.

The reuse gap sits above these connections. A RevOps team’s Clari skill, an engineering team’s GitHub stack configuration, and a support team’s Intercom integration remain separate deployments without a governed publishing layer. Another team may have permission to reach the same data but no way to discover and reuse the existing skill. As access spreads, teams end up with separate instructions and rebuild logic that already exists elsewhere.

What should enterprises look for in a governed AI agent skill registry?

The decisive test is whether one team’s work becomes a governed resource for another. A platform should let a team publish a skill with a version, owner, and access scope, then let an authorized team discover and reuse it without rebuilding the instructions. That goes beyond listing tools.

Permission inheritance must survive that handoff. Adding a team, agent, or chat surface should not require source-system permissions to be manually recreated. Scoped MCP endpoints should let each team use its approved capabilities through Claude, ChatGPT, Cursor, or Slack without building and maintaining a custom UI. Business context, permissions, and guardrails need to remain usable when the organization changes the LLM or surface through which a skill runs.

Auditability must also reach the action itself. An instruction’s edit history answers a different question from who approved an agent action and when. Buyers need both to hold people accountable within the organization and to meet the rules that apply, including EU AI Act requirements.

How to run a registry evaluation without letting the pilot become another governance gap

First, ask what access the agent inherits and from whom. That question needs an answer before a server is wired to an agent. The pilot should then test cross-team publishing and discovery using a department workflow with a natural reuse case, such as a RevOps skill that engineering or support could also use.

Approval must be in place before write access. The evaluation should test the gate on a destructive action, such as a database deletion or bulk CRM update. For any platform that still provisions agents through Dynamic Client Registration, a plan to migrate in line with the specification’s deprecation policy is also a condition for the evaluation.

Finally, the evaluation should score how well governance works separately from how many deployments there are. Running more agents shows adoption, while permission inheritance, reusable skills, approval enforcement, and auditability show whether the organization can control that adoption. A pilot can succeed at one and fail at the other. The registry is the condition under which the pilot is allowed to run.