MCP management needs governance, access control, and ownership

At a glance

What this is: This is a governance analysis of MCP management, showing that the hard part is not building servers but controlling access, discovery, auditability, and ownership as adoption spreads.

Why it matters: For IAM, IGA, PAM, and security teams, MCP turns AI-to-tool connectivity into an identity and governance problem that needs central control before informal adoption hardens into shadow infrastructure.

Context

Model Context Protocol is a standard way for AI clients to connect to tools and data sources through servers that expose actions to the client. In identity terms, that creates a governance surface for delegated access, token handling, and tool-level authorisation, not just a software integration layer.

The article's central point is that MCP adoption tends to spread faster than the surrounding controls. Once multiple teams build their own servers, organisations inherit duplicated OAuth handling, uneven visibility, weak ownership, and inconsistent policy enforcement across a growing non-human access estate.

That makes MCP management a lifecycle and governance issue as much as a platform issue. The reader is being asked to think less about how to build a server and more about how to discover, approve, monitor, and retire them in an enterprise setting.

Key questions

Q: What breaks when MCP servers run locally without governance?

A: Local MCP servers inherit workstation privileges, which means they can read plaintext secrets, access user-scoped tools, and operate without a central approval point. That breaks the assumption that credential use is limited to known services. The practical result is hidden NHI sprawl, with no reliable inventory or review path for the identities doing the work.

Q: Why do remote MCP servers need role-based access control?

A: RBAC is necessary because authenticated users do not all need the same tool power. MCP servers often expose a mix of low-risk and high-risk actions, and a single identity may be legitimate for one but dangerous for another. Role-based restrictions keep sensitive commands, such as installation or environment-changing tools, limited to users with explicit authority.

Q: How do teams know whether MCP controls are actually working?

A: Teams know MCP controls are working when every tool invocation can be traced to a verified identity, a policy decision, and a recorded approval state where required. If logs cannot answer who asked, what was allowed, and why the call ran, then the controls are not governing the workflow. They are only documenting its existence.

Q: What happens when an MCP credential is compromised?

A: Without centralized revocation, a compromised credential can leave multiple servers exposed and difficult to contain. A managed MCP setup should make token invalidation immediate, visible, and tied to the identity that owns the access, not to each server individually.

Technical breakdown

Why MCP server sprawl becomes a governance problem

MCP servers are easy to create, but each one introduces a separate control surface for delegated access, token storage, and tool exposure. The problem is not the protocol itself. It is that every additional server creates another place where OAuth flow handling, access scope, and operational ownership can drift away from central policy. In practice, that turns a simple integration layer into distributed identity infrastructure. Once developers deploy servers informally, IT inherits a population of shadow services that may work well individually but do not share a common governance model.

Practical implication: treat every new MCP server as an access-bearing service that needs inventory, approval, and lifecycle ownership from day one.

How OAuth handling changes inside MCP environments

MCP implementations commonly rely on OAuth for delegated access, which means callback URLs, token refresh, and secure token storage become part of the server design. If those controls are repeated inside each server, the organisation ends up with fragmented credential handling and inconsistent revocation behaviour. A central token broker changes the pattern by keeping raw credentials away from individual servers and making refresh and revocation governable in one place. That matters because tool access in MCP is not just authentication, it is continued delegated authority that must remain auditable and revocable.

Practical implication: centralise token issuance and revocation so MCP servers never become independent credential stores.

Why discovery and tool-level access control matter for AI clients

MCP is not only about machine connectivity. It also creates an employee experience problem because users need to find the right server, understand what tools it exposes, and know what they are allowed to use. Without a curated catalog and role-based access control, discovery happens through informal channels and access decisions become inconsistent. When AI clients can invoke tools on behalf of users, audit logging becomes essential to show who called what, when, and with what result. This is where MCP shifts from developer convenience to enterprise governance.

Practical implication: pair a searchable catalog with role-based access controls and audit logs before broadening MCP adoption.

Threat narrative

Attacker objective: The practical objective is not a single exploit but uncontrolled access and unmanaged trust across AI-connected tools and data sources.

1. Entry occurs when teams create MCP servers quickly and share them informally, often before IT has visibility into what is running or who owns it.
2. Credential exposure and delegated access drift follow when OAuth handling, token refresh, and storage are duplicated across many servers instead of governed centrally.
3. Impact shows up as governance debt, because organisations lose reliable visibility, revocation, and accountability across an expanding tool-access layer.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP management is an identity governance problem before it is a platform problem: Once MCP servers proliferate across teams, the real risk is not whether the SDK works but whether access, ownership, and revocation remain controllable. The article shows that organisations quickly accumulate duplicate OAuth handling, weak visibility, and unclear service ownership. The practitioner conclusion is that MCP needs the same lifecycle discipline as any other access-bearing infrastructure.

Ephemeral experimentation creates permanent governance debt: MCP adoption often starts informally, with developers building and sharing servers faster than IT can inventory them. That assumption was designed for small-scale trials, not for enterprise rollout. It fails when informal use becomes production dependency and nobody can reliably answer who owns a server, who can use it, or how it is removed. The implication is that discovery and stewardship must be designed as core controls, not retrofitted later.

Centralised OAuth handling is the control boundary that matters most: The article's architecture argument points to a simple truth: if raw credentials sit inside individual servers, the organisation loses revocation consistency and audit fidelity. That makes credential handling the decisive governance layer, not an implementation detail. Practitioners should treat token custody as a platform boundary and not as a per-server engineering choice.

Tool-level authorisation defines the real blast radius: An MCP server that exposes too much to too many users turns AI clients into high-speed amplifiers of overbroad access. Role-based access mapped to existing identity groups is therefore not just convenient, it is the mechanism that keeps tool access aligned to business need. The practitioner conclusion is to govern at the tool and server level together, not separately.

Shadow MCP adoption will be the default failure mode unless ownership is explicit: The article's maturity model makes clear that most organisations are still between ad hoc experimentation and managed pilot. That means the dominant risk is unmanaged sprawl, not sophisticated attack chains. The practitioner implication is to establish ownership, auditability, and support paths before adoption scales beyond the team that built the first server.

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.
• Read next: MCP Security Guide

What this signals

Governance debt is the real scaling limit for MCP: Teams can build an MCP server quickly, but they cannot sustainably run dozens of them without central discovery, ownership, and revocation. That is why the management conversation starts looking like IAM and IGA rather than pure engineering. The control question becomes who can see, approve, and retire each server as adoption spreads.

MCP reuses familiar identity problems in a new place: The protocol does not eliminate OAuth, access scope, audit logging, or support ownership. It relocates them into a high-velocity AI tooling layer where informal deployment habits can outpace policy. Practitioners should expect the same failure patterns seen in API sprawl and microservice sprawl, then govern MCP accordingly.

For practitioners

• Inventory all MCP servers Map every MCP server already running, identify its owner, and record what data and tools it can reach. Shadow deployments are the starting point for governance debt, so the inventory must cover informal and local installs as well as approved production services.
• Centralise OAuth token handling Move callback handling, refresh logic, and token storage into a controlled broker so individual servers do not manage raw credentials. This reduces duplication and makes revocation and monitoring consistent across the environment.
• Apply role-based access to tool exposure Tie server and tool access to existing identity groups so users only see the MCP functions their role allows. That keeps marketing, engineering, and operations access boundaries aligned with the rest of the identity programme.
• Stand up a curated discovery catalog Give employees a browsable registry of approved MCP servers with clear descriptions, access filters, and support paths. Discovery by ticket or word of mouth creates friction and pushes users back to unmanaged workarounds.
• Require audit logging and revocation paths Log who called which tool, when they called it, and what happened, then make revocation immediate when a credential is compromised or a user leaves. Without that evidence chain, MCP becomes difficult to govern at scale.

Key takeaways

• MCP is easy to deploy, but unmanaged servers quickly create governance debt across access, discovery, and ownership.
• Centralised OAuth handling, role-based access control, and audit logging are the controls that turn MCP into governable enterprise infrastructure.
• If employees cannot reliably find, use, and support MCP servers through an approved process, adoption will drift into shadow infrastructure.

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.
• MCP governance: MCP governance is the set of policies, controls, and oversight used to manage how AI agents use the Model Context Protocol to reach tools and data. It defines approved connections, authentication, authorization, logging, data handling, and change control so agent actions remain traceable, bounded, and aligned with security and compliance requirements.
• Token Broker: A token broker is a service that issues, refreshes, or mediates access tokens on behalf of an application. It simplifies implementation, but it also becomes part of the trust chain, so organisations must define ownership, logging, renewal policy, and revocation responsibilities.
• Curated Package Catalog: A curated package catalog is a controlled source of dependencies that have been reviewed, built, and maintained under defined security and quality rules. It reduces reliance on public registries alone and gives developers or agents a governed place to request components that have already passed upstream checks.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.