Kong AI reviews show where API gateways fall short on AI governance

At a glance

What this is: This is an analysis of Kong AI reviews that separates API gateway maturity from full AI governance readiness.

Why it matters: It matters because IAM, PAM, and AI security teams need to know whether gateway controls actually govern model, tool, and identity flows, not just traffic routing.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read TruFoundry's analysis of Kong AI reviews and AI gateway governance gaps

Context

Kong AI reviews are really a test of a broader governance question: can an API gateway manage AI traffic without leaving gaps in token control, tool access, and audit evidence? The answer depends on whether teams are evaluating routing features or true AI governance controls, because those are not the same thing. In AI environments, the security problem is not only where requests go, but who or what is allowed to act, under what identity, and with what traceability.

For IAM and identity teams, the distinction matters because AI agents and MCP-connected tools create new control boundaries. A gateway can centralise policy enforcement, but it does not automatically provide identity propagation, privilege scoping, or lifecycle evidence across users, agents, and tools. That makes Kong relevant to AI governance discussions, but only as one layer in a wider control stack. The article’s starting point is typical for buyers comparing platform maturity against governance depth.

TrueFoundry’s analysis also reflects a common enterprise pattern: teams inherit an existing API platform and then try to extend it into AI operations. That approach can reduce implementation friction, but it often exposes missing controls only after deployment begins. The result is a familiar governance gap in a new form, where traffic management exists before accountability does.

Key questions

Q: What breaks when AI gateways do not tie requests to identity?

A: When requests are not tied to identity, teams lose the ability to distinguish between approved use, delegated agent activity, and accidental overreach. That weakens accountability, complicates investigations, and makes policy enforcement dependent on shared keys or coarse account logs. In practice, the gateway becomes a transport layer rather than a control layer.

Q: Why do AI agents complicate traditional gateway controls?

A: AI agents can chain decisions, call multiple tools, and retry actions in a single workflow, which means request-level controls no longer capture the full risk. Traditional gateway logic often sees only traffic, while governance needs to understand intent, privilege, spending, and downstream effects. That is why AI gateways must be evaluated for runtime policy, not just throughput.

Q: How do organisations know whether an AI gateway is actually working?

A: Look for three signals at once: AI traffic is inventoried, identity is preserved through the call chain, and audit records are usable in incident response or compliance review. If any one of those is missing, the gateway is serving as a transport layer, not a governance control.

Q: Should organisations add a separate governance layer on top of an API gateway for AI?

A: Yes, when they need hard budgets, audit-grade identity, MCP tool enforcement, or regulatory evidence. An API gateway can handle traffic policy, but it usually does not close the full gap between request routing and governed AI execution. The right answer is often layered control, not gateway substitution.

Technical breakdown

AI gateway routing versus AI governance

An AI gateway sits between clients and models, handling routing, rate limiting, retries, caching, and policy enforcement at request time. That is valuable, but it is not complete governance. Governance also needs identity propagation, audit logs, cost attribution, tool-level authorization, and evidence of which actor triggered which model interaction. In Kong’s case, plugin architecture can support some of these needs, but the control quality depends on configuration, edition, and operational discipline. A gateway can reduce exposure, yet it cannot by itself resolve accountability across human users, AI agents, and downstream tools.

Practical implication: validate whether gateway controls produce audit-grade identity and cost evidence before treating them as governance controls.

MCP tool governance and identity propagation

Model Context Protocol connects AI agents to tools and data sources, which creates a new trust boundary inside the enterprise stack. If a gateway only sees the outer request, it may miss the context needed to decide whether a tool call is permitted, attributable, and reversible. Identity propagation matters because a service account or proxy identity is not enough when the real decision maker is a user, agent, or workflow. Runtime controls need to preserve that chain from human intent to agent action to tool execution. Without that, investigations and policy enforcement become incomplete.

Practical implication: require end-to-end identity propagation across agent, tool, and audit trail before enabling MCP-connected workflows.

Token budgets, quotas, and cost attribution in production AI

AI usage introduces a control problem that standard gateway reviews often understate: token consumption is both a security and financial boundary. A gateway can rate limit traffic, but enterprise teams also need per-team, per-application, or per-agent cost attribution so they can stop overspend and detect abuse. That becomes especially important when agents can loop, retry, or invoke multiple models and tools in one workflow. The control objective is not just availability. It is to make consumption attributable, bounded, and enforceable before the environment scales.

Practical implication: pair rate limiting with token-aware quotas and budget enforcement that can stop runaway AI usage.

Threat narrative

Attacker objective: The objective is to misuse AI connectivity and obscure accountability so actions, costs, or data access cannot be reliably traced back to the initiating actor.

1. Entry occurs when an organisation extends its existing API gateway into AI traffic without adding model-specific governance controls.
2. Escalation follows when an AI agent or workflow gains access to tools, prompts, or data sources that were not scoped to a human user or business function.
3. Impact appears when missing identity propagation, audit trails, or token budgets prevent teams from proving what the agent accessed, spent, or changed.

NHI Mgmt Group analysis

AI gateway maturity is not the same as AI governance maturity. Kong-style gateways can do a credible job on routing, plugin-based policy, and operational continuity. The missing question is whether they also create governance evidence across identity, model, and tool layers. In AI programmes, the control gap is often not traffic management but accountability, and that changes how buyers should assess platform fit. Practitioners should treat gateway reviews as a starting point, not a governance verdict.

MCP creates a new governance boundary that legacy gateway thinking can miss. Once agents can discover and call tools, policy must travel with identity, not just with packets. This is where the identity bridge becomes explicit: AI agents behave like governed non-human actors only if the enterprise can bind actions to identities, permissions, and logs. The practical conclusion is that MCP needs runtime authorization and traceability, not just discovery and registration.

Token budgets are becoming a security control, not just a finance metric. AI systems can fail through cost exhaustion, noisy retries, or agent loops long before they create a classic breach. That makes consumption policy part of operational resilience. Teams that still treat token usage as an after-the-fact chargeback issue are underestimating the control surface; the practitioner takeaway is to govern spend as a boundary condition for safe AI execution.

Gateway flexibility increases configuration debt unless lifecycle controls are disciplined. Plugin-rich platforms make it easy to add AI-specific behaviours, but every extra policy creates order-of-operations risk, drift, and testing burden. In identity terms, that is similar to allowing privilege sprawl without ownership discipline. The practitioner conclusion is simple: configuration depth must be matched by review, versioning, and rollback controls.

Named concept: AI gateway governance gap. This is the gap between being able to route AI traffic and being able to prove who controlled it, what it accessed, and how decisions were enforced. Kong AI reviews expose that gap clearly because platform maturity can look strong while governance evidence remains incomplete. Practitioners should use this concept when separating infrastructure readiness from regulated AI readiness.

What this signals

The governance signal for readers is straightforward: if your AI architecture still treats the gateway as the primary security boundary, you are probably under-controlling identity and tool risk. The control plane now has to carry auditability and attribution, not just routing decisions. For teams working to the NIST AI Risk Management Framework, that means aligning gateway policy with accountable AI operations rather than assuming traffic mediation is enough.

AI gateway governance gap: the operational blind spot appears when routing, caching, and rate limiting are in place but identity propagation and MCP enforcement are not. That combination creates the illusion of control while leaving the real decision path opaque. Practitioners should pair gateway reviews with policy evidence, log correlation, and tool-level authorisation checks.

For identity teams, the programme implication is to treat AI agents as governed non-human actors only when the platform can preserve attribution across models, tools, and users. That is where AI security starts to intersect directly with IAM and NHI governance. When that chain is broken, the organisation may still have an AI gateway, but it does not yet have governed AI.

For practitioners

• Validate identity propagation across the AI request path Test whether the gateway preserves user, service, and agent identity through logs, traces, and policy events, not just the outer request metadata.
• Map MCP tool controls to explicit authorisation checks Require pre-tool policy enforcement, ownership records, and audit logs for every MCP server and tool invocation, including fallback and retry paths.
• Enforce token-aware budgets and stop conditions Set per-team and per-agent quotas that can terminate usage before runaway loops, provider retries, or cost spikes create operational risk.
• Separate routing capability from governance evidence Use the gateway for traffic control, then confirm you can export audit-grade records for access, cost, and tool use to your SIEM or GRC workflow.
• Review plugin order and lifecycle controls Version plugin changes, test policy ordering, and document rollback paths so prompt handling, sanitisation, caching, and rate limiting do not conflict in production.

Key takeaways

• Kong AI reviews show strong gateway maturity, but routing performance does not equal governance readiness for AI traffic, tools, and identities.
• The biggest control gaps are identity propagation, MCP authorisation, and token-aware budgets, because those are what turn traffic management into accountable AI operations.
• Teams should evaluate AI gateways as one layer in a wider control stack, then prove auditability, enforcement, and lifecycle discipline before production rollout.

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.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Identity propagation: The preservation of origin and acting principal information as a request moves through multiple services. In MCP chains, this is what allows downstream systems to make a trustworthy authorization decision instead of relying on a stripped-down token with no task context.
• Token-Aware Governance: Token-aware governance is the practice of controlling AI usage based on model consumption rather than only on request counts or network traffic. It helps security and finance teams enforce quotas, detect abuse, and link spend to accountable owners or workloads.

What's in the full article

TruFoundry's full analysis covers the operational detail this post intentionally leaves for the source:

• Pricing and tier distinctions between free, paid, and enterprise AI Gateway capabilities
• Concrete examples of AI Proxy, RAG Injector, sanitisation, and semantic caching configuration
• Evaluation questions for MCP Registry coverage, audit logging, and deployment boundaries
• Review-based context on configuration overhead, support expectations, and platform maturity

👉 The full TruFoundry article covers plugin-specific detail, review patterns, and AI governance checks in more depth.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is designed for practitioners building control frameworks across modern identity programmes.