Why MCP Needs Authorization at the Gateway
MCP is a JSON-RPC-based protocol with a semantic layer for LLMs, capability negotiation, and stateful sessions. Those sessions are long-lived, not the short-lived REST interactions traditional proxies handle. Authorization today is baked into each MCP server individually. Third-party servers may ship with none at all. For platform engineers, that means audit trails scattered across multiple places and duplicated authorization logic. Centralizing it at a gateway is the same problem IAM solves for any other API surface.
Agentgateway: A Purpose-Built Data Plane for AI Traffic
Agentgateway is written in Rust and supports Kubernetes Gateway API 1.5, inference extensions for self-hosted models, and a unified API that translates OpenAI calls to Anthropic or any other provider. It runs standalone or in Kubernetes. For MCP specifically, it implements the OAuth 2.0 spec from the MCP specification, handling token exchange with an IDP so agents authenticate once per session with no mid-session interruptions. It also supports the same external authorization spec as Envoy, which is how Kyverno plugs in without any custom adapter code.
Kyverno Authorization: Reusing Kubernetes Policy at the Edge
Kyverno’s new authorization server mode uses the same ValidatingPolicy resource already used for Kubernetes admission control. Policies run in Envoy mode because agentgateway speaks the Envoy external authorization protocol natively. A policy has three parts: variables, match conditions, and validation. For MCP traffic, Kyverno added a CEL library to parse MCP requests, extract the tool name and arguments, fetch and unmarshal the YAML from the target URL, then issue a SubjectAccessReview to Kubernetes. The result is a direct allow or 403, backed by the cluster’s existing RBAC groups.
Live Demo: Blocking a Production Manifest Apply
The demo scenario: a user opens Cursor, connects to a kagent MCP server fronted by agentgateway, logs in as Alice through Keycloak, and receives a token. Alice can list pods and namespaces. When the agent attempts to call create_resource_from_url targeting the production namespace, agentgateway forwards the request to Kyverno before the tool executes. Kyverno checks the SubjectAccessReview, returns denied, and agentgateway sends back a 403. Every retry by the LLM fails the same way. Production stays up.
Applying Existing Cloud-Native Tools to AI Workloads
The core argument is that the security primitives already exist. Kyverno handles policy. Kubernetes RBAC handles access decisions. Keycloak handles identity. Nothing here was invented for AI. The same pattern extends beyond IAM: Cosign handles model verification, and other existing tools cover isolation. Agentgateway bridges the gap between the MCP protocol and those tools by speaking OAuth 2.0 toward the client and Envoy external authorization toward the policy engine. No new security model is required.
Notable Quotes
native MCP oats might not be enough especially for enterprise and this is where agent gateway can bridge the gap and bring a unified um authorization layer to your AI infrastructure. Luc Chmielowski · ▶ 25:24
we are not reinventing the wheel we are using tools and processes that exist since like years you know Luc Chmielowski · ▶ 25:48
There’s no off in place and the manifest gets applied and prod goes down. Nina Polshakova · ▶ 09:38
Key Takeaways
- MCP’s stateful sessions and third-party servers make per-server authorization unreliable at scale.
- Agentgateway implements MCP OAuth 2.0, so agents authenticate once with no mid-session token prompts.
- Kyverno’s CEL-based MCP library lets existing Kubernetes RBAC block tool calls before they execute.
About the Speaker(s)
Nina Polshakova is a software engineer at Solo.io focused on AI Gateway projects. She maintains agentgateway and contributes to Kubernetes, Istio, kagent, and kgateway. She served as Kubernetes v1.33 Release Lead and is a CNCF Ambassador.
Luc Chmielowski is a software engineer at Nirmata and a Kyverno maintainer. He built the Kyverno authorization server feature demonstrated in this talk, which extends Kyverno’s policy-as-code model from Kubernetes admission control to external authorization for AI gateways.