AI & MCP
How Uber built the enterprise AI security playbook
Cameron McClellan
May 28, 2026 - 6 min read
Uber is one of the few companies in the world that has solved enterprise AI security at scale. By early 2026, more than 84% of Uber’s developers were using agentic coding tools daily. AI was generating between 65% and 72% of all code written inside the company’s IDEs. A single background coding agent called Minions was generating 1,800 code changes per week , used by 95% of the engineering organization.
This didn’t happen because Uber got lucky with governance. It happened because Uber built the infrastructure first, then scaled adoption on top of it. And building that infrastructure took years, cost a significant fraction of a platform engineering organization, and required deep integration with systems most companies don’t have.
Why Uber had to build this
Before the gateways, before the registry, before the identity system, Uber faced the problem every enterprise faces at the beginning of an AI rollout: adoption faster than governance.
Engineers were connecting AI tools directly to internal services. Every new team invented its own integration. There was no standard for which models were approved, which data could be sent to external vendors, or who was responsible when an AI action went wrong. As agentic workflows matured from single-call queries to multi-step agents with write access to production systems, the blast radius of an ungoverned deployment grew from embarrassing to dangerous.
The specific failure modes Uber was trying to prevent:
- Data exfiltration to external vendors. Uber handles rider and driver PII at enormous scale. An engineer connecting an agent directly to an external model API, without PII scrubbing, was sending production data to a third party.
- Shadow integrations. Without a central registry, teams were independently building connections to the same internal services. There was no visibility, no governance, no ability to deprecate them cleanly.
- Ungoverned tool access. Agents with write access to production databases and no authorization layer were a single bad prompt away from an incident.
- Identity loss across agent hops. In multi-agent workflows, downstream systems had no reliable way to trace a tool call back to the human engineer who initiated it.
Uber had no choice but to treat AI infrastructure the way it had treated API infrastructure: build a centralized control plane and route everything through it.
What they built
The infrastructure has three layers.
An LLM gateway (which Uber calls the GenAI Gateway ) sits between every application and every model provider. It handles PII redaction before requests reach external models, enforces access control through a standardized security review process, routes traffic across OpenAI, Google Vertex AI, and Uber’s own inference infrastructure, and generates an audit log on every call. By 2024 it was handling 16 million queries per month across approximately 30 internal teams.
An MCP gateway and registry governs every agent-to-tool connection across Uber’s 10,000+ internal services. The registry auto-generates tool definitions by running a language model over Uber’s existing Interface Definition Language files (proto and thrift) that already described every internal service. The gateway enforces authorization, PII redaction, and continuous security scanning on every tool call, with a hard tiered-trust distinction between internal and third-party MCP servers. As Uber’s platform team put it at the 2026 MCP Dev Summit : “MCPs are not just important. They are what make AI usable at Uber.”
An agent identity system extends Uber’s existing Zero Trust Architecture to cover multi-agent workflows. Each agent holds a short-lived, single-hop token scoped to one destination. Every token embeds the full prior actor chain. By the time a tool call reaches the gateway, the system has a cryptographically attested record of every participant in the lineage: which human engineer initiated the workflow, which agents were in the middle, and whether each hop was authorized. P99 latency for this token exchange is below 40 milliseconds.
What it actually took to build this
The three layers didn’t arrive at once. Uber published the GenAI Gateway in July 2024. The agent identity system was built in early 2025 and published in May 2026 . The MCP Gateway and Registry came between them as agentic workflows scaled and the tool-integration problem became acute. Each layer required its own design cycle, security review against Uber’s standards, and integration with existing systems. By the time the MCP Gateway launched, it was handling 60,000 agent task executions per week across Uber’s internal services.
Uber had the organizational capacity to build this because it had built foundational infrastructure for years before AI became relevant. The agent identity system extends an existing SPIRE deployment. The MCP Gateway’s authorization integrates with an existing authorization service. The GenAI Gateway routes to Uber’s own inference infrastructure, not just third-party APIs. None of these foundations were built for AI. They were built for a platform serving billions of trips, and extending them to cover AI agents required engineers who understood them deeply enough to extend them safely. Uber maintains a dedicated Agentic AI Platform team, led by Meghana Somasundara and Rush Tehrani, whose specific mandate is this infrastructure.
The lesson from Uber’s own published analysis is that the sequence matters as much as the components: build the governance layer first, then scale adoption on top of it . Most organizations do the reverse. They deploy AI use cases, then try to retrofit security controls onto a system that was never designed for them. Uber could afford to get the sequence right because it had the platform engineering capacity to build the infrastructure before it was needed. Most enterprises don’t have that option.
Getting here without Uber’s resources
Uber built this infrastructure because they had no choice and had the capacity to do it. The rest of the market has neither condition.
The Speakeasy AI control plane is the infrastructure Uber built, available as a product. It combines an MCP gateway with agent hooks that enforce policy at the tool-call boundary, identity and access management that extends enterprise SSO to AI agents, PII redaction and prompt inspection at the infrastructure level, and the audit logging and observability that makes compliance evidence possible. The four questions Uber’s multi-year platform was designed to answer (what is connected, who is authenticated, what is inspected, and what is measured) are the four questions Speakeasy answers out of the box.
Uber’s engineering investment established that this architecture works. Speakeasy exists so that the rest of the market doesn’t have to replicate it.
Further reading
- What is an AI control plane?: the architecture that spans LLM gateway, MCP gateway, identity, and observability.
- What is an MCP gateway?: the enforcement layer for tool-call security.
- AI security frameworks compared: NIST AI RMF, MITRE ATLAS, OWASP and how they map to enforcement layers.
- The OWASP Agentic Top 10, explained: the threat categories the Uber architecture was built to address.