Re-Evaluating Your MCP Gateway After the Portkey Acquisition

Palo Alto Networks announced its acquisition of Portkey on April 30, 2026, expected to close in PANW’s fourth quarter of fiscal 2026. Portkey will serve as the AI Gateway for Prisma AIRS, PANW’s “central nervous system” for monitoring, routing, and securing every AI transaction across the enterprise.

An MCP gateway sits between MCP clients (Claude Desktop, Cursor, ChatGPT, VS Code) and the MCP servers your team connects to (Linear, GitHub, Notion, Stripe, internal). It authenticates the user, brokers per-service OAuth, enforces tool-level access, and writes the audit log.

The deal is good news for Portkey, its investors, and PANW’s AI security story. It also changes the math for buyers before their next renewal.

Here’s the five-question framework I’d run before signing or extending any MCP gateway contract in the next twelve months.

1. Is the gateway optimizing for your persona, or your acquirer’s?

Portkey’s message to customers is reassuring: same gateway, same APIs, same team. Take it at face value. The question isn’t whether anyone intends to neglect the developer surface; it’s where investment flows once the roadmap sits inside Prisma AIRS.

Every acquired product eventually serves the buying motion of the parent. PANW sells Prisma AIRS to Fortune 500 security organizations on multi-year ELAs, not to the platform engineer wiring up an MCP gateway over a long weekend. Portkey’s product surface is bimodal: the $49/mo Production tier and the open-source router serve developers, while SSO, VPC, advanced RBAC, and EU data residency are gated to Enterprise. Acquisitions move that gate up-market, not down. That isn’t a prediction about hostility, it’s the default outcome.

Question to ask: Where does my team sit on the persona spectrum your gateway will optimize for in 18 months?

2. Does your gateway fail closed or fail silent?

Portkey meters Production-tier usage on logs, not requests. Once you exceed your log allotment, Portkey’s pricing page states “exceeding this limit doesn’t affect your requests; only logs beyond the limit are not recorded.” The gateway keeps routing; new logs stop being recorded.

For a routing product, that’s a reasonable trade-off: the LLM call still goes through. For a governance product, it’s the wrong failure mode. A gateway that stops recording who called which tool, with which arguments, against which user identity may not hold the audit trail you bought it for.

Question to ask: What happens to my audit trail when I exceed the gateway’s metering threshold under load?

3. Will the audit retention pass your compliance review?

Portkey’s Production tier retains 30 days of logs. Long-term retention is an Enterprise add-on. Thirty days is short against most compliance regimes, and short against incidents, which are usually discovered weeks after they begin.

Question to ask: How many years of MCP tool-call audit logs will my compliance team need to produce, and is that retention a base-tier feature or an add-on?

4. Is governance behind a sales call?

The shape is familiar. Open-source router, free Developer tier, $49/mo Production tier with the basics, and SSO, advanced RBAC, VPC deployment, EU residency, and long-term audit logs all behind “contact sales.”

For a 50-person team running Cursor and Claude across an engineering org, the $49/mo tier is too thin and the Enterprise contract is overkill. The middle of the market has been the gap in this category for two years, and enterprise security tools tend to widen that gap, not narrow it.

Question to ask: Are the controls I actually need (SSO, tool-level RBAC, audit retention, IDP brokering) included in the tier I’m being quoted, or are they each an upcharge?

5. Who owns the next year of your roadmap?

Independent companies set their own roadmap. Acquired companies set theirs with the acquirer. Both are fine; they’re just different.

I’ve been on the acquired side of this. Azure API Management started life as Apiphany; I came to Microsoft through that deal and watched a small team’s roadmap fold into a portfolio business. Not a bad outcome, a different one.

Portkey shipped its MCP Gateway product on January 21, 2026, 99 days before the acquisition was announced, so the MCP line has not had a full year of independent velocity. You no longer have to guess where the next twelve months go: Portkey has published the direction. Unified access to over 3,000 LLMs and MCP tools, AI identity security, and the rest of the Prisma AIRS platform. That’s a strong roadmap, on the cadence of a roughly $230B public company absorbing an engineering team into a broader security platform. It’s also a Prisma AIRS roadmap: the items that ship serve the gateway for “every AI transaction across the enterprise.” Whether that includes the developer-facing MCP refinements a 50-person team wants is now an open question.

For some buyers, that’s the right answer: you wanted PANW anyway. For others, the value of an independent, developer-first gateway is precisely that the team can refactor a design after talking to five customers.

Question to ask: Whose roadmap am I buying? Mine, the gateway team’s, or the acquirer’s?

What to do today

Nothing urgent. PANW has stated they will support existing Portkey customers, your contract is honored, and the MCP Gateway you set up last quarter still works. What I’d do, in order:

1. Pull your renewal date. Anything renewing in the next 6–9 months is the priority window. Renewals further out can wait; the integration plan will be clearer by then.
2. Re-read your contract for “subject to” language around SSO, log retention, and tier inclusion. Those are the levers acquirers pull.
3. Re-evaluate the MCP gateway specifically, not the AI gateway as a whole. MCP traffic is a small migration: clients point at a gateway URL. LLM provider routing is a much larger one. Don’t conflate them.
4. Run a 30-minute spike on an alternative. Cheap insurance: it gives you negotiating leverage and a real fallback if the renewal terms move on you.

Where Zuplo fits

We’ve been building in this category since 2025, treating the MCP gateway as one of the three gates of AI infrastructure. We opened early access in December and announced public beta in June. The short version of the wedge:

• Independent. No acquirer, no security suite to integrate into. Our roadmap is set by our customers.

• Built on the MCP spec, not around it. The Gateway implements the 2025-11-25 MCP authorization spec over streamable HTTP, with a full OAuth 2.1 authorization server bundled by default: Dynamic Client Registration (RFC 7591), PKCE S256, spec-compliant discovery (RFC 8414 + RFC 9728), and RFC 8707 resource indicators that bind every token to a specific MCP route, so a token minted for one is rejected at another.

  First-class identity-provider presets ship in the box for Auth0, Okta, Entra, WorkOS, Cognito, Clerk, Google, Keycloak, Logto, OneLogin, and PingOne, plus a generic OIDC policy for any other provider. Drop in your issuer URL and your customers click Connect.

• One gateway, many virtual servers. Put Linear, GitHub, Stripe, Atlassian, and your own internal MCP servers behind a single deployment. Each virtual server is a curated view of one upstream on its own route URL (/mcp/linear-v1, /mcp/stripe-v1, and so on). Pass an upstream’s catalog through live, or curate the exact tools, prompts, and resources it exposes.

• Upstream credentials, picked per route. Two OAuth modes are live today: per-user (each user connects once) and shared (an admin connects once and every user reuses that grant). Set authMode per upstream and mix across your fleet without a redeploy. For non-OAuth upstreams, attach a static credential through Zuplo’s standard policy chain.

  Per-user attribution stays in the audit log regardless of which credentials reach the upstream, because the Gateway’s OAuth flow authenticates the user on the front end. Stored upstream tokens are encrypted at rest, keyed per user.

• Typed analytics across the request lifecycle. A dedicated MCP tab in Zuplo Analytics covers the KPIs that matter (events, success rate, p95 gateway vs upstream latency, failure origins), plus top capabilities and users, all filterable by MCP method (initialize, tools/list, tools/call, and the rest).

  Every failure mode returns a documented reason code (missing_token, invalid_audience, connect_required, and more), and structured logs carry the same identifiers (user, route, upstream, capability, latency, and failure origin) straight into Datadog, Splunk, New Relic, or any OTel-compatible destination like Honeycomb. When an audit asks who called what, the answer is in the log, not lost to a metering threshold.

If you’re running this re-evaluation, the Zuplo MCP Gateway is in public beta and open to everyone today. Stand up a virtual server, point a client at it, and see what an independent, developer-first gateway feels like before your next renewal.