Red Hat turns the MCP gateway into a tool-level policy boundary

A shared Model Context Protocol endpoint can simplify how agents reach enterprise tools, but it can also collapse several security boundaries into one. Red Hat’s new OpenShift gateway pattern separates those boundaries again: tenant isolation controls who owns a gateway path, Kubernetes network policy limits workload communication, Red Hat Connectivity Link policy authorizes individual tools, and rate limiting constrains traffic volume.

Authentication is only the first gate

The article starts from a practical failure mode: a caller that can authenticate to an MCP gateway should not automatically gain every operation exposed behind it. Reading inventory and changing a customer service may share the same protocol and endpoint, but they do not carry the same risk.

Red Hat uses MCPGatewayExtension resources to give teams either separate gateway instances or isolated listeners on one shared Gateway API resource. In both designs, MCP servers are registered against the team’s extension. The first option maximizes deployment isolation; the second shares infrastructure while retaining separate listener configuration and backend groups.

Policy is layered by concern

Kubernetes NetworkPolicy handles workload reachability rather than user identity or tool names. Red Hat’s example narrows inbound traffic to the controller-managed MCP router and broker, then adds a separate policy allowing that gateway to reach a specific inventory MCP server over HTTPS. The separation matters because network policies are additive and cannot decide whether a particular authenticated user may invoke a particular JSON-RPC tool.

That decision moves to Connectivity Link AuthPolicy. An OIDC or JWT rule validates the caller at the MCP listener. For authorization, the router parses the request and supplies the selected server and tool names to policy evaluation. The example compares those values with identity-provider roles such as tool:read; a request without the matching role receives a 403 before the backend performs the operation.

A RateLimitPolicy adds a fourth boundary. Red Hat shows a gateway-wide default of 1,000 requests per minute and notes that route-level limits can replace it for specific backends. Rate limits do not grant permission, but they can protect a gateway or MCP server from excessive traffic after authentication and authorization succeed.

What platform teams should take from it

The important design choice is not one policy object. It is refusing to ask authentication to do every job. Gateway topology defines tenant ownership, network policy controls reachability, identity-aware policy governs server and tool use, and rate policy controls volume.

Red Hat also states what this stack does not solve: content guardrails, credential isolation and provenance checks remain separate controls. Teams adopting MCP on OpenShift should therefore inventory those gaps alongside the gateway configuration rather than treating a valid JWT as the end of the agent-security design.

A useful first implementation is a low-risk read-only MCP server. Give it a dedicated registration, issue one narrowly scoped tool role, restrict gateway-to-server traffic, and test rejected calls before adding state-changing operations. That turns the gateway from a shared transport endpoint into an enforceable policy boundary.