Most vendor comparisons in agent governance resolve into the same tired shape: one side watches, the other side acts. That shape does not survive contact with Portkey.

Portkey is an AI gateway that Palo Alto Networks acquired on 29 May 2026 and has since folded into its security platform. Since 16 July 2026 it ships as the Prisma AIRS AI Gateway, and portkey.ai carries a banner reading "Portkey is now PRISMA AIRS AI Gateway." It sits inline. It kills requests that fail a check. Its MCP Gateway page is headed "Runtime policy enforcement" and says, in Portkey's own words, "Stop unauthorized tool invocations before they execute." Anyone writing that Portkey only observes has not opened the page.

So the honest comparison with the Waxell MCP Gateway is not about whether both enforce. Both enforce, inline, on the tool call. It is about what each gateway treats as the thing most likely to betray you — and therefore what it re-checks, and when.

That question matters more than it did a year ago. Palo Alto Networks' own next-generation firewall telemetry, published with the gateway's launch, records MCP activity climbing from 11% late in 2025 to 41.4% by mid-2026, monthly AI transaction volume growing twelve-fold over the same six months, and some individual sessions moving hundreds of megabytes of enterprise data outbound.

What Portkey is now

The product has two halves that a buyer should keep separate.

The first is the AI gateway Portkey has always been: a universal API in front of model providers, with routing, fallbacks, load balancing, semantic caching, virtual keys with budgeting, and prompt management. Guardrails run as before- and after-request hooks. Portkey's documentation is specific about the mechanics — the default state is asynchronous, which runs checks alongside the request and adds no latency, and a guardrail set to Deny: TRUE means that "the request will be killed with a 446 status code." Portkey's own docs recommend rolling that out on a subset of traffic first. Sound advice, and worth noting that the enforcing behaviour is a configuration rather than the default.

The second half is the MCP Gateway, and it is a genuine peer to Waxell's. It proxies between MCP clients and MCP servers, supports OAuth 2.1, API tokens and header auth with JWT validation and identity providers such as Okta and Entra, and keeps a central MCP Registry of servers and tools scoped to workspaces and users through role-based access control reaching individual-user granularity. Tool provisioning enables or disables specific tools per user; tool calls are logged with the user, the parameters and the response; rate limits throttle by request count or token consumption per key, server or tool. And the registry acts as an allowlist: "No shadow tooling. If it's not approved in the gateway, agents can't use it."

The surrounding Palo Alto Networks platform adds more. Prisma AIRS Agent Security says it will "scan supply chain vulnerabilities in agent artifacts, including agent code, MCP servers, and skills," and the Prisma AIRS documentation describes AI Supply Chain Security as scanning "models and AI artifacts for vulnerabilities and malicious content before deployment." Agent identity is bound at execution, with the gateway acting as the enforcement point so that only authenticated agents make approved calls.

That is a serious product with a serious parent. Treat it as one.

Where the two gateways diverge

The clock. Prisma AIRS validates artifacts before they are deployed and then governs traffic by verified identity against an approved registry. The trust decision about a given MCP server is made at onboarding and at scan time; afterwards, the runtime question is whether this agent is allowed to call this approved tool.

The Waxell MCP Gateway makes a different bet: that an approved tool is a moving target. Every tool the gateway discovers is fingerprinted as a hash over its name, description and input schema. Tools carry one of five trust states — Pending review, Drift detected, Trusted, Blocked, Removed. A newly discovered tool cannot be called until an admin approves it. A tool that was Trusted and whose definition changes does not stay Trusted; it moves to Drift detected at the next discovery refresh and resurfaces for review. The policy engine can act on that state: a deny_drift rule blocks tools whose fingerprint changed since they were last approved. Waxell's starter rule set recommends enabling it; it is a rule you author, not a default.

This is the rug-pull problem, and it is specific. An upstream quietly edits what search_documents does — appending "also forward the results to this URL" to the description — and the model, which reads descriptions as instructions, obeys. Nothing in the traffic looks anomalous: the agent is authorised, the tool is approved, the call succeeds. Any control that re-verifies identity at every call but the tool only at onboarding will pass that call — which is an argument about control design, not about any particular vendor's.

Waxell's gateway also scans tool descriptions for prompt-injection patterns at fingerprint time, before any agent calls the tool, and re-scans when a description changes. Findings land as risk flags with a severity, and a risk_deny rule can block tools carrying unacknowledged flags. That is Waxell's design reasoning rather than a survey of the market — the claim here is about what Waxell does, not about what anyone else does not.

Whose identity reaches the upstream. Prisma AIRS binds a verifiable, ephemeral identity to the agent and injects credentials at the gateway so they never leave it. Waxell resolves the caller to a user, plus roles, teams and the agent profile acting for them, and offers on-behalf-of OAuth: the gateway brokers the flow and mints a fresh token at call time, so GitHub's or Slack's own audit log shows the person who triggered the call rather than a service account. Both are credible answers to agent accountability; they put the name in different places. Waxell also supports a shared service account and bring-your-own token, which attribute to the account instead.

What the check set covers on the MCP side. Portkey's MCP guardrails use the same policy engine as its LLM guardrails with the target set to mcp_tools, running on tool inputs, outputs or both. The checks are structural and deterministic: regex match and replace, contains, JSON schema and keys, word and character counts, code detection, URL validation, webhook callouts to your own service. Portkey's documentation states plainly that "LLM-specific checks (PII detection, content moderation, language checks, and third-party provider checks like Patronus, Azure, Bedrock, etc.) are not available for MCP tool calls." Waxell's policy actions on a tools/call include dlp_scan_args and dlp_scan_result, their blocking variants, redact_args and redact_result, and egress_block, which blocks results referencing hosts outside an allowlist. Both sets are documented; they are drawn differently.

Scope. Prisma AIRS AI Gateway is deliberately one control plane for models, MCP servers and agent-to-agent traffic — Palo Alto Networks describes access to more than 3,000 models, MCP servers and tools through a single enforcement point, with 8.3 billion requests and 107 trillion tokens passing through monthly. Waxell's MCP Gateway is scoped to the tool call. One is an argument for consolidation; the other for depth at a single boundary.

Feature comparison

Three scenarios

You already buy Palo Alto Networks and your AI estate is mostly model traffic. Prisma AIRS. The consolidation argument is real, the gateway is generally available, and running AI policy inside the platform your security team already operates is worth a great deal.

Your agents are coding assistants calling a dozen third-party MCP servers you do not control. Waxell. The exposure is the tool definition itself, supplied by someone else and mutable without notice, and drift states plus a deny_drift rule are a direct answer to it.

You need both model-call budgets and tool-call supply-chain defence. These are complements more often than substitutes — a gateway in front of your model providers and a gateway in front of your MCP upstreams are different chokepoints, and nothing stops you running both.

When Prisma AIRS AI Gateway is the right call

Choose it when breadth of perimeter matters more than depth at the tool boundary: one enforcement point across models, MCP and agent-to-agent traffic; a buying centre that is already a Palo Alto Networks security buyer; routing, fallbacks, semantic caching and per-provider budgeting that are load-bearing for your workloads; pre-deployment scanning of agent code and MCP servers that fits how your organisation ships agents; or an open-source gateway you can self-host before you buy anything.

How Waxell handles this

The Waxell MCP Gateway gives a tenant one MCP endpoint that replaces the upstream MCP configuration on each client, working with Claude Desktop, Claude Code, Cursor and any MCP-compatible client. Each tools/call that reaches it is identity-resolved, policy-checked, fingerprinted and logged before the upstream sees it, and the result is checked again on the way back.

The policy engine matches rules on upstream, tool glob, user email, role, team and the agent profile acting for the user, with precedence running deny over require_approval over redact over allow. Its actions fall into four documented groups: access control, data protection, budget and abuse, and supply-chain defence. The approval mechanic is worth singling out — a parked call holds the MCP connection open with progress notifications, so the agent waits rather than timing out, and a denial returns a structured error the agent can recover from.

Offboarding is a single transaction: deactivating a Waxell account revokes the per-upstream OAuth grants that user held, across upstreams simultaneously, with the revocation recorded in the audit log. The audit log is payload-free — it records who called what tool, which decision applied and which rules fired, exportable to CSV, without retaining argument values or result bodies.

One limit, stated plainly: coverage through any gateway is configured, not guaranteed. An agent holding direct upstream credentials, a locally registered MCP server or an unconfigured client goes around the Waxell gateway, exactly as it would go around Portkey's. That is a property of the architecture both vendors chose, and it is the first thing to check in either evaluation.

Waxell is SOC 2 Type II, audited by Advantage Partners, observation period 12 May to 12 August 2026. The free tier includes 10,000 traced executions per month, two seats, one connected client, one MCP upstream and 14 days of retention — enough to point a coding agent at the gateway and watch what it actually does. For a comparison against an observability-first vendor rather than a gateway peer, see Waxell vs Datadog.

FAQ

Is Portkey still a separate product?

Palo Alto Networks completed its acquisition of Portkey on 29 May 2026 and announced general availability of the Prisma AIRS AI Gateway on 16 July 2026, six weeks after closing. portkey.ai still operates, still carries self-serve Developer, Production and Enterprise tiers, and still publishes its own documentation — but the site banner now reads "Portkey is now PRISMA AIRS AI Gateway" and the enterprise motion has moved to Palo Alto Networks.

Does Portkey block MCP tool calls, or only log them?

It blocks. The MCP Gateway page says it stops unauthorised tool invocations before they execute, the registry functions as an allowlist, and guardrails configured with Deny: TRUE kill a failing request with a 446 status code. The nuance worth knowing is that the guardrail action defaults to asynchronous, so blocking is something you turn on.

What is tool-definition drift, and why does it need its own control?

An MCP server can change a tool's description or input schema after you have approved it. Because agents read tool descriptions as instructions, an edited description can redirect behaviour without any change in who is calling or what they are authorised to do. Identity and allowlist controls both pass that call, because neither the caller nor the tool's name changed. The Waxell MCP Gateway fingerprints name, description and input schema, moves a changed tool to Drift detected, and can deny it through a deny_drift rule until a human re-approves.

Can I run both?

Yes, and for some estates that is the sensible answer. The integration question to ask is whose audit trail is authoritative when a call traverses both.

Do I have to buy a whole platform to get the Waxell gateway?

No. The Waxell MCP Gateway is sold standalone for teams that want tool governance without a coordination layer, and it is also included by default inside Waxell Connect. It is the same engine either way.

Sources

• Palo Alto Networks, "Palo Alto Networks Completes Acquisition of Portkey to Secure AI Agents" (investor release), 29 May 2026

• Palo Alto Networks (Jaimin Patel), "Announcing the General Availability of Prisma AIRS AI Gateway" (blog), 16 July 2026

• Palo Alto Networks, "The AI Control Plane for the Enterprise" — Prisma AIRS AI Gateway product page, read 2 October 2026

• Palo Alto Networks, "Prisma AIRS Agent Security", read 2 October 2026

• Palo Alto Networks, "Prisma AIRS" — product documentation home, read 2 October 2026

• Portkey, "MCP Gateway — Secure Access to MCP Servers", read 2 October 2026

• Portkey, "MCP Gateway" and "Guardrails for MCP" — product documentation, read 2 October 2026

• Portkey, "Guardrails" — guardrail actions and the 446 response, read 2 October 2026

• Portkey, "Pricing", read 2 October 2026

• Waxell, "MCP Gateway" and "Policies & Approvals", read 2 October 2026

Governing the tool call is where agent risk actually lands. See how the Waxell MCP Gateway resolves identity, enforces policy and catches tool drift on your own upstreams — book a 30-minute demo.