What is the difference between an MCP catalog and an MCP proxy in enterprise governance?

An MCP catalog is the approved list of servers users can choose from, while an MCP proxy is the control point that filters, secures, and records the traffic between clients and those servers. The catalog governs availability and trust. The proxy governs enforcement, inspection, and audit. Used together, they separate discovery from control.

Why an MCP Catalog Is Not an MCP Proxy

An enterprise MCP catalog and an MCP proxy solve different governance problems. The catalog is about sanctioned choice: it tells users and agents which servers are approved, discoverable, and suitable for use. The proxy is about execution control: it sits in the request path to enforce policy, inspect traffic, and preserve evidence. That distinction matters because governance fails when discovery and enforcement are treated as the same control.

In practice, a catalog can reduce shadow adoption, but it cannot stop a risky request once an approved server is selected. A proxy can block or transform traffic, but it cannot make an unsafe service trustworthy simply because it is reachable. If a team only curates a catalog, it still lacks runtime protection; if it only deploys a proxy, it still lacks a governed source of truth for what should be available. The best enterprise patterns pair both, and the proxy policy should be derived from the catalog, not loosely inferred from whatever happens to be exposed. For broader governance context, the NIST Cybersecurity Framework 2.0 is useful when you want to separate asset governance from protective enforcement.

One useful way to think about the split is that the catalog governs the allowed surface area, while the proxy governs the live behaviour of that surface area.

How the Two Controls Work Together in Practice

In enterprise use, the catalog is usually the reference layer for approved MCP servers, ownership, descriptions, business purpose, and sometimes minimum trust requirements. It helps answer who may select a server and under what declared conditions. The proxy then becomes the technical control plane for what actually happens when a client calls that server. It can validate destination, constrain methods, redact or inspect payloads, attach identity context, and record the interaction for review.

That design is especially important when MCP is used by autonomous or semi-autonomous clients, because approval at selection time does not guarantee that every downstream request is safe. A proxy can enforce real-time policy against unexpected tool calls, sensitive parameter values, or disallowed destinations. A catalog cannot do that on its own because it is not in the request path.

The catalog answers: “Is this server allowed to be discovered and chosen?”
The proxy answers: “Is this specific interaction allowed to proceed right now?”
The catalog supports governance and user choice; the proxy supports enforcement and auditability.
Together, they reduce the chance that approval becomes a false sense of control.

For practitioner depth on MCP-specific exposure patterns, NHIMG’s State of MCP Server Security 2025 is especially relevant because it shows how often MCP deployments still lack basic scoping and secret discipline. OWASP’s OWASP Agentic AI Top 10 is also useful when the question extends to autonomous clients making tool calls under changing context.

This model breaks down when organisations expose the proxy as a thin pass-through with no meaningful inspection, or when the catalog becomes stale and no longer reflects the actual servers, permissions, or trust assumptions in use.

Where Governance Usually Goes Wrong

Tighter catalog controls often improve discoverability and policy consistency, but they also create a tradeoff: if the catalog is treated as the whole control, teams may overestimate their protection and underinvest in runtime enforcement. That is a governance weakness, not just an administrative one. A catalog can be accurate and still leave dangerous traffic completely visible only after the fact.

Two edge cases matter. First, if the proxy is doing all the real work, the catalog may devolve into documentation and lose its value as an approval boundary. Second, if the proxy is overly permissive, teams may rely on catalog approval as a proxy for trust, even though approval says nothing about the safety of every method, payload, or downstream dependency. Current guidance suggests treating the catalog as a curated allowlist and the proxy as the place where least privilege is actually enforced.

NHIMG’s Top 10 NHI Issues is relevant here because the same failure pattern appears in machine and workload governance: visibility without enforcement, or enforcement without authoritative inventory, creates gaps that are easy to miss until misuse or sprawl is already entrenched.

Practitioners should also be careful not to confuse audit logs with control. Logging helps reconstruction, but it does not prevent an unsafe tool invocation. These controls tend to break down when the catalog is managed separately from the proxy policy engine, because drift between the two creates approval without enforcement or enforcement without clear approval.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Catalog and proxy split is a governance and control-boundary issue.
	PR.AA-01 — Identity and Access Management	Proxy enforcement depends on controlling who and what can invoke servers.
	DE.CM-01 — Continuous Monitoring	Proxy inspection and logging support ongoing visibility into MCP traffic.
Recommendation — Align catalog and proxy ownership to a formal risk management strategy. Enforce access decisions at runtime for approved MCP interactions. Monitor MCP requests continuously and retain evidence of blocked or allowed actions.
CIS Controls v8	6 — Access Control Management	The proxy enforces who can reach which MCP services and actions.
	8 — Audit Log Management	A proxy is valuable because it can capture auditable interaction records.
	15 — Service Provider Management	The catalog formalises which external or internal MCP services are approved.
Recommendation — Restrict MCP access paths to approved users, clients, and servers. Log MCP traffic with enough context to support investigation and review. Vet MCP providers before adding them to the approved catalog.
NIST Zero Trust (SP 800-207)	SC-1 — Policy Enforcement Point	An MCP proxy acts as the enforcement point for live request decisions.
	PA-1 — Policy Engine	Catalog-approved servers should feed policy decisions consistently.
Recommendation — Place policy enforcement in the MCP request path, not only in discovery. Drive MCP proxy rules from a central policy source of truth.
MITRE ATT&CK	T1195 — Supply Chain Compromise	An ungoverned MCP server can become a trusted dependency with hidden risk.
Recommendation — Map trusted MCP servers to supply-chain risk and monitor for tampering.

Practitioner Guidance

What to prioritise: Build the catalog as the source of approved MCP services, then require the proxy to consume that approval state so the policy boundary is consistent. If the two are owned by different teams, define which one is authoritative for server admission, because split authority is where drift appears first.

What to verify: Confirm that the proxy is enforcing more than destination filtering. It should also be able to observe request context, block disallowed methods or scopes, and generate evidence that can be traced back to the selected catalog entry. If it cannot do those things, it is not acting as a real control point.

What practitioners underestimate: The catalog is often treated as “governance,” but the real risk is assuming approval equals safety. The stronger pattern is catalog for admission, proxy for live enforcement, with change control linking the two so an approved server cannot silently gain broader access later.

Practitioner takeaway: Treat the catalog as the decision about what may be chosen, and the proxy as the decision about what may actually happen; enterprise governance is strongest when those are intentionally separate but continuously reconciled.