Governed AI Registries for Shared Agent Skills
A governed registry is not a shared drive with a folder called "AI Skills." Shared drives have no version control, no access scoping, no ownership metadata, and no mechanism to block use of a stale or compromised version. They are passive storage. They intercept nothing.
A governed registry is also not an internal marketplace in the consumer sense. Browsing and installing are secondary concerns. The governance primitives that make installation safe are what actually matter, and framing this as a discoverability problem mislocates the value entirely.
What a registry actually provides is a single entry point where every AI asset, including MCP servers, agent skills, prompt templates, and multi-step workflows, is registered once before it can be used anywhere. Version control is embedded at that entry point: every change is tracked, consumers can pin to a specific version, and a bad update can be rolled back without hunting down every team that already adopted the skill. Ownership metadata is attached at registration, meaning each skill has a named owner responsible for its accuracy and upkeep. Access scoping is enforced at publication and consumption, not left to whoever happens to be clicking around. And every invocation is recorded, so there is a coherent answer to who ran this skill, against what data, and when.
The AWS MCP Gateway and Registry is a concrete reference implementation of this model: register a server or skill once, discover it through natural-language search, reach it through a single authenticated gateway that enforces access and records every call. One control plane, one access model, one audit trail. JFrog's AI Catalog positions its MCP Registry similarly, as a single system of record unifying custom and third-party MCP servers, agent skills, models, and binaries. The phrase "system of record" matters because it implies the registry is authoritative, not merely advisory.
A shared drive is pull-only and passive. A registry is active infrastructure that intercepts, authenticates, and logs every use.
How Fast MCP Adoption Has Outrun the Governance Organizations Put Around It
MCP server downloads grew from a relatively small base in November 2024 to many millions by April 2025, though the source of these figures should be verified before publication. Any procurement or security review process inherited from the SaaS era was structurally incapable of keeping pace with that trajectory.
The governance gap is documented in several industry reports. Ninety-one percent of organizations are already using AI agents; 44% have no governance framework at all, per Okta's AI at Work 2025 report. Only 10% have a well-developed strategy for managing non-human identities, which is the foundational requirement for governing agent access in the first place. Nearly two-thirds of organizations cite security and risk concerns as the primary barrier to scaling further.
The shadow MCP problem makes the gap tangible rather than statistical. In a typical 10,000-person organization, research from Clutch Security finds that roughly 15% of employees are running an average of two MCP servers each, producing an estimated 3,056 total deployments with no monitoring, no governance, and no connection to enterprise identity systems.
An agent can act. It can access databases, send emails, trigger workflows. It doesn't merely generate text. The surface area for harm is qualitatively larger, and it's expanding faster than the organizations sitting underneath it can track.
The Specific Risks That Emerge When Skills Are Shared Without a Registry
The security posture of the current MCP ecosystem presents significant documented vulnerabilities. Independent scans find that between 30% and 82% of public MCP servers carry exploitable flaws, though the range across sources is wide and the methodology varies. Only 8.5% use OAuth, meaning the vast majority have no standardized authentication at all.
The Wallarm 2026 API ThreatStats report catalogued 315 MCP-related vulnerabilities published in 2025. Sixty-five percent of assessed breaches originated from authentication issues: weak tokens, scope problems, reused credentials, no runtime enforcement. These are precisely the categories a registry's access control layer is designed to close.
The abstract risk has documented incidents behind it now. In September 2025, a backdoored MCP package distributed through an unvetted channel was confirmed as the first in-the-wild malicious MCP server, moving the threat from theoretical to active in a single disclosure. A November 2025 billing amplification incident cost $47,000 for a four-agent deployment, the result of runaway agent behavior with no circuit-breaker at the registry or gateway level. CVE-2025-49596, a vulnerability in Anthropic's own MCP Inspector, allowed browser-based attacks leading to remote code execution.
OWASP's MCP Top 10 has formalized the threat categories showing up in security audits: tool poisoning, where malicious instructions are hidden in tool metadata; schema poisoning; tool shadowing; command injection through unsanitized agent input; context oversharing across shared agent sessions. Every one of these is a registry-level control problem, not a model-level one. The model cannot inspect its own tool metadata for tampering. The registry gate can.
A 2026 survey of over 750 CIOs, CTOs, and engineering leaders conducted by Gravitee found that 47% of an estimated 3 million deployed AI agents are not actively monitored or secured, and 88% of those organizations had already experienced or suspected an agent-related security or data privacy incident in the prior twelve months. Cisco's State of AI Security 2026 found only 29% of organizations feel prepared to secure agentic AI at scale.
Sharing skills without a registry doesn't merely leave existing risk in place. It distributes that risk across every team that adopts the skill, because they inherit whatever vulnerabilities the original author introduced, with no visibility into what those vulnerabilities actually are.
The Four Controls a Registry Must Enforce to Make a Skill Trustworthy at Reuse
Version Control
A skill that worked correctly in January embeds stale context, broken tool references, or a deprecated API by March. This isn't hypothetical. It's what happens when an organization's tooling drifts and the skills built on top of it stay static. The gap between them compounds quietly until something breaks in production, usually at the worst possible moment.
Without versioning, every consumer of a skill is exposed to that drift with no warning and no rollback path. Version control at the registry layer means consumers can pin to a known-good version, maintainers can deprecate gracefully, and a bad update doesn't silently propagate to every team that adopted the skill. This is the first non-negotiable. Everything else in governance depends on knowing which version of something you're actually running.
Access Scoping Inherited from Source Systems
The most common governance failure looks like this: a new AI tool gets introduced, and administrators manually redefine who can see what, creating a second permissions layer that drifts from the source of truth over time. It's not negligence; it's an architectural inevitability when permissions aren't inherited from the systems that already define them.
A governed registry avoids this by inheriting permissions from the systems the skill touches. When someone invokes a skill, the response draws only from data that person already has access to. The MCP specification added OAuth 2.1 in June 2025 and enterprise IdP policy controls in November 2025 specifically to enable this pattern: sign in once to the MCP client, get access to every authorized server without re-authenticating per server. The permissions travel with the identity, and the registry enforces them.
Ownership Metadata as Accountability Infrastructure
Every skill in the registry needs a named owner, and not IT as a catch-all. The owner should be the domain expert or team who holds the business context the skill encodes. RevOps owns the deal-history skill. Engineering owns the deployment-status skill. Support owns the ticket-triage skill.
Ownership determines who approves updates, who gets notified of downstream breakage, and who is accountable when the skill produces incorrect output. This is what allows domain experts to encode their own context into agents without requiring central IT to intermediate every change. IT governs the infrastructure; the business owns the content. These are different jobs, and conflating them is where most centralized governance models collapse under their own weight.
A Complete Audit Trail at the Point of Invocation
Every tool call routed through the registry should be logged: which skill, which user or agent identity, which data sources were touched, what action was taken. This isn't primarily a compliance artifact. It's how organizations detect runaway behavior before it becomes a billing incident or a data leak. A policy document without a log to enforce it isn't governance; it's aspiration.
A fifth control deserves explicit mention: security scanning at registration time, not after deployment. The registry's gate function, reviewing a skill before it enters the shared catalog, is where tool poisoning, schema poisoning, and injected malicious instructions are caught. The AWS MCP Gateway and Registry applies access control and security scanning at registration time for exactly this reason. What's in the catalog has passed a check. It hasn't merely been submitted.
How the Department-Owns, Registry-Hosts Model Distributes Skill Creation Without Fragmenting Control
Centralized skill authorship breaks down in a predictable way. IT becomes the bottleneck for every domain-specific capability. The domain experts who hold the actual business context have no efficient path to encode it. The skills that do get built are generic and often wrong. Teams work around them, which is how you end up with multiple slightly different Salesforce summarization skills living in different Slack threads, none of them owned, none of them auditable.
Fully decentralized authorship without a registry breaks down in the opposite direction, but with the same result: more AI activity, less organizational control than you started with. No one knows which version is current. Permissions are configured differently in each copy. None of it is auditable.
The governed registry resolves this with a structural separation that sounds almost too simple once you see it. Each line of business develops the skills relevant to its function. When development is complete, the skill is hosted centrally through the registry and made accessible across lines of business. Department-owned, centrally governed. These two things are not in tension; they operate at different layers.
Operationally, it works like this. RevOps builds and owns the deal-history summarization skill. They encode their CRM field conventions, their pipeline stage logic, their data quality rules. They publish it to the registry once. The registry records the owner, the version, the access scope. Sales Ops discovers it through search, requests access, and inherits the same skill rather than rebuilding it from scratch. The domain knowledge RevOps embedded travels with the skill. If RevOps updates it to reflect a new pipeline stage, all consumers see the update through the version control mechanism. No one is silently running a stale copy.
Central IT's role in this model is infrastructure and governance, not content. They maintain the registry, enforce the registration gate, and ensure every skill routes through the authenticated gateway. They don't need to understand Salesforce pipeline logic to govern it. That's a feature of the model, not a workaround.
The scoped MCP server is what makes this practical at the deployment level. Each team's skills plug into any agent or chat surface, whether that's Claude, ChatGPT, Cursor, or Slack, without requiring a custom integration for each surface. The registry entry point is the consistent layer. The surface becomes irrelevant to the governance model, which is the point.
What Organizations Building Toward a Governed Registry Should Prioritize First
Start with inventory, not architecture. Before designing a registry, catalog what MCP servers and agent skills already exist in the organization. The Clutch Security research suggests the answer will be larger and more fragmented than most IT leaders expect.
Establish the gateway before expanding the catalog. Routing all agent connections through a governed gateway, even a minimal one, immediately closes the visibility gap that enables shadow AI. Discoverability and skill-sharing can follow once there is a control plane. Building a catalog before establishing the gateway gives you a well-organized list of things you still cannot monitor.
Authentication is the first technical priority. The MCP specification now supports OAuth 2.1, enterprise IdP policy controls, and OAuth client credentials for machine-to-machine flows. Only 8.5% of current MCP servers actually use OAuth, per available scan data. Connecting the registry to existing enterprise identity infrastructure, through SSO, OIDC, or SAML, means permissions are inherited rather than manually redefined, which eliminates a primary source of drift before it compounds.
Name owners before publishing skills. The registry's ownership metadata is only as useful as the organizational commitment behind it. Each skill needs a team responsible for its accuracy, not just a submitter. If ownership isn't established at publication, it won't be retrofitted later.
Enforce versioning from the first publication. Retrofitting version control onto skills that have already propagated across teams is substantially harder than enforcing it at the registration gate. Every skill published without a version is a future incident waiting to be investigated with no rollback path available. The time to establish versioning discipline is before the catalog grows, not after the fourth team has adopted a skill you can no longer trace.
The organizations that get this right won't necessarily have the most sophisticated agents. They'll have agents other teams can actually trust, and in a landscape where ungoverned proliferation is the default, that distinction matters.
