MCP access governance needs RBAC before server sprawl starts

At a glance

What this is: This is Stacklok’s argument that MCP access control should move from hand-written per-server policies to role-based governance before server sprawl makes audits and onboarding unmanageable.

Why it matters: It matters because MCP servers are NHI-adjacent control points that can quietly accumulate standing privilege unless IAM, IGA, and platform teams standardise how roles, bindings, and denies are governed.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Stacklok's analysis of RBAC for ToolHive MCP access governance

Context

MCP access governance breaks down when every server carries its own hand-written policy and nobody can explain who is allowed to call which tools. In practical identity terms, that creates a non-human identity control problem, not a configuration convenience problem, because the authorization surface expands faster than teams can review it.

Stacklok’s point is that per-server policies do not scale once MCP usage moves from a few pilots to a real enterprise fleet. That is the same pattern identity teams have seen with service accounts, cloud roles, and privileged access: the governance model that works for one system becomes brittle when multiplied across many systems.

The real issue is not Cedar itself. The issue is the operating model around it, including role design, group binding, and exception handling. Without those controls, MCP access becomes a manual entitlement exercise that platform teams inherit long before security and audit teams are ready to trust it.

Key questions

Q: How should teams govern MCP server access as their fleet grows?

A: Start by moving away from per-server handwritten policies and toward named roles, IdP group bindings, and a separate narrowing layer for sensitive servers. That structure keeps tool access auditable, reduces drift, and prevents every new server from becoming a custom authorization project. Governance becomes scalable when access is expressed in reusable policy objects, not isolated files.

Q: Why do per-server MCP policies break down in enterprise environments?

A: They break down because each new server adds another entitlement surface, another review cycle, and another opportunity for inconsistent rules. What looks manageable in a pilot becomes an audit and onboarding bottleneck once multiple teams, auditors, and platform owners all need the same access answer. The failure is structural, not just operational.

Q: What do security teams get wrong about role-based access for MCP?

A: They often assume that coarse roles alone solve the problem. In practice, roles must be paired with server-specific restrictions and explicit deny rules, otherwise broad grants can still expose destructive tools. The important decision is not whether to use RBAC, but how to narrow it where tool risk is highest.

Q: Who should own MCP access decisions: the IdP team or the platform team?

A: The IdP team should own identity groups, while the platform team should own tool-level roles and server restrictions. That division keeps organisational identity separate from operational capability and avoids turning every MCP change into an identity platform dependency. The right model is shared governance with clear ownership boundaries.

Technical breakdown

Why per-server MCP policies become unmanageable

MCP server authorization often starts with direct policy statements that name individual tools, prompts, and resources. That is manageable when the environment has one or two servers, but it scales poorly because each new server adds another policy object, another review surface, and another place for drift. The result is not just more work. It is inconsistent entitlement logic across similar systems, which makes audit evidence hard to assemble and privilege decisions hard to compare.

Practical implication: replace one-off server policies with a governance layer that standardises entitlement logic before the fleet grows.

How RBAC changes ToolHive authorization

Role-based access control shifts the unit of governance from individual requests to named capability bundles. In ToolHive’s model, roles can represent patterns such as reader or writer, while bindings map IdP groups to those roles. That lets identity governance stay anchored in group membership and avoids encoding tool-specific access into the IdP itself. The important technical point is separation of concerns: the identity provider asserts who the person is, while the MCP layer determines what that identity may do.

Practical implication: keep IdP groups coarse and push tool-level authorisation into a separate policy layer that your platform team can manage.

Why deny rules matter more than broad grants

MCP environments need more than allow lists because some actions are too risky to inherit through role membership. Deny rules create a hard stop that overrides broader role grants and policy narrowing, which is critical when a tool can delete repositories, transfer assets, or modify production data. Without explicit denial semantics, a writer role can become an accidental super-user pattern once server scope expands or role reuse spreads across teams.

Practical implication: define explicit deny boundaries for destructive MCP tools and test them separately from role grants.

NHI Mgmt Group analysis

Per-server MCP authorization is already a governance debt pattern: Stacklok’s model reflects a broader truth about NHI control surfaces. When every server needs its own handwritten policy, the organisation has not solved authorization, it has distributed exception handling. That works for pilots and fails for fleets. The practitioner conclusion is that MCP access governance must be designed as a lifecycle problem, not a per-server configuration task.

Role abstraction is the only scalable bridge between identity governance and tool governance: Keeping roles outside the IdP is not a cosmetic design choice, it is a boundary that prevents identity sprawl from becoming access sprawl. IdP groups describe organisational affiliation, while MCP roles describe operational capability. That separation aligns with NIST CSF access governance principles and avoids turning every tool change into an identity-team ticket.

Policy narrowing is where enterprise MCP governance becomes real: Broad roles are useful only if server-specific authorization policies can reduce their scope without rewriting the identity model. The moment teams need to block destructive tools, narrow a role to read-only actions, or protect production servers differently, governance shifts from assignment to constraint. Practitioners should treat that narrowing layer as the real control plane, not the role name itself.

Named concept: MCP policy drift debt: This is the accumulation of small, manually maintained per-server authorization differences that no one can safely compare or audit at scale. It appears first as convenience, then as inconsistency, and finally as a privilege review failure. The practitioner conclusion is that any MCP rollout without a standard role and binding model will inherit policy drift as a structural feature, not an edge case.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly unmanaged MCP estates accumulate credential risk.
• For a broader control baseline, see Top 10 NHI Issues for the governance patterns that stop secret sprawl before it starts.

What this signals

MCP policy drift debt: once access logic is hand-written per server, the governance problem becomes cumulative and difficult to reverse. Teams should expect audit effort, exception handling, and role review work to grow faster than the fleet itself unless they move to standardised role binding and narrowing patterns.

The immediate programme signal is that MCP belongs in the same governance conversation as service accounts, workload identity, and privileged access. If your IAM, IGA, and platform teams are not jointly defining entitlement patterns now, they will end up reconciling them later under audit pressure, which is always more expensive.

The stronger operating model is to align MCP controls with the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 so the access layer is designed before scale arrives. That gives security teams a framework for role design, exceptions, and evidence collection that can survive fleet growth.

For practitioners

• Standardise MCP roles before server count grows Define a small, named set of roles for common MCP access patterns, then bind them to IdP groups rather than individual users. Keep tool-level decisions out of group design so the identity team is not reworked for every new server.
• Use server-specific policy narrowing for exceptions Apply a separate authorization layer to restrict broad roles on sensitive servers, especially where destructive tools or production resources are involved. Review those restrictions as part of change management, not as ad hoc exceptions.
• Create explicit deny boundaries for high-risk tools Block actions such as deletes, transfers, and force-push style operations with rules that override inherited role grants. Test those denies independently so you can prove they survive role reuse across teams.
• Treat MCP access review as an audit query problem Make role bindings and policy narrowing queryable so security and audit teams can answer who can do what without reconstructing handwritten files. If you cannot produce that answer quickly, the model is already too manual.

Key takeaways

• MCP authorization fails at scale when every server depends on hand-written policies that no one can compare or trust.
• RBAC helps only when it is paired with server-level narrowing and explicit deny rules for destructive tools.
• The governance problem is not just access control, it is preventing MCP policy drift from becoming a permanent audit burden.

Key terms

• Mcp Authorization Orchestration: The control layer that manages what happens between an MCP authorization request and token issuance. It can route tenants, enforce step-up checks, shape consent, and enrich claims so the resulting token carries the right context for downstream access decisions.
• Role Binding: A role binding connects an identity source such as an IdP group to a named access role. It lets organisations keep identity and capability separate, so changes in team membership can update MCP access without rewriting individual tool rules or manual user entitlements.
• Scope drift: Scope drift is the gradual mismatch between what an integration was meant to do and what its credentials still allow it to do. It happens when permissions are not revalidated as business needs change, creating hidden over-privilege across SaaS and API-connected systems.
• Deny Rule: A deny rule is an explicit prohibition that overrides broader grants and prevents a specific action or tool call. It is especially important in MCP governance because broad roles can otherwise expose destructive operations through accidental inheritance or overly wide scope.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact Cedar policy and manifest structure used to express roles, bindings, and server-level restrictions.
• The end-to-end request flow from IdP login through role resolution to final authorization decision.
• Examples of how platform teams translate writer and reader patterns into deployable ToolHive manifests.
• The practical differences between broad roles and server-specific rule restrictions in a live MCP fleet.

👉 Stacklok's full post covers the role manifests, binding examples, and request flow in detail.

Deepen your knowledge

NHI governance, workload identity security, and secrets management 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 or platform security programme, it is worth exploring.