Enterprise AI Skill Catalogue Tools With Role-Based Access Control Compared

A governed AI agent skill registry for enterprises must control both who publishes skills and who can run them. This comparison covers Salesforce Agentforce, Microsoft Copilot Studio and Foundry, CData Connect AI, and governed gateway architectures. The deciding factor is not skill breadth but whether source permissions, scoped access, and audit trails remain enforceable across teams and AI clients.

Why the governance gap in AI skill catalogues is a structural problem, not a configuration one

Enterprise adoption of AI skill catalogues has moved faster than governance. The underlying protocol connects agents to tools, but it does not supply a complete access-control model. Model Context Protocol, or MCP, defines how those systems communicate without deciding who may call each tool, under what conditions, or on whose behalf. Authentication is optional in the base protocol. A catalogue built on it therefore inherits no access control by default.

That gap changes what a buyer must evaluate. A feature checklist can show that a catalogue connects to business systems, but not whether it limits access to those systems correctly. Every governance layer must be added deliberately by the platform or the enterprise. Without enforced role scoping, company-wide skill exposure also expands the reach of a misconfigured agent. Connectivity is not permission to act.

This is why “the catalogue has admin roles” is an incomplete answer. Those roles may limit who runs the platform while leaving application code to decide which tool calls to allow. The buyer must evaluate the architecture as well as the settings. If the catalogue does not enforce access control, every application that uses it must do so. The integration boundary needs the same scrutiny as any API boundary.

What MCP is and why it has become the substrate most enterprise skill catalogues are built on

Anthropic open-sourced MCP in November 2024 to give AI clients a consistent way to communicate with tool-providing servers. Developers can use one protocol to connect clients and servers that work with it, instead of building a separate connector for each model and business system. That reduces the custom integration burden. It also makes the protocol’s design choices consequential for every catalogue built on it.

Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation in December 2025, placing it under neutral stewardship. The foundation was co-founded by Anthropic, Block, and OpenAI, while the Linux Foundation also supports Kubernetes, PyTorch, and Node.js. That institutional shift reduced single-vendor risk. It did not, however, turn shared infrastructure into a complete enterprise governance product.

The 2026-07-28 MCP specification changed the protocol from bidirectional and stateful to stateless request/response, allowing any request to reach any server instance behind a standard load balancer without maintaining persistent sessions. The same release hardened authorization through RFC 9207 issuer validation and the formal deprecation of Dynamic Client Registration in favor of Client ID Metadata Documents, added header-based routing, and included Enterprise Managed Authorization, already stable since June 18, 2026, in its formal extensions framework.

These changes make infrastructure-level enforcement more practical at scale. Gateways can use the Mcp-Method and Mcp-Name headers to identify individual tool calls without parsing JSON bodies. Authorization can therefore move out of application-specific logic and into shared infrastructure. But the protocol only enables that arrangement. A catalogue still needs an actual policy and a place that enforces it.

What RBAC actually means in the context of a skill catalogue — and what it does not mean

Role-based access control has two distinct layers here. Admin RBAC governs who operates the platform, including who can create API keys, publish a skill, view audit logs, or change guardrails. Runtime access control governs who can call that skill when an agent is working. It covers agents, applications, and employees, together with their identities and constraints.

The distinction is concrete in a CRM skill. An administrator may be allowed to publish the skill without giving every employee the right to read every CRM record. At runtime, results should inherit the requesting user’s existing CRM access rather than depend on a separate copy of those permissions in the AI layer. Inheritance avoids a second permission system drifting from the first. It is a different capability from assigning catalogue administrators.

Agents also need identities of their own. Each needs a defined role, explicit permissions, and technical limits that restrict it to the tasks it must perform. Broad system access for convenience defeats that boundary. The audit trail must then connect the agent, the skill, the arguments, the person it acted for, and the time of the call.

SOC 2 Type II addresses access accountability through CC6 and monitoring through CC7.2, rather than prescribing one universal agent-log format. NIST AI RMF offers guidance that is voluntary, including its Govern function, and does not require logging artifacts. Logs of what administrators did cannot, on their own, show how agents used skills. Runtime evidence is a separate requirement in the evaluation.

The governance architecture Pinterest built — and what it shows about the minimum viable controls

Pinterest’s March 2026 production MCP deployment separates tools by domain. It runs servers for Presto, Spark, Airflow, and general-purpose knowledge. A central registry handles server discovery. Skills are therefore inventoried and searchable.

Pinterest also requires every server to pass security and legal/privacy reviews before it goes into production, along with a generative AI compliance review when that applies. At the other end of the workflow, high-risk operations require human approval. Together, these controls establish a supply-side gate for what enters production and a demand-side gate for what can happen during use.

The later MCP specification supports this kind of approval through Multi Round-Trip Requests, or MRTR. A server can return “input_required” and pause for confirmation before completing a destructive action. That mechanism leaves open how Pinterest set up its earlier deployment. It shows how the protocol now supports the same class of control.

Pinterest is a reference point. Its deployment makes the minimum control surface concrete, including domain scoping, central discovery, review before release, and approval during risky operations. Most vendors claim to offer controls of this kind. The comparison turns on whether those controls are built into the enforcement architecture or depend on separate configuration around each use.

What tools exist for enterprise AI skill catalogues with role-based access control?

Salesforce Agentforce, with the Agentforce 3 governance layer, is strongest where skills use Salesforce’s existing data-access controls. Its Einstein Trust Layer is integrated at that layer, so MCP skill exposure inherits platform-level controls rather than relying only on a catalogue administrator’s settings. Salesforce executives cited substantial MCP activity after Headless 360’s April 2026 launch and millions of weekly tool calls on Slack’s MCP server. The deployment evidence goes beyond pilots. The boundary is external systems, where coverage depends on how each system’s MCP server is configured.

Microsoft Copilot Studio supports building, testing, and publishing MCP connectors. Microsoft corporate VP Tina Schuchman’s July 2026 release statement described Foundry using MCP to scale “from dozens of integrations to thousands”. Cross-surface governance still needs separate attention, however, because GitHub Enterprise controls do not automatically extend to ChatGPT, Claude Desktop, or Cursor. Support for connectors alone does not show that permissions carry over to those clients or that audits cover them.

CData Connect AI takes a data-gateway approach. CData’s 2026 MCP guide describes servers built on vendor platform APIs as the mechanism for limiting agents to data they are authorized to use. Governance sits at the data-source layer, while a single gateway centralizes governance and auditability across connections. This reduces the per-connection configuration burden. Its primary focus is data connectivity and governance.

A governed MCP gateway paired with a private registry offers a different choice. The Bifrost, ToolHive, and JFrog Artifactory pattern combines upstream curation and provenance with runtime enforcement. The official MCP Registry, Artifactory, or Stacklok ToolHive can serve upstream roles, while the runtime catalogue enforces per-tool RBAC, rate limits, PII redaction, secrets filtering, and immutable audit logging. The strength is infrastructure-enforced separation between approved supply and permitted use, while the cost is integrating and operating multiple tools.

An inherited-permission registry is also an architectural model rather than a single named product in this comparison. It combines automatically synced source permissions with a versioned registry, ownership records, and scoped MCP servers provisioned per team without a UI requirement for building or maintaining them. It can also support chains of specialized agents with auditable version control. Its central promise is policy portability across Claude, ChatGPT, Cursor, and Slack, without redefining access in each client. That promise requires permissions stored as registry metadata to be enforced along the whole path.

The options answer different enterprise needs. Salesforce brings integrated controls within its ecosystem, Microsoft supplies connector-building and integration surfaces, and CData concentrates on governed data access. Gateway and registry patterns separate the control layers more explicitly but introduce assembly work. None of those descriptions proves every governance capability by itself. The right comparison follows the enterprise’s identity infrastructure, agent surfaces, and preference for a single-vendor product or a composed architecture.

The evaluation criteria that separate a governed catalogue from a liability at scale

For procurement teams and architects, the comparison becomes six questions to ask every vendor. The first is whether permissions are inherited automatically from connected systems or redefined in the AI layer whenever tools or users change. Redefinition creates maintenance work and drift risk. The useful distinction is not whether permissions exist, but where their authority comes from. A second copy is not the source of truth.

The second question concerns the registry itself. Does it record who owns each skill, support version control and rollback, and provision skills by role, or is it mainly a shared place to publish them? Provenance needs more than a descriptive label. Vulnerability scanning and signed provenance help check the supply chain, while context-layer integration links skills to a governed source of metadata. These controls establish what is being shared, where it came from, and how changes are managed.

Third, buyers must check whether publication has an enforced review gate. Pinterest provides a concrete reference through security, legal/privacy, and applicable generative AI compliance review before production. Self-service publication is not the same control. Evaluation gating needs to happen before a skill becomes available for production use, rather than remain a policy that publishers are expected to remember.

Fourth, buyers must check for immutable runtime audit records. Can the system show which agent called which skill, with what arguments, on whose behalf, and when? The relevant evidence must support access accountability and monitoring, with compliance assessed against the applicable requirements rather than a broad claim that logging makes the product compliant.

Fifth, buyers must check whether risky actions have native approval gates. Database deletions, bulk record changes, financial transactions, and outbound data transfers need checks that go beyond who can find the skill. MRTR provides a protocol mechanism for pausing a call. The vendor’s answer should distinguish support in the platform from approval logic left for application developers to build.

Can the governance system find MCP-connected local applications and allow or block them across the fleet? Claude Desktop or Cursor can get around catalogue controls when they run outside the governed gateway. Across all six questions, runtime integration with the existing identity provider is structurally sounder than requiring a parallel access-control model.

Why governance architecture — not skill breadth — is what determines whether a catalogue scales across teams

Skill duplication is often a symptom of permissions that cannot travel. When a team cannot safely share a skill because access controls are fragmented or audit trails are incomplete, another team rebuilds it under its own controls. The enterprise pays again for something it can already do. That helps explain why identity management, auditability, and gaps in access control can hold up pilots even when teams already have skills they can use.

The official MCP Registry has accumulated thousands of registered servers, and community directories index more. Supply is not the central constraint here. Enterprise Managed Authorization points toward setting up identity once at the identity provider so that authorization reaches approved servers without each app having to negotiate OAuth. That direction addresses the organizational obstacle behind fragmented catalogues.

For teams evaluating platforms, the decisive question is therefore practical. When legal publishes a skill, can sales use it with the right permissions, a full audit trail, and no access-control redefinition, or must it rebuild the skill? The same test holds when teams share agent prompts. Central publication is only the beginning. A governed registry turns individual skill-building into institutional capability by making reuse safe beyond the team that created it.