Kong AI Gateway 3.14 adds agent-to-agent traffic to the gateway

API gateways started as a way to control traffic to APIs. Then they learned to handle calls to language models, and later to MCP servers. On 14 April, Kong took the next step: version 3.14 of Kong AI Gateway also routes and governs traffic between agents using the A2A protocol.

Kong says this makes it the first gateway to handle all three types of AI traffic in one place: calls to LLMs, calls to MCP servers and calls between agents.

What Kong launched

The main new feature is support for A2A traffic, which Kong also markets as Kong Agent Gateway. According to Kong, it provides:

• routing and policy enforcement for calls between agents,
• structured logging of A2A calls, including payloads and statistics, for audit purposes,
• token usage tracking for agent traffic,
• one control point for security and access rules.

Version 3.14 also has several improvements aimed at MCP and cost control:

• Token exchange (RFC 8693), so a token can be narrowed down before it is passed on, and access to MCP tools can be limited by OAuth scope.
• Local validation of MCP tokens using the authorisation server’s published keys, without an extra call for each request.
• Token budgets across all providers and models, with separate limits per model.
• Standardised guardrails and support for custom guardrails from third parties.
• New model providers, including Databricks, DeepSeek and self-hosted models through vLLM.

The features are available in Kong’s Konnect platform.

Why it matters

When agents start calling each other, the same questions come up as with APIs: who called whom, with what rights, what did it cost and what happened when something failed? Gateways already answer those questions for APIs, so putting agent traffic through the same kind of gateway is a natural step.

The details in 3.14 show where the difficult parts are. Token exchange and scope-based tool access are about making sure an agent only gets the rights it needs for a specific task, and not the broad rights of the service it runs as. Token budgets respond to the fact that AI costs are harder to predict than API costs.

How it compares

Kong is not alone. The large iPaaS and API management vendors are building their own AI gateways with support for MCP and, gradually, A2A. What sets Kong apart is that it comes from the gateway side and has no integration platform of its own, so it is often used in front of other platforms.

For organisations that already use Kong for APIs, extending it to agent traffic may be simpler than adding a new component. For those that use an iPaaS with its own gateway, the question is whether you want one gateway for everything or one per platform.

What to ask

1. One gateway or several? Map where LLM, MCP and agent traffic runs today, and decide whether it should be governed in one place.
2. Delegated rights. Check how the gateway limits what an agent can do on behalf of a user, and whether token exchange is supported.
3. Cost control. Ask whether token budgets can be set per team, per model and per agent, and how you are warned before a limit is reached.