Kong has made Kong AI Gateway 2.0 generally available, marking another step in the shift from simple LLM proxying toward a broader control plane for models, agents, tools and AI spend.
The September 1 release brings several features that matter to teams already running production AI workloads: MCP Server Bundling for governed tool access, dynamic cost management that accounts for different modalities, broader model and provider coverage, identity-aware AI policies, and native IAM authentication for Amazon Bedrock AgentCore. Kong also says the product is now available in Kong Konnect without beta enablement.
That combination is the news. The AI gateway category is no longer only about taking an OpenAI-style request, forwarding it to a provider and logging the response. Enterprise buyers increasingly want the gateway to decide who can call which model, which tools an agent can reach, how spend should be measured, and how those decisions map to identity systems already used by the business.
What changed in Kong AI Gateway 2.0
The most notable addition is MCP Server Bundling. MCP, or Model Context Protocol, has become a common way to expose tools and resources to AI agents. Bundling MCP servers at the gateway layer gives platform teams a place to aggregate and govern those tool connections rather than leaving every application team to wire and police its own agent integrations.
That is a meaningful product direction. As agents move from demos into internal workflows, the risk is less about a model answering one question badly and more about a model being connected to too many tools with too little oversight. A gateway that can package and control MCP access sits closer to the operational problem: which agents can reach which systems, under whose identity, and with what policy boundaries.
Kong also added dynamic modality-aware cost management. This matters because AI pricing is no longer a single token meter. Text, image, audio, video, tool calls, cached context and reasoning modes can each carry different economics depending on the provider. A cost control layer that understands modality can give teams more accurate limits and routing rules than a generic request counter.
The release also expands model and provider coverage and adds identity-aware AI policies. Kong’s native IAM authentication for Amazon Bedrock AgentCore is especially relevant because Bedrock AgentCore is becoming one of the places where enterprises run and manage agents. Connecting gateway policy to cloud identity reduces the gap between AI-specific controls and the access systems companies already audit.
Why this matters for developers and platform teams
For developers, the practical effect is that the gateway is becoming part of the application architecture, not just an infrastructure add-on. A team building an internal support agent, coding assistant or data-analysis workflow may now need gateway rules for model access, tool access, budget thresholds and identity propagation before the app reaches production.
That can add some setup cost, but it also addresses a real failure mode. Without a shared gateway layer, model selection, provider credentials, tool permissions and spend controls tend to spread across application code, CI secrets, SDK wrappers and team-specific dashboards. That fragmentation makes incidents harder to investigate and model migrations harder to execute.
Kong’s release is also a signal to vendors building OpenAI-compatible API layers and multi-model API products. Compatibility alone is becoming table stakes. Customers increasingly expect governance around the request: policy enforcement, usage analytics, team-level access, budget controls, fallback routing and model/provider visibility.
For Model Gate users, the connection is direct. Unified billing, API-key management, usage analytics and team controls all become more valuable when model access is only one part of the workflow. As agents gain tool access through MCP-style interfaces, gateways will need to represent not only which model was called, but also which team, key, tool bundle and policy context were involved.
The competitive benchmark is changing
Kong is not alone in this direction. Recent moves across the market show AI infrastructure vendors converging on the same broader problem: enterprise AI needs a governed path between users, models, agents, tools and spend. Gateway products are being judged less by whether they can normalize request formats and more by whether they can support production controls.
That puts pressure on buyers to ask sharper questions. Does the gateway understand provider-specific pricing and modalities? Can administrators set policy by team or identity? Can it route across providers without losing auditability? Can it govern agent tools, not just model endpoints? Can it expose usage and cost data in a way finance, security and engineering can all use?
Those questions are no longer theoretical. Long-context models, agent tool calls and multimodal workloads can change cost profiles quickly. A workflow that looks cheap during testing can become expensive when repeated context, image inputs or tool-heavy agent loops enter production. A gateway that cannot distinguish these patterns may still centralize access, but it will not give operators enough control.
What remains uncertain
The announcement establishes general availability and names the key capabilities, but real-world adoption will depend on implementation details: how teams configure MCP bundles, how granular the identity-aware policies are, how cost controls behave across mixed providers, and how much operational visibility customers get in practice.
It is also too early to know whether enterprises will standardize agent governance in a single AI gateway or split responsibility across cloud platforms, security tools, developer platforms and observability vendors. AWS, hosting platforms, IDE vendors and standalone gateway providers are all trying to own parts of the same control surface.
Still, the direction is clear. Kong AI Gateway 2.0 treats AI traffic as a governed enterprise system rather than a stream of model calls. For developers and businesses building on model APIs, that means gateway decisions are becoming architecture decisions: they affect cost, security, model choice, tool access and the reliability of agent workflows.