MCP server governance starts with discovery and claims-based access

At a glance

What this is: This is a how-to post on MCP server governance that argues discovery alone is not enough, because approval status and access scope must be enforced through claims-based authorization.

Why it matters: It matters because IAM teams now have to govern MCP tool catalogs for people and AI agents together, and UI filtering without API-layer enforcement leaves the actual access problem untouched.

Context

MCP server governance starts with a basic identity problem: if no authoritative source tells you which servers exist, who approved them, and who may use them, the catalog itself becomes the risk surface. In practice, discovery through docs, chat, or public listings creates ambiguity about sanctioned tools and makes access decisions impossible to audit consistently.

The article frames this as a governance gap for MCP adoption, not a tooling preference issue. For IAM and platform teams, the question is whether the registry is merely a convenience layer or the control plane for approving, filtering, and authorising tool access for both users and the agents acting on their behalf.

Key questions

Q: How should teams govern MCP servers once they are discovered?

A: Classify recurring MCP servers as managed access objects, not personal tooling. Put approved servers behind a shared control point, assign ownership, restrict who can use them, and remove direct local registrations that cannot be reviewed or logged. That approach keeps productivity while restoring observable access governance.

Q: Why does hidden UI filtering not solve MCP access risk?

A: Because access can still be exercised through the API even when a server is hidden in the interface. If the registry does not evaluate claims on every request, users or agents may still reach tools outside their intended scope. The enforcement point has to be the protocol layer, not the screen.

Q: What breaks when MCP servers are approved once but allowed to change later?

A: The original approval no longer describes the current access surface. If tools, backends, or ownership change after onboarding, the enterprise is operating on stale risk information. That creates blind spots in authorization, logging, and recertification, because the governing record reflects a past state rather than the server’s present capabilities.

Q: How do AI agents change the way MCP catalog access should be controlled?

A: AI agents inherit the same catalog visibility as the user or service identity acting on their behalf, so any weakness in registry filtering also becomes an agent access problem. Teams should govern the catalog as an authorization surface, because discoverable tools are available to both humans and agents unless the API blocks them.

Technical breakdown

Why scattered MCP discovery breaks governance

MCP discovery is often informal by design: a server appears in a chat thread, a wiki entry, or a public catalog, and that is enough to make it usable. That model does not preserve approval state, ownership, or role scope, so it cannot answer the core governance questions a platform team needs to manage. When the same server can appear under different names or live in multiple places, the organization loses a canonical inventory and cannot reason about exposure. In identity terms, discovery becomes the front door, but the door has no policy attached to it.

Practical implication: Treat MCP discovery as an inventory and approval problem, not a documentation problem.

How claims-based authorization changes the registry model

Claims-based authorization moves the decision from a shared catalog view to a user-specific view based on identity claims in the token. The registry validates JWTs on each request and filters sources and registry entries according to roles or group claims, so different users receive different catalogs from the same backend. That is a material shift for governance because access is decided at retrieval time, not by hoping the UI hides sensitive tools. The same logic also applies to AI agents acting for a user, because if the API filters the response, the agent inherits that boundary.

Practical implication: Enforce access decisions at the registry API, not in the presentation layer.

Why Kubernetes-native sources still need explicit access control

Discovery through Kubernetes annotations and source aggregation makes onboarding easier, but it does not by itself establish who should see a server or why. A resource can be opt-in for registry exposure and still require group-based claims before it appears in a user’s catalog. That distinction matters because automated registration reduces manual work without replacing governance. The architecture is therefore a two-step model: advertise the source, then authorise its visibility. Without the second step, the registry is only a searchable list, not a governed catalogue.

Practical implication: Separate registry exposure from registry visibility in your control design.

NHI Mgmt Group analysis

Discovery without authorization is not governance: a shared MCP URL list can tell users what exists, but it cannot prove who approved it or who may invoke it. That makes discovery a visibility layer, not a control layer, and the difference matters because a tool that is merely discoverable is functionally reachable. The implication is that MCP programmes need a canonical access decision point, not a better directory.

API-layer filtering is the real enforcement boundary for MCP: UI-based hiding only changes what people can see, not what the protocol can return to a client or agent. Once the registry evaluates claims on every request, the catalog becomes personalized by identity rather than shared by convenience. Practitioners should treat the registry API as the governance boundary, because that is where tool exposure is actually decided.

Claims-based cataloging aligns MCP with existing IAM patterns: group claims, token validation, and role-scoped visibility are familiar identity controls, but they now govern tool discovery as well as tool use. That matters because MCP collapses the distance between “listing a tool” and “authorizing a tool” if the registry is not carefully designed. The control question is no longer whether the server can aggregate sources, but whether the aggregation is still policy-aware at the point of access.

Agentic workflows make catalog governance stricter, not looser: an AI agent that can browse the same registry as a user inherits the user’s visible toolset unless the API narrows it first. That means the catalog is no longer just an operational convenience for humans; it is a policy artifact that can expand or constrain machine action. The practitioner takeaway is to govern MCP catalogs as part of identity authorization, not as an adjacent developer experience.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: MCP Security Guide

What this signals

Catalog governance is now an identity problem: as MCP adoption spreads, the main failure mode is not lack of tooling but lack of a single authoritative decision point for discovery and access. If server visibility is determined by scattered documents, then governance never has a stable inventory to certify, review, or revoke.

API-layer control is the only boundary that survives agentic workflows: once AI agents can consume the same registry as users, any control that lives only in the UI is bypassed by design. The practical implication is that identity claims, not catalog aesthetics, must decide which tools exist for each caller.

MCP registry exposure should be treated like access governance, not publishing: publishing a server to a registry is only the first step. The real control is whether the registry evaluates group and role claims before a source is visible, because that is what keeps shared catalogs from becoming shared blast radius.

For practitioners

• Define a canonical MCP inventory Consolidate approved server sources into one registry-backed list so teams stop relying on scattered URLs, wiki pages, and chat threads for tool discovery.
• Enforce claims-based visibility at the API Validate identity tokens on each registry request and filter tool exposure by role or group claims before any catalog data is returned.
• Separate discovery from authorization decisions Allow servers to be discoverable only after they are explicitly tagged for registry exposure, then gate their visibility with source-level claims.
• Model AI agents as catalog consumers Assume agents will inherit whatever the registry returns to the user, then test whether the visible catalog matches the permitted operational scope.

Key takeaways

• MCP governance fails when discovery is scattered and no authoritative source records approval and access scope.
• Claims-based authorization at the registry API is the control that turns a shared catalog into a governed one.
• AI agents inherit catalog visibility, so registry filtering has to be enforced before the tool is exposed, not after.

Key terms

• Claim-Based Authorization: Claim-based authorization is access control that evaluates token claims such as issuer, audience, subject, repository, or environment before granting access. It is stronger than static client registration because the policy can tie access to the actual operating context of the caller.
• Mcp Registry: An MCP Registry is a catalog that lists available Model Context Protocol servers, tools, and resources for AI agents to discover and use. It typically stores metadata such as endpoints, capabilities, ownership, and trust information, helping organizations govern which tools agents can access and how those connections are managed.
• Catalog Exposure: Catalog exposure is the set of tools or services made visible through a registry or discovery layer. In identity governance, visibility matters because anything discoverable may become reachable unless the underlying API also enforces authorization boundaries.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.