TL;DR: AI policy now has to follow the full request path, not just the application perimeter, as Kong AI Gateway 3.14 adds native agent-to-agent traffic control, token exchange, scope-based tool filtering, and JWK validation to govern multi-agent AI workflows without code changes, according to Kong.
NHIMG editorial — what this means for NHI practitioners
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Downscope tokens before downstream service calls Use token exchange to narrow audience and scopes before forwarding requests to sensitive systems.
- Bind MCP tools to explicit OAuth scopes Assign read and write capabilities to different scopes and enforce those scopes at the gateway.
What's in the full announcement
Kong's full product release covers the operational detail this post intentionally leaves for the source:
- Configuration examples for A2A proxying, token exchange, and MCP OAuth2 validation across real gateway plugins.
- Policy syntax for scope-based tool filtering, including how read and write scopes map to specific tools.
- Rate-limiting examples that combine global token budgets with per-model caps for production environments.
- Guardrail configuration patterns for connecting third-party safety services to the gateway layer.
👉 Read Kong's release on governing the full AI data path with Kong AI Gateway 3.14 →
AI data path governance in Kong 3.14: what changes for IAM teams?
Explore further
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.
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, 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.
A question worth separating out:
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.
👉 Read our full editorial: Kong AI Gateway 3.14 shifts control to the AI data path