MCP needs identity governance, not just a gateway

At a glance

What this is: NHI Mgmt Group's analysis, drawing on C1.ai's blog post: Model Context Protocol governance fails if teams stop at a gateway and do not add identity, policy, lifecycle, and audit controls.

Why it matters: IAM and NHI teams need to govern MCP through entitlement, lifecycle, and audit models because protocol enforcement alone does not answer who is acting or whether the actor should be allowed to act.

👉 Read C1.ai's analysis of why MCP needs identity governance, not just a gateway

Context

Model Context Protocol is an application-layer integration standard for AI clients and tool servers, but it does not decide who may call a tool or on whose behalf the call occurs. That gap matters because identity governance is what turns a usable protocol into a governed control surface for human, machine, and agent access.

The governance failure is not that MCP lacks transport or syntax. The problem is that access decisions, entitlement checks, lifecycle state, and audit evidence still have to be enforced by the surrounding identity stack, especially where AI agents run inside engineering workflows and inherit tool reach from upstream credentials.

Key questions

Q: What breaks when MCP controls stop at the gateway layer?

A: Teams lose end-to-end authorization coverage. The gateway may restrict tool calls, but the downstream service account can still execute the final action with broader permissions than the task needs, which creates a mismatch between policy intent and actual system effect.

Q: When should teams prioritise identity governance over protocol enforcement for MCP?

A: Identity governance should come first whenever MCP connects tools to data, workflow changes, or privileged actions. If the decision depends on who is acting, on whose behalf, or under what approval, the protocol alone is insufficient. Use the gateway for enforcement, but use identity policy for the real authorisation decision.

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: What is the difference between MCP protocol control and identity governance?

A: MCP protocol control governs how clients and servers exchange tool calls. Identity governance governs whether the caller should be allowed to act at all, under what authority, and with what audit trail. The first is transport and message handling; the second is entitlement, lifecycle, and accountability.

Technical breakdown

Why a gateway is not MCP governance

A gateway can inspect and block tool traffic, but it only sees the request in flight. It does not hold the enterprise identity graph needed to determine whether the caller is a human, workload, or agent, whether that actor is entitled to the tool, or whether another approval or review already happened elsewhere. That makes the gateway an enforcement point, not a source of policy truth. In practice, the more MCP becomes embedded in IDEs, CI/CD pipelines, and SaaS workflows, the more governance has to move from traffic inspection to identity-aware authorisation.

Practical implication: Treat MCP gateways as control points, not governance systems, and anchor decisions in identity policy and entitlement data.

How entitlement-aware policy applies to tool calls

MCP tool use becomes risky when authorisation is divorced from enterprise context. A request to create a role in Salesforce, read a Snowflake table, or invoke a workflow action may be technically valid yet still wrong for the requester’s department, time window, risk score, or delegated authority. This is the difference between protocol permission and business permission. Identity governance has to evaluate not only the tool name, but the actor’s role, the sensitivity of the target, and whether the action matches an approved workflow. Without that, MCP simply becomes a new path for overreach.

Practical implication: Bind tool access to role, context, and workflow state rather than allowing protocol-valid requests to pass unchecked.

Why short-lived credentials matter in MCP environments

The article’s stronger point is that governance only works when the identity model covers credential lifecycle as well as authorisation. If an agent runs in CI/CD, the problem is not just whether it can call a tool, but whether the credential it uses has been rotated, revoked, or scoped to the current job. That is the same control logic used for federated workload access: issue a scoped token for a specific run, not a reusable secret that outlives the task. In MCP deployments, reusable credentials are the real governance debt.

Practical implication: Replace stored secrets with federated, task-scoped credentials and review their lifecycle alongside tool permissions.

Threat narrative

Attacker objective: Exploit protocol-level trust to gain tool access, data visibility, or workflow execution beyond the actor’s legitimate authority.

1. Entry occurs when engineers wire MCP clients and servers into IDEs, SaaS platforms, or CI/CD workflows without independent identity governance around the connection.
2. Credential or authority abuse follows when a tool call is accepted because the protocol is valid even though the actor’s entitlement, approval state, or credential lifecycle is not checked.
3. Impact appears when the system grants access, reads data, or triggers changes on behalf of an actor whose authority was never evaluated against enterprise policy.

Breaches seen in the wild

• Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
• JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP governance is really an identity governance problem: The protocol defines message exchange, not authority, accountability, or lifecycle. That means the control question is not how to secure MCP itself, but how to express who may act, on whose behalf, and under what policy. Practitioners should treat MCP as a new integration surface that inherits the full burden of IAM, NHI, and audit design.

The gateway-first model is a control-plane illusion: A proxy can block requests, but it cannot determine whether the caller already had valid approval, whether the request matches role intent, or whether the actor’s credential should still exist. That assumption was designed for narrow traffic enforcement, not enterprise authorisation. The implication is that governance must live in the identity fabric, not in the edge filter.

Ephemeral tool calls still need durable identity context: MCP may make interactions feel lightweight, but tool use remains part of the broader identity surface. A temporary call to a SaaS action can still create permanent privilege, data access, or audit exposure if the upstream identity model is weak. Practitioners should evaluate MCP in the same control domain as entitlement reviews and workload federation, not as a standalone protocol issue.

Named concept: protocol-level trust debt: MCP adoption creates a gap between what the protocol can enforce and what the enterprise must govern. That gap grows every time teams assume protocol compliance equals identity compliance. The practical conclusion is that AI toolchains should be measured by how completely they inherit lifecycle, policy, and traceability from the surrounding identity stack.

The strongest governance pattern is federation plus traceability: When tool access is issued from workload or user identity, scoped to the run, and tied back to audit evidence, MCP becomes governable without inventing a parallel control plane. That aligns MCP operations with existing identity discipline rather than creating a separate exception for AI tooling. Practitioners should extend existing identity controls before they multiply protocol gateways.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Protocol-level trust debt: MCP expands the number of places where teams can confuse a valid request with a legitimate one. Governance will fail if access reviews, federation, and audit are still designed only for human logins and static service accounts, because agentic workflows now consume the same privileges through new paths. The control problem is not protocol adoption alone, but whether the identity stack can still explain who acted and why.

The emergence of MCP inside IDEs and CI/CD pipelines makes workload federation more important than gateway filtering. If teams continue to rely on reusable secrets, they will multiply the exposure surface faster than they can review it, especially as MCP configuration files accumulate across tools and repos.

For practitioners

• Define who can invoke each MCP tool Map tool access to human, workload, and agent identities, then express the allowed caller, approved context, and downstream authority for each action.
• Replace proxy-only enforcement with identity-aware policy Require entitlement checks, workflow state, risk context, and approval evidence before a tool call is accepted, even if the MCP request is syntactically valid.
• Move MCP clients to federated credentials Use short-lived tokens issued for the specific workflow run instead of stored secrets that can outlive the task or be reused across sessions.
• Review lifecycle for AI agents and service accounts Include MCP-connected actors in access reviews, offboarding, and revocation workflows so their permissions do not persist after the use case changes.

Key takeaways

• MCP creates a governance gap when teams treat protocol enforcement as a substitute for identity authority, lifecycle, and audit.
• The article’s core warning is that gateways can block requests but cannot decide whether an actor is entitled to perform the action.
• Identity-aware policy, short-lived credentials, and lifecycle review are the controls that turn MCP from an exposed integration layer into a governed one.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Identity-aware gateway: An identity-aware gateway is a control layer that verifies identity, applies authorization policy, and records audit data before forwarding a request. For AI systems, it becomes the enforcement point between the orchestrator and internal services, preventing the model from becoming the authority for access decisions.
• 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.
• Protocol-Spread Trust Debt: Protocol-spread trust debt is the accumulated risk created when a standard protocol reuses credentials, consent and delegated authority across many hops. In MCP environments, the debt grows whenever teams assume the protocol itself is enough to prove who is acting and why.

What's in the full article

C1.ai's full blog covers the operational detail this post intentionally leaves for the source:

• The article's walkthrough of identity-aware MCP governance versus proxy-only enforcement
• Examples of how workload federation applies to AI tool calls in CI/CD and IDE environments
• The platform-oriented explanation of hosted, custom, and on-prem MCP deployment models
• The article's discussion of how AI Access Management extends existing identity infrastructure to tool use

👉 C1.ai's full post explains how identity infrastructure, federation, and audit fit around MCP tool access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.