TL;DR: MCP server adoption creates a governance gap when tools are discovered through scattered URLs, public catalogs, and chat threads, because there is no authoritative source for approval status or access scope, according to Stacklok. The security issue is not discovery alone but whether registry filtering and claims-based authorization happen at the API layer, where AI agents inherit the same controls as users.
At a glance
What this is: This how-to shows that MCP server governance starts with an authoritative registry, not a shared list, and that API-layer claims filtering is the key control for user-specific tool access.
Why it matters: It matters because IAM teams need a way to govern which MCP tools humans and AI agents can discover, which requires access control at the registry layer rather than relying on UI visibility alone.
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
👉 Read Stacklok's how-to on MCP server governance and claims-based access
Context
MCP server governance fails when discovery is treated as a convenience problem instead of an identity and access problem. In practice, teams end up with URLs in wikis, docs, and chat threads, while no authoritative catalog records which servers exist, who approved them, or which identities are allowed to use them.
That gap matters for MCP server governance because AI agents inherit the same discovery paths as the people they assist. If the access decision happens only in the UI, an agent can still reach tools through the API path, which means the real control point has to sit where the tool request is evaluated.
For practitioners building NHI governance, the question is not whether a server is visible but whether its visibility, source, and entitlement are all governed together. That is the difference between inventory and control.
Key questions
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.
Q: Why do MCP tools create a governance problem for IAM teams?
A: MCP turns each tool into a potential permission boundary, which means IAM teams must govern many small access decisions instead of one broad application login. If those boundaries are not scoped carefully, autonomous agents can accumulate effective privilege faster than traditional reviews can catch.
Q: What breaks when MCP tools are filtered only in the user interface?
A: The control breaks as soon as an AI agent or API client can still reach the underlying endpoint. UI filtering hides tools from people, but it does not stop machine-readable access paths. Real governance requires the registry to decide what each authenticated identity can see before any tool data leaves the server.
Q: What frameworks help with MCP server governance and least privilege?
A: Use NIST Cybersecurity Framework 2.0 for access governance, OWASP NHI guidance for non-human identities, and OIDC-backed claims for source-level authorization. Those controls help teams separate inventory from entitlement and keep agentic workflows inside the same policy boundary as human users.
Technical breakdown
Why a shared MCP server list is not governance
A shared list of MCP servers is only a directory. Governance requires a source of truth that tracks approval status, source provenance, and who can reach which tool under which identity. In MCP environments, discovery happens across Git repositories, upstream registries, and Kubernetes resources, so a static list quickly drifts out of sync with reality. The problem is compounded when the same server appears in multiple places with different labels or trust levels.
Practical implication: treat discovery inventory as a governed registry with source attribution and approval state, not as a manually curated document.
How claims-based authorization changes MCP server access
Claims-based authorization ties tool visibility to identity attributes such as group membership, so the catalog becomes personalised rather than universal. The registry checks JWT claims on each request and only returns sources that match the caller, which means access decisions are enforced before tool details are exposed. That matters because MCP servers can aggregate multiple source types into one API, and each source can carry its own claims block. The control is identity-aware, not presentation-aware.
Practical implication: require source-level authorization logic in the registry itself so entitlement filtering is enforced consistently for every caller.
Why API-layer filtering matters for AI agents
AI agents follow the same machine-readable paths as users, but they may invoke tools without the same human hesitation or contextual judgement. If a tool is only hidden in a UI, the agent can still discover it through the API and attempt to use it. API-layer filtering closes that gap because the server returns only what the authenticated identity can see. This is particularly important in agentic workflows where the tool catalogue itself becomes an attack surface.
Practical implication: place access enforcement at the registry API so agentic workflows cannot bypass the same entitlement checks applied to human users.
NHI Mgmt Group analysis
MCP governance fails when discovery is treated as a navigation problem instead of an identity problem. A URL list, public catalog, or wiki page can tell users where a server lives, but it cannot tell the enterprise whether that server is approved, current, or in scope for a given identity. That leaves platform teams with inventory, not control. The practitioner conclusion is that MCP governance must start with authoritative registry ownership.
API-layer authorization is the real control plane for MCP tool exposure. If entitlements are enforced only in the user interface, the same tools remain reachable through machine-readable API paths, including by AI agents acting on behalf of users. That means hidden tools are not governed tools. The practitioner conclusion is that registry filtering must occur before tool metadata leaves the server.
Claims-based cataloging is a practical expression of least privilege for NHI and human identities alike. Group-based visibility creates separate catalog views without multiplying infrastructure, which is the right direction for mixed human and machine access patterns. The same entitlement model can support shared tools, role-specific tools, and restricted operational tooling. The practitioner conclusion is to map registry claims to existing identity groups rather than inventing a parallel authorization model.
Tool discovery is becoming part of the identity attack surface. In MCP environments, the ability to find a tool can be enough to make it reachable, especially when agents are capable of chaining tool use on behalf of a user. That shifts governance from catalog hygiene to access enforcement and auditability. The practitioner conclusion is that discovery, entitlement, and logging need to be managed as one control surface.
Authoritative MCP inventory is the named concept that explains the governance gap here. The enterprise needs a single, current source that binds server existence, approval status, source type, and entitlement policy together. Without it, every downstream review becomes partial and every access decision becomes harder to defend. The practitioner conclusion is to build governance around authoritative inventory rather than scattered reference lists.
From our research:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security's The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to Astrix Security's The State of MCP Server Security 2025.
- For a deeper governance lens, see Top 10 NHI Issues for the control failures that repeatedly show up in machine identity estates.
What this signals
Authoritative registry control is now a practical requirement for MCP adoption. Once discovery spans Git, upstream registries, and Kubernetes-native resources, governance can no longer depend on manual curation or local team memory. Teams that already use NHI Lifecycle Management Guide patterns for provisioning and offboarding should extend the same discipline to server visibility and approval state.
The broader shift is that catalog governance and identity governance are merging. With 96% of technology professionals identifying AI agents as a growing security threat in AI Agents: The New Attack Surface, the registry becomes part of the control boundary, not a convenience layer. Practitioners should expect tool discovery, entitlement checks, and audit trails to be evaluated together.
Claims-based cataloging: this is the practical pattern for separating shared tools from role-specific tools without fragmenting infrastructure. Teams that align registry claims with OIDC group membership and existing access review processes will find it easier to defend who could discover what, and why.
For practitioners
- Build an authoritative MCP registry Centralise server discovery in a governed registry that records source type, approval status, and entitlement scope instead of relying on shared URLs or informal catalogs.
- Enforce access at the API layer Apply authorization before tool metadata is returned so AI agents and users receive the same entitlement decisions from the registry endpoint.
- Map registry claims to identity groups Bind source visibility to existing IdP group claims so shared, engineering, and finance tools are separated without creating a second identity system.
- Track Kubernetes-native MCP resources as governed inventory Require opt-in annotations and periodic sync for MCPServer, MCPRemoteProxy, and VirtualMCPServer resources so cluster-hosted tools stay visible to governance workflows.
Key takeaways
- MCP governance fails when discovery is unmanaged, because an inventory of URLs is not the same as an authoritative access model.
- The access decision has to happen at the registry API, or AI agents can bypass UI-only controls and reach tools that were meant to stay hidden.
- Claims-based authorization turns a shared MCP catalog into a least-privilege control point that IAM and NHI teams can actually govern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP registry exposure and access scoping map to non-human identity governance. |
| NIST CSF 2.0 | PR.AC-4 | The post centers on least-privilege access to tools and identities. |
| NIST Zero Trust (SP 800-207) | Section 4.2 | API-layer filtering reflects zero-trust evaluation of each request. |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement and source-level authorization are central to the design. |
Apply NHI governance to registry sources and require approval-aware visibility for every MCP server.
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- 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.
- Authoritative inventory: An authoritative inventory is the trusted source of record for identities, assets, and entitlements that a security programme uses to make access decisions. For Zero Trust, it must be current enough to support policy enforcement, recertification, and incident investigation without relying on stale assumptions.
What's in the full article
Stacklok's full how-to covers the operational detail this post intentionally leaves for the source:
- Step-by-step MCPRegistry deployment on Kubernetes, including the operator, resource definition, and sync setup.
- Full config examples for Git, upstream API, and Kubernetes discovery sources with filter logic and annotations.
- OAuth and OIDC configuration details for per-user catalog views and role-based source visibility.
- Live demo flow showing how the registry behaves before and after claims-based authorization is enabled.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
