Kong Gateway 3.14 shifts policy and identity control to the gateway

At a glance

What this is: Kong Gateway 3.14 centralises policy, token handling, WebSocket auth, and cloud-native identity controls at the gateway edge.

Why it matters: That matters because platform, IAM, and security teams can reduce scattered credential logic while enforcing consistent controls across APIs, services, and real-time workloads.

👉 Read Kong's product release details for Gateway 3.14 policy and identity controls

Context

API gateways increasingly sit on the critical path for identity decisions, not just traffic routing. As service meshes, multi-cloud estates, and AI-driven workloads expand, the weak point is often not authentication in principle but where policy is enforced, how tokens are transformed, and whether static credentials still exist in the path. For platform teams, that is an IAM problem as much as an API problem.

Kong Gateway 3.14 is best read as a consolidation of enforcement primitives at the edge: conditional policy logic, token exchange, WebSocket authentication, and cloud-native IAM integration. The core governance question is whether teams want identity rules embedded in applications and middleware, or enforced once where traffic enters and leaves the platform. For NHI, human IAM, and emerging AI traffic, that architectural choice shapes auditability and blast radius.

Key questions

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. Gateway-level token exchange is the cleanest pattern when a backend service needs a narrower audience, shorter-lived authority, or a different issuer context than the original caller token.

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. They also widen the compromise window because the same secret can persist far beyond the operational need, which makes lifecycle governance weaker and incident response more difficult.

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. Teams lose a single source of truth for access and transformation rules, and the result is usually more maintenance debt, not more control.

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.

How it works in practice

Conditional plugin execution changes how gateway policy scopes work

Traditional gateway policy often forces teams into route duplication, custom code, or overly broad enforcement. Conditional plugin execution changes the scoping model by letting a plugin evaluate request attributes such as headers, paths, or content types before deciding whether to run. That is a policy-time decision at runtime, which is useful when a control should apply to most traffic but not all of it. The mechanism matters because it reduces configuration sprawl without pushing exceptions into application code. It also makes policy intent more explicit, which helps avoid accidental over-enforcement or blind spots in edge controls.

Practical implication: define policy exceptions in gateway logic instead of duplicating routes or embedding exception handling in services.

Token exchange at the gateway reshapes downstream identity delegation

OAuth 2.0 Token Exchange, standardised in RFC 8693, lets a gateway validate one inbound token and issue a new token with a different audience, scope, or delegation context for downstream services. That solves a common trust problem in microservices: the original token was issued for one party, but backend services should not inherit that same authority. In this model, the gateway becomes the controlled broker of service-to-service identity, rather than a pass-through. It also reduces the need for custom middleware that often becomes a hidden security dependency.

Practical implication: use gateway-level token exchange when downstream services need narrower, purpose-built credentials than the inbound token provides.

Cloud-native authentication removes static secrets from infrastructure access

The cloud-native authentication update replaces static access keys and passwords with provider-native IAM across AWS, Azure, and GCP. Mechanically, that means the gateway authenticates to supporting services using the cloud’s own identity system rather than carrying long-lived secrets in configuration. This is important because static credentials expand the compromise window and create lifecycle problems that are hard to monitor consistently. When the gateway can rely on native identity primitives, secret handling becomes a smaller part of the architecture and access governance becomes easier to standardise across environments.

Practical implication: treat static infrastructure credentials as a design defect and move supporting service access to cloud-native identity wherever possible.

NHI Mgmt Group analysis

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.

Static credentials remain the most fragile part of multi-cloud identity design. The cloud-native authentication changes reflect a simple reality: long-lived keys are difficult to govern once platforms span multiple providers and backend dependencies. This is an NHI problem first, an infrastructure convenience problem second. Teams should treat any remaining static secret path as a lifecycle gap, not a tooling preference.

Token exchange is the right abstraction when delegated access must be narrowed before it reaches backends. Forwarding the same user token to every service collapses audience boundaries and hides over-privilege inside application chains. Gateway-mediated exchange preserves intent while forcing the downstream credential to match the target service. Practitioners should reassess where delegation is being approximated by token forwarding.

WebSocket security needs first-class identity controls before the connection is established. Handshake-time OIDC, mTLS, and ACL enforcement close a common gap where real-time traffic is authenticated too late or inconsistently. That is especially relevant for AI-driven and event-heavy workloads where persistent connections can outlive the assumptions made at session start. Practitioners should align WebSocket governance with the same identity standards used for HTTP traffic.

Conditional execution creates a more precise policy model, but it also raises governance expectations. Once the gateway can decide whether a control runs based on runtime attributes, teams need stronger discipline around policy ownership, exception logic, and audit review. The benefit is reduced glue code and better separation of concerns. The practitioner takeaway is to manage gateway policy as a governed control surface, not a convenience feature.

From our research:

• 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.
• For the governance model behind those controls, see OWASP Agentic AI Top 10 for the runtime risks that appear when policy and identity decisions move into autonomous execution paths.

What this signals

Gateway-centric identity control is where platform governance is heading, but the operating model has to be explicit. If token exchange, conditional policy, and cloud-native auth are distributed across teams without clear ownership, the gateway becomes another place where policy fragments instead of consolidating. Teams should define which identity decisions belong at the edge and which remain in upstream systems, then align audit evidence to that split. For deeper identity standards context, the NHI Lifecycle Management Guide provides the lifecycle framing that many platform teams still lack.

One useful concept here is identity policy relocation: moving identity enforcement from application code and ad hoc middleware into a governed control point closer to traffic ingress and egress. That reduces hidden exception paths, but only if platform teams document policy intent, ownership, and review cadence. The operational signal to watch is whether exceptions shrink while auditability improves, not just whether teams remove code.

As AI-driven traffic grows, the distinction between workload identity and delegated user identity becomes harder to ignore. The relevant question is no longer whether a gateway can authenticate traffic, but whether it can preserve the correct audience, scope, and lifecycle for every hop. For teams formalising this model, the Top 10 NHI Issues is a useful starting point for mapping the governance pressure points.

For practitioners

• 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.
• Enforce real-time connection auth at handshake Apply OIDC, mTLS, and ACL checks before a WebSocket session is accepted so persistent connections do not bypass the same identity rules used for HTTP traffic.

Key takeaways

• Kong Gateway 3.14 moves more identity and policy enforcement to the edge, which reduces glue code but raises the bar for gateway governance.
• Token exchange, WebSocket handshake auth, and cloud-native IAM all point to the same design principle: authority should be narrowed before it reaches downstream services.
• Teams should treat static secrets and duplicated policy logic as architecture debt, then centralise the controls that decide who or what gets access.

Key terms

• Token Exchange: Token exchange is a delegation pattern where one credential is validated and then replaced with another that is narrower, differently scoped, or intended for a different audience. In practice, it reduces the risk of passing over-broad identity from one trust domain to another.
• Conditional Policy Execution: Conditional policy execution means a security control runs only when runtime conditions are met, such as a header, path, or content type. For gateways and identity controls, it allows a single policy to cover most traffic while safely excluding defined exceptions.
• Cloud-native authentication: Cloud-native authentication uses the identity mechanisms built into the cloud provider instead of static passwords or access keys. For platform teams, it improves lifecycle control because access can be issued, governed, and revoked through native IAM rather than embedded secrets.
• Handshake-time authentication: Handshake-time authentication is the practice of verifying identity before a persistent session is established, rather than after traffic has already begun to flow. This is especially important for WebSocket and similar long-lived connections where late checks are easier to bypass.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: More Control, Less Toil: Simplified Security and Policies in Kong Gateway 3.14. Read the original.