Enterprises deploying AI agents often start their infrastructure evaluation with a traffic gateway. Cloudflare AI Gateway and Kong AI Gateway are both documented as request-layer products: they route calls to multiple LLM providers, cache responses, apply rate limits, and generate request and cost analytics. These are HTTP/API-layer functions. They operate per request, are stateless across a session, and treat every call as a discrete unit of traffic.
Runtime governance is a different problem. When an AI agent operates over multiple steps, invoking several tools through the Model Context Protocol (MCP) within a single task, the relevant unit of control is not the individual HTTP request but the agent's identity, its permitted scope of tool access, and the sequence of actions it takes. Public documentation for Cloudflare AI Gateway and Kong AI Gateway does not describe native agent identity management or per-tool-call permission enforcement as core features. This is not a shortcoming of either product; it reflects a difference in what each was built to do. The practical risk for enterprises is conflating the two categories during procurement and assuming traffic-layer observability satisfies governance and audit requirements it was not designed to meet.
Capability Comparison Across the Gateway Stack
Each product occupies a distinct role in an enterprise AI stack. The summary below reflects what is documented for each, not a ranking of features.
Cloudflare AI Gateway
Unified routing across LLM providers with caching, rate limiting, and request analytics.
Kong AI Gateway
Plugin-based LLM routing on Kong Gateway with semantic caching and prompt filtering.
Trussed
Runtime governance for agent identity, tool-call permissions, and audit logging across MCP sessions.
MCP and the Boundary Between Request Control and Tool Governance
Model Context Protocol, published by Anthropic in November 2024, defines how AI agents discover and invoke external tools and data sources. The specification includes a transport and tool-discovery/invocation model, with a separate OAuth-based authorization component added as the protocol matured. MCP standardizes how a tool call is structured and transmitted; it does not, by itself, decide which agent is allowed to call which tool, under what conditions, or with what scope of data access. That decision is left to the implementing organization.
This is the architectural boundary platform teams need to evaluate carefully. A traffic gateway sitting in front of an MCP server can apply rate limits and log the HTTP envelope of a tool call. Based on reviewed documentation, it cannot evaluate agent identity, enforce least-privilege scopes across a multi-step session, or produce an audit record that attributes a specific tool invocation to a specific agent and policy decision. Runtime governance operates at this session-aware, identity-aware layer, tracking state across the sequence of tool calls an agent makes rather than treating each call as an independent, unrelated request.
Where Each Tool Fits in an Enterprise Stack
Cloudflare AI Gateway is positioned as a routing and observability layer for organizations calling multiple LLM providers. It fits well where the primary need is provider failover, cost tracking, and response caching at the API level. Kong AI Gateway extends an existing Kong Gateway deployment with LLM-specific plugins, including semantic caching and prompt-pattern filtering, making it a fit for teams already standardized on Kong for API management who want to add LLM traffic handling without introducing a new platform.
Trussed operates at the runtime governance layer: agent identity, tool-call permissions, least-privilege enforcement, tool approval workflows, and audit logging for agent and MCP-based sessions. It is not a substitute for a traffic gateway's routing, caching, or provider failover functions, and it does not claim those capabilities. For enterprises running AI agents that invoke multiple tools across a session, particularly where compliance requires an attributable record of what an agent did and why it was permitted to do so, a traffic gateway alone does not produce that record.
The practical implication for platform teams is that these are not mutually exclusive purchases evaluated against each other on a single feature checklist. Many enterprise stacks will use a traffic gateway for provider routing and cost control, and a governance layer for agent identity, permissioning, and audit. The evaluation question is not which single tool wins, but which combination covers both the request layer and the agent runtime layer without leaving a gap between them.