Notifications
Clear all
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.
NHIMG editorial — based on content published by Knostic: Key Findings on MCP Governance
By the numbers:
- 88% of organizations now utilize AI in at least one business function, with 23% already scaling agentic AI systems and 39% experimenting with them.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: What breaks when MCP access is not centrally governed?
A: When MCP access is not centrally governed, developers and agents can create unregistered connections that bypass ownership, logging, and approval.
Q: Why do MCP environments increase identity governance risk?
A: MCP environments increase identity governance risk because they turn tool access into a live control plane for AI agents and IDEs.
Q: How can teams know whether MCP policy is actually working?
A: Teams can tell MCP policy is working when live server usage matches the approved registry, logs show attributable actor and action data, and drift alerts fire before unapproved connections are used in production.
Practitioner guidance
- Build a central MCP server registry Catalogue every approved MCP endpoint with owner, purpose, data classification, and environment scope.
- Separate human and agent entitlements Map roles to specific MCP scopes and ensure agent tokens do not inherit human-grade privileges.
- Enforce policy-as-code for MCP changes Put server lists, allowed methods, and rate limits into version control and validate them before merge.
What's in the full article
Knostic's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step MCP governance checklist for security, platform, and DevSecOps teams
- Policy examples for allowed servers, tool methods, and environment-specific scopes
- Operational guidance for logging, registry reviews, and drift detection across IDEs
- Implementation patterns for turning shadow AI automation into managed change requests
👉 Read Knostic's full analysis of MCP governance and shadow AI automation →
MCP governance and shadow AI automation: what are teams missing?
Explore further
09/07/2026 12:41 pm
Shadow AI automation is the governance failure MCP exposes, not just a configuration mistake. Once developers can add servers locally, the enterprise loses a reliable inventory of what is connected, by whom, and for what purpose. That creates an access surface that looks informal until it is embedded in critical workflows. The practitioner implication is that MCP must be governed as part of identity and access management, not as an isolated developer feature.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: Who should be accountable for MCP governance failures?
A: Accountability should sit across platform engineering, security, and the product owners of the workflows using MCP, because each owns a different part of the control plane. Security defines the policy, platform engineering enforces the server boundary, and the workflow owner approves the business purpose. If any one of those is missing, governance fragments quickly.
👉 Read our full editorial: MCP governance is now an identity problem for AI agents
