Enterprise AI traffic is not composed of a single type of LLM call. Organizations use models from multiple providers together, connect internal tools and data through MCP (Model Context Protocol) servers, and add flows where agents call other agents. As the number of connection targets increases, where to handle authentication, access control, cost attribution, and logging remains an operational challenge.
Kong released AI Gateway 2.0 in private beta on July 16, 2026, and announced general availability on September 1. With this release, the AI Gateway became a separate product with its own runtime, control plane, and management API, rather than a set of features within Kong API Gateway. This article organizes what Kong AI Gateway is as a product, how the configuration method has changed in 2.0, what new features have been added, and what conditions should be checked when considering a transition from an existing environment.
☑️ What is Kong AI Gateway 2.0
Kong AI Gateway is an AI connectivity and governance product that sits between applications and LLMs, MCP servers, and AI agents, handling the routing, authentication, access control, cost management, and observability of AI traffic in a single layer. AI Gateway 2.0 is the release in which this product moved away from being a bundle of plugins within Kong API Gateway to having a dedicated runtime, a dedicated control plane, its own management API, and its own versioning scheme, and it became generally available on September 1, 2026, usable in Kong Konnect without a separate beta activation.
What has changed from before is the unit of management. Models, MCP servers, and agents are each treated as independent management targets in the configuration screen and management API. Rather than the method of creating services and routes and attaching plugins to configure AI behavior, this is a method where declaring the needed AI resources causes the control plane to generate the underlying configuration on its own.
☑️ Why the AI Gateway was separated into its own product
Kong AI Gateway has, since its launch, been deployed as part of Kong API Gateway. Features such as LLM routing, prompt guards, semantic caching, and token-based rate limiting all followed the same release schedule as the API Gateway.
The background for the separation is the difference in the rate of change between the two workloads. Mission-critical API infrastructure requires a conservative release cycle that prioritizes stability, while the AI environment—where new model providers keep emerging and protocols like MCP or A2A are still changing in progress—moves on a weekly basis. The reason for the separation is that it is difficult to meet both cycles with a single codebase.
As a result, the AI Gateway now has its own runtime, control plane, and management API, and moved to an independent versioning scheme starting with 2.0. Kong Gateway maintains its proven, stability-focused cycle as is, while AI Gateway is deployed separately, in step with the pace of the AI ecosystem. It is a structure where the governance operating model stays unified while only the release cycle is split according to the workload.
☑️ Configuration method changed from plugins to AI entities
What has changed in Kong AI Gateway 2.0 is the configuration method.
In the method that operated on top of Kong Gateway, AI functionality was provided through three proxy plugins. AI Proxy Advanced handled model proxying, transformation, and load balancing between providers and models; AI MCP Proxy connected Kong-managed services via MCP or sat in front of upstream MCP servers; and AI A2A Proxy was responsible for observability and control of agent-to-agent protocol traffic. In this structure, services and routes had to be created first and plugins attached to them, and logically defining a single model required a service, a route, the AI Proxy Advanced plugin, and several auxiliary plugins together. It was a structure where AI-related configuration was split across multiple objects.
AI Gateway 2.0 abstracted these plugins into a dedicated entity model. AI Proxy Advanced, which used to be attached to a service or route, becomes an AI Model entity, with one entity per virtual model, inside which one or more targets are defined. Provider credentials that used to be entered inline in plugin configuration are separated out into a reusable entity called AI Model Provider, so that a provider can be declared once and referenced by name from multiple AI Models. The existing route_type setting is split into a capabilities array and the type in formats.
AI MCP Proxy becomes the AI MCP Server entity. Each mode of the plugin maps directly to a type value, a new type called upstream-server has been added, and the default_acl and tools.acl that were in the plugin configuration are elevated to the access or tools.access fields of the AI MCP Server, making the access control list a basic configuration item of the entity. AI A2A Proxy becomes the AI Agent entity, with URL rewriting and A2A analytics provided by default.
The plugins themselves are replaced by AI Policy. Each policy has a type field, and this value corresponds to the existing plugin, with the configuration content remaining the same. Consumers and consumer groups become AI Consumer and AI Consumer Group, and Vault is managed in the control plane as AI Vault and AI Data Plane Certificates, with the vault reference syntax kept in the same format as before.
Features that were previously in use carry over as is. The same load balancing algorithms are provided, and the Redis and pgvector strategies for semantic caching are maintained in the same way. What has changed is the unit in which these are declared.
☑️ 5 new features added to Kong AI Gateway 2.0
In addition to the dedicated runtime and control plane for AI traffic and the Konnect usage environment, this general availability release newly includes the following five items.
1. MCP Server Bundling
When agents are deployed to production, a problem arises where MCP servers that multiply per agent, per LLM application, and per MCP client each need to be configured individually. Each server has a different endpoint, a different handshake, and a different access permission scheme. As this scales up team by team, MCP connectivity itself becomes an ongoing task for the platform team.
MCP Server Bundling consolidates this configuration into a single point of contact. When a user, LLM, or agent connects to a single Kong route, the entire JSON-RPC used for MCP tool calls passes through that path, and Kong handles the MCP handshake behind that route, then presents the results of running tools/list against all the mapped upstream MCP servers as a single unified tool catalog.
What matters here is what goes into the catalog. Bundling is integrated with the MCP ACL plugin, so the gateway exposes only the tools that each caller is authorized to view and execute. Even when connecting to the same bundle route, different callers receive different tool lists. Unauthorized tools are not blocked at the execution stage but are invisible from the stage of querying the tool list itself, which narrows the scope that an agent can even recognize and consider as a candidate for judgment. This holds true even in cases where the agent has been compromised.
From a platform team's perspective, this structure allows MCP governance to be handled the same way as API governance. There is one endpoint to publish, one point at which policy is applied, and access control per caller is not left dependent on the configuration state of each individual client.
2. Cost Management by Modality
AI cost management breaks down when the billing model recognized by the gateway is simpler than the actual billing model used by the provider. Recent models are not billed by token alone. Text, audio, image, and video have different unit prices, cache reads and cache writes have different unit prices, and real-time requests and standard requests also have different unit prices. If a gateway tracks only input and output cost as a single unified figure, the resulting cost attribution will diverge from reality.
In this release, dynamic modality-aware LLM pricing has been added to ai-proxy-advanced. This is a method of defining pricing information once and reusing it across multiple configurations via the Konnect pricing catalog; the catalog supports price entries for text, audio, image, and video as well as cache-read and cache-write entries, and the same catalog entry applies jointly to real-time requests and standard multimodal requests.
There is a set default order of priority. The catalog serves as the common baseline, the input_cost and output_cost set per target in model.options take precedence by default, and an override option that reverses this order can optionally be turned on per catalog entry. It is a structure in which a central platform team manages the pricing standard while individual teams can adjust values to fit their own deployment environment.
This configuration allows the pricing information referenced by the gateway's cost analytics and token-based policies to be managed against a single standard.
3. Expanded Model and Provider Support
The scope of use of an AI gateway is determined by the range of models and platforms it can connect to. In this release, Kimi, Microsoft Foundry, and Amazon SageMaker have been added to the list of supported targets.
Kimi is natively supported, and AI Gateway's policies apply to Kimi traffic in the same way as they do to other providers.
Microsoft Foundry is a platform in which Microsoft has unified Azure OpenAI Service, Azure AI Studio, and Azure AI Services, providing multiple model families at the services.ai.azure.com endpoint via path-prefix routing. OpenAI-compatible deployments use the /openai/v1/ path, while Claude deployments use the /anthropic/v1/messages path. Kong's Azure provider had been built around the existing Azure OpenAI URL structure, and Foundry endpoints had been connected through a temporary workaround—a structure that inferred the format from the model name and was therefore prone to misconfiguration. This release replaces that with a schema-validated azure_service selector and changes the transport format to be determined by the configured path prefix, and Claude models served through Foundry are also now included among the supported targets.
Many organizations built around AWS environments serve foundation models on Amazon SageMaker. ECR inference containers broadly, including TGI, TEI, HuggingFace Inference, and LMI (vLLM/DJL), are among the supported targets. Rather than creating a new SageMaker-specific format, the approach standardizes requests sent by the application into the OpenAI format and internally converts them into the HuggingFace format when the target container supports it, so that an environment where applications are already configured to make OpenAI-compatible calls can connect to models served on SageMaker without code changes, with the same governance applied as for other providers.
4. Kong Identity Principal-Based Policy
Kong Identity has introduced the Principal, an authentication subject that is shared across multiple gateways and has its own metadata. A Principal is defined centrally rather than by an individual gateway. In this release, this concept is applied to AI Gateway.
Previously, AI Gateway policy identified callers only as consumers. A consumer is a gateway-level concept and could not capture an identity that spans the entire organization. Now AI Gateway recognizes Principals, and rate limiting, analytics, cost attribution, and model and route access control can be applied based on the authenticated Principal rather than the consumer.
This distinction takes on greater significance in agentic environments. When the calling subject is an agent acting on behalf of a user, a team, or another system, the question of who is making this call is information that serves as the standard for cost chargeback, access decisions, and audit trails alike. Using the Principal as the standard makes it possible to answer this question using a single, consistent identity definition across the entire Kong environment.
This feature is additive to existing configuration and is disabled by default. Existing consumer-based configuration continues to operate as is, and Principal can be adopted starting from wherever it is needed.
5. AWS IAM Authentication for Bedrock AgentCore
The ai-a2a-proxy and ai-mcp-proxy plugins had no built-in means of authenticating requests going out to Bedrock AgentCore agents or MCP servers hosted on AWS. As a result, writing a pre-function directly for request signing was the method used.
This release introduces a plugin-agnostic upstream authentication framework and connects AWS SigV4 (IAM) authentication targeting AgentCore endpoints to the two plugins. Operators can declaratively configure authentication for AgentCore agents and MCP servers, and credentials are handled in the same way as other credentials on the platform.
☑️ Conditions to check when considering a transition from an existing environment
General availability means that Kong AI Gateway 2.0 has become a production-supported target, and Kong's compliance and support framework applies to it.
If you are currently operating AI Gateway plugins on Kong Gateway, your existing implementation continues to work as is. The AI plugins continue to be supported on the LTS release, Kong Gateway 3.14, and the reference point is Kong Gateway 3.18. Starting with that release, the AI plugins will be excluded from the default bundle and will switch to an opt-in method when needed, so it is recommended to plan migration before that point.
Migration tooling is already available. kongctl converts existing decK configuration into AI Gateway 2.0 native configuration, and 2.0 configuration can be managed declaratively through kongctl, connecting directly into existing GitOps workflows. A method is also provided in which the Kong account team carries out the migration directly, based on a decK dump of the environment.
☑️ Frequently Asked Questions
What is Kong AI Gateway 2.0?
Kong AI Gateway 2.0 is an AI gateway product equipped with a dedicated runtime, control plane, and its own management API for AI traffic. It became generally available on September 1, 2026, and is usable in Kong Konnect without a separate beta activation. It treats models, MCP servers, and agents each as independent management targets.
If I am using the existing AI Gateway plugins, do I need to migrate right away?
No, that is not the case. Implementations currently operating on Kong Gateway continue to work as is, and the AI plugins continue to be supported on the LTS release, 3.14. However, starting with 3.18, the AI plugins will be excluded from the default bundle and switched to an opt-in method, so it is recommended to plan the transition before then.
What problem does MCP Server Bundling solve?
It solves the problem of having to individually configure multiple MCP servers for each client. Connecting through a single Kong route lets Kong query the tool lists of all upstream MCP servers and present them as a unified catalog, and this is integrated with MCP ACL so that only tools the caller is authorized for appear in the list.
What is the difference between a Consumer and a Principal?
A Consumer is a gateway-level concept, while a Principal is an authentication subject defined centrally and shared across multiple gateways. Using the Principal as the standard makes it possible to apply rate limiting, cost attribution, and access control across the entire organization using a single, consistent identity definition. It is disabled by default, and existing consumer-based configuration is maintained as is.
How is AI Gateway 2.0 configuration managed?
It can be managed declaratively through kongctl, connecting directly into existing GitOps workflows. kongctl is also a migration tool, converting existing decK configuration into AI Gateway 2.0 native configuration.
☑️ Conclusion
Kong AI Gateway 2.0 is a release that redefines the AI Gateway as a product with its own runtime and release cycle, separated from being a feature set within the API Gateway. The unit of configuration has changed from plugins to entities such as AI Model, AI Model Provider, AI MCP Server, and AI Agent, and along with general availability, MCP Server Bundling, cost management by modality, expanded provider support, Principal-based policy, and IAM authentication for AgentCore have been added.
If you are considering adoption or migration, the starting points to check are: how far your currently used models, providers, and MCP servers fall within the supported scope; what identity standard to design per-caller tool access control around; and when to transition your AI plugin configuration currently operating in an existing Kong Gateway environment.
CloudNetworks supports the process from reviewing a customer environment's AI traffic configuration and MCP server status, examining the scope of application and deployment form based on Kong AI Gateway, through to building it out. If you are considering adopting an AI gateway or transitioning an existing environment, please contact CloudNetworks.
▶ Learn more about Kong AI Gateway
[Source: Kong, "Kong AI Gateway 2.0 Is Now GA — And It's Already Moving Faster," https://konghq.com/blog/product-releases/kong-ai-gateway-2-0-ga; Kong, "Announcing Kong AI Gateway 2.0: Built for the Pace of Agentic AI," https://konghq.com/blog/product-releases/kong-ai-gateway-2-0-agentic-ai; Kong, "AI Gateway 2.x concepts," https://developer.konghq.com/ai-gateway/ai-gateway-v2-concepts/]
