Topic starter
20/08/2026 5:26 pm
TL;DR: MCP adoption is moving into funded enterprise programmes while only 11% of organisations report production use, and Obot’s analysis argues that the largest exposure sits in pre-production systems where authorization, logging, and runtime guardrails are still being defined. The security question is no longer whether MCP needs a framework, but whether teams can govern model-to-tool trust before exposed servers and shadow deployments create open paths into downstream systems.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “The Reality of MCP Security: A CTO Action Plan”.
By the numbers:
- Only 11% have reached production, according to Obot.
Key questions
Q: What breaks when MCP servers are exposed without identity controls?
A: Without identity controls, anyone with a link, key, or copied credential can reach tools and data outside policy.
Q: Why do MCP deployments create risk before production rollout?
A: Because the highest-risk controls are often still being designed when teams start experimenting.
Q: What are the signs that MCP governance is failing?
A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose.
Practitioner guidance
- Audit every remote MCP endpoint Find unauthenticated or weakly protected servers, especially HTTP-exposed instances created for testing or demos, and remove them from the reachable path before they broker downstream access.
- Centralize authorization at the gateway layer Enforce request-level policy, tool inventory control, and audit logging before any model request reaches downstream databases, SaaS tools, or internal services.
- Separate trusted instructions from untrusted content Inspect tool metadata, retrieved documents, and returned data for hidden directives, and treat model input sanitization as part of runtime security control.
Bottom line: MCP changes AI integration into an access-governance problem because the protocol decides what tools and data sources a model can reach at runtime.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:15 pm
MCP security has already become a governance problem, not a sandbox problem. The market moved faster than the control model, so security teams now have to manage model-to-tool trust, authorization boundaries, and auditability at the same time. That shift puts IAM and SOC teams in the same operating conversation as AI engineering, and practitioners should treat MCP as a governed access plane.
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: Should teams centralize MCP controls or manage each server separately?
A: Centralization is the more defensible model when multiple servers, tools, and data sources are involved. Per-server controls fragment policy, while a gateway or shared control layer can enforce authentication, authorization, logging, and inventory management consistently across the whole MCP estate.
👉 Read our full editorial: MCP security is closing fast on the enterprise risk window