Topic starter
19/08/2026 3:41 pm
TL;DR: Uber’s MCP summit keynote showed that large-scale agent deployment quickly becomes ungovernable without a standard interface, central registry, and policy layer, according to Obot. The practical lesson is that MCP has become an identity and access problem, because tool discovery, authorisation, observability, and lifecycle control now sit on the critical path for AI agents.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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