# agentgateway vs LiteLLM vs Portkey: When Each

> When agentgateway, LiteLLM, or Portkey fits a Kubernetes agent platform: the job each does, a when-each table, and demos for budgets and MCP federation.

- Canonical URL: https://webofmike.com/agentgateway-vs-litellm-vs-portkey/
- Author: Mike Moore (https://webofmike.com/about/)
- Published: 2026-09-29
- Last modified: 2026-09-29
- Tags: AI Gateways, Kubernetes, Platform Engineering, Generative AI, MCP
- Cite as: Mike Moore, "agentgateway vs LiteLLM vs Portkey: When Each", Web of Mike (webofmike.com), 2026-09-29. https://webofmike.com/agentgateway-vs-litellm-vs-portkey/


Three products get compared side by side because they all speak an OpenAI-compatible API and they all say MCP on the datasheet. They share an API surface, not a job. The useful question is which plane you are buying: a Python LLM proxy and SDK, a managed AI-ops control plane, or a Kubernetes Gateway API data plane that also carries ordinary services.

I have been running agentgateway in public demos for the controls that decide that choice. Those demos are evidence for one column, not a claim that the other two products are empty. Product facts below come from primary docs. Last checked 2026-09-25.

## The one-paragraph verdict

Use **LiteLLM** when the binding constraint is provider catalog breadth or a Python SDK in process, and virtual keys plus OSS budgets are enough for the next year. Gateway API, SPIFFE, and a general service plane are out of scope. Use **Portkey** when the team wants hosted observability, prompt management, and governance workflows, and would rather not operate a gateway. The OSS gateway is not the full product. Use **agentgateway** when you need one Kubernetes-native data plane for HTTP, gRPC, LLM, MCP, and A2A, with identity, hard spend caps, and tool policy on that same path, preferably without discovering the next control behind a license key. If you already standardized on Kong, Agent Router, or a cloud APIM AI gateway, extend that instead of adding a second front door.

## They are not the same product category

**agentgateway** is a unified HTTP, gRPC, LLM, MCP, and A2A data plane. It is written in Rust, licensed Apache 2.0, donated to the Linux Foundation in 2025, and accepted as an [AAIF](https://agentgateway.dev/docs/standalone/latest/documentation/about/introduction/) project in 2026. On Kubernetes it is [conformant to Gateway API](https://agentgateway.dev/docs/kubernetes/latest/) (`HTTPRoute`, `GRPCRoute`, `TCPRoute`, `TLSRoute`). You can front ordinary APIs with the same proxy you use for models and agent protocols.

**LiteLLM** is a Python LLM proxy plus SDK with the widest provider catalog I would actually bet a lab on. The [project](https://github.com/BerriAI/litellm) describes 100+ LLM APIs through one OpenAI-compatible surface. Virtual keys, spend tracking, and dollar budgets are in OSS, backed by Postgres. [Enterprise](https://docs.litellm.ai/docs/enterprise) adds SSO, SCIM, OIDC and JWT auth, secret managers, key rotation, and org/project admin behind `LITELLM_LICENSE`. Code under `enterprise/` is a separate commercial license.

**Portkey** is a managed AI-ops and governance plane with an MIT-licensed gateway core you can `npx`. Palo Alto Networks [closed the acquisition](https://www.paloaltonetworks.com/company/press/2026/palo-alto-networks-completes-acquisition-of-portkey-to-secure-ai-agents) on 2026-05-29. Current docs brand it [Prisma AIRS AI Gateway](https://docs.paloaltonetworks.com/prisma-airs/ai-gateway/ai-gateway-overview): SaaS or hybrid data plane, workspaces, virtual keys, guardrails, prompt management, and hosted logs. Self-hosting the OSS gateway and then connecting it to Portkey is a supported path, not the default experience.

### Shared surface that creates false equivalence

All three terminate `/chat/completions`. All three can hold provider credentials off the agent and issue a gateway-scoped key. All three now have an MCP story. That is enough to make a feature matrix look interchangeable.

The split shows up when you ask three other questions. Does this proxy also carry the REST and gRPC services the agents call? Can a workload prove who it is with SPIFFE, or only with a bearer token you issued? When a dollar budget is gone, what status code comes back, and does the check fail open if the store is missing? Those answers do not live in a provider-count column.

## Comparison table

Cells are OSS, paid, partial, or N/A. "Partial" means the surface exists and the control you need is thinner than the checkbox.

| Row | agentgateway | LiteLLM | Portkey |
| --- | --- | --- | --- |
| Runtime | Rust proxy; binary or Kubernetes controller | Python proxy and SDK; Postgres for keys and budgets | Managed control plane; MIT Node gateway you can attach |
| License and paid line | Apache 2.0. [Solo Enterprise](https://docs.solo.io/agentgateway/) is a separate distribution | MIT proxy. `enterprise/` and `LITELLM_LICENSE` gate SSO, OIDC/JWT, vault, key rotation, org admin | MIT gateway. Workspaces, logs, prompts, MCP registry live on the commercial/SaaS plane |
| Non-AI HTTP/gRPC | First-class. Same proxy as LLM, MCP, A2A | N/A as a service plane | N/A as a service plane. gRPC listed as beta transport |
| Kubernetes Gateway API | Conformant: HTTPRoute, GRPCRoute, TCPRoute, TLSRoute | Runs on Kubernetes. Not a Gateway API implementation | Hybrid Helm data plane. Not a Gateway API implementation |
| LLM catalog | OpenAI-compatible front of major providers and self-hosted inference | Binding strength: 100+ APIs, in-process SDK | Binding strength on the managed plane: PANW docs cite 1,600+ models / 50+ providers |
| MCP | OSS: federation, transports, CEL tool authz | MCP gateway on the same virtual-key plane | Workspace and server access available. [Claim-based tool authz](https://portkey.ai/docs/product/mcp-gateway/authorization) and MCP guardrails: coming soon. Tool enable/disable exists |
| A2A | Native, same proxy | A2A agent gateway, same virtual keys | Agent gateway on the Prisma AIRS/Portkey plane, not the OSS binary as a general A2A data plane |
| Virtual keys and dollar budgets | OSS v1.5.0: per-key token or USD, `Block` = HTTP 429. CRD budgets are Solo Enterprise | OSS key/team/user budgets, HTTP 429. **Fail open** without Postgres. Tag/model/project extras are Enterprise | Workspace and key usage limits. Exhaustion is HTTP **412**. 429 is rate limit. Confirm plan coverage |
| SPIFFE / workload identity | OSS v1.5.0: Workload API, `source.spiffeId` in CEL | N/A. JWT/OIDC request auth is Enterprise | N/A as SPIFFE. API keys, OAuth, IdP |
| Secretless upstream credentials | `backendAuth` attaches the provider key. Agent can present SPIFFE or a short-lived JWT | Proxy holds provider keys. Agent holds a virtual key. Vault is Enterprise | Gateway injects provider and MCP credentials. Agent holds a Portkey/workspace key |
| Egress / CONNECT | CONNECT-time destination control. Fail closed outside the workload | N/A. Application proxy | N/A. Application proxy |
| Observability | Proxy metrics and traces. You wire the backend | Logs and Prometheus in OSS. Per-team callback routing is Enterprise | Hosted logs and traces are the product |
| Ops footprint | Binary, or controller plus proxies. No Postgres on the OSS data plane | Proxy + Postgres. Redis for multi-instance | SaaS or hybrid. OSS gateway alone is not the control plane |
| Best fit | One Kubernetes plane for services, models, tools, agents | Catalog and Python SDK first | Managed AI ops first; Prisma AIRS trajectory |

## When to use LiteLLM

Use it when the team already writes Python, already calls many providers, and the next year is more models and spend reports, not one Gateway API for the cluster.

Print the [OSS versus Enterprise table](https://docs.litellm.ai/docs/enterprise) into the ADR before anyone says it is fully open. Virtual keys, spend tracking, and budgets are OSS. SSO past five UI users, OIDC/JWT on the request path, secret managers, key rotation, and org/project admin are not. Those flip on with `LITELLM_LICENSE`.

Budgets return 429 with `type: budget_exceeded` when Postgres is connected. [Without a database](https://docs.litellm.ai/docs/proxy/users) the global budget check is skipped and requests keep flowing. A warning at startup is not a cap. Gateway API, SPIFFE, and general HTTP/gRPC stay out of this column. The proxy can sit on Kubernetes. It is not the cluster's service plane.

## When to use Portkey

Use it when the team wants a hosted control plane more than it wants to own a proxy. Prompt management, guardrail workflows, workspace provisioning, and a log UI that already exists are the product. The MIT gateway is the data-plane option, not the thing you are buying.

Read the MCP docs as published. Workspace and server access are available. [Claim-based tool authorization](https://portkey.ai/docs/product/mcp-gateway/authorization) and [MCP guardrails](https://portkey.ai/docs/product/mcp-gateway/guardrails) are coming soon. Enabling or disabling tools in the registry is not CEL over `mcp.tool.name` on every call.

[Error docs](https://portkey.ai/docs/api-reference/inference-api/error-codes) map budget exhaustion to HTTP 412 and rate limits to 429. If runbooks treat 429 as stop-spending, write the 412 down. Confirm which plan includes the limit. Do not invent prices.

Palo Alto Networks closed the acquisition on 2026-05-29. Prisma AIRS is the platform the gateway sits in. That is the buying context: a Palo Alto Networks AI-ops trajectory, SaaS or hybrid, not a small independent proxy. Self-host only if you accept that the OSS binary without the control plane is a router.

## When to use agentgateway

Use it when the platform job is one front door for the traffic agents generate: ordinary services, model calls, MCP tools, and A2A, on Kubernetes, with policy you can review in Git. I ran that A2A path on an [LLM robot fleet on agentgateway](/llm-robot-fleet-agentgateway/).

That is what the public demos are for. [Per-key budgets](/agentgateway-per-key-llm-budgets/) in OSS v1.5.0 return HTTP 429. [SPIFFE](/spiffe-identity-for-ai-agents/) puts `source.spiffeId` in CEL with no certificate file on the path. [Secretless agents](/secretless-ai-agents/) call a model holding no provider credential. [MCP federation](/multi-tenant-mcp-federation/) (on Solo Enterprise) filters `tools/list` per tenant. [Egress](/agent-egress-control-bypasses/) authorizes the destination at CONNECT time.

Say the license line out loud. The proxy, Gateway API controller, MCP federation, A2A, JWT/CEL, SPIFFE, and standalone per-key budgets are Apache 2.0. Some Kubernetes CRDs I have used elsewhere (`EnterpriseAgentgatewayBudget`, `WAFPolicy`) are Solo Enterprise. The [cost-controls writeup](/llm-cost-controls-ai-gateway/) is the CRD path. The v1.5.0 budget demo is the OSS path. Put the one you are standardizing on in the ADR.

kagent is an agent runtime, not a fourth gateway. Pod-versus-agent sizing is [Agent Substrate](/kagent-agent-substrate/).

## Controls that actually decide platforms

Provider count decides a router. These five rows decide whether you can defend the design in review.

### Dollar budgets that return 429

A budget that increments a dashboard is accounting. A budget that refuses the call is a control. I ran the OSS path until the seventh request flipped: [alice 429, bob on his own bucket still 200](/agentgateway-per-key-llm-budgets/). Token counts are not dollars until a catalog prices the model ([cost controls](/llm-cost-controls-ai-gateway/), on Solo Enterprise). LiteLLM 429s when Postgres-backed spend crosses `max_budget`, and fails open without the DB. Portkey stops spend with 412. Write the status code and the store into the ADR.

### SPIFFE / workload identity

OAuth and a gateway API key are enough when a human is in the loop. They are the wrong primitive for a fleet of ephemeral agents. A bearer token can be copied. SPIFFE issues a short-lived SVID from attested workload properties. I ran that path with no certificate file on the agent, the gateway, or the model: [SPIFFE identity for AI agents](/spiffe-identity-for-ai-agents/). LiteLLM JWT/OIDC on the request path is Enterprise. Portkey uses API keys or an IdP. Neither is SPIFFE. "The agent is a workload" is a different requirement than "SSO for the admin UI."

### Secretless LLM keys

The agent needs to prove who it is. It does not need the provider credential. A vault changes where the key rests, not the moment the process holds plaintext.

On 2026-03-24, compromised LiteLLM wheels on PyPI harvested environment variables, `.env` files, cloud credentials, kubeconfigs, and SSH keys. [Sonatype](https://www.sonatype.com/blog/compromised-litellm-pypi-package-delivers-multi-stage-credential-stealer) and [InfoQ](https://www.infoq.com/news/2026/03/litellm-supply-chain-attack/) have the timeline. That is ADR context for key placement, not a scorecard dunk. On any of these products the gateway can attach the upstream key. The extra move on agentgateway is inbound SPIFFE or a 60-second JWT, so there is no long-lived `sk-` in the agent either: [secretless agents](/secretless-ai-agents/).

### Multi-tenant MCP federation and tool policy

A registry screenshot is not multi-tenant MCP. The control is one URL per domain, a different `tools/list` per caller, a deny-by-default allowlist, and a meter you can bill. I ran that pattern in [Multi-Tenant MCP Federation](/multi-tenant-mcp-federation/) on Solo Enterprise. How you slice those servers is [Conway's law for MCP servers](/conways-law-mcp-servers/). The OSS project documents multiplexing and per-client virtualization. Say which distribution you used to prove entitlements.

Prompt policy is not that control. An `AGENTS.md` sits in the same context window as the injection. The gateway allowlist stopped the call the file did not: [AGENTS.md is not a security control](/agents-md-not-a-security-control/). MCP still authenticates the employee more than the agent. Fill the gap at the gateway: [MCP agent identity](/mcp-agent-identity-gap/).

### Egress bypasses

A method-aware HTTP proxy is not an egress policy. I reproduced four bypasses, then put the same agent behind CONNECT-time destination control and watched all four fail: [egress control](/agent-egress-control-bypasses/). LiteLLM and Portkey are not that choke point. If agents leave the cluster, pick a second control or pick a proxy that does this job.

## Ops footprint and failure modes

**agentgateway.** A binary, or a controller plus proxies. No application database on the OSS request path.

**LiteLLM.** Python proxy plus Postgres if keys or budgets matter, plus Redis once you run more than one replica. Budgets [fail open](https://docs.litellm.ai/docs/proxy/users) without the database.

**Portkey.** Hosted control plane (Prisma AIRS path) with an optional hybrid data plane. The failure mode is dependency on that plane, not a local Postgres you forgot to size.

Supply-chain history belongs in the ADR as a key-placement argument, with the citations above. It does not belong as a scorecard dunk. The question is whether a stolen agent process still has a provider key.

## When neither is the right default

You already standardized on Agent Router, Kong, or a cloud APIM AI gateway, and the missing controls can be added there. A second front door is a second policy language and a second place agents will learn to bypass.

You do not have a platform team. Buy managed. Portkey, a cloud provider gateway, or whoever already holds your observability contract will beat a self-hosted plane you cannot page.

You need a thin router: one provider today, maybe two, no MCP federation, no workload identity, no egress story. Do not buy an agent platform for a `base_url` change.

## ADR checklist before the POC

- Tick the controls you need in the next six months: Gateway API, non-AI traffic, MCP tool entitlements, dollar fail-closed (and the status code), SPIFFE or JWT, secretless upstream keys, CONNECT-time egress, hosted vs self-hosted ops.
- Map each tick to OSS, paid, or missing on all three. Paste the table. Do not summarize it into "all have budgets."
- Run one MCP server and one provider through the finalist, on the same identity you will use in production. A lab key on localhost does not test SPIFFE or tenant filter.
- Write the when-each sentence into the ADR. If you cannot say why the other two lost, you are not done.

## Related demos

- [Per-key LLM budgets that return 429](/agentgateway-per-key-llm-budgets/)
- [Capping LLM spend at the AI gateway](/llm-cost-controls-ai-gateway/)
- [SPIFFE identity for AI agents](/spiffe-identity-for-ai-agents/)
- [Secretless AI agents](/secretless-ai-agents/)
- [Multi-tenant MCP federation](/multi-tenant-mcp-federation/)
- [Agent egress control bypasses](/agent-egress-control-bypasses/)
- [MCP agent identity gap](/mcp-agent-identity-gap/)
- [AGENTS.md is not a security control](/agents-md-not-a-security-control/)
- [kagent Agent Substrate](/kagent-agent-substrate/)

*Disclosure: I work at Solo.io, which makes agentgateway. The OSS project is [agentgateway/agentgateway](https://github.com/agentgateway/agentgateway). The demos linked above are public repositories and public posts. Product facts for LiteLLM and Portkey are from their docs, cited in place. I have not run a three-way latency or QPS bake-off, and I am not claiming one.*