The Model Context Protocol (MCP) has become the dominant integration layer connecting AI agents to enterprise tools, APIs, and data. And without governance controls, it is also the dominant unmanaged attack surface. Every MCP connection is a potential supply chain risk.
On 15 April 2026, JFrog launched the industry’s first enterprise-grade MCP registry. That launch signals that agentic AI governance has moved from a security recommendation to a purchasable product category. On the same day, OX Security disclosed a “by-design” architectural flaw in MCP’s STDIO transport layer — making the timing pointed and commercially significant.
In this article we look at what the JFrog Universal MCP Registry actually does, compare it with TrueFoundry‘s MCP Gateway Registry and Kiteworks‘ Secure MCP Server, and give you a framework for choosing between them. This guide is part of our comprehensive MCP security supply chain overview, where we explore the full range of threats and mitigations facing enterprise AI deployments.
What Is the JFrog Universal MCP Registry and What Problem Does It Solve?
The JFrog Universal MCP Registry is a centralised control plane that treats MCP servers as managed software artefacts. Think of it as giving your MCP servers the same inventory, signing, scanning, and policy-gate treatment that code packages already get in JFrog Artifactory.
In unmanaged MCP deployments, AI agents freely discover and execute any server they can reach — no verification, no version locking, no policy check before execution. The shadow MCP governance gap — where 70% MCP integration with near-zero governance is the norm — means most organisations have no inventory of what is actually running. CrowdStrike‘s research identifies three attack classes that exploit exactly this gap:
- Tool poisoning: an attacker publishes an MCP server with malicious instructions embedded in its tool descriptions; static analysis tools miss it because the vulnerability lives in the LLM’s reasoning layer, not in source code
- Tool shadowing: a rogue server shapes how the agent uses a completely separate, legitimate tool — because all tool descriptions are simultaneously visible to the LLM
- Rugpull: a trusted server’s behaviour changes silently after deployment. In September 2025, an unofficial Postmark MCP server with 1,500 weekly downloads was modified to BCC all outgoing emails to an attacker’s address
JFrog frames all of this as agentic software supply chain failure — the same category of risk that conventional software supply chain attacks exploit, now applied to the AI tool layer. The registry launched GA on 15 April 2026, sitting within the JFrog AI Catalog alongside the JFrog Agent Skills Registry (currently in beta).
💡 Agentic software supply chain: JFrog’s term for the full chain of artefacts, models, MCP servers, and agent skills that AI agents consume and produce — analogous to the software supply chain for traditional code, but applied to AI agent tooling.
One distinction worth flagging: “MCP registry” (JFrog’s product) and “MCP gateway” (a routing and policy-enforcement layer) describe different architectural components. JFrog separates them; some competitors combine them. That distinction matters when you get to the evaluation section.
What Are the Four Core Capabilities of the JFrog MCP Registry?
The JFrog MCP Registry organises its governance into four functional areas, each closing a specific gap in unmanaged MCP deployments.
1. Server inventory and unified control plane
A unified catalogue of every approved MCP server in the organisation, with versioning and provenance metadata. Platform teams get clear visibility into exactly what agent tool connections exist, who approved them, and when.
2. Cryptographic signing and version pinning
MCP servers are signed at upload; any modification is detectable before execution. This directly mitigates tool poisoning — signature verification fails if tool descriptions have been altered — and tool shadowing, because a rogue server fails signature verification. Version pinning locks agents to specific approved versions, so a changed server requires a new approval cycle. CrowdStrike recommends both as baseline controls.
3. Vulnerability scanning via JFrog Xray
The same scanning engine that inspects containers and packages in Artifactory now applies to MCP servers, checking for CVEs, malicious payloads, and compliance violations. Servers that fail the policy gate are blocked before any agent connection is attempted.
4. Access-control policy enforcement via JFrog AppTrust
Policy gates determine which agents and developers can discover and execute which servers. AppTrust supports Policy-as-Code: custom governance rules expressed as OPA/Rego code that physically block non-compliant artefact versions. Compliance evidence is immutable and version-controlled.
💡 Policy-as-Code (PaC): Expressing governance rules as machine-readable code that can be version-controlled and automatically enforced — rather than as manual checklists or configuration settings.
Why Do the JFrog Cursor and NVIDIA Integrations Matter for Platform Teams?
JFrog has a verified plugin on the Cursor Marketplace. Developer MCP connections routed through Cursor are automatically checked against the registry before execution — developers never interact directly with unapproved servers. VS Code and Claude Code are also listed integration targets, giving governance coverage across the three most widely used AI-native development environments.
The NVIDIA partnership, announced at GTC in March 2026, positions JFrog Artifactory as the system of record for NVIDIA NemoClaw and the NVIDIA AI-Q Blueprint — NVIDIA’s reference architecture for enterprise agentic deployments.
💡 NVIDIA NemoClaw: NVIDIA’s open-source runtime for building and deploying autonomous, long-running AI agents; it sandboxes each agent in an isolated virtual environment for safe execution.
For organisations already on the NVIDIA AI stack, governance is layered on top of an existing investment rather than requiring a whole new platform adoption.
What Is the TrueFoundry MCP Gateway Registry and How Does It Differ from JFrog?
TrueFoundry MCP Gateway Registry combines gateway and registry in a single platform deployed inside your own VPC — AWS, GCP, or Azure. Tool traffic, credentials, and discovery requests never leave your network.
That in-VPC deployment is TrueFoundry’s primary differentiator. And it either is or is not a requirement for your organisation. For healthcare, finance, and government organisations with data residency requirements under HIPAA, GDPR, or national data sovereignty regulations, a SaaS-hosted registry simply can’t satisfy those requirements. TrueFoundry’s in-VPC model does.
The other distinguishing capabilities:
- RBAC at the tool-visibility level: agents cannot discover tools they’re not permitted to use — not merely blocked from executing them
- Centralised credential vaulting: API keys and OAuth tokens stored in a managed vault, injected at runtime; agents never handle raw credentials
- On-Behalf-Of (OBO) authentication: agent tool calls reflect the actual human user’s identity and permissions, not a generic service account — which limits blast radius if the agent is compromised
- Pre- and post-call guardrails: tool calls validated against defined schemas before execution and inspected afterward
JFrog separates the registry from the gateway; TrueFoundry combines both in a single in-VPC deployment. Simpler stack, fewer integration points — but you’re tied to TrueFoundry’s deployment model.
TrueFoundry’s Pro tier is $499/month — unusually transparent pricing for enterprise MCP tooling. Enterprise pricing is on request.
What Is the Kiteworks Secure MCP Server and When Is Data-Layer Governance the Right Choice?
Kiteworks Secure MCP Server enforces governance at the data-access layer. Every AI data request is independently authenticated and authorised at the point where the agent actually accesses data — regardless of which MCP server initiated the request.
Here’s the important distinction. A registry controls which servers are approved before execution. Kiteworks controls what data those approved servers can actually access during execution. These are complementary, not competing concerns.
Every operation is evaluated in real time against the Kiteworks Data Policy Engine, applying both RBAC and ABAC.
💡 Attribute-Based Access Control (ABAC): Access policy evaluated dynamically at runtime based on context — who is requesting, what data, at what time, under what conditions — rather than on predefined roles alone.
Every tool-call event is logged in real time and streamed to your SIEM, satisfying HIPAA, GDPR, SOC 2, and FedRAMP requirements natively. The Kiteworks AI Data Gateway extends this to RAG pipelines — organisations using retrieval-augmented generation face the same governance gap in their data-query layer, and conventional registry controls don’t reach it.
How Do You Evaluate MCP Governance Tooling? An Evaluation Framework
Start with your organisational context, not the feature lists. These three tools serve genuinely different needs.
Scenario 1 — Startup or SMB (no regulatory mandate, speed is the priority)
JFrog’s Cursor and VS Code integrations give you governance without standing up additional infrastructure. If you’re already on Artifactory, the MCP Registry is a natural extension with no new toolchain required.
Scenario 2 — Enterprise with existing JFrog or Artifactory investment
JFrog MCP Registry is the natural extension of what you already have. Supply chain provenance, Policy-as-Code gates, and Xray scanning integrate with infrastructure already in place. The NVIDIA partnership matters if you’re evaluating NemoClaw-powered deployments.
Scenario 3 — Regulated enterprise (healthcare, finance, government) with data-residency requirements
TrueFoundry’s in-VPC deployment satisfies data sovereignty requirements that a SaaS registry cannot. Combine with Kiteworks for the data-access audit trail if HIPAA, GDPR, or FedRAMP compliance requires tamper-evident logs of every AI data interaction.
Scenario 4 — Organisation with large-scale RAG or data-pipeline usage
Kiteworks AI Data Gateway is the only solution here that governs at the data-access layer. Evaluate it regardless of which registry you choose — the registry governs which servers are approved; Kiteworks governs what those approved servers can actually retrieve.
A quick reference across scenarios:
JFrog MCP Registry — SaaS; OPA/Rego policy gates; immutable policy log; best fit for existing JFrog/Artifactory users and NVIDIA AI-Q deployments. Pricing not publicly documented; contact JFrog.
TrueFoundry MCP Gateway — In-VPC; OBO authentication, credential vault, Okta/Azure AD; RBAC at tool-visibility level; best fit for regulated industries with data residency requirements. Pro tier $499/month.
Kiteworks Secure MCP Server — SaaS plus data gateway; RBAC and ABAC at the data layer; real-time SIEM streaming; HIPAA, GDPR, SOC 2, FedRAMP natively; best fit for RAG pipelines and compliance-heavy sectors.
One baseline to verify with any vendor: mutual TLS (mTLS). CrowdStrike recommends it for all agent-server communication.
💡 Mutual TLS (mTLS): Both sides of a connection — agent and MCP server — must present verified certificates before data is exchanged. Prevents a rogue server from impersonating a legitimate one at the network layer.
What Does a Registry Actually Address — and What Doesn’t It Fix?
A registry addresses the pre-execution layer: which servers are approved, signed, scanned, and version-pinned before any agent reaches them. That is valuable and necessary. It is not complete.
What a registry addresses:
- Tool poisoning and tool shadowing: signing detects modified or substituted servers before execution
- Rugpull: version pinning prevents silent updates to a changed server
- Ungoverned discovery: policy gates block agents from unapproved servers
What a registry does not address:
The architectural flaw that registries address is distinct from what they cannot fix. The MCP by-design flaw disclosed by OX Security operates at the runtime protocol layer — allowing arbitrary command execution across Python, TypeScript, Java, and Rust implementations. Anthropic’s response: the behaviour is by design; no patch will be issued.
A registry-approved server can still be the pivot point. Once compromised, it can reach every connected resource the agent touches. GTG-1002 — the Chinese state-sponsored threat actor Anthropic attributed to a November 2025 campaign using Claude Code and MCP tools — demonstrated this at scale across approximately 30 organisations. A registry would have provided pre-execution vetting; it would not have contained a pivoting agent at runtime.
Disabling STDIO transport in favour of HTTP-based SSE is a separate protocol-level action. A registry does not enforce transport protocols. Both controls are complementary; neither alone is a complete remediation.
Data-layer governance fills the remaining gap: Kiteworks authenticates, authorises, and audits every AI data request at the access point — where prompts cannot override safety. For the full analysis of why patching won’t close the STDIO gap, see that article.
Frequently Asked Questions
What is the JFrog Universal MCP Registry?
A centralised control plane treating MCP servers as managed software artefacts — providing inventory, cryptographic signing, vulnerability scanning, and access-control policy enforcement for enterprise AI deployments. Launched GA on 15 April 2026 as part of the JFrog AI Catalog.
Is the JFrog MCP Registry open source?
No. It is a commercial product. The enterprise governance capabilities — OPA/Rego policy gates, AppTrust integration, immutable compliance records — are commercial features. Contact JFrog directly for current pricing.
Does a registry replace the need to disable STDIO transport?
No. A registry enforces pre-execution governance — which servers are approved before any agent connects. Disabling STDIO is a protocol-level change that addresses the by-design architectural flaw. Both controls are complementary; neither alone is complete.
Does TrueFoundry’s MCP Gateway Registry work with all MCP clients?
TrueFoundry implements the MCP protocol, so any compliant client can connect. The constraint is network-layer — the client must be able to reach the VPC endpoint. Verify specific client compatibility with TrueFoundry directly.
What is the JFrog Agent Skills Registry and how does it differ from the MCP Registry?
The MCP Registry governs MCP server connections — which tools and APIs agents can reach. The Agent Skills Registry (currently in beta) governs executable agent skills and binary assets, not connections. Together they form JFrog’s full agentic governance stack. NVIDIA NemoClaw integrates with the Agent Skills Registry as its system of record.
What is TrueFoundry in-VPC deployment and why does it matter?
The entire TrueFoundry registry runs inside your own cloud account — AWS, GCP, or Azure — so tool traffic, credentials, and discovery requests never reach TrueFoundry’s infrastructure. That is the decisive factor for organisations with data residency requirements under HIPAA, GDPR, or national sovereignty regulations.
What attack classes does a signed manifest protect against?
Primarily tool poisoning and tool shadowing. A signed manifest detects modified server descriptions or substituted servers before execution. Rugpull is addressed by version pinning: agents are locked to the specific signed version, and a changed server requires a new approval cycle.
What is the “agentic software supply chain” and why does JFrog use this term?
It’s JFrog’s framing for the full chain of artefacts, models, MCP servers, and agent skills that AI agents consume and produce. It positions MCP servers as managed software artefacts requiring supply chain governance — making the registry a natural extension of existing DevSecOps practice rather than a new product category.
What is data-layer governance and when is it required?
It’s enforcement at the point where agents access data — independent of which server initiated the request. It’s required when compliance frameworks mandate tamper-evident logs, sensitive data stores connect via RAG pipelines, or zero-trust enforcement is required regardless of which tool makes the request.
What does mutual TLS (mTLS) provide in an MCP deployment?
Both the AI agent and the MCP server authenticate each other at the transport layer before data is exchanged. Combined with registry-level cryptographic signing, mTLS provides defence-in-depth across transport and application layers. CrowdStrike recommends it as a baseline for enterprise MCP deployments.
What is the GTG-1002 threat and what does it demonstrate about MCP security?
GTG-1002 is a Chinese state-sponsored threat actor attributed by Anthropic to a November 2025 campaign — the first confirmed nation-state weaponisation of MCP at scale, targeting roughly 30 organisations. It demonstrates that an attacker who compromises or impersonates an MCP server can direct autonomous agents to execute full intrusion lifecycles at machine speed.
For implementation guidance after selecting a governance tool, see our An MCP Security Playbook for Surviving the Next Vulnerability Disclosure. For the foundational architectural analysis, see our MCP security supply chain overview.
