MCP needs identity governance, not just a gateway

At a glance

What this is: This analysis argues that MCP solves tool connectivity but leaves identity governance undefined, so enforcement must come from the surrounding IAM and lifecycle controls.

Why it matters: It matters because IAM teams need to govern humans, workloads, and AI agents through the same identity fabric rather than treating MCP gateways as a complete control plane.

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.

👉 Read ConductorOne's analysis of what MCP leaves out of governance

Context

Model Context Protocol connects AI clients to tools, but MCP itself does not decide who may call which tool, when, or under what policy. That omission matters for identity governance because the protocol can move work, while the enterprise still has to control authority, entitlement scope, and auditability across humans, machines, and AI agents.

The gap is especially visible when teams treat a gateway as governance. A proxy can stop a tool call, but it cannot on its own verify whether the requester is entitled elsewhere in the identity graph, whether the credential has been rotated, or whether approval already happened in another workflow. For NHI practitioners, this is a familiar pattern: transport control is not lifecycle control.

Key questions

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. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

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. They cannot verify whether the caller is entitled elsewhere, whether a credential has been revoked, or whether the access aligns with the organisation’s lifecycle and audit requirements.

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. That problem is especially acute for AI-connected systems, where access may be distributed across tools and runs instead of tied to one stable operator.

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.

Technical breakdown

Why MCP gateways are not identity governance

An MCP gateway is an enforcement point in front of tool traffic. It can terminate requests, log activity, and apply policy at the edge, but it does not natively know the caller’s enterprise role, the downstream resource owner, or the lifecycle state of the credential being used. That means it can mediate a session without governing the identity behind it. In practice, the protocol layer describes transport and tool invocation, while identity infrastructure must supply authorization context, entitlement mapping, and audit lineage.

Practical implication: Treat the gateway as one control point, not the governance layer.

Policy decisions need identity context, not just request context

Tool calls in MCP are only safe when policy can evaluate more than the request itself. A call to grant access in Salesforce, for example, must be checked against the requester’s role, department, risk posture, and whether a human approval already ran. Without that context, policy becomes request filtering rather than governance. This is where unified identity data becomes essential, because the control must understand the requester, the asset, and the business rule at the same time.

Practical implication: Bind MCP policy decisions to the enterprise identity graph before allowing production use.

Workload federation reduces stored secret exposure

The article’s strongest operational point is that MCP governance gets better when teams stop relying on long-lived stored secrets. Workload federation exchanges an existing OIDC token for a scoped access token on each workflow run, so the identity used by the agent or pipeline is short-lived and policy-bound. That pattern narrows secret exposure and makes tool access easier to trace. It also aligns machine and agent access with the same lifecycle discipline used for human access, which is where governance becomes durable rather than ad hoc.

Practical implication: Prefer federated, scoped credentials over embedded secrets for AI-connected workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Gateway-based control creates a false sense of coverage. A gateway can stop a call, but it cannot determine whether the caller is a human, workload, or AI agent with valid standing elsewhere in the enterprise. It also cannot prove that approval, recertification, or offboarding has been completed. This is a classic control gap in NHI programmes: the enforcement point is present, but the lifecycle state behind it is invisible. Practitioners should treat gateway policy as necessary but incomplete.

Unified identity context is the named concept this market is converging on. MCP tool access only becomes governable when request handling is tied to the unified identity graph, where role, entitlement, risk, and audit obligations are evaluated together. That is the difference between one-off request filtering and actual governance. The same model must span human users, service accounts, and AI agents if teams want consistent authority over tool use. The implication is that identity platforms, not protocol wrappers, will define the control plane.

Stored secret dependency is the failure mode that keeps reappearing in agent and workload access. The article’s federation example shows why long-lived credentials are the weak point, not just an implementation detail. Once an MCP-connected workflow depends on embedded secrets, rotation, revocation, and attribution become harder to operationalise. This is the same structural issue seen across NHI environments: access outlives the business intent that created it. The practitioner conclusion is that durable governance depends on eliminating static credential dependency.

AI agent governance will inherit NHI lifecycle discipline rather than replace it. The article is really arguing for extension, not exception. AI-connected workflows still need scoped access, audit trail, and revocation logic that behaves like NHI governance because the technical problem is identity continuity across runs. That means the market should stop treating agent access as a separate category and start treating it as a new class of NHI. Practitioners should align AI access control with existing lifecycle and entitlement processes.

From our research:

• 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.
• For lifecycle grounding, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how offboarding, rotation, and review change the control model.

What this signals

Unified identity context is where MCP governance will separate itself from gateway theatre. As AI-connected workflows spread, teams will need policy decisions that can see human approvals, workload entitlements, and lifecycle state in one place, not three disconnected systems.

The operational signal is familiar from NHI programmes: secrets and tokens remain the easiest part of the stack to misuse, especially when embedded in code or CI/CD. The question for practitioners is not whether MCP exists, but whether their identity platform can govern the credentials and entitlements that MCP exposes.

Teams should also expect the control conversation to shift toward federated access and lifecycle alignment. For a deeper view of the underlying identity model, the Ultimate Guide to NHIs remains the reference point, and the NIST Cybersecurity Framework 2.0 helps frame the broader govern, protect, detect, and respond mapping.

For practitioners

• 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. Do not approve requests based on the MCP session alone.
• 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.
• Audit gateway decisions against downstream entitlement state Check whether the tool call aligns with the requester’s actual roles, department, and risk status in the target system, not just whether the gateway allowed the request through.
• Separate transport enforcement from governance ownership Assign the proxy team responsibility for request mediation and the identity team responsibility for entitlement, lifecycle, and audit controls so neither layer is treated as complete on its own.

Key takeaways

• MCP creates connectivity for AI tools, but it does not create governance, so identity context must come from the surrounding enterprise stack.
• Gateway controls are useful but incomplete when they cannot see entitlement, lifecycle, and audit state across human, machine, and agent identities.
• Federated short-lived credentials and authoritative lifecycle controls are the practical difference between request filtering and real access governance.

Key terms

• Model Context Protocol: A protocol that lets AI clients connect to tools and data sources through a standard interface. It defines communication, not enterprise authority. For governance teams, the important point is that protocol compatibility does not equal identity control, entitlement scoping, or audit readiness.
• Identity Graph: The connected record of who or what an organisation has, what it can access, and under which conditions. In NHI and AI governance, it must unify humans, service accounts, workloads, and agents so policy can evaluate authority, lifecycle state, and risk together.
• Workload Federation: A credential exchange pattern where a workload proves its identity and receives a short-lived, scoped token in return. It reduces dependency on stored secrets and gives governance teams a cleaner way to bind access to workflow context, trust conditions, and revocation boundaries.
• Gateway Governance Gap: The mismatch between request-level enforcement and actual identity governance. A gateway can inspect traffic and block calls, but it cannot by itself determine standing privilege, lifecycle status, or whether the caller is entitled across the broader enterprise environment.

Deepen your knowledge

MCP governance, workload federation, and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity controls to AI-connected workflows, it is worth exploring.

This post draws on content published by ConductorOne: What MCP doesn't include: governance. Read the original.