Portkey's public offering includes a managed AI gateway: a single API in front of multiple model providers, with virtual keys, budgets, rate limits, caching, and observability shipped as built-in product features rather than assembled configuration. Its documentation also includes an MCP gateway for configured MCP servers. Portkey is now part of Palo Alto Networks, which completed its acquisition of Portkey on May 29, 2026; Portkey's site now presents the product as Prisma AIRS AI Gateway. Teams evaluating alternatives are usually deciding along one axis — how much of that infrastructure they want to run themselves versus hand to a managed vendor — and along a second, less obvious axis: whether their actual traffic is LLM-provider calls, agentic tool-calling traffic, or both. Other vendor-by-vendor guides are collected on the comparison hub.
Evaluate one Praesidia model route
Review Praesidia's model gateway for supported APIs and limits, then follow Your First Model Request. You need a workspace, permission to configure a provider, your provider account and key, a Praesidia application key, and the workspace's gateway address from your administrator or Praesidia support. Real requests incur provider charges, including on a free Praesidia plan. Check the returned model and recorded workspace usage before increasing traffic. For MCP access, use the separate connection quickstart; its controls apply to the registered, routed connections you configure.
What a managed AI gateway is built for
An AI gateway sits between applications and model providers, giving a platform team one place to manage provider credentials, enforce spend and rate limits, cache repeated requests, and observe traffic across every team calling into it. Portkey's public materials describe this as a managed, product-first version of that layer: RBAC, SSO, budgets, and compliance-oriented controls presented as configurable features rather than infrastructure you build and patch yourself. That is a meaningful difference from a self-hosted approach — the operational burden of running and upgrading the proxy moves to the vendor, in exchange for a dependency on that vendor's roadmap and data-handling posture. For what to require from that layer whichever vendor runs it, see the AI gateway guide.
This category exists because provider-key sprawl and inconsistent per-team cost tracking are real, common failure modes once more than a couple of teams start calling model providers independently. A gateway consolidates that into one control point, which is valuable in direct proportion to how many teams and providers you actually have — a single team calling a single provider usually doesn't need a gateway in front of it at all.
Check model traffic and MCP tool calls separately
Model-provider requests carry prompts and completions between an application and a model provider. MCP tool calls are a separate path with their own credentials, permissions, and effects: a tool can execute an action. Portkey's MCP gateway documentation, reviewed on 22 October 2026, describes authentication, server and tool access checks, upstream credential injection, and request logging. It also documents tool provisioning and guardrails, including approval workflows. These are documented capabilities; this guide does not report a hands-on Portkey test or establish availability in every plan or deployment.
For any candidate, confirm the configured paths and test the controls you need on each. A successful model response does not demonstrate that a disallowed MCP tool call is refused. The two flows and evaluation questions are covered in more depth in MCP gateway comparison 2026.
Evaluation lenses that actually separate gateway options
- Operating model. Fully managed cloud, self-hosted open source, or an extension of an API gateway you already run — each trades operational burden for control differently, covered generally in self-hosted vs. managed AI governance.
- Enforcement vs. tracking on spend. Confirm whether a budget limit actually stops further calls once breached, or only reports spend after the fact — the difference determines whether you have a control or a dashboard, detailed in budgets vs. rate limits.
- Traffic scope. LLM-provider calls only, or also MCP/tool-calling traffic. Agentic estates need both covered, whether by one system or two.
- Provider breadth and consistency. Does policy (budgets, rate limits, logging) apply uniformly across every provider routed through the gateway, or does coverage vary by provider?
- Key and credential handling. How are provider credentials stored and rotated, and does the gateway reduce the number of places raw provider keys exist in your estate — see securing LLM provider API keys for why key sprawl is a security problem independent of which gateway you pick.
Comparing approaches
| Approach | Operating model | Reach for it when |
|---|---|---|
| Managed AI gateway (Portkey and similar) | Fully managed cloud | You want governance (RBAC, SSO, budgets) as a product feature without operating infrastructure |
| Self-hosted open-source gateway | You run and patch it | Full data-path control and no per-seat cost matter more than operational simplicity, see LiteLLM enterprise alternatives |
| Extension of an existing API gateway | Platform you already operate | You already run a general-purpose API gateway and want to add AI-specific routing to it |
| Edge-native managed gateway | Managed, tied to an edge network | Your traffic already flows through that edge network |
Match the scope to your traffic
If your question is "how do we route and control LLM-provider traffic across teams without running our own proxy," evaluate a managed AI gateway and the self-hosted and platform-extension approaches above against your actual team count, provider count, and on-call capacity, per the LLM gateway comparison 2026. If you also need to authorize and audit tool calls, include the candidate's MCP path in that evaluation. Portkey documents both paths; do not infer their coverage from the model-routing features alone. Check which identities, permissions, approval decisions, and audit records your configured deployment supports. That evidence determines whether one platform or complementary systems fit your requirements.
Migration and rollout considerations
Switching or adding a gateway needs a route-by-route compatibility check. For an API-compatible route, an existing SDK may need only a base URL and credential configuration change, as the Praesidia model gateway examples illustrate. Check provider-specific API features, streaming, tool support, errors, and credential handling before treating that configuration change as a complete migration. An internal wrapper can centralize these changes, but each application's configured route still needs verification.
Rollout order also matters more than it first appears. Moving every team and every provider onto a new gateway simultaneously maximizes the blast radius of a misconfiguration; a staged rollout — one team, one provider, then expanding — surfaces integration issues (unexpected latency, a provider-specific feature the gateway doesn't pass through cleanly, a logging gap) while the cost of a mistake is still small. The same staged-rollout logic that applies to guardrail changes, described in staged guardrail rollout and shadow mode, applies just as well to a gateway migration: run the new path in parallel, observe it against production traffic, and only cut traffic over once its behavior matches expectations under real load.
Finally, plan for the rollback path before you need it. A gateway that becomes a single point of failure for every team's model access needs the same operational rigor as any other production-critical dependency — health checks, a documented fallback (direct provider access, or a secondary gateway instance), and a clear owner for on-call response. High availability for an AI control plane covers the general reliability pattern that a gateway carrying meaningful production traffic needs to meet.
What good looks like
- You know exactly how many teams and providers route through your gateway today, and that number, not brand preference, is driving the managed-vs-self-hosted decision.
- Budget limits are enforced, not just reported — verified by testing that a call is actually blocked once a limit is crossed.
- You have a documented answer for tool-calling traffic, whether that's the same gateway, a dedicated MCP gateway, or an explicit decision that it's out of scope for now.
- Provider credentials live in one place, not scattered across every application that calls a model directly.
- A proof-of-concept ran real traffic through the candidate, not just a routing and latency benchmark, before committing to a migration.
If you want a bring-your-own-key gateway that keeps provider keys server-side, see Praesidia's model gateway.
Common questions
What is Portkey known for? Its public offering includes a managed AI gateway providing a unified API across model providers, with RBAC, SSO, budgets, rate limits, caching, and observability. Its MCP gateway documentation also describes controls for configured MCP servers. Confirm current packaging and plan availability directly.
Who owns Portkey now? Palo Alto Networks, which completed its acquisition of Portkey on May 29, 2026. Portkey's site now presents the gateway as Prisma AIRS AI Gateway, so check current packaging and pricing with Palo Alto Networks before shortlisting it.
Is an AI gateway the same thing as an agent governance platform? The labels overlap. Model-provider routing, MCP tool authorization, per-agent identity, approvals, and audit evidence are different controls and paths that a product may combine. Portkey documents an MCP gateway alongside its AI gateway. Evaluate the configured controls and their evidence rather than relying on the category label.
When does a team not need a gateway at all? When a single team calls a single model provider directly, a gateway typically adds operational overhead without a corresponding benefit — direct SDK integration is simpler. The case for a gateway strengthens as team count, provider count, and traffic volume grow.
Does a managed gateway remove the need to think about data residency? No — it changes where that responsibility sits. Confirm any managed vendor's current documentation on data handling and residency directly, especially if your traffic includes regulated data; see data residency for AI agents for the questions to ask.