Uber's MCP Gateway: Separate Registration from Runtime Before Agents Touch Internal Tools

In a large internal tool estate, teams can lose track of what agents are allowed to call, what data those calls return, and who is responsible when something breaks. Uber's reported MCP Gateway addresses part of that governance problem: it standardizes how agents discover and invoke internal services across more than 800 MCP servers and 5,000 tools, and separates tool registration from runtime execution ¹.

That scale is a reason for platform and security leaders to pay attention, not proof that the gateway is secure or right for every environment. The practical question is what controls this architecture makes possible, and what evidence a company needs before putting any gateway in the live path between agents and internal systems.

MCP Server Governance: The Problem a Gateway Is Meant to Solve

Uber says it built its MCP Gateway to standardize how agents discover and invoke internal services. Reported capabilities include automated API discovery, access controls, sensitive-data redaction, response filtering, and incremental tool discovery through Omni MCP ¹.

The risk in a sprawling tool estate is not just an agent picking the wrong tool. An organization may also struggle to say which tools exist, which identities can call them, what data flows back, or which team owns a failure. Direct, point-to-point connections between agents and service-specific tools may leave those questions scattered across teams and integration patterns.

A gateway can give an organization a shared place to catalog and invoke tools, which may make policy and process more consistent. But it is also another component in the request path. Its value depends on what it enforces, how it behaves when something fails, and whether its decisions can be traced afterward. Teams weighing a gateway for model traffic as well as tool traffic can look at how an enterprise AI gateway approaches governed access, then apply the same evidence questions below.

Uber's published account establishes the gateway's scale and lists its capabilities. It does not establish that the design eliminates access risk, reduces latency, meets a specific security standard, or achieves particular availability or scaling results ¹. Each of those requires its own evidence, independent of the architecture description.

MCP Gateway Architecture: Separating Registration from Runtime

Uber says its gateway separates tool registration from runtime execution ¹. For evaluation purposes, registration can be treated as the process for defining which tools are available; runtime is the handling of a live request from an agent to invoke a tool.

This split suggests two distinct control areas worth demanding from any vendor. Registration could cover catalog quality, tool ownership, metadata, policy classification, and version state. Runtime could cover identity checks, authorization, request handling, response filtering, and failure behavior. These are useful design responsibilities to require, not details Uber has confirmed about its own implementation.

One possible benefit of the split is that a tool can be reviewed before agents are allowed to use it, while invocation-time controls are applied when a call occurs. Whether that happens depends on the implementation: separation alone does not establish that registration records stay accurate or that runtime decisions follow policy. Ask how the two sides stay synchronized.

Treat the gateway as a control point, not a replacement for controls in the underlying services. What happens if registration data goes stale, a policy changes mid-session, or the gateway cannot reach a backend service? A control layer may improve consistency while adding a dependency and an operational owner.

Governing Automated Tool Discovery

Uber lists automated API discovery as a capability and reports incremental tool discovery through Omni MCP ¹. Automated discovery may reduce manual registration work across a large estate. Incremental discovery may help make tools available as they are discovered; the source does not say whether it avoids requiring agents to load a full catalog.

Discovery is not governance. A discovered endpoint is not automatically ready for agent access. Reviewers need enough context to understand what a tool does, which service it reaches, what inputs it accepts, what it might return, and who owns it.

Ask the platform team to show what discovery produces and how that output becomes a reviewed catalog entry. Does the metadata support a policy decision? Is human approval required? How does the catalog communicate a tool's status to agents?

Incremental discovery also raises a visibility question: are discovery results consistent across agents and environments, and how do policies apply to tools that appear dynamically? Uber's account does not specify the discovery lifecycle, version handling, approval states, stale-registration behavior, deprecation process, or removal mechanism ¹.

Request evidence for each gap directly: registration timestamps, failed-discovery behavior, version-change logs, approval records, and proof that a removed or disallowed tool no longer appears to agents. These are evaluation requests, not reported features of Uber's gateway.

AI Agent Tool Access Controls: What Authorization Must Prove

Uber reports access controls as a capability ¹. The published account does not say how the gateway establishes identity, evaluates authorization, or applies permissions at the level of individual tools and actions ¹.

That gap matters because authentication and authorization answer different questions. Authentication identifies which user, agent, workload, or service is making a request. Authorization determines whether that identity, in its current context, may invoke a specific tool. A platform team should be able to walk through both parts of that decision.

Ask for policies scoped to tool and action, not just to server. A server-level allow or deny may be too blunt if tools behind the same server expose different actions or data. Ask how user identity propagates through an agent's call, whether delegation is supported, and whether the underlying service sees the caller's identity or only the agent's.

The evidence to request:

• A trace from the initiating user or workload, through the agent and gateway, to the underlying service.
• Sample allow and deny decisions, including the policy context behind each.
• Behavior on denial, mid-session policy change, or urgent access revocation.
• Records of policy review and change history.

These are questions for a prospective deployment. The reported access-control capability does not answer them on its own ¹. Model behavior is a separate layer from gateway enforcement; for a related look at why chat behavior and tool behavior need separate checks, see Refusing in Chat Doesn't Mean Refusing with Tools.

Internal AI Tools Security: Assessing Redaction and Response Filtering

Uber reports sensitive-data redaction and response filtering as gateway capabilities ¹. Those names describe intended functions, not their coverage or effectiveness.

Redaction may alter data before it reaches an agent, while response filtering may remove or reject content according to policy. A buyer needs to establish how each control applies to tool requests, tool responses, metadata, logs, and error messages.

Ask for the sensitive-data model in writing. Which data classes are covered? How are detection rules written and updated? How are false positives and missed detections measured? Does redaction happen before data is logged, or only before it is shown to the agent? The source does not specify these details for Uber's gateway ¹.

Require controlled tests that show the actual response under allowed, denied, partially redacted, and policy-conflict conditions. Check error and log paths as well as normal responses. A capability listed in a feature description is not evidence that sensitive data cannot leak.

Ownership When Something Fails

A gateway handling tools at Uber's reported scale, more than 800 servers and 5,000 tools, raises an ownership question that scale alone does not answer ¹. The published account does not describe Uber's ownership model or specify the gateway's performance, availability, scaling, or audit characteristics ¹.

Before adoption, assign explicit ownership for the catalog, runtime operations, access policy, data-handling rules, tool behavior, and incident response. The gateway team cannot own the correctness of every tool it exposes, and service teams need clear boundaries for their responsibilities.

Write down a responsibility matrix covering the gateway team, tool owner, underlying service owner, security team, and agent application owner. Then test it against failure modes such as a tool returning unexpected data, a policy blocking a legitimate action, discovery surfacing stale metadata, or a dependency becoming unavailable.

Operational evidence should include incident procedures, policy-change review records, audit-retention periods, dependency-failure behavior, and a traceable path from agent action to the accountable team. Treat gaps in that evidence as open risks, not problems the architecture solves by default.

Evidence to Request Before Adopting an MCP Gateway

Split diligence into four packs. This keeps architecture claims separate from security controls and operational readiness, so each can be evaluated on its own evidence.

Evidence pack	What to request
Architecture	Registration-to-runtime flow, discovery lifecycle, versioning, and behavior when tool metadata is missing or stale. Uber's reported design provides comparison points: separated registration and runtime, automated discovery, and incremental discovery 1.
Authorization	Sample policies, identity propagation, denial and revocation behavior, and records linking each invocation to its initiating user or workload. Uber reports access controls but not these implementation details 1.
Data handling	Redaction and filtering rules, treatment of logs and errors, and controlled test results. Uber reports redaction and filtering without specifying coverage or effectiveness 1.
Operations	Named owners, incident procedures, change review, dependency-failure behavior, scaling evidence, and audit retention. The published account does not state these details 1.

Weigh the evidence against the intended use, not against whether a gateway exists. A read-only lookup tool and a tool that changes internal state may warrant different levels of authorization, review, and testing. The control model should make that difference explicit rather than assume one policy fits both.

Next Steps for the Platform Team

Start with a small set of internal tools. Document, for each one, how it is registered, discovered, authorized, filtered, audited, and eventually removed before expanding the catalog.

Write acceptance tests for identity propagation, per-tool authorization, denied calls, sensitive-data responses, stale metadata, tool removal, policy changes, and gateway or service failure. Name owners for catalog quality, runtime operations, access policy, data handling, and incident response before an agent goes live against real tools.

Use Uber's reported architecture as a design reference, not as proof that a different gateway will deliver the same outcomes ¹. Before rollout, have platform, security, and service owners review the evidence together and document the risks that remain before broader access is approved. If the agents in question also run long, multi-step workflows, What Arca's Stop-Start Financial Agent Workflows Reveal About Agent Design is a useful companion read on structuring those runs.