Kong AI Gateway 3.14 shifts control to the AI data path

At a glance

What this is: Kong AI Gateway 3.14 extends policy, auth, and observability across the full AI data path, including agent-to-agent traffic and token handling.

Why it matters: IAM, NHI, and platform teams need to treat AI tool calls and agent hops as governed identity events, not just application traffic.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Kong's release on governing the full AI data path with Kong AI Gateway 3.14

Context

Kong AI Gateway 3.14 reflects a simple governance problem: AI traffic is no longer a single request to a single model, so perimeter-only controls miss the real decision points. In practice, the security question has shifted to who or what is allowed to call tools, exchange tokens, and hand off work across agent hops, which is why AI gateway policy now matters to NHI and IAM teams as much as application teams.

The release is aimed at environments where multiple models, MCP-based tool calls, and agent-to-agent communication are already part of production workflows. That makes the gateway a policy enforcement point for identity, authorization, rate limits, and auditability across the AI data path, rather than a simple traffic router. The article is typical of where enterprise AI infrastructure is heading.

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 AI agents complicate existing IAM and NHI controls?

A: AI agents complicate IAM and NHI controls because they can chain requests, change tools, and pass delegated authority across multiple hops. Traditional controls often assume a stable subject and a predictable action path, but agentic workflows introduce dynamic execution paths that need policy enforcement at runtime, not only at provisioning.

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: Which frameworks should teams use to govern AI gateway policy and agent access?

A: Teams should map AI gateway controls to OWASP Agentic AI Top 10, NIST AI Risk Management Framework, and Zero Trust principles where the workflow includes autonomous tool use or delegated access. Those frameworks help define boundaries for authorization, observability, and accountability across agent hops and downstream services.

How it works in practice

Agent-to-agent traffic as a policy boundary

Agent-to-agent communication changes the control plane because the subject of authorization is no longer just a human caller. Each agent hop can introduce a new trust decision, a new payload, and a new opportunity for scope drift. In gateway designs like Kong's, A2A policy sits between specialized agents so authentication, rate limiting, and logging apply consistently to inter-agent calls as well as client-to-agent calls. That matters because the path, not the model alone, determines exposure. Practical implication: treat agent hops as governed identity events and enforce policy where the hop occurs.

Practical implication: treat agent hops as governed identity events and enforce policy where the hop occurs.

Token exchange and scope-based tool filtering

Token exchange lets a gateway take an incoming token and issue a narrower one with different scopes or audience claims before forwarding to a downstream service. That is the core of downscoped delegation for AI workflows. Scope-based tool filtering then maps token scopes to specific MCP tools, so an agent with read-only authority cannot invoke write-capable actions. This is materially different from application-level checks because the policy follows the request into the tool layer. Practical implication: align token scopes with tool privileges so downstream actions are enforced by the gateway, not by agent code.

Practical implication: align token scopes with tool privileges so downstream actions are enforced by the gateway, not by agent code.

JWK validation closes auth gaps in MCP flows

Not every authorization server exposes token introspection, but many do publish JWKs for local verification. JWK-based validation lets the gateway fetch public keys, cache them, and verify MCP tokens on each request without a round trip to the auth server. That matters in distributed AI environments because validation has to keep pace with high-frequency calls while still preserving cryptographic trust. It also reduces dependency on a live auth-server response for every authorization check. Practical implication: support both introspection and JWK-only identity providers so MCP traffic can be validated consistently.

Practical implication: support both introspection and JWK-only identity providers so MCP traffic can be validated consistently.

NHI Mgmt Group analysis

The AI gateway is becoming the identity control point for agentic workflows. Once teams split AI work across models, agents, and tools, the gateway sits where authorization, observability, and policy enforcement can still be made consistent. That is why AI gateway design now overlaps with NHI governance, not just API management. Practitioners should treat the gateway as a control boundary for non-human execution.

Scope-based tool access is the right mental model for MCP, not coarse application permissioning. MCP turns tool use into a first-class governance problem because the meaningful question is not whether an agent can connect, but which tools it can invoke under which scope. The release shows the shift from generic API access to tool-level authorisation. Practitioners should map scopes to actual business actions, not just to service endpoints.

Token exchange turns delegation into an enforceable identity policy. Downscoping an incoming token before it reaches a downstream service preserves the original trust relationship while constraining what the next hop can do. That is a stronger model than assuming an upstream agent will remain well-behaved after handoff. Practitioners should re-evaluate any workflow where downstream services still trust the original token unchanged.

Runtime AI governance now depends on the same evidence disciplines as NHI governance. Structured logs, payload capture, and request-level validation are what make audit, forensics, and compliance possible across multi-agent systems. Without those artefacts, teams cannot prove who accessed what, through which tool, and under which delegated scope. Practitioners should plan for auditability at the gateway layer before agent fleets expand further.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials, 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.
• Gateway-based policy is becoming the practical answer, and the broader agent security view is laid out in OWASP Agentic AI Top 10.

What this signals

Scope drift is now the defining governance problem for agentic workflows. The moment an agent can hand off work across tools and providers, the old assumption that one identity equals one bounded action no longer holds. With 80% of organisations already seeing agents act beyond intended scope, the operational issue is not future risk, it is current control failure. Teams should align policy, logging, and review at the gateway layer rather than in scattered application code.

AI gateway policy is converging with NHI governance. Token exchange, scope binding, and request-level logging are the same disciplines identity teams already use for workloads and service accounts, just applied to agent hops. As agent fleets grow, the programme question becomes whether governance can prove who delegated what, to which tool, and under which scope. The architecture increasingly points toward the NHI Lifecycle Management Guide for lifecycle thinking and the OWASP Agentic AI Top 10 for threat modelling.

Identity evidence will matter more than model capability. Teams that cannot reconstruct tool use across A2A traffic will struggle with incident response, audit, and policy exception management. The practical signal to watch is not how many models are connected, but whether delegated access can be observed, constrained, and explained end to end.

For practitioners

• Map every agent hop to a policy boundary Inventory where AI workflows cross from one agent, model, or tool to another, then place enforcement at those handoff points. Focus on where delegation changes, because that is where authorization drift usually appears.
• Downscope tokens before downstream service calls Use token exchange to narrow audience and scopes before forwarding requests to sensitive systems. Preserve original identity context where needed, but do not forward broader permissions than the downstream action requires.
• Bind MCP tools to explicit OAuth scopes Assign read and write capabilities to different scopes and enforce those scopes at the gateway. Keep tool access aligned to actual business operations so an agent cannot invoke actions outside its delegated purpose.
• Validate MCP tokens both locally and centrally Support JWK-based local validation where introspection is unavailable, and keep introspection for servers that support it. The goal is consistent cryptographic verification across heterogeneous identity providers.
• Log payloads and statistics at the control layer Capture enough request detail to reconstruct agent-to-agent activity, including payloads, timing, and tool outcomes. Use those logs for audit trails, anomaly review, and breach reconstruction.

Key takeaways

• Kong AI Gateway 3.14 reflects a broader shift from model-centric controls to path-centric AI governance.
• Agent-to-agent calls, token exchange, and scope-based tool access turn delegation into an identity problem that IAM and NHI teams must own.
• The practical test is whether organisations can enforce, observe, and audit every AI hop without relying on scattered application code.

Key terms

• Agent-to-agent traffic: Agent-to-agent traffic is the communication path between two software agents that can independently exchange requests, data, or tasks. In identity terms, each hop creates a separate authorization decision that should be governed like any other privileged machine interaction, not treated as ordinary application chatter.
• Token exchange: Token exchange is the practice of replacing an incoming credential with a new token that has narrower audience, scope, or delegation claims. In AI workflows, it is used to reduce privilege before a request reaches a downstream service, preserving traceability while limiting what the next hop can do.
• Scope-based tool filtering: Scope-based tool filtering is a policy method that maps token scopes to the specific tools an agent may invoke. It converts broad access into task-scoped access so a read-only identity cannot call write-capable functions, which is especially important in MCP and agentic workflows.
• JWK-based token validation: JWK-based token validation verifies a token locally by checking it against the authorization server's published public keys. It is useful when introspection is unavailable, because the gateway can still validate trust cryptographically on every request without depending on a live server round trip.

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 governance in your organisation, it is worth exploring.

This post draws on content published by Kong: Govern the Full AI Data Path with Kong AI Gateway 3.14. Read the original.