AI & MCP

How Uber built the enterprise AI security playbook

Cameron McClellan

May 28, 2026 - 7 min read

How Uber built the enterprise AI security playbook

Deploying AI agents into enterprise systems requires security infrastructure that has to be built. Agents need to be authorized, audited, and traceable in ways that existing enterprise controls weren’t designed to handle. Getting that infrastructure right before deploying at scale is a significant investment.

Uber is a great example of what it takes to scale AI deployment and secure it at the same time. By early 2026:

84% of Uber’s developers were using agentic coding tools daily.
AI was generating between 65% and 72% of all code written in the company’s IDEs.
A background coding agent called Minions was producing 1,800 code changes per week across 95% of the engineering organization.

That scale was only possible because Uber built the governance layer first. The process took years and consumed a significant fraction of a dedicated platform engineering team, built on top of infrastructure Uber already had from running a platform serving billions of trips.

This article covers what Uber built, why each layer was necessary, and how to get the same result without replicating that investment.

Why enterprise AI governance fails without infrastructure

Before Uber built the infrastructure described in this article, it faced the same governance problem that comes with any serious AI deployment.

Engineers were connecting AI tools directly to internal services, and every new team invented its own integration. There was no standard for:

Which models were approved for use.
Which data could be sent to external vendors.
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 risk surface of an ungoverned deployment grew with it.

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 AI. Without a central registry, teams were independently building connections to the same internal services. There was no visibility, no governance, and no ability to deprecate connections 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.

The answer was to apply the same approach Uber had used for API infrastructure. Build a centralized control plane and route everything through it. Enterprises building API infrastructure could afford to retrofit governance after the fact. With agentic AI, that window is much shorter.

Uber’s three-layer agentic AI security architecture

The infrastructure Uber built has three layers, each addressing a different gap in what traditional enterprise security controls can see.

Uber's three-layer agentic AI security architecture: LLM Gateway, MCP Gateway and Registry, and Agent Identity System

LLM gateway

The GenAI Gateway (Uber’s LLM gateway, also referred to as an AI gateway) sits between every application and every model provider. Traditional network controls see a TLS connection to an external API. The LLM gateway sees the prompt, the model, the response, and the data flowing through each call. At that layer it can:

Redact PII before requests reach external model providers.
Enforce access control through a standardized security review process.
Route traffic across OpenAI, Google Vertex AI, and Uber’s own inference infrastructure.
Generate an audit log on every call for AI observability and compliance.

By 2024, Uber’s GenAI Gateway was handling 16 million queries per month across approximately 30 internal teams.

MCP gateway and registry

The MCP gateway and registry governs every agent-to-tool connection across Uber’s 10,000+ internal services. The LLM gateway sees model calls. The MCP gateway sees tool calls, meaning the actions agents take inside a session. Without it, there is no enforcement point between an agent and the internal service it is calling. Uber’s MCP gateway:

Auto-generates tool definitions from existing Interface Definition Language files (proto and thrift), eliminating manual registration of 10,000+ services.
Enforces authorization, PII redaction, and continuous security scanning on every tool call.
Maintains a hard tiered-trust distinction between internal and third-party MCP servers.

As Meghana Somasundara put it at the 2026 MCP Dev Summit : “MCPs are not just important. They are what make AI usable at Uber.”

Agent identity system

The agent identity system extends Uber’s existing Zero Trust Architecture to cover multi-agent workflows. Traditional identity systems see the final service call. This system sees the full chain — which human initiated the workflow, which agents were in the middle, and whether each hop was authorized. Each agent holds a short-lived, single-hop token scoped to one destination, with the prior actor chain embedded in it. Uber’s agent identity system:

Issues cryptographically attested tokens for every agent hop in a pipeline.
Traces every tool call back to the human engineer who initiated the workflow.
Enforces authorization at each hop, not just at the entry point.

P99 latency for the token exchange is below 40 milliseconds.

The cost of building enterprise AI security from scratch

The three layers didn’t arrive at once. Each required its own design cycle, security review, and integration with existing systems:

GenAI Gateway — published July 2024.
MCP Gateway and Registry — built as agentic workflows scaled and the tool-integration problem became acute.
Agent identity system — built in 2025 and published in May 2026 .

Today, the MCP Gateway handles 60,000 agent task executions per week across Uber’s internal services.

The reason Uber could build this is that the foundations already existed. The agent identity system extends an existing SPIRE deployment, the MCP Gateway’s authorization integrates with an existing authorization service, and the GenAI Gateway routes to Uber’s own inference infrastructure.

None of these were built for AI. They were built for a platform serving billions of trips. Extending them to cover agentic AI required engineers who understood them well enough to extend them safely. Uber maintains a dedicated Agentic AI Platform team for exactly this purpose, with Meghana Somasundara as Agentic AI Lead and Rush Tehrani as Head of Agentic AI Platform.

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. Enterprises that deploy AI use cases first and then try to retrofit controls find that the risk surface grows faster than the security team can respond. Uber could get the sequence right because it had the platform engineering capacity to build the infrastructure before it was needed. Enterprises without that capacity are making governance decisions under the opposite constraint.

Enterprise AI security infrastructure, without building it yourself

Uber built this infrastructure because they had no choice and had the capacity to do it. Neither condition is common for enterprises that are earlier in their AI deployment.

The Speakeasy AI control plane is the infrastructure Uber built, available as a product. It covers the same four layers Uber assembled over several years:

MCP gateway. Governs every agent-to-tool connection with authorization enforcement, PII redaction, and security scanning on every tool call.
Agent hooks. Enforce policy at the tool-call boundary inside the agent runtime, at the layer where traditional endpoint and network controls have no visibility.
Identity and access management. Extends enterprise SSO to AI agents, so every agent action is traceable to an authenticated identity.
Audit logging and observability. Generates the evidence record that AI compliance requires.

The diagram below shows how those layers connect: every agent call routes through the control plane before reaching any model or internal system.

The Speakeasy AI control plane: agent hooks, MCP gateway, shared identity, and observability on a single governed path from every agent to every system

Uber’s platform was built to answer whether every connection is registered, every agent is authenticated, every call is inspected, and every action is measured. Speakeasy answers all four out of the box. Uber’s engineering investment established that this architecture works at enterprise scale.