Notifications
Clear all
Topic starter
18/08/2026 2:52 pm
TL;DR: Hand-written Cedar policies work for a few MCP servers, but they become an audit, onboarding, and privilege-management bottleneck as fleets grow, according to Stacklok. The governance assumption that per-server access can stay manually curated does not survive enterprise-scale MCP adoption.
NHIMG editorial — based on content published by Stacklok: MCP access governance starts with RBAC
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.
Questions worth separating out
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.
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.
Q: What do security teams get wrong about role-based access for MCP?
A: They often assume that coarse roles alone solve the problem.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Stacklok's analysis of RBAC for ToolHive MCP access governance →
MCP server RBAC: is your access model ready for scale?
Explore further
18/08/2026 3:36 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP access governance needs RBAC before server sprawl starts
