In July, we announced Kong AI Gateway 2.0 in private beta and made a promise: freed from the API gateway release train, [AI Gateway](https://konghq.com/products/kong-ai-gateway)AI Gateway would ship at the speed of the AI ecosystem itself. We said you'd see the evidence quickly.
Here it is. **Kong AI Gateway 2.0 is now generally available**, and it isn't arriving quietly.
Alongside the production-ready runtime, control plane, and Kong Konnect experience we introduced in beta, this release ships a wave of net-new capabilities: MCP Server Bundling for governed agent tool access; dynamic modality-aware cost management; expanded model and provider coverage across Kimi, Microsoft Foundry, and Amazon SageMaker; identity-aware AI policies powered by Kong Identity; and native IAM authentication for Amazon Bedrock AgentCore.
Let's get into it.
If you're running agents in production, you've felt this problem: every agent, every LLM application, every MCP client needs to be configured against a growing sprawl of MCP servers, each with its own endpoint, its own handshake, and its own access story. Multiply that across teams, and MCP connectivity becomes the thing your platform team spends its week untangling.
**MCP Server Bundling** collapses that sprawl into a single front door. A user, LLM, or agent connects to one Kong route and exchanges all of its MCP tool-use JSON-RPC through it. Kong handles the full MCP handshake behind that route — including executing tools/list across all of the mapped upstream MCP servers — and presents the results as one unified tool catalog.
The critical part is what that catalog contains. Bundling is integrated with Kong's MCP ACL plugin, so the gateway reveals **only the tools each caller is authorized to see and execute**. Two agents hitting the same bundled route can receive entirely different tool lists based on who they are. Unauthorized tools aren't just blocked at execution time–they're invisible at discovery time, which shrinks the surface area an agent (or a compromised agent) can even reason about.
For platform teams, this means MCP governance finally works the way API governance does: one endpoint to publish, one place to enforce policy, and per-caller access control that doesn't depend on every client being configured correctly.
Learn more in [the docs](https://developer.konghq.com/ai-gateway/)the docs.
AI cost management breaks down when your pricing model is simpler than your providers'. Modern models don't just charge per token. They charge differently for text, audio, image, and video, differently for cache reads versus cache writes, and differently again for real-time versus standard requests. If your gateway can only track a flat input/output cost, your cost attribution is fiction.
With this release, **ai-proxy-advanced gains dynamic, modality-aware LLM pricing** built on a reusable pricing catalog. You can define your pricing data once and reuse it across configurations via the Konnect pricing catalog. The catalog supports pricing dimensions for **text, audio, image, and video**, plus **cache read and cache write** fields, and the same catalog entries are applied to both real-time and standard multimodal requests.
Precedence works the way you'd want it to: the catalog is a shared baseline, and per-target `model.options.input_cost / output_cost` values take precedence by default, with an opt-in override available per catalog entry when you want the catalog to win. That gives central platform teams a governed source of truth for pricing while still letting individual teams tune costs for their specific deployments.
This is the custom model cost management capability we teased at the beta launch, and it turns Kong's cost analytics and token-based policies into something you can hand to finance with a straight face. And it sets the foundation for a brand new wave of tokenomics functionality, but more on that at [API + AI Summit 2026](https://konghq.com/events/conferences/api-ai-summit)API + AI Summit 2026.
An AI gateway is only as useful as the models and platforms it can reach. This release meaningfully expands that reach in three directions.
Kimi has moved rapidly from research darling to enterprise reality, with adoption at companies like Tencent and Cursor. As the only open source model competing in the global frontier cluster alongside Claude and GPT-5.2–and one of the strongest Chinese AI models available–it's a model enterprises increasingly expect their infrastructure to support.
Kong AI Gateway now supports Kimi natively, expanding our coverage of both the open source model ecosystem and the fast-growing Asia-Pacific AI market. The full set of AI Gateway policies applies to Kimi traffic just like any other provider.
Microsoft has consolidated Azure OpenAI Service, Azure AI Studio, and Azure AI Services into **Microsoft Foundry**, exposing `services.ai.azure.com` endpoints that host multiple model families through path-prefix routing — `/openai/v1/...` for OpenAI-compatible deployments, and `/anthropic/v1/messages` for Claude deployments.
Kong's Azure provider was originally built around the classic Azure OpenAI URL structure, and while an interim workaround made Foundry endpoints reachable, it relied on implicit inference that was easy to get wrong. This release replaces that with an explicit, schema-validated `**azure_service**`** selector**, with the wire format derived from the configured path prefix rather than guessed from the model name. The result: first-class, validated support for the platform Azure AI is becoming, including Claude models served through Foundry.
Many AWS-native organizations serve their foundation models through **Amazon SageMaker**, across the full range of ECR inference containers — TGI, TEI, HuggingFace Inference, and LMI (vLLM/DJL). Kong AI Gateway now supports SageMaker natively.
Rather than inventing a SageMaker-specific format, we leaned on the architecture that already works: the plugin standardizes on the broadly supported OpenAI format and converts internally to HuggingFace where the target container supports it. If you've standardized your applications on OpenAI-compatible calls, they can now reach SageMaker-hosted models through Kong with no application changes–and with the same governance you apply to every other provider.
Kong Identity [_introduced_](https://konghq.com/blog/product-releases/kong-identity-principals-govern-every-api-event-and-application-identity)_introduced_ the **Principal**: a centrally defined authenticating entity, shared across gateways, carrying first-class metadata. With this release, principals reach AI Gateway.
Until now, AI Gateway plugins identified callers only by Consumer–a gateway-local concept that couldn't carry organization-wide identity. Now, AI Gateway is **principal-aware**: rate limiting, analytics and cost attribution, and model and route access control can all key on the authenticated principal instead of only the Consumer.
This matters more in the agentic era than it ever did for APIs. When the caller is an agent acting on behalf of a user, a team, or another system, "who is making this call" is the single most important governance dimension you have for cost showback, for access decisions, and for the audit trail. Principal awareness lets you answer that question consistently, using the same identity definitions across your entire Kong footprint.
The capability is entirely additive and off by default: existing Consumer-based configurations continue to work unchanged, and you adopt principals where and when they add value.
One more for the AWS-native crowd. Kong's **ai-a2a-proxy** and **ai-mcp-proxy** plugins previously had no built-in way to authenticate outbound requests to AWS-hosted Bedrock AgentCore Agents or MCP servers, and teams resorted to hand-rolled pre-function workarounds to sign requests.
This release introduces a new **plugin-agnostic upstream authentication framework** and wires **AWS SigV4 (IAM) authentication** into both plugins, scoped to AgentCore endpoints. Operators can now authenticate to AgentCore Agents and MCP servers declaratively, with credentials handled the way the rest of the platform handles them.
Generally available means exactly that: Kong AI Gateway 2.0 is production-supported, with the compliance and support posture you expect from Kong.
If you're running AI Gateway plugins on Kong Gateway 3.x today, the migration story is unchanged from the beta announcement. Your current implementation keeps running, and AI plugins remain supported in Kong Gateway 3.14 as an LTS release. **Kong Gateway 3.18** remains the release where AI plugins become opt-in rather than bundled, so we recommend planning your migration before then.
Migration tooling is available now: **kongctl** converts your existing decK configuration into native AI Gateway 2.0 config, and your Kong account team can run a white-glove migration from a decK dump of your environment. The [migration guide](https://developer.konghq.com/ai-gateway/v2-migration-guide/)migration guide and [FAQs](https://developer.konghq.com/ai-gateway/)FAQs cover support timelines, LTS, certifications and compliance, and custom plugin questions.
Kong AI Gateway 2.0 is available in Kong Konnect now — no beta enablement required. Create an AI Gateway control plane, connect your providers, and route your first governed LLM, MCP, or agent traffic in minutes.
Your infrastructure already has the raw materials: compute (VMs, containers, serverless), event streaming (Kafka, Kinesis, Pub/Sub, RabbitMQ), data stores (warehouses, databases, object storage), and AI endpoints (any hosted or self-hosted LLM). Tho
Kong makes every MCP client and server work with Enterprise-Managed Authorization, whether they speak the protocol or not. Standard MCP authorization is user-scoped and interactive: every user authorizes every server, one consent flow at a time. T
Multi-agent workflows live and die on context. Every agent-to-agent call and every agent-to-tool call is either a retrieval — fetching information the agent needs — or a mutation — changing state that downstream agents will depend on. At prototype s
When an organization deploys AI agents at scale, high uptime and low latency are an important baseline. However, Platform owners and business stakeholders could be flying blind on several fronts: The Insights Gap: Non-technical stakeholders have li
Multi-agent systems are, at their core, context distribution systems. Every agent in your workflow is a consumer and producer of context. The interesting architectural questions are all about how that context moves. Two operations drive everything:
As AI adoption scales, applications evolve into complex systems of agents, orchestration layers, and context servers. Infrastructure lags behind — struggling with authentication, cost control, and data security across a provider list that change
An AI agent isn't magic. It's a reasoning engine that makes decisions based on what it knows at a given moment. That "what it knows" is its context — the information available to it right now. Context is everything. Give an agent the wrong context,
