Topic starter
09/07/2026 12:36 pm
TL;DR: MCP governance determines who can call which servers, with what permissions, and under what accountability, because unmanaged configurations can turn AI coding workflows into shadow automation and hidden production infrastructure, according to Knostic. The identity layer, not just the protocol, now defines whether MCP is governable or merely connected.
Editorial analysis by NHI Mgmt Group, based on content published by Knostic: “Why MCP Governance Isn’t Optional Anymore”.
Key questions
Q: What breaks when MCP permissions are left to local IDE settings?
A: Local MCP permissions break governance because they fragment ownership, obscure which identities can reach which servers, and make it impossible to enforce one policy consistently.
Q: Why do MCP servers create new identity risk for AI-native development?
A: MCP servers create risk because they extend delegated access from the model into repositories, data, and workflow tools.
Q: What should organisations do about shadow AI in MCP environments?
A: Organisations should discover unmanaged agents before expanding gateway policy.
Practitioner guidance
- Establish a central MCP server registry Require every approved MCP endpoint to have an owner, purpose, data classification, and environment scope before it can be used in any IDE or agent workflow.
- Separate human and agent privileges Map agent identities to narrower scopes than the human user behind them, and prevent tokens from inheriting full human permissions by default.
- Scan IDEs and repos for unmanaged endpoints Discover MCP settings in local workspaces, dotfiles, and configuration repositories so hidden servers can be removed before they become embedded in delivery paths.
Bottom line: MCP governance becomes an identity issue when agent and IDE access is allowed to sprawl outside central approval and audit. That turns convenient connectivity into hidden automation with unclear ownership.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 12:41 pm
MCP governance is now an identity governance problem, not a tooling preference. The article shows that the real control question is who may use which server, for what purpose, and under what accountability. That moves MCP out of the category of convenience plumbing and into the category of governed access fabric. Practitioners should read it as an identity architecture issue that spans NHI, AI agents, and developer workflows.
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.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How do security teams prove accountability for agent actions through MCP?
A: They need structured audit records that tie each tool invocation back to the human who exercised the authority, along with the tool name, parameters, server, and policy decision. Without that chain, review teams cannot reconstruct what happened or who authorised it.
👉 Read our full editorial: MCP governance is now an identity problem for AI agents