A product rename lands in your inbox. The release notes say “no breaking changes.” Your CI/CD pipelines still run. Your CLI commands still work. The obvious question is whether MuleSoft shipped something real or just re-skinned what you already had.

For Anypoint Omni Gateway, the honest answer is: mostly real — and the more important story isn’t the rename at all. It’s what Omni Gateway reveals about a gap in Azure Foundry that your AI governance strategy probably hasn’t accounted for.

The Runtime Didn’t Change. Here’s What Did.

Start with what’s accurate in every Omni Gateway announcement: the Envoy-based runtime is the same one that shipped as Flex Gateway. Envoy got a version bump to 1.37.2. The control plane is still Anypoint API Manager and Runtime Manager. Deployment models are unchanged — Managed on CloudHub 2.0 or Runtime Fabric, Self-Managed on Docker, Kubernetes, and Linux. CI/CD pipelines don’t break. The Anypoint Platform CLI, the Anypoint APIs, the environment variables, the MCP tool names, the documentation URL structure — all unchanged. MuleSoft was not exaggerating when it said this was a non-breaking evolution.

So what is the “Omni” actually buying?

The name reflects a genuine expansion of protocol coverage. Omni Gateway now natively handles REST, SOAP, gRPC, GraphQL, WebSocket, Model Context Protocol (MCP), and Agent2Agent (A2A) — from a single gateway runtime with a unified policy engine. Flex Gateway handled the first four. The last three are new.

GraphQL gets first-class policy types: Schema Validation, Introspection Control, and Operation Limits. GraphQL subscriptions and WebSocket transport now get gateway-level policy enforcement — something you previously had to handle in application code or with a separate layer.

Gateway Federation is the addition that enterprise architects should pay the most attention to. Omni Gateway can federate visibility and policy enforcement across Kong, Apigee, and other third-party gateways. That’s not a minor feature — it means you can apply consistent governance to infrastructure you didn’t deploy with MuleSoft and don’t plan to replace. If your organization runs a mixed gateway estate (common in acquisitions and multi-cloud environments), that’s a genuinely new architectural lever.

The AI Gateway expansion (Token Rate Limiting, Prompt Guard, Semantic Routing, PII detection) existed in Flex Gateway. Those capabilities are now extended to cover MCP and A2A traffic under the same policy engine. The governance model didn’t change; the protocol surface it governs did.

Verdict: the runtime name is new. The protocol coverage is real.

The Part That Actually Matters for Agents: MCP and A2A Native Governance

The reason MCP and A2A support belongs in a gateway — and not just in application-layer code — is the same reason REST governance belongs in a gateway. You want a consistent enforcement point that doesn’t require every agent developer to re-implement security controls.

Omni Gateway’s agent governance policies are specific and documented, not roadmap slides. For A2A traffic: Schema Validation (enforces expected message structure), Rate Limiting and Spike Control (protects downstream agents from traffic storms), and SSE Content Logging (captures Server-Sent Events for compliance audit trails). For MCP connections: restricting endpoint access to authorized agents only, with centralized visibility across all MCP interactions.

The policy types specific to the agent model are the most interesting: Agent Card Policy rewrites Agent Card URLs so your governance layer controls how agents advertise their capabilities. Prompt Decorator injects governance context into agent prompts. PII Detector flags sensitive data in agent-to-agent message bodies, not just API payloads.

These didn’t exist in Flex Gateway because the agent protocols didn’t exist at the enterprise governance layer. The capabilities are legitimately new.

Gateway Federation compounds this. If your agent fleet spans Kong-managed MCP servers, Apigee-fronted REST APIs, and Anypoint-deployed A2A endpoints, you can now bring all of that into a single governance plane without replacing your existing infrastructure. That’s the architectural pitch from Salesforce: a control plane for the agentic enterprise that’s additive, not rip-and-replace.

Whether the operational reality matches that pitch depends on your specific estate. But the technical capability is there.

The LLM Proxy Angle: Where Omni Gateway Fits Above Azure Foundry

Omni Gateway’s AI Gateway positions it as the governance layer above wherever your LLM traffic is running — including Azure Foundry. This is worth unpacking because the layer diagram gets complicated.

Azure Foundry uses Azure API Management (APIM) as its underlying gateway. APIM ships AI-specific policies: llm-token-limit, llm-emit-token-metric, llm-semantic-cache-store, llm-semantic-cache-lookup. These are real, functional, and table stakes. If you’re running all your AI traffic through a single Azure-hosted stack, APIM’s policies may be sufficient.

The distinction is scope. APIM’s policies operate inside the Azure fabric. Omni Gateway’s LLM proxy operates at the provider-routing layer — and its supported provider list is specific: OpenAI, Azure OpenAI, Google Gemini, AWS Bedrock, and NVIDIA Nemotron. Azure Foundry endpoints are not on that list, and neither is the direct Anthropic API. That constraint shapes the architecture more than most evaluations acknowledge.

The Agent Fabric vs. Microsoft Foundry post I wrote last month traced the governance battle at the agent registry and identity layer. Omni Gateway operates at the traffic layer below that — the point where requests actually flow to AI providers, not where agents are registered or credentialed. Both layers matter. They’re not competing for the same position.

The practical implication for Anypoint shops evaluating AI traffic governance: Omni Gateway governs Claude traffic if you route through AWS Bedrock — not if you route through Azure Foundry. These are parallel access paths to Claude, not stacked layers. Foundry and Omni Gateway don’t share a governance plane for LLM traffic; they sit in front of separate Claude backends.

If your organization uses Azure Foundry for Claude access, Omni Gateway’s LLM proxy has no visibility into that traffic. If your organization uses AWS Bedrock for Claude access, Omni Gateway governs it. The decision about which Claude backend you use is, functionally, also a decision about whether Omni Gateway is in your AI governance picture at all.

Which brings us to why this matters more than it sounds.

The Foundry-Anthropic Problem Omni Gateway Reveals

Here’s what most evaluations of Claude on Azure Foundry gloss over: all inference routes to Anthropic’s servers, not Azure’s.

The Microsoft Foundry documentation says it plainly: “In this preview platform integration, Claude models run on Anthropic’s infrastructure.” Foundry is a commercial integration for billing and access through Azure. When your application sends a message to a Claude deployment in Foundry, that request leaves Azure — regardless of which Azure region you selected — and is processed on Anthropic’s infrastructure. Data residency requirements that your Azure architecture is designed to satisfy don’t apply to Claude traffic routed through Foundry.

That’s a significant constraint for regulated industries. If your data governance policy requires that AI inference stay within a specific geographic boundary, Claude on Foundry doesn’t satisfy it. You’re billing through Azure. You’re not computing through Azure.

The second problem is more operationally immediate: extended thinking is blocked for Claude Opus 4.7 in Foundry.

Claude Opus 4.7’s most significant capability relative to previous generations is adaptive reasoning — the thinking={"type":"enabled"} parameter that enables multi-step deliberation before responding. Complex agent tasks, financial analysis, architectural reasoning — these are exactly the use cases where extended thinking produces materially better outputs. In Foundry, the parameter is explicitly not supported. The temperature and top_k parameters are also blocked for Opus 4.7, with top_p locked at 0.99. You’re accessing the model but not the capability.

Every Claude model currently available through Foundry carries “Preview” status. Not GA. In banking and other regulated environments, Preview is a governance red flag: you cannot build production-critical systems on Preview-labeled integrations without an exception process and ongoing re-certification as the preview evolves. The capability is technically accessible but operationally constrained.

The missing API surface adds to the picture: no Message Batches API, no Admin API, no Compliance API, no Models API through the Foundry endpoint. The standard anthropic-ratelimit-* response headers — the ones your retry logic and circuit breakers read — aren’t passed through. You manage rate limiting through Azure Monitor instead.

The pattern I traced in the Fabric post applies here exactly: open at the access layer, constrained above it. The Foundry endpoint is technically accessible. The meaningful capability — the reasoning mode that makes Opus 4.7 worth its cost — lives above that access layer and isn’t available. The architect’s dilemma of dual-vendor dependency applies too: Anthropic controls the capability roadmap; Microsoft controls the integration timeline. You’re downstream of both.

Where Omni Gateway Actually Helps (and Where It Doesn’t)

AWS Bedrock is where Omni Gateway’s Claude governance actually applies. If your organization is running Claude through Bedrock, Omni Gateway’s Semantic Routing, Prompt Guard, PII detection, and token rate limiting are real governance capabilities on real Claude traffic. Bedrock’s Claude models — including Sonnet 4.6, Opus 4.6, and Haiku 4.5 — support extended thinking, unlike Azure Foundry’s Opus 4.7 deployment where it’s blocked. That’s a meaningful capability difference if your use cases depend on complex multi-step reasoning.

The architectural pattern that Omni Gateway enables: a single governance plane across AWS Bedrock (Claude), Azure OpenAI (GPT), and Google Gemini — with Semantic Routing distributing traffic based on prompt complexity, cost, or capability requirements. Foundry is not a routing target in this picture. If your organization is on Azure Foundry for Claude, you’re outside Omni Gateway’s LLM proxy scope.

That’s a real governance architecture with real value for multi-cloud AI stacks. It also draws a sharp line: Bedrock and Foundry are mutually exclusive Claude paths from Omni Gateway’s perspective.

What Omni Gateway doesn’t fix:

• The Foundry path entirely. If you’re on Azure Foundry for Claude, Omni Gateway’s LLM proxy has no visibility or governance over that traffic. There is no routing workaround within Omni’s supported provider list.
• Preview status. Claude models in Foundry are still Preview-labeled regardless of how you govern adjacent traffic.
• The missing batch and compliance APIs. These are Foundry endpoint limitations, not traffic routing problems.

Omni Gateway is a real tool for enterprises running heterogeneous AI stacks. It’s not a patch for Foundry’s Anthropic integration constraints. Those are constraints that have to be addressed at the Foundry level — or by routing around Foundry entirely.

Honest Admission

I don’t know when extended thinking will land in Foundry. The integration documentation doesn’t say, and neither does the public roadmap. The current state is “Preview, extended thinking unsupported.” That could change next month or next year.

I also don’t know whether Anthropic’s infrastructure will eventually be physically hosted within Azure’s network — enabling genuine data residency rather than the current billing-pass-through model. There are precedents: Cohere’s Command models run on Azure’s own infrastructure in Foundry. Claude’s architecture makes that integration harder, but it’s not impossible in principle.

And Omni Gateway’s MCP/A2A policy types are GA-labeled, but GA-labeled is not the same as battle-hardened. Agent protocols are still maturing in enterprise deployments. The policies I described are real and documented. How they perform under production agent traffic patterns at scale is a different question — one that will take another year of production deployments to answer honestly.

What to Actually Do With This

If you’re an Anypoint shop evaluating how to govern AI traffic: Omni Gateway is worth taking seriously as the cross-provider governance plane. The MCP/A2A policy types are real. Gateway Federation is a genuine architectural advantage over point solutions. The AI Gateway capabilities (Semantic Routing, Prompt Guard, PII detection) are production-usable.

If you’re counting on Azure Foundry to give you production-ready, full-capability Claude access: read the capability table more carefully. Extended thinking is unavailable. All models are Preview. Inference leaves Azure. Those constraints may be acceptable for your use case — but they should be explicit in your architecture documentation, not discovered during a compliance review.

The rebrand-vs-reality question has a cleaner answer than most: Omni Gateway is 70% real product expansion and 30% naming cohesion. The Foundry-Anthropic gap it reveals is 100% real — and it doesn’t have a simple fix yet.

---

The agent governance conversation I started in the Agent Control Plane War post keeps extending: traffic governance, protocol governance, identity governance, and now capability governance. The full picture requires all four layers. I’m working through each one. If you’re navigating similar questions in a regulated environment — or you think I’ve read the Foundry constraints wrong — I’m at @orestesgarcia on X and LinkedIn.