TL;DR: MCP adoption is real, but the protocol is silent on identity, policy, lifecycle, and audit, leaving governance to the surrounding identity stack, according to ConductorOne. The missing layer is not another proxy, but entitlement-aware control that can evaluate who or what is calling tools, under what authority, and with what traceability.
NHIMG editorial — based on content published by ConductorOne: What MCP doesn't include: governance
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.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern MCP tool access in enterprise environments?
A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools.
Q: Why do MCP gateways fail as a complete governance model?
A: MCP gateways fail as a complete governance model because they only see the request in transit, not the broader authority behind it.
Q: What breaks when AI-connected workflows rely on stored secrets?
A: Stored secrets create brittle governance because rotation, revocation, and attribution become harder once long-lived credentials are embedded in workflows.
Practitioner guidance
- Map MCP tool calls to enterprise identities Require every tool invocation to resolve to a human, workload, or agent identity in the enterprise identity graph before policy enforcement.
- Use federated, short-lived credentials for AI workflows Replace embedded secrets with OIDC-based workload federation so each workflow run receives a scoped token with explicit trust conditions and revocation boundaries.
- Tie access decisions to lifecycle events Connect approval, recertification, and offboarding to the same identity records used for MCP-connected tools so gateway policy can inherit authoritative state rather than guess.
What's in the full article
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- How its identity-aware MCP gateway is intended to evaluate tool calls against enterprise identity context
- How workload federation uses OIDC tokens, CEL conditions, and scoped access tokens in practice
- How hosted, custom, and on-prem MCP deployment patterns change governance and data placement
- How the access model is intended to extend existing human identity governance to AI agents and workflows
👉 Read ConductorOne's analysis of what MCP leaves out of governance →
MCP governance is missing identity controls, not more protocol?
Explore further
MCP governance failure is an identity problem, not a protocol problem. MCP defines how clients and tools exchange messages, but it does not define who is entitled to invoke which capability, on whose behalf, or under what lifecycle rules. That leaves enterprises with a transport layer that is visible and a governance layer that is fragmented. The consequence is that access policy gets displaced into proxies and gateways that cannot see the full identity surface. The practitioner takeaway is to locate governance in the identity system, not the protocol edge.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who should own MCP governance, identity teams or platform teams?
A: MCP governance should be shared, but the identity team must own entitlement, lifecycle, and audit state while the platform team owns request mediation. If one team tries to own both, organisations usually end up with a proxy that filters traffic but does not govern access.
👉 Read our full editorial: MCP needs identity governance, not just a gateway