Notifications
Clear all
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.
NHIMG editorial — based on content published by Obot: MCP Dev Summit North America keynote coverage of Uber's enterprise MCP strategy
By the numbers:
- Uber described more than 1,500 monthly active agents built across the company.
- 90%+ of its 5, + of its 5,000+ engineers use AI tools monthly.
Questions worth separating out
Q: How should security teams govern managed MCP access for AI clients?
A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task.
Q: Why do MCP environments create new identity governance problems at scale?
A: MCP environments multiply access paths as more agents and servers are added, which makes direct point-to-point governance brittle.
Q: What breaks when MCP servers are not registered centrally?
A: Unregistered servers create shadow deployment.
Practitioner guidance
- Define MCP tool ownership and approval boundaries Assign a named owner for every MCP server, every exposed tool, and every change path that can modify access or parameters.
- Build a central MCP registry with lifecycle states Track active, deprecated, and retired servers in one source of truth so agents do not continue to call stale definitions or orphaned tools.
- Enforce tool-level logging and redaction Capture tool name, parameters, response class, and decision outcome for every invocation, and redact sensitive fields before logs are retained or forwarded.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- The full architecture of Uber's MCP Gateway and Registry, including the IDL crawler workflow and definition generator.
- How service owners enable tools, tune descriptions, and route changes through code and security scanning.
- The specific way Uber handles auto-auth, PII redaction, observability, and write-operation guardrails.
- The Skills Registry roadmap, including evaluations, SLA metadata, and dynamic discovery on demand.
👉 Read Obot's analysis of Uber's enterprise MCP governance model →
Enterprise MCP strategy at scale: what IAM teams need to know?
Explore further
19/08/2026 4:20 pm
MCP governance is becoming the non-human access layer for enterprise AI. Once agents use a common protocol to discover and invoke tools, the governance question shifts from integration to entitlement. That means identity teams have to think about tool exposure, parameter control, and auditability as first-class access decisions, not technical implementation details. The practical conclusion is that MCP cannot be managed as a developer-only convenience if it is touching enterprise data or action paths.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: What should IAM teams do before scaling agent-to-tool integrations?
A: Set guardrails around mutable endpoints, require telemetry for each invocation, and define which teams can add or change tools. Then align the MCP gateway with your existing access review and logging processes so non-human access is treated as governed identity, not just application traffic.
👉 Read our full editorial: Enterprise MCP governance is now mandatory for scaled AI agents
