Microsoft MCP Gateway: A Kubernetes Acceptance Sheet

Microsoft MCP Gateway puts a reverse proxy and management layer in front of MCP servers running on Kubernetes. The project separates stateless request routing from lifecycle operations that deploy or update server adapters, plus operations that delete them. Its current README also sets a sharp compatibility boundary: clients and adapters must support MCP 2026-07-28. Legacy initialization and transport sessions have been removed, as has protocol downgrade.

A green Kubernetes deployment says little about production readiness. Put an adapter under load and revoke one caller's role. Then drain a pod during an in-flight request and roll back the release. The acceptance sheet should preserve every result with the gateway resource ID and pod identity, plus the protocol version and change approval.

TL;DR

• Review the data plane and control plane separately. A healthy router cannot prove that adapter creation, update, deletion, or authorization is controlled.
• Test Entra roles and creator rights, plus mcp.admin and requiredRoles, with permitted and denied users plus workloads.
• Pin the MCP protocol contract. Exercise draining and unsupported clients, plus rollout, state dependencies, and rollback, before approving an upgrade.
• MCP routing and Kubernetes, plus Entra, tools, and adapters, sit outside DeepInspect. Only separately routed HTTP LLM calls enter its enforcement boundary.

The gateway has two operational planes

The Microsoft MCP Gateway repository describes a reverse proxy and management layer for MCP servers. Each data-plane request goes to a ready server instance. Control-plane operations manage the MCP server lifecycle through deployment, update, and deletion. Kubernetes supplies the environment for those managed workloads.

Review the data plane and control plane independently. Data-plane acceptance covers discovery and routing, plus readiness, retries, timeouts, and behavior when a backend disappears. Control-plane acceptance covers who can create an adapter and who can change its image or role requirements. It also covers how the change is approved and what event proves the old resource was removed.

The split also changes incident ownership. An adapter can be healthy while the gateway rejects the caller. A valid token can reach the gateway while no ready server exists. The MCP versus A2A guide helps separate tool access from inter-agent messaging, but protocol selection cannot replace deployment evidence for this implementation.

Entra roles need actor-by-actor tests

Microsoft's Entra application roles guide tells operators to create an admin role with the value mcp.admin. Adapter and tool definitions can carry requiredRoles values such as mcp.engineer or mcp.scientist. The documented permission provider gives rights based on creator status and admin membership, together with the configured role collection.

Build a test grid with four actors: the resource creator, an assigned role holder, an mcp.admin, and an authenticated user with none of those claims. Exercise read and update separately, then exercise delete and execution separately. Capture the token claims and resource creator. Then add the configured requiredRoles and gateway decision, plus the resulting object version.

Repeat the actor grid after role removal. Cached claims and token lifetime can delay the observed denial, so record the exact interval. I would fail acceptance if the packet says only "RBAC works." It should show which actor performed which operation against which adapter version, and why the gateway permitted or denied it.

Workload identity has a shared-trust consequence

The same Entra guide documents useWorkloadIdentity: true. That setting binds the deployed pod to the cluster's shared federated identity through the workload-sa service account and the azure.workload.identity/client-id annotation. Any container in that pod can use the shared identity for Azure access.

Treat this as a trust-boundary decision. Record the service account and client ID, followed by the federation subject and Azure role assignments. Add namespace controls and pod admission policy, plus image provenance and the list of adapters permitted to request the identity. Then execute a permitted Azure operation from the intended container.

A permitted Azure operation cannot show whether another pod can assume the same identity. Attempt the operation from an unauthorized namespace and service account, then from an unauthorized image and adapter. Preserve Azure denial evidence plus Kubernetes identity metadata. If multiple adapters share one identity, document the common authority ceiling and compensate with destination-side authorization. The gateway flag changes credential delivery. It does not create per-adapter Azure roles by itself.

Protocol compatibility belongs in the release gate

The repository currently states that MCP 2026-07-28 is required. It removes legacy initialization and transport sessions. Protocol downgrade is also removed, so every production client and adapter must negotiate the pinned version.

Build a compatibility record for each SDK and test client, with its negotiated protocol version and adapter image. Attempt a supported request and an older-client request. Preserve the exact response and confirm that operators can distinguish protocol incompatibility from authentication failure and backend unavailability.

Next, test a rolling gateway upgrade while traffic continues. Send a fixed request every second and drain one old instance. Observe how in-flight work completes. Record duplicate calls and dropped responses, plus retries and routing to ready server instances. Then deploy one incompatible adapter image and prove that readiness prevents production routing. Roll back to the pinned release and repeat the corpus.

Do not approve the release because the deployment object reaches Available. Approval should require request-level evidence before, during, and after the rollout.

The deployment and upgrade acceptance sheet

Create one sheet per cluster and gateway release. Add child rows for every adapter and tool set, plus every identity mode. Keep the following fields in the evidence packet:

• Deployment identity: Record the cluster and namespace, plus the gateway release and image digests. Add the chart or manifest revision, owner, approver, and review expiry.
• Data plane: Name the route and adapter, plus backend readiness and protocol version. Add timeout and retry results, plus rate-limit, unavailable-backend, and malformed-response results.
• Control plane: Record creator and administrator identities. Test adapter creation and update, plus deletion, unauthorized mutation, and reconciliation after a failed deployment.
• Entra authorization: Preserve audience and issuer, plus role claims and requiredRoles. Add creator state and mcp.admin state, plus the decision and reason.
• Workload identity: Record the service account and client ID, plus the federated credential and Azure assignments. Add the pod annotation and denied cross-namespace test.
• State dependencies: Name Redis and Cosmos DB, or other configured stores when present. Add connection ownership and retention, plus backup, restore, failover, and credential rotation evidence.
• Telemetry: Join gateway request and Kubernetes workload events, plus adapter and destination events, with stable identifiers. Record sampling and retention settings.
• Upgrade: Pin old and new versions, plus the compatibility corpus and draining result. Add the rollout window and rollback trigger, plus the rollback owner and post-rollback verification.
• Residual risk: State the open failure mode and accountable owner, plus the expiry date and production restriction.

Print one completed adapter row and hand it to an engineer who did not deploy the cluster. If that person cannot reconstruct the caller and route, plus the pod identity, protocol version, and result, without opening the original terminal session, the sheet is incomplete.

Runtime LLM authorization remains separate

Microsoft MCP Gateway authorizes and routes MCP operations. Kubernetes schedules the gateway and servers. Entra supplies caller and workload identity. A downstream service still decides what the resulting credential may do.

A customer-controlled model call adds another decision: whether an authenticated caller may send a classified prompt to a particular LLM route under the current policy. The AI gateway observability guide explains how to correlate model traffic, but telemetry alone remains weaker than an independent permit or deny record created before forwarding.

Keep the two paths separate in diagrams and evidence. An MCP tool can call a ticketing API without calling an LLM. An LLM request can pass through a policy gateway without touching Microsoft MCP Gateway. Shared HTTPS or bearer tokens do not merge those control boundaries.

DeepInspect

Microsoft MCP Gateway routing and adapters, plus tools and Kubernetes lifecycle, remain outside DeepInspect's boundary. Entra roles and workload identity also remain outside, as do state stores. DeepInspect applies only to an authenticated HTTP LLM request that a customer-controlled application deliberately routes through its proxy.

For that model request, DeepInspect evaluates supplied identity context and the requested model route, plus data classification and current policy, before forwarding. It writes an independent decision record for permit, redact, deny, or error. Keep that record alongside the Microsoft acceptance sheet only when the MCP tool path actually triggers the routed model call. DeepInspect cannot prove that an adapter drained cleanly or that an Entra role was removed.

Book a technical deep dive at deepinspect.ai.