Speakeasy vs Kong MCP gateway: Which layer should govern your agents' tool calls?

Kong treats Model Context Protocol (MCP) traffic as one more kind of API traffic. Its AI Gateway converts REST APIs into MCP tools, fronts existing MCP servers, and applies the same authentication, rate limiting, and logging that already govern your APIs. If your platform team runs Kong well and needs the gateway inside its own network, that is a strong answer, and we say so below.

Speakeasy is the better fit when the hard question is which people, agents, and AI clients may reach which tools, and that answer has to come from your identity provider rather than from gateway configuration. This post compares the two on six dimensions: identity, per-tool policy, client admission, upstream credentials, audit, and deployment. Kong wins the last one outright.

Where do Kong and Speakeasy sit?

Kong ships MCP support in two shapes. On Kong Gateway 3.12 and later, the AI MCP Proxy plugin bridges MCP and HTTP: it can proxy an existing MCP server, convert REST endpoints described by OpenAPI into MCP tools, or aggregate tools from several plugins behind one endpoint. Both it and the AI MCP OAuth2 plugin are part of the AI Gateway Enterprise offering. In AI Gateway 2.x, managed through Konnect, the same capabilities become a first-class AI MCP Server entity with built-in access fields, so you declare the server instead of wiring Services, Routes, and plugins.

Speakeasy's MCP gateway is one part of an AI Control Plane: the governing layer between every AI agent in an organization and the systems it is allowed to reach. People and roles come from your directory, AI clients are admitted or refused at sign-in, and the same platform hosts servers, generates them from OpenAPI documents, and proxies remote ones.

The difference in starting point explains most of what follows. Kong extends an API gateway that already knows how to authenticate a request, so its MCP features inherit Kong's model of identity and policy. Speakeasy started from the MCP session, so its features start from who the person is, which client they are using, and which tool they are calling.

Speakeasy vs Kong at a glance

What Kong does well

Kong's case is strongest for a company that already fronts its APIs with Kong. MCP becomes another route on infrastructure the platform team already operates, reviewed under a security assessment that has already happened, with no new vendor. The openapi2mcp command in decK turns an OpenAPI document into a Gateway Service, an MCP Route, and the tool definitions, and the plugin runs on the gateway itself, so there is no separate MCP server to host or scale.

The plugin catalog carries over. The AI MCP Proxy plugin page lists OpenID Connect and key authentication, rate limiting, request and response transformation, ACL, and logging plugins as available on MCP endpoints. Kong's identity story is broader than "Kong Consumers" suggests: an AI Auth Strategy of type openid-connect accepts tokens from Okta, Azure AD, Google, or any OIDC provider, and Kong's token exchange support can swap that token for one issued by a different authorization server before the call reaches the upstream.

Kong's MCP logging is detailed. The AI audit log reference records session IDs, JSON-RPC methods, tool names, latencies, request and response payloads, and an allow or deny entry for every access-control decision, naming the AI Consumer. Third-party plugins such as CrowdStrike Falcon AIDR MCP inspect tool listings, inputs, and outputs at the same gateway.

Kong also has documented limits on MCP traffic. The AI MCP Proxy plugin's scope of support table lists AI Guardrails, structured output, tool-change notifications, and session sharing between instances as not supported. The AI MCP Server reference notes that AI Policies built for LLM prompt and response flows, such as prompt guards, don't apply to MCP traffic. Partner plugins fill some of that gap; Kong's own guardrails don't.

Who is the caller: a Kong Consumer or a directory identity?

In Kong, authorization decisions land on an AI Consumer. Kong's auth strategy documentation describes the AI Consumer as an "AI Gateway-local identity": an OIDC token from your IdP is validated, then a claim in it is mapped to that local record, and AI Consumer Groups, ACLs, and policies attach to the record. Kong also lets an ACL evaluate a token claim directly, such as an email or a group, instead of a Consumer. Either way, the group structure your ACLs depend on lives in Kong configuration or in whatever claims your IdP puts in the token.

Speakeasy keeps the directory as the source of record. Directory Sync provisions members over SCIM and assigns roles from IdP group mappings, and once it is on, role membership in the dashboard is read-only and marked Managed by directory sync. Deprovisioning a person in the IdP ends their membership and role assignments right away, and agents they own are blocked until an admin reassigns them. Roles can also be assigned to registered agent identities, filtered against an agent runtime scope allowlist so a role can't hand an agent a scope it couldn't hold directly.

For Okta shops, Enterprise Managed Auth goes a step further: a person signs in once with Okta and reaches every MCP server set up for them, without a separate OAuth prompt per service. Speakeasy reads Okta through an API service app with read-only scopes (okta.apps.read, okta.users.read, okta.groups.read) and never writes to the Okta org. The trade-off is that Okta is the only supported provider for this today, and each downstream service needs an authorization server that supports Cross App Access. The Okta use case page walks through the setup.

How fine-grained can per-tool policy get?

Both products restrict individual tools. Kong evaluates a default ACL and per-tool ACLs on each MCP server, deny first, and filters tools/list so a Consumer sees only the tools they may call. Kong documents one sharp edge: a per-tool ACL replaces the default ACL for that tool rather than merging with it, so every allowed subject has to be listed again. Because the rules are configuration, teams that manage gateways through decK, Terraform, or Kubernetes operators get policy as code with no extra tooling.

Speakeasy writes per-tool policy as part of a role that spans the organization. The role editor narrows mcp:connect to All servers, Specific projects, Specific servers, or Specific tools, and the same rules appear on each server's Team Access tab. Remote and tunneled servers can be permissioned by tool name once their tool metadata has been recorded. Each scope has a blocking counterpart, such as mcp:blocked_connect, that withdraws access for matching resources even when another role grants it. Blocking scopes can't be written against agents.

A Kong ACL belongs to one MCP server, so a "finance analysts can call read-only billing tools" rule is repeated on each server that carries billing tools. A Speakeasy role states that rule once, against an IdP group, and a denied request shows up as an authorization challenge an admin can resolve by granting a narrower role.

Which AI clients are allowed to connect at all?

A tool permission says nothing about the software making the call. An engineer with legitimate access to a CRM server might connect through an approved coding agent or through an unreviewed desktop app, and both present the same user.

In Kong's design, the AI MCP OAuth2 plugin acts as the resource server: it validates tokens issued by an external authorization server and checks the audience. Which MCP clients can obtain a token is decided by that authorization server's client registrations, outside Kong. Kong's inventory features catalog servers, not clients. MCP servers in Catalog are defined manually, pasted as JSON, or imported from AI Gateway, and the MCP Registry is a tech preview enabled on request.

Speakeasy acts as the OAuth authorization server for servers with user sessions, which lets it make client admission a policy. Each server's Client access setting can limit which clients that identify with a Client ID Metadata Document (CIMD) are admitted. Shadow AI, generally available under Guardrails for every organization, inventories the coding harnesses, assistants, and local models that enrolled devices report. An admin marks a tool Approved or Blocked, and a blocked tool is refused when it authenticates, on every MCP server in the organization. The allow and block list guide covers the server-side equivalent for shadow MCP servers.

Three limits apply. Enforcement depends on the tool publishing a CIMD; decisions about tools without an MCP client, and about local models, are recorded rather than enforced. The Client access allowlist doesn't restrict clients that register through Dynamic Client Registration (DCR). And a tool on an unenrolled device doesn't appear in the inventory at all.

Whose credential reaches the upstream service?

Kong's external MCP gateway cookbook lays out its two patterns for third-party servers. In the passthrough pattern, the user authenticates directly with the upstream (GitHub, in Kong's example), Kong forwards that token, and a separate Key Auth layer supplies the Consumer identity for ACLs. In the token swap pattern, Kong authenticates the user against your IdP and replaces their token with a stored shared credential. For internal services, token exchange trades the user's token for one from another authorization server, and the AI MCP Server entity supports AWS SigV4 signing for IAM-protected upstreams.

Speakeasy offers the same two choices, with the platform holding the per-user grant. With per-user credentials, the platform is the OAuth client of the upstream and stores an access token and refresh token for each person, encrypted and refreshed silently, so a Linear tool call runs as that person in Linear. With a shared credential, each remote server uses one static key or an OAuth client credentials token for every caller; the static credential guide covers the setup. With Enterprise Managed Auth, Okta supplies the upstream token on each call, and removing a person or a resource connection in Okta stops new access to every server that uses it.

Two documented costs come with Speakeasy's approach. One expired upstream credential fails every tool served through that issuer until the person reconnects. Revoking a person's session in Speakeasy doesn't revoke the grant at the provider, so offboarding still needs the IdP or the provider to cut access.

What does the audit trail record?

Kong's MCP audit data is request-level and thorough, as described above, and it flows into whatever logging pipeline your Kong deployment already feeds, through file log or OpenTelemetry policies. Because the log includes request and response payloads, the team operating the logging sink also holds tool inputs and outputs.

Speakeasy splits the record in two. The Audit Logs feed covers administrative activity across the organization: each entry carries a resource:action badge, the actor, a diff of what changed, and the surface it came from (an API key, the Platform MCP, or the Project assistant), with filters and an Audit Log Insights assistant for questions. MCP session revocations and transcript opens are audit-logged, and the chat:read scope needed to review transcripts is in no default role, including Admin. Tool activity goes to Tool Logs, which list every observed call with its server, tool, user, client, and status.

If your auditors ask "which calls did this person make", both products can answer. If they ask "who changed the policy that allowed it, and from where", Speakeasy answers that in the same product.

Where does the gateway run?

Kong is the stronger choice when the gateway has to run inside your network. Kong Gateway runs self-hosted in traditional, hybrid, or DB-less mode, and Konnect supports data planes you host, Kong-managed Dedicated Cloud Gateways on AWS and Azure, and serverless gateways. Dedicated Cloud Gateways can run in a private networking mode with private IP addresses only, reached through network peering or Transit Gateway. AI Gateway 2.x entities are managed through Konnect, while on-prem deployments use the plugin model.

Speakeasy is a managed gateway, and it doesn't run in your VPC, on-premises, or air-gapped. Two features narrow the gap for teams whose real requirement is that MCP traffic stays off the public internet. Tailscale private access puts hosted MCP servers and gateways on your tailnet, with each server set to Public only, Public and private, or Private only. It requires an Enterprise organization. Private-only servers have no automatic public fallback, and the setting covers client-facing MCP endpoints, not the dashboard or management APIs. For backends inside your network, tunneled servers open an outbound connection, so the service never needs public ingress.

Whether that is enough depends on how your security team phrases the requirement. If it is "no MCP endpoint reachable from the internet", Tailscale private access on an Enterprise org can meet it; our private MCP gateway guide explains how to tell that apart from a self-hosting requirement. If it is "the gateway process runs on infrastructure we operate", choose Kong or another self-hosted gateway.

When should you choose Kong?

Choose Kong when most of these are true:

• You already operate Kong Gateway or Konnect. MCP routes sit next to your API routes, under the same plugins, logging pipeline, and on-call rotation.
• The gateway must run on infrastructure you control. Self-hosted data planes, on-prem, or a private Dedicated Cloud Gateway are documented options; Speakeasy has none of them.
• Your MCP tools are mostly your own REST APIs. Kong's openapi2mcp command and conversion modes turn them into tools without hosting MCP servers.
• Policy is managed as code by a platform team. ACLs in decK or Terraform fit an existing GitOps workflow.
• Your IdP already puts the right claims in tokens. Claim-based ACLs can stand in for a synced directory when groups are stable.

Kong's AI Gateway Enterprise licensing is part of the cost, and the Kong MCP gateway alternatives post covers options for teams that don't run Kong today.

When should you choose Speakeasy?

Choose Speakeasy when MCP governance is owned by security or AI enablement rather than the API team, and the questions are about people and clients rather than routes. Roles follow IdP group mappings and end on deprovisioning. Per-tool grants are written once per role instead of once per server. Blocked AI clients are refused on every server in the organization. The platform holds and refreshes per-user upstream grants, and the audit feed records who changed which policy, from which surface.

You give up the option to run the gateway yourself. For many teams, Tailscale private access on an Enterprise org and outbound tunnels cover the underlying network requirement; for some, they won't, and Kong is the better choice for them. The Speakeasy vs Kong comparison page and our enterprise MCP gateway roundup cover adjacent ground.

If you're running Kong for APIs and weighing whether MCP belongs there too, we'd be interested to hear how you're approaching it.