Portkey vs Kong AI Gateway (2026): AI Gateways Compared — and Where Kosmoy Fits

Three shapes on the same ten axes. Portkey (orange) and Kong AI Gateway (violet) both peak on Gateway & Policy Control; Portkey reaches higher on observability and FinOps, Kong a little further on open-source coverage and per-tool MCP governance. Both cluster low on the governance axes — the gateway category's signature. Kosmoy (blue) trades some raw gateway breadth for reach across inventory, compliance and agent containment. Read it as area: the two gateways compete on one spoke; the suite covers the web.

Observability depth. Full request/response logging, tracing, 21+ analytics metrics, per-key and per-workspace budgets and FinOps/executive dashboards make Portkey an integrated cost-and-usage control plane (Portkey observability), where Kong's LLM analytics are a Konnect-tier add-on.

Model breadth and a prompt studio. One API to 250+ LLMs / 1,600+ models across 45+ providers, plus a versioned Prompt Engineering Studio with a cross-model playground that Kong has no equivalent for.

Turnkey guardrails. 20+ deterministic checks plus LLM-based checks with synchronous blocking (HTTP 446) and streaming output guardrails, integrated in the platform rather than assembled from plugins.

Open-source momentum. An Apache-2.0 core with ~43.8k stars and active development (releases 3.13 and 3.14 shipped in early 2026), versus Portkey's OSS gateway (MIT, ~12.4k) with no release since January 2026 and a roadmap now inside Palo Alto Networks.

Granular MCP governance on a proven runtime. MCP Tool ACLs, OAuth2 scope-based tool filtering and RFC 8693 token exchange deliver per-tool authorization on the same engine enterprises already run for their APIs — both vendors govern MCP and A2A, but Kong's tool-level control is more granular.

Roadmap independence. Kong remains independent and shipping; Portkey's public docs changelog has been quiet since April 2026 after the acquisition closed in May 2026.

Both Portkey and Kong answer “how do we route and govern model, MCP and agent traffic?” Neither answers “what AI are we running across the organization, is it compliant, and what happens when an agent misbehaves?” Those are different questions, and in a regulated enterprise they arrive together.

Kosmoy includes the gateway both products are — one OpenAI-compatible policy point with guardrails, RBAC, budgets and logging — but wraps it in the three layers a gateway leaves out: a risk-tiered inventory of every model, MCP server and agent (including a master agent registry that pulls from Foundry, Bedrock, Vertex, Salesforce and ServiceNow); EU AI Act, ISO 42001 (aligned) and NIST AI RMF evidence built from registry state plus gateway logs; and kernel-enforced Action Capsule containment for agents that act.

So the honest framing is not “Kosmoy beats Portkey and Kong at being a gateway” — they are capable gateways, and each leads on real spokes. It is that a gateway is one spoke. If the requirement is the whole web — inventory, gateway, compliance and containment in one self-hosted platform — that is a suite decision, not a gateway decision.

For a team whose problem genuinely is model, MCP and agent traffic, pick on the axis that matters: Portkey for an integrated managed control plane with observability and prompt depth, Kong to extend a large open-source runtime — and existing API-gateway estate — across all three AI traffic patterns. Both offer self-hosted paths, so a later move is largely a configuration exercise.

For an enterprise that has to prove control over all of its AI — not just route it — the choice is not between these two gateways but between a point tool and a suite. Kosmoy can also sit in front of either: some teams keep a specialist gateway for a specific stack while Kosmoy holds the inventory, compliance evidence and containment for what reaches production.