How do organisations decide whether MCP belongs in IAM, PAM, or NHI governance?

MCP belongs across all three because it touches machine identity, privilege enforcement, and lifecycle controls at the same time. IAM provides the principal model, PAM governs high-risk tool actions, and NHI controls the credentials and service identities the gateway may inject. The right approach is integrated policy, not separate ownership silos.

Why This Matters for Security Teams

MCP is not just an integration layer, so deciding where it belongs in the control stack changes who owns the risk. If the gateway is treated as an IAM problem, teams may miss tool-level privilege and runtime policy concerns. If it is treated only as PAM, they may ignore workload identity and credential lifecycle. If it is treated only as NHI, they may miss access governance and approval boundaries. Current guidance suggests MCP should be governed as a shared control point across all three.

That matters because MCP can broker tool access, inject secrets, and expose privileged actions to agents or services that behave dynamically rather than according to a stable human role. NHI Management Group’s Top 10 NHI Issues and lifecycle guidance for NHIs both point to the same practical issue: identity, privilege, and credential management cannot be separated cleanly when a machine intermediary can act on behalf of multiple systems.

The maturity gap is still wide. In The State of Non-Human Identity Security, Astrix Security and CSA report that only 1.5 out of 10 organisations are highly confident in securing NHIs, which helps explain why MCP ownership is often debated in the first place. In practice, many security teams encounter MCP sprawl only after a gateway has already become a privileged control plane rather than through intentional design.

How It Works in Practice

The cleanest way to decide ownership is to split MCP into three questions: who is allowed to use the gateway, what the gateway is allowed to do, and how the gateway proves its own identity. IAM answers the first question through principal, group, and policy mapping. PAM answers the second when MCP can launch elevated actions, retrieve high-value secrets, or reach administrative tools. nhi governance answers the third by controlling service accounts, tokens, certificates, and other secrets the gateway may hold or inject.

In mature environments, this means MCP should be fronted by workload identity rather than static shared credentials. Standards such as NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev. 5 support the underlying principle: access should be explicit, governed, and traceable. For agentic or tool-using workloads, that should be paired with runtime controls described in the OWASP Agentic AI Top 10, because a gateway that serves autonomous systems must assume unpredictable request chains, not fixed user journeys.

• Use IAM for policy ownership, approvals, and entitlement review.
• Use PAM for privileged tool execution, break-glass paths, and session oversight.
• Use NHI controls for short-lived credentials, rotation, and secret storage.
• Use runtime policy checks so the gateway evaluates each request in context.

This model aligns well with NHIMG’s NHI guidance, especially where gateways mediate access to secrets and service identities across multiple systems. These controls tend to break down in legacy estates where one shared MCP credential is reused across environments because segmentation and per-request policy are impossible to enforce consistently.

Common Variations and Edge Cases

Tighter MCP governance often increases operational overhead, requiring organisations to balance rapid integration against stronger control boundaries. That tradeoff is especially visible in environments with many SaaS connectors, cross-cloud workflows, or human-in-the-loop approvals. There is no universal standard for this yet, so the right answer usually depends on where the highest-impact failure would occur: unauthorised tool invocation, secret exposure, or privilege escalation.

One common edge case is a “platform team owns MCP” model. That can work, but only if IAM defines the human and service principals, PAM controls privileged operations, and NHI policy governs the secrets lifecycle. Another edge case is an AI agent calling MCP through a service account. In that case, the agentic layer should be reviewed against 52 NHI Breaches Analysis patterns, because compromised machine identities often become the easiest path to lateral movement.

Best practice is evolving toward shared governance with clear accountability, not a single-team ownership answer. Organisations that wait for one domain to “own” MCP usually discover that the control failure was cross-functional from the start.

Related resources from NHI Mgmt Group

• How can organisations decide whether an AI agent belongs in PAM, IAM, or NHI governance?
• How should organisations decide whether DLP belongs with IAM governance?
• How should organisations decide whether AI agent access belongs in IAM or separate governance?
• How should organisations connect IAM, PAM, and governance for NHI security?