Red Hat Takes MCP Gateway to GA for Governing Agent Tool Traffic at Scale

Red Hat has moved its Model Context Protocol gateway for OpenShift from technology preview to general availability, adding a Kubernetes-native control point in front of enterprise agent tool sprawl.

The company announced the GA on Oct. 16 as part of Red Hat Connectivity Link 1.5, natively integrated into the Red Hat AI portfolio. Red Hat describes expanded AgentOps capabilities to govern AI agent tool traffic at scale, with gateway isolation, stateless session support, prompts and resources support, MCP guardrails, and security hardening for production use. Red Hat’s Friday Five page for Oct. 16 surfaces the gateway announcement in its More like this rail.

That positioning matters because agent fleets are hitting a practical limit: dozens of MCP servers, hundreds of tools, and no consistent place to enforce tenancy, authentication, auditing, or safety checks. Reference servers give you tools. A gateway decides which agent sees which tool, logs what was called, and screens payloads.

The distinction is visible this month. Community MCP reference servers reached v1.0.0 on Oct. 11, packaging filesystem, memory, fetch, git, time, sequential-thinking and other reference implementations for developers. Red Hat’s product is the layer between MCP clients such as coding agents and those back-end servers. That control-plane role is explored in The Agent Gateway Is the Control Plane for Enterprise Agents: without it, every agent becomes its own integration and audit problem.

Two isolation models for tenants

The headline enterprise feature is gateway and MCP server isolation, with two patterns.

The first delegates a completely separate gateway instance, including router and broker components, so traffic stays isolated through to the back-end MCP server. The second uses a shared gateway with isolation from the listener level down, with separate gateway components after routing is triggered. Red Hat’s example puts sets of MCP servers behind one endpoint with paths such as /mcp-team-a and /mcp-team-b.

Consider dedicated stacks where teams need the strongest traffic separation, for example when different business units must not share gateway components. Consider the shared model to reuse core gateway infrastructure while giving each team its own endpoint and policy scope. Red Hat describes these isolation patterns without certifying any regulatory outcome, so teams operating under regulatory constraints would still need to validate the chosen pattern against their own controls. For fleets split across IT, finance, or customer-facing assistants, that avoids a single flat tool namespace or a proliferation of full gateway deployments.

Prompts, resources, and taming tool bloat

GA federates more than tool calls.

Prompts from upstream servers are federated alongside tools, prefixed the same way and accessible through prompts/list and prompts/get. A virtual server can scope prompts with the spec.prompts field on the MCPVirtualServer resource, and authorization filtering supports prompts through the allowed-capabilities JWT claim. Resources cover resources/list and resources/read for prefixed ui:// resources, primarily on the stateful path, also subject to authorization filtering. Because agents load system prompts and enterprise context as well as tools, Red Hat describes this per-tenant scoping as a way to constrain what each tenant’s agents can load, subject to authorization rules.

Tool bloat gets a dedicated fix. As catalogs grow, returning everything in one tools/list response wastes context and degrades model efficiency. The gateway now supports upstream progressive discovery with discover_tools and select_tools. The first returns lightweight metadata — server names, categories, hints, and tool names without schemas — so an agent can browse. The second scopes the stateful session to a working set and emits notifications/tools/list_changed so the agent refreshes its view.

Operators annotate MCPServerRegistration resources with category and hint fields to make servers discoverable. The limitation is explicit: discovery relies on sessions and state, so it is only available for the stateful protocol version.

Stateless and stateful side by side

The gateway now supports the 2026-07-28 stateless HTTP transport alongside 2025 versions 2025-11-25, 2025-06-18, and 2025-03-26 on a single endpoint. Clients negotiate the version and the gateway routes accordingly.

The /mcp path auto-negotiates, while /mcp/stateful forces the older protocol. Older servers can keep exposing tools through the stateful protocol next to newer servers using stateless transport, which Red Hat positions for serverless and horizontally scalable workloads on OpenShift. Platform teams avoid a flag day: onboard elastic stateless servers without rewriting every legacy stateful server.

Audit, metrics, and NeMo guardrails

For observability, the router now emits a structured audit entry for valid tools/call requests at INFO level with audit=true, carrying the calling user from the JWT sub claim when available, plus tool and server names, response status, and request and session identifiers. Entries are emitted both when a call reaches the back end and when the router rejects it early, such as session-init failure or unknown server. That complements OpenTelemetry and MLflow integrations for agentic tracing.

The broker exposes Prometheus metrics on a dedicated scrape endpoint, port 9090 by default. Five metrics cover discovery attempts, discovery duration, current tool count per server, upstream connection failures, and tools/list response size. Red Hat says server_name is the primary label, bounded by registration count, to avoid cardinality explosion.

For safety, the gateway natively integrates with NeMo guardrails, the default guardrail service across Red Hat AI. It checks tools/call request and response bodies against active policies — requests before forwarding to the back end, responses before returning to the client — to help address prompt injection and sensitive-data exfiltration risks, independent of authentication or authorization. Red Hat describes this screening behavior without claiming it eliminates those risks. Configuration uses a Secret referenced from MCPGatewayExtension and per-server annotations, with per-server config IDs additive to global checks. Operators must still install NeMo and configure endpoint and model.

What to do now

This is availability, not a roadmap promise: GA in Connectivity Link 1.5 after a technology preview, with documentation for installing and configuring MCP traffic and a console plug-in in developer preview for creating gateways, registering servers, viewing health, and inspecting tools and prompts from OpenShift Console.

Start with tenancy: dedicated instances or shared-gateway listener isolation. Annotate registrations so discovery works. Plan /mcp versus /mcp/stateful routing as you adopt stateless transport. Wire audit logs and broker metrics into SIEM and Prometheus on day one, and decide which NeMo checks apply globally versus per server. The console remains preview while the gateway is GA — but the direction is clear: MCP tool traffic is becoming platform traffic.