Kong AI Gateway 3.14 shifts control to the AI data path

At a glance

What this is: This is Kong's release analysis for AI Gateway 3.14, centred on governing the full AI data path with A2A traffic management, token exchange, scope-based tool filtering, and local JWK token validation.

Why it matters: It matters because IAM, PAM, and platform teams now have to govern AI tool access and delegation at the gateway, not just inside application code, especially as multi-agent workflows spread across providers.

Context

AI data path governance is the discipline of controlling identity, authorisation, and observability across every hop in an AI workflow, including model calls, tool calls, and agent-to-agent traffic. Kong's article argues that this layer now matters because multi-agent pipelines are already in production and the old pattern of embedding policy inside application code no longer gives platform teams consistent control.

The practical issue is not model choice alone but delegated access across services, providers, and agents. Once an agent can call another agent, token scope, audience binding, and logging become part of the identity model for the workflow itself, not a downstream implementation detail.

For IAM and security teams, the shift is toward policy enforcement at the data path where requests actually move. That makes AI gateway design a governance question as much as a routing question, and it is increasingly relevant to NHI, human delegation, and autonomous execution models.

Key questions

Q: How should security teams govern agent-to-agent traffic in AI workflows?

A: Security teams should treat agent-to-agent traffic as a governed identity path, not as ordinary internal API chatter. Apply authentication, rate limits, logging, and authorization at the hop boundary so each agent call is evaluated independently. That approach preserves visibility when workflows split into specialized agents and prevents trust from silently carrying forward across the chain.

Q: Why do token exchange and downscoping matter for AI agents?

A: They matter because an upstream token should not automatically retain broad authority as it moves through a chain of agents and tools. Token exchange lets teams replace that broad access with a narrower token for the specific audience and action required. This reduces delegated privilege and makes AI authorisation easier to explain and audit.

Q: What breaks when tool permissions are managed only in application code?

A: When tool permissions live only in application code, teams lose a central enforcement point and policy quickly becomes inconsistent across workflows. Audits become harder, visibility drops, and every model or tool integration requires new code changes. A gateway layer gives security teams one place to apply and prove control over access decisions.

Q: How do teams handle JWK-only token validation for MCP traffic?

A: They should validate tokens at the gateway using published JWKs, cache keys safely, and continue to check audience and scope on every request. That approach supports identity providers that do not expose introspection while keeping the control point centralised. The main governance task is to ensure the validation model stays consistent across providers.

How it works in practice

Agent-to-agent traffic as a governed identity path

Agent-to-agent communication turns AI workflows into chained identity events rather than isolated model requests. In Kong's model, the gateway sits in the path between agents and can apply authentication, rate limits, and observability to each hop, which is important because every hop can change context, privilege, and auditability. The key architectural point is that policy no longer depends on each agent implementing its own controls consistently. Instead, the gateway becomes the enforcement layer for traffic between orchestrators, specialist agents, and downstream services.

Practical implication: Treat A2A traffic as a governed identity path and place enforcement where hops are visible and consistent.

Token exchange and scope-based tool filtering

Token exchange lets a gateway downscope an incoming token before forwarding it, so the downstream call carries only the claims and audience needed for that step. Scope-based tool filtering applies the same idea to MCP tool access, letting the gateway map OAuth2 scopes to allowed tools without consumer-group logic in application code. This matters because tool access becomes tied to delegated intent rather than broad upstream privileges. The governance value is in reducing inherited authority as requests move through agentic workflows.

Practical implication: Use downscoped tokens and scope-mapped tool access to keep delegated AI actions inside explicit permission boundaries.

Local JWK validation closes the auth dependency gap

JWK-based validation lets the gateway verify MCP tokens locally when an authorization server publishes public keys rather than supporting introspection. That removes a dependence on a live round trip to the auth server while still giving the gateway a way to validate each request. Architecturally, this matters in mixed environments where some identity providers expose introspection and others do not. The control question becomes whether token verification can remain consistent across identity providers without weakening the policy model.

Practical implication: Support both introspection and JWK-only identity providers without weakening token verification at the enforcement point.

NHI Mgmt Group analysis

The AI gateway is becoming the control plane for delegated identity in agentic systems. Once agent-to-agent traffic is part of production workflows, the decision about who can do what moves out of application code and into the request path. That changes governance from a developer-by-developer problem to a platform-enforced one, which is exactly where identity policy belongs when agents are composing actions across services.

Token exchange is the cleanest expression of least privilege for AI workflows. The article shows why upstream identity should not simply be forwarded unchanged through a chain of agents and tools. Downscoping, audience restriction, and on-behalf-of claims turn delegation into an explicit governance event, which is more defensible than assuming the original token should remain valid everywhere.

Scope-based tool access makes MCP authorization readable to IAM teams. Mapping OAuth2 scopes to tool permissions gives security teams a control model they already understand, but applied at the AI tool layer. That is a useful bridge between classic IAM and AI operations, because it turns tool use into governed entitlement rather than opaque runtime behaviour.

Local JWK validation reduces auth architecture fragility without changing the trust problem. Supporting JWK-only servers is operationally useful, but it does not remove the need to govern token audience, scope, and delegation semantics. The real issue is whether the gateway can consistently enforce the same trust model across identity providers, and practitioners should measure that consistency rather than the convenience of the integration.

AI data path governance is now a distinct identity discipline. The article reinforces a broader market direction: policy is moving closer to the traffic layer because agentic systems are too dynamic to govern reliably inside each application. Practitioners should expect gateway-layer identity controls to matter more, not less, as multi-agent workflows expand.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

AI data path governance is becoming the practical boundary for agentic access control. Policies that live only inside application code do not scale when workflows span model providers, tools, and inter-agent calls. Security teams should expect gateway-layer enforcement to become the default way to make delegation, scope, and audit decisions visible.

Delegated identity has to be narrowed at the point of transfer. The important design question is no longer whether an agent has a token, but how much of the original authority survives the next hop. That is why token exchange and scope mapping are now identity controls, not just API mechanics.

For practitioners

• Define gateway-level policy for A2A traffic Place authentication, rate limiting, and logging at the layer that sees agent-to-agent calls, not only client-to-agent requests. This lets platform teams govern every hop in a multi-agent workflow with one policy surface.
• Downscope delegated tokens before forwarding Use token exchange to reduce upstream authority to the minimum audience and scopes needed for the next service or agent. Preserve on-behalf-of context only where the downstream action genuinely needs it.
• Map OAuth2 scopes to tool permissions Tie tool access to scopes so read-only and write-capable agents are separated at the gateway. Avoid consumer-group logic in application code when the real control objective is tool-level authorisation.
• Standardise token validation across identity providers Support both introspection and JWK-based validation so the enforcement point can verify MCP tokens consistently. Cache keys carefully and confirm the gateway still enforces audience and scope checks on every request.
• Instrument AI hops for audit and incident response Capture logs for each agent hop, including payload metadata and policy decisions, so investigations can reconstruct how authority moved through the workflow. This is especially important when multiple providers and downstream tools are involved.

Key takeaways

• Multi-agent AI workflows now need governance at the request path because policy embedded only in application code cannot keep pace with every hop.
• Token exchange, scope-based tool filtering, and local JWK validation turn delegated AI access into a controllable identity problem instead of a code-by-code exception.
• For practitioners, the main shift is to enforce authorisation, audit, and trust decisions at the gateway where AI traffic already passes.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
• Scope-based Tool Filtering: Scope-based tool filtering limits which tools an AI system or agent can call based on the authority it has been granted. It is a runtime control, not a static label, and it becomes essential when agent behaviour can change from one task to the next.
• JWK Validation: JWK validation is local token verification using the public keys published by an authorization server. For AI gateways, it allows tokens to be checked without an introspection round trip, which is useful when identity providers expose keys rather than active validation endpoints.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.