Notifications
Clear all
Topic starter
24/06/2026 7:24 pm
TL;DR: Conditional policy execution, native token exchange, WebSocket authentication, and cloud-native IAM are pushed into the gateway layer by Kong Gateway 3.14, reducing glue code while tightening control over API and AI traffic, according to Kong. The shift matters because identity, scoping, and enforcement move closer to traffic decisions, where IAM teams can actually govern them.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should teams scope delegated access in API and microservice flows?
A: Teams should scope delegated access at the point where trust changes, not after the token has already been reused downstream.
Q: Why do static credentials create governance problems in multi-cloud environments?
A: Static credentials are hard to track, rotate, and offboard consistently once access spans multiple clouds and backend dependencies.
Q: What breaks when gateway policy logic is duplicated across routes and services?
A: Duplicate policy logic creates configuration drift, inconsistent enforcement, and hard-to-audit exceptions.
Practitioner guidance
- Map gateway controls to identity decisions Inventory where authentication, token transformation, and policy exceptions are currently implemented in apps or middleware, then move the governing control to the gateway where feasible.
- Replace static service credentials Identify database, cache, and vault connections that still rely on long-lived secrets, and migrate them to cloud-native IAM authentication across AWS, Azure, and GCP.
- Scope downstream tokens explicitly Use token exchange when a backend service should receive a narrower credential than the inbound user token, especially in microservices and multi-tenant request paths.
What's in the full announcement
Kong's full product release covers the operational detail this post intentionally leaves for the source:
- Step-by-step configuration examples for conditional plugin execution across request attributes and policy exceptions.
- Implementation detail for JWT Decode, Verify, and Sign nodes inside Datakit workflows.
- The exact mechanics of OAuth 2.0 Token Exchange in the OIDC plugin for downstream delegation.
- Cloud-native authentication setup notes for AWS, Azure, GCP, Postgres, Redis, and Vault.
👉 Read Kong's product release details for Gateway 3.14 policy and identity controls →
Kong Gateway 3.14 and the identity control gap at the edge?
Explore further
25/06/2026 4:40 am
Gateway policy is becoming an identity enforcement plane, not just a routing layer. Kong Gateway 3.14 shows the industry moving policy logic closer to where credentials, claims, and traffic decisions actually intersect. That matters because the control point becomes auditable in one place instead of being scattered across services, middleware, and bespoke code. Practitioners should read this as a governance shift toward edge-enforced identity controls.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint.
A question worth separating out:
Q: How should security teams govern WebSocket authentication?
A: Security teams should treat WebSocket authentication as a handshake-time identity decision, not a message-by-message workaround. That means enforcing OIDC, mTLS, and authorization rules before the persistent session is created, then monitoring connection health and failure patterns as part of the access model.
👉 Read our full editorial: Kong Gateway 3.14 shifts policy and identity control to the gateway
