Kubernetes' AI Gateway Working Group: Build the Gateway Boundary Before You Add Another MCP Tool

Every new MCP tool you hand an agent is a new door into your platform — and most teams are installing doors faster than walls. In August 2026, researchers counted roughly 15,930 public MCP servers across four registries, riding on 500 million-plus monthly SDK downloads. Meanwhile, over a third of MCP servers probed ahead of RSAC 2026 showed serious security gaps, and Microsoft's incident responders spent June warning that a poisoned tool description — no exploit code, just words — can steer an approved agent into leaking data.

If you run an agent-facing PaaS, the question is no longer whether agents get deploy and rollback tools. It is what stands between the agent and the tool.

Kubernetes answered that question structurally on March 9, 2026, by forming the AI Gateway Working Group: agent traffic, model endpoints, and policy enforcement are an operational boundary, not just another application route. For a self-hosted deploy-from-chat platform, that boundary holds four controls. Build them before you expose one more tool — especially a mutating one.

The boundary, up front: four controls before the fifth tool​

That table is the whole post in miniature. The rest is the evidence and the ship order.

What the Working Group actually said (March 9, 2026)​

The announcement — from Keith Mattix, Nir Rozenbaum, Morgan Foster, and Flynn — defines an AI Gateway as network gateway infrastructure that generally implements the Gateway API specification with enhanced capabilities for AI workloads. The deliberate framing matters: rather than defining a distinct product category, AI gateways describe infrastructure designed to enforce policy on AI traffic, including token-based rate limiting, fine-grained access controls for inference APIs, payload inspection for routing/caching/guardrails, and support for AI-specific protocols and routing patterns.

The charter commits the group to developing proposals for SIGs and sub-projects around four goals: standards development (declarative APIs for AI networking), community collaboration, extensible architecture (composable, pluggable, ordered processing), and a standards-based approach that layers AI capabilities on proven networking foundations.

Two active proposals carry most of the weight for an agent-facing platform:

• Payload processing (proposal 7) standardizes inspection and transformation of full HTTP request and response payloads: guarding against malicious prompts and injection, content-filtering responses, semantic routing, intelligent caching to cut inference cost, and RAG integration — with declarative configuration, ordered pipelines, and configurable failure modes.
• Egress gateways (proposal 10) defines secure routing outside the cluster: managed authentication and token injection for third-party AI APIs, backend resources for external FQDNs, TLS policy and CA control, and regional compliance and failover.

At KubeCon + CloudNativeCon Europe 2026 in Amsterdam, the group's session — "AI'm at the Gate!" — explicitly put MCP and agent networking patterns on the roadmap alongside inference. That is the tell: the WG sees tool traffic as gateway-governed traffic, not application internals.

Why agent traffic is not just another app route​

A normal API route has one attacker-controlled input: the request. Agent tool traffic has attacker influence in both directions — the user prompt plus every tool description and every tool result. A gateway that only filters at the front door misses the entire rear channel. Three 2026 data points make this concrete:

1. Tool descriptions are an attack path. Microsoft Incident Response guidance from June 30, 2026 warns that attackers can manipulate MCP tool descriptions — the natural-language metadata explaining what a tool does — to steer agents into leaking sensitive data or taking unintended actions. The risk is not code execution; it is an approved agent treating a poisoned description as a legitimate instruction.
2. The ecosystem is already sprawling. Beyond the ~15,930 public servers, MCP is now embedded in government data infrastructure — the U.S. Census Bureau publishes an MCP server, and the GPO GovInfo server entered public preview in January 2026. Your deploy tools will sit in clients alongside servers you did not write, cannot audit, and whose descriptions your agent reads with equal trust.
3. A third of servers ship with serious gaps. Researchers presenting around RSAC 2026 found more than a third of MCP servers showed serious security gaps, with small input changes able to turn routine automation into silent data exposure. MCP without a gateway reintroduces familiar vulnerabilities — SSRF, privilege escalation — at agent speed.

Add the protocol's own shape: without a central control point, any consumer of an MCP server can invoke any tool it exposes, with no native per-agent restriction — and credentials fan out to every app connecting to every server. That is the baseline your boundary replaces.

The four controls, concretely​

1. Agent identity: name the instance, hold the secrets​

Grant permissions to a specific agent instance — identity, human sponsor, scope, expiry — not to a model family. In practice this means OIDC/OAuth 2.1 between the agent and the gateway, per-tool authorization behind it, and credential brokering: the gateway holds the upstream secrets and injects the right one per call, so agents never see raw provider keys. The MCP spec itself forbids token passthrough — the gateway must terminate the client credential and inject per-server credentials — which makes the identity boundary a protocol-shaped requirement, not just good hygiene. Downstream servers should see the verified user identity in a forwarded header, not "some agent."

Concrete options shipping today: agentgateway's token-exchange flow (exchange the agent/user identity for the correct backend secret per call), Keycloak-backed JWT validation with per-tool roles, and per-tool OAuth with vault-backed secrets in enterprise MCP planes.

2. Quotas: budget the blast radius in tokens and calls​

Token-based rate limiting is the WG's headline capability for a reason: inference spend is the failure mode that needs no attacker. Quotas at the boundary mean per-agent token budgets, per-tool call limits, and cost-aware routing (semantic or priority routing toward cheaper-satisfying backends, failover across providers). The Gateway API Inference Extension's InferencePool plus its endpoint-picker protocol give Kubernetes-native scheduling for this — priority, load, and prefix-cache-aware routing expressed declaratively rather than hard-coded in each gateway.

For deploy tooling specifically, quotas cap the retry storm: an agent stuck in a deploy-status-log loop should hit a budget wall long before it hits your platform's rate limits or your invoice.

3. Tool-call tracing: record every invocation, both directions​

If a deploy goes wrong at 3 a.m., "the agent did it" is not a postmortem. The boundary must emit a per-tool-call record — agent identity, tool name, arguments, result summary, latency, token cost — for every hop through the gateway. Payload-aware processing (the WG's proposal 7 territory) is what makes traces useful rather than merely voluminous: knowing what the model saw when it chose the tool is often the difference between "agent bug" and "poisoned tool result."

Treat trace completeness as a release gate for each new tool: no audit record, no route.

4. Deny-by-default egress: the agent's internet is an allowlist​

Agents fetch URLs, call external model APIs, and follow tool results wherever they point. The egress-gateways proposal's shape — backend resources for external FQDNs, gateway-managed auth and token injection, TLS/CA control, regional restrictions — is exactly the control: default-deny external traffic, allowlist per agent or per tool, and never let the agent's own credential touch the third party directly. This is also where multi-provider failover lives: when one model API degrades, the gateway reroutes — the agent never learns a second set of endpoints.

The stack you build it on (no new product category)​

The WG insists this is not a new product category, and the landscape agrees — it is Gateway API plus extensions, with competing implementations converging on the same APIs:

• Gateway API Inference Extension (GIE) supplies the shared vocabulary: InferencePool as the routing contract plus the endpoint-picker protocol, with the llm-d router (welcomed to CNCF Sandbox on March 24, 2026) as the reference scheduler. Build routing policy against the Pool, not against a vendor's CRDs.
• agentgateway is the Rust-native, MCP/A2A-aware data plane — donated to the Linux Foundation in August 2025, now an Agentic AI Foundation project, and the first GIE v1.4.0-conformant gateway. It unifies agent-to-LLM, agent-to-tool (MCP), and agent-to-agent traffic behind identity, policy, token limiting, and cost controls.
• Agent Router (formerly Envoy AI Gateway, renamed September 9–10, 2026 on joining the AAIF) is the Go control plane driving Envoy: one OpenAI-compatible API across providers, token-cost rate limiting, and an MCP gateway via MCPRoute, keeping the existing aigateway.envoyproxy.io CRDs.
• kgateway (CNCF Sandbox) became the first gateway conformant with both Gateway API v1.3.0 and Inference Extension v1.0.0, and its v2.1 release folded agentgateway in as its AI data plane — a concrete sign of the industry shift from "LLM proxy" to "agent gateway."

Map each to the table: identity and egress live in the gateway/MCP-route layer (agentgateway, Agent Router MCPRoute, Kong/Traefik equivalents); quotas split between token limiting at the gateway and scheduling in GIE/InferencePool; tracing rides the payload-processing pipeline. No single project is the boundary — the boundary is the composed policy across them.

Ship order: boundary first, deploy tools last​

Sequencing is the actual thesis. Concretely:

1. First: identity + egress. Per-instance agent identity with OAuth/OIDC, credential brokering at the gateway, and default-deny egress with an allowlist. Nothing agent-driven touches production or the public internet without these.
2. Second: quotas + tracing. Token and call budgets per agent and per tool, plus per-call audit records. Now a misbehaving agent is bounded and legible.
3. Third: read-only tools. Status, logs, metrics, list/describe — behind per-tool authorization and filtered tool lists so each agent sees only its entitled subset.
4. Last: mutating tools. Deploy, rollback, scale, config change — each with its own policy (approval gates, concurrency limits, environment scoping) on top of the full boundary.

The worked example is rollback: a rollback tool behind no identity means you cannot prove which agent reverted production; behind no quota, a confused agent can flap deploys in a loop; behind no tracing, the incident review is archaeology; behind open egress, the tool result that triggered the rollback may have come from anywhere. Each control answers one of those sentences. Ship the answers before the tool.

The WG's message to platform teams is ultimately a pacing one: the ecosystem is standardizing the boundary now — Gateway API extensions, payload processing, egress control, MCP-aware routing — precisely so you do not have to invent it per tool. Adopt the boundary once, then add tools at the speed your roadmap wants. The teams that invert that order will spend 2027 retrofitting identity onto a dozen tools their agents already call.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents are first-class operators: a Render-compatible API with machine-readable state that deploy agents can drive through exactly the kind of gateway boundary this post describes. Star the repo on GitHub or deploy your first app today.