Platform teams don't build great infrastructure by writing glue code. They build it by configuring great primitives. But as API footprints grow in scale and complexity, the gap between what a platform needs and what it takes to run it keeps widening: more workarounds, more bespoke scripts, more operational surface area to maintain.
Kong API Gateway 3.15 closes that gap. This release makes the Konnect Control Plane the authoritative source of truth for both plugin configuration and plugin code, bringing meaningful new capabilities across policy composition, developer experience, security, and application governance.
Here's what's new:
Platform teams running complex API topologies often need the same plugin logic applied at multiple points in a request, e.g., dual JWT validation, global and route-specific IP restrictions, or combined ACLs. They may also need to customize the priority of plugin execution, e.g., run before authentication takes place. Previously, the only way to achieve this was to duplicate plugin source code and maintain it separately, a practice that creates inconsistency and grows harder to manage over time.
Plugin Cloning lets operators duplicate supported plugins under a new name and custom priority, enabling multiple instances of the same plugin logic per request without writing or maintaining custom plugin code. Cloned first-party plugins inherit the same support tier as their parent, making this a production-safe capability for enterprise workloads. The result is layered policy enforcement that stays coherent as your gateway configuration scales.
Distributing custom plugins to a fleet of data plane nodes has historically meant coordinating image builds, deployment pipelines, and restarts — a cycle that slows iteration and introduces consistency risk across nodes. Any time a plugin needed to be updated, the entire distribution process had to run again.
With Plugin Streaming, custom plugin code is streamed directly from the API Gateway Control Plane to all connected data plane nodes. Every node in a Control Plane runs exactly the plugin version that was uploaded and platform teams no longer need to build or maintain automation for plugin file distribution. Developers can ship and update custom plugins without coordinating with ops release cycles, and the build-deploy-restart cycle is eliminated entirely. This also closes the capability gap between Dedicated Cloud Gateway and hybrid or self-managed deployments, giving all deployment models a consistent operational experience.
Conditional Policy Execution was introduced in beta with Kong Gateway 3.14. The premise was simple: attach an expression to a plugin so the gateway decides whether to run it based on request context — headers, paths, content types — rather than running it unconditionally. That eliminates configuration duplication and lets teams enforce the right policy at the right time without maintaining separate plugin configurations per route or service.
With Kong API Gateway 3.15, Conditional Policy Execution is generally available. With GA, we're moving to the Common Expression Language (CEL) — a more expressive and widely adopted standard that brings greater flexibility to how conditions are defined. Beta support for conditional expressions from Gateway 3.14 will be deprecated on August 1 2026. If you're currently using beta conditional expressions, now is the time to migrate.
Read more about this in [_our documentation_](https://docs.google.com/document/d/19N-8bt3GdHFY1mJtWxHc1R27EQBLrSHlbszQ62VrjMA/edit#)_our documentation_.
Security at enterprise scale means more than setting the right policies — it means keeping credentials fresh, consistent, and verifiable across every environment your gateway touches. Here are some highlights of how Kong API Gateway 3.15 delivers targeted enhancements that give platform teams tighter control over certificates, secrets, and token validation without adding operational complexity.
**Azure Key Vault Certificate.** Managing certificates as static secrets in Azure Key Vault is an operational headache. One missed manual rotation can take down your backend services. Kong Gateway 3.15 solves this by adding native support for **Azure Key Vault Certificates**. By moving from "Secrets" to "Certificates", you gain automated lifecycle management and hands-free rotation, securing your infrastructure at scale.
**File-based vault secret resolution.** Teams running in air-gapped environments or using Kubernetes Secrets that write to the filesystem have needed bespoke synchronization scripts to get secrets into their data planes. Kong API Gateway 3.15 adds secret resolution from file-based vaults, allowing consistent vault configuration with runtime secret resolution from the filesystem without the need for third-party software.
**Proof of Possession token validation behind WAFs.** Enterprises that terminate TLS at a WAF before traffic reaches Kong face a specific problem: the client certificate never arrives at the gateway via the TLS handshake, which breaks mTLS-based Proof of Possession validation. Kong API Gateway 3.15 adds PoP token validation support for exactly this topology, enabling cryptographically-bound token authentication even when the gateway sits behind a WAF.
Standard container images carry a range of system utilities that enterprise security teams scrutinize closely. In environments with strict compliance requirements — particularly in regulated industries and government — CVE counts in those images can stall or block platform adoption entirely.
Kong API Gateway 3.15 introduces a distroless minimal image built on Wolfi. It removes non-essential system utilities, significantly reducing the container's attack surface and minimizing CVE exposure. The result is a more deterministic runtime environment, easier compliance reviews, and stronger security boundaries out of the box — without requiring custom image management or case-by-case handling from solutions engineers.
If you’d like to learn more, please refer to [this blog](https://konghq.com/blog/product-releases/kong-api-gateway-3-15-ships-distroless-image)this blog.
When developers register an application in a Developer Portal, they expect it to behave like any other entity in your platform — subject to the same authentication requirements, rate limits, and observability as everything else. An application consuming APIs is, in every meaningful sense, an identity that needs to be governed.
With Kong API Gateway 3.15, Applications registered in the developer portal are now fully governed entities. Platform engineers can apply plugins directly to applications, enforce authentication, view analytics, by mapping applications to existing consumers — all through a unified model. Whether you need to rate-limit a partner integration, enforce an auth policy for a third-party app, or pull consumption analytics for a specific application, you can do it the same way you would for any consumer on the platform.
The result is a cleaner operational model and a more consistent developer experience.
Kong API Gateway 3.15 is a foundational step toward making the Control Plane the single authoritative source for all gateway configuration and logic. Plugin Cloning and Plugin Streaming lay the groundwork for upcoming capabilities including plugin versioning, rollback, and richer plugin composition — bringing Kong closer to a fully unified, cloud-native API governance platform.
Ready to get started? Upgrade to Kong Gateway 3.15 and see what's new in [the changelog](https://developer.konghq.com/gateway/plugins/expressions/)the changelog. To see these features in action, [_request a demo_](https://konghq.com/contact-sales)_request a demo_ or try them hands-on in Kong Konnect today.
AI is not just producing different answers. It is starting to do different kinds of work. JEV introduces a different model for using AI: instead of generating text, it returns typed, probabilistic decisions that software can act on directly. By ret
When an AI application fails, knowing that an individual model call returned a 200 isn’t enough. You need to know what led to it. Kong stitches the interactions associated with an AI session together, giving developers a view across the sequence of
Consider a bank using an AI agent to investigate potentially fraudulent transactions. A transaction is processed and the bank’s fraud detection system identifies suspicious activity. That event is published to Kafka: fraud.suspected The bank’s Fraud
Most AI cost management starts with infrastructure. A provider can tell you that you consumed a certain number of input and output tokens on a particular model. An observability platform can show requests, latency, tokens, and traces. A cloud cost p
Traditional applications generally have well-defined boundaries. They interact with a known set of services using credentials provisioned specifically for those connections. Agents are different. Their value comes from their ability to work across s
