Topic starter
19/08/2026 3:41 pm
TL;DR: Scaled AI agent programmes fail quickly when MCP access is treated as an integration detail rather than a governed access surface, Obot reports. Registry, gateway and observability functions have to define what agents can reach, audit and revoke across the fleet.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “What Uber’s MCP Journey Tells Us About Enterprise MCP Strategy”.
Key questions
Q: Why do unmanaged MCP servers create risk for enterprise AI programmes?
A: Because every unmanaged server expands the number of reachable actions without a corresponding governance record.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact.
Q: What breaks when AI tools are exposed through loosely governed MCP servers?
A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight.
Practitioner guidance
- Define MCP ownership and publishing rules Require every MCP server to have a named owner, version history and approved tool scope before it can be discovered by agents.
- Enforce gateway mediation for mutable tools Place a policy layer between agents and services so write operations, sensitive endpoints and third-party tools can be blocked or rate-limited.
- Inventory agent-facing tools and skills together Track MCP servers, the agents that consume them and any composite skills that chain multiple tools into one workflow.
Bottom line: Scaled AI agent programmes fail quickly when MCP access is treated as an integration detail rather than a governed access surface.
Glossary terms: Model Context Protocol, MCP Gateway, Mcp Registry, Skills Registry
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 18 hours ago by NHI Mgmt Group
19/08/2026 4:20 pm
Enterprise MCP governance is an identity control problem, not just an integration problem. Once agents can discover tools dynamically, the enterprise is no longer managing a fixed connection map. It is managing delegated access paths that need ownership, authorisation and revocation logic. The practical conclusion is that MCP governance belongs in the identity operating model, not beside it.
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.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should teams govern skills and MCP together in production?
A: Treat MCP as the protocol boundary and skills as governed instruction assets. That means separate ownership, approval, versioning, and audit for each layer. If an agent can load a skill and then act through an MCP server, both layers need lifecycle controls, because a safe tool can still be used unsafely when the instruction layer is unmanaged.
👉 Read our full editorial: Enterprise MCP governance is now mandatory for scaled AI agents