Topic starter
06/06/2026 1:40 am
TL;DR: C1.ai says MCP adoption is real, but the protocol leaves identity, policy, lifecycle, and audit outside its scope, so tool governance still has to come from the surrounding identity stack. A gateway can enforce calls, but it cannot replace entitlement-aware control over who or what is acting, under what authority, and with what traceability.
Editorial analysis by NHI Mgmt Group, based on content published by C1.ai: “What MCP doesn't include: governance”.
Key questions
Q: What breaks when MCP controls stop at the gateway layer?
A: Teams lose end-to-end authorization coverage.
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.
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
- 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.
Bottom line: MCP creates a governance gap when teams treat protocol enforcement as a substitute for identity authority, lifecycle, and audit.
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
👉 Read C1.ai's analysis of why MCP needs identity governance, not just a gateway →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 14 hours ago by NHI Mgmt Group
06/06/2026 2:55 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP needs identity governance, not just a gateway
This post was modified 14 hours ago by NHI Mgmt Group