In August 2026, two vendors were shipping a product called an MCP gateway — and they meant substantially different things by it. On August 26, Nutanix announced Nutanix Enterprise AI (NAI) 2.8, and the headline feature was the general availability of MCP server management inside its Agent Gateway — a capability Nutanix's press release presents as a generally available MCP Gateway acting as a secure, unified front door between agents and the tools and data they reach. Waxell has shipped a product named MCP Gateway — one governed MCP endpoint per tenant, fronting every upstream a team's agents call. Same name, same protocol, and a genuinely different architectural bet underneath.

This is not a case of one vendor imitating the other. The Model Context Protocol became the standard way for agents to reach enterprise tools, so the gateway pattern — put one governed door in front of the sprawl — is where every serious platform converged. Forbes argued in July 2026 that agent gateways are becoming enterprise AI's control plane. Nutanix's own editorial defines the category the same way: an inline control plane sitting between agents and the systems they touch. That is the same AI control plane category Waxell operates in. The interesting question is not who owns the name. It is where each vendor draws the governance perimeter — and what each one's gateway actually inspects.

Nutanix Agent Gateway is a control layer inside Nutanix Enterprise AI, an enterprise platform you deploy on your own Kubernetes clusters. It puts a single front door between AI agents and two things behind it: the models they consume (public providers or private self-hosted inference) and, as of NAI 2.8, the MCP servers they call — with access control, token budgets, and audit trails at that door. Waxell MCP Gateway is a hosted governance product: one URL per tenant replaces every upstream MCP config, and a policy engine inspects each tool call in flight — identity resolution, policy evaluation before the upstream sees the call and again on the way back, tool fingerprinting with drift detection, and approval holds on destructive actions. Nutanix governs where agents run and what they may reach. Waxell governs what each tool call contains and does.

What is Nutanix Agent Gateway built for?

Nutanix is an infrastructure company — hybrid cloud, hyperconverged infrastructure, Kubernetes — and its agent governance story ships inside that stack. Nutanix Agent Gateway reached general availability with NAI 2.7 in May 2026, aimed at a problem Nutanix customers feel acutely: token spend and access sprawl. The gateway centralizes traffic from agents to LLMs, giving IT teams token observability across model vendors, cost attribution by team, and granular token-based rate limiting. NAI 2.8 extends this with header-based per-user token budgets, currently in Tech Preview.

The MCP side arrived in Tech Preview with 2.7 and went GA in 2.8. It is a real, well-documented capability. Teams can register remote MCP servers (HTTPS with CA-signed TLS, Streamable HTTP transport, MCP protocol version 2025-06-18) or deploy local MCP servers as containers inside the NAI cluster itself — and the local option is genuinely hardened: servers run as a non-root user with a read-only root filesystem, and a default Kubernetes NetworkPolicy restricts ingress and blocks egress to the Kubernetes API server. A single /mcp endpoint aggregates multiple servers. Access is governed through MCP connectors: an admin binds a client key to selected servers and grants specific tools to that connector, with Nutanix's docs advising admins to grant tools sparingly. Permissions can distinguish read-only from write access per user or API key, requests can be denied when a required forwarded header is missing, and the platform records MCP requests into an audit trail — the kind of evidence chain regulated industries need.

Underneath it sits the deployment model that defines the product. NAI runs on CNCF-certified Kubernetes — Nutanix's own NKP, or EKS, AKS, GKE — with an Envoy-based data plane and a documented six-node baseline for an Agent-Gateway-only deployment, licensed via keys from the Nutanix Licensing Portal. For a Nutanix shop that wants agent governance living in the same estate as its VMs, containers, and self-hosted inference, this is exactly the shape you would want.

Where does the scope end?

None of this is a flaw in what Nutanix set out to build. And the problem both vendors are aiming at is real: Gartner predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents after governance gaps surface in production incidents — a forecast Nutanix itself cites in its NAI 2.8 announcement. The question is which gaps a gateway closes. Nutanix's is an infrastructure-plane gateway, and its boundary sits where content-layer enforcement would need to begin.

The controls are about access, identity, and budget — at the door. Nutanix's NAI 2.8 documentation describes which agents may reach which servers and tools, with which credentials, under which token budgets, with every request logged. Those are necessary controls, and Nutanix documents them well. What its published MCP governance material does not describe is inspection of the tool-call layer itself: fingerprinting of tool descriptions, detection of tools that silently change after approval, scanning tool descriptions for prompt injection, redacting sensitive data inside call arguments, or holding a destructive action for human approval. The docs place server vetting on the customer — teams adding a remote MCP server are instructed to "ensure the performance, reliability, safety, and output quality" of that server themselves. A tool your admin approved on Monday can describe itself differently on Friday — and nothing in Nutanix's published MCP governance material describes a control that would catch the change.

The perimeter is the estate you deploy. The gateway governs what routes through the NAI environment you operate. That is a deliberate design — it is why the local-MCP-server hosting is so well hardened — but it means the governance surface is your Kubernetes estate, not your agents wherever they run. It also means adoption starts with a platform deployment: Kubernetes cluster, load balancer, TLS certificates, license keys. Nutanix's own sizing guide validates the baseline at a six-node cluster before the first policy is written. The trial motion is a guided Test Drive rather than a self-serve signup, and NAI pricing runs through Nutanix's licensing and sales channels rather than a published price list.

Model governance is consumption governance. On the LLM side, the gateway's documented controls are about routing, quota, and spend — which model, whose tokens, how many. Content-level policy on what agents actually do with models and tools — the 50+ policy categories a platform like Waxell evaluates with its Observe SDK at the execution level — is a different layer of the problem, and it is not the layer Nutanix's agent governance materials describe.

What Waxell does differently

Waxell's MCP Gateway starts from the opposite end: the tool call itself. One URL per tenant fronts a catalog of 160+ upstream MCP connectors. Every call is resolved to a real user identity, then evaluated by a policy engine before the upstream ever sees it — and the results are evaluated again on the way back. Policy rules scope by upstream, tool, user, role, team, and agent profile, and their actions span four groups: access control (deny, allow, require approval), data protection (redaction, DLP scanning and blocking on arguments and results, egress blocking), budget and abuse (rate limits, cost caps), and supply-chain defense. A require_approval rule parks a destructive action until a human reviewer decides, with the exact arguments in front of them.

The supply-chain group is where the difference is sharpest. The Waxell MCP Gateway fingerprints every tool's name, description, and input schema, and tracks each tool through five trust states — Pending review, Drift detected, Trusted, Blocked, Removed. When an upstream changes a tool under you, the fingerprint changes, the tool resurfaces for review, and its new description is re-scanned for prompt injection — a scan that runs at fingerprint time, before any agent calls the tool. Detection is automatic; blocking is policy: with a deny_drift rule in place — Waxell's starter rule set recommends one everywhere — the Gateway denies calls to a drifted tool from that point on. Fingerprinting detects. A policy decides. Both halves are real, and both live at a layer that access control alone does not reach.

The delivery model is the other half of the bet. The Waxell MCP Gateway is hosted — pointing your assistants at one URL is the deployment — with a self-hosted option running the same image in a customer VPC for teams that need it. Waxell publishes its pricing tiers — including a free tier, with the Business tier at $199 per month — and signup is self-serve. And because the Gateway ships inside Waxell Connect as well as standalone, teams that adopt Connect for agent coordination get the same tool-call enforcement without a separate purchase.

Feature comparison

⚠️ in the Nutanix column means the capability is not described in Nutanix's NAI 2.8 documentation and announcements (see Sources) — an observation about published material, not a verified statement that the capability cannot be configured.

Three scenarios, two different perimeters

You run a Nutanix estate and want AI governed where your infrastructure already lives. Nutanix is built for exactly this: agents, models, and MCP servers governed inside the same Kubernetes platform as your VMs and data, with self-hosted inference cutting token spend. Waxell does not compete for this job — it does not host models or run your clusters.

Your agents already live everywhere — Claude, Cursor, custom builds — and your worry is what their tool calls are doing. This is Waxell's home ground. The MCP Gateway inspects each call in flight: identity, policy, fingerprint drift, injection scanning, redaction, approval holds. There is no cluster to size first; the deployment is a URL change.

You need governance evidence for auditors. Both produce a real trail: Nutanix records MCP requests into its audit pipeline; Waxell keeps a payload-free tool-call log with CSV export, including the policy decision and the rule that fired. The difference is what the record can show — that access was granted, versus what the gateway did about the call.

When to use Nutanix

• You are standardizing on Nutanix infrastructure and want agent governance, model serving, and MCP server hosting operated as one licensed platform in your own estate.

• Your primary exposure is token economics — spend visibility, budgets, and routing between public and self-hosted models.

• You want sensitive MCP tools deployed inside your own infrastructure perimeter, with the platform hardening the containers they run in.

When to use Waxell

• Your governance question is about the content and behavior of tool calls — drift, injection, data leakage, destructive actions — not only who may connect to what.

• Your agents and assistants run on surfaces you don't host, and you need one governed URL in front of their tool calls without deploying a Kubernetes platform first.

• You want to start self-serve against published pricing, then extend the same enforcement into agent coordination with Connect, which includes the MCP Gateway.

How Waxell handles this

Waxell's MCP Gateway puts one governed URL in front of a 160+ connector catalog and treats each tool call as the unit of governance: identity resolved to a real user, policy evaluated before dispatch and again on the response, rules scoped down to the specific tool and the specific agent profile acting for a specific person. Its supply-chain defenses — tool fingerprinting across five trust states, prompt-injection scanning of tool descriptions at fingerprint time, and a recommended deny_drift rule that blocks tools whose fingerprint changed since last approved — address the case where an approved tool stops being the tool you approved. For teams governing the agents they build in Python, Observe extends governance to the execution layer with 50+ policy categories evaluated during the run. And the whole thing starts as a URL change, not an infrastructure project.

Weighing an agent gateway and want the Waxell MCP Gateway's view — the layer that inspects the calls, not just the door they pass through? Get started with Waxell.

FAQ

Is Waxell an alternative to Nutanix Agent Gateway?

For MCP tool-call governance, yes — with a different center of gravity. Both put one governed endpoint in front of a team's MCP servers with per-tool access control, rate limiting, and audit trails. Waxell adds content-layer enforcement in flight — tool fingerprinting with drift blocking via policy, prompt-injection scanning, DLP on arguments and results, and human approval holds. Nutanix adds what Waxell does not attempt: self-hosted model serving, and hosting hardened MCP servers inside your own Kubernetes estate. Many organizations would be choosing between perimeters, not between feature lists.

Are Nutanix's MCP Gateway and Waxell's MCP Gateway the same kind of product?

They share a name and a pattern, not an architecture. Nutanix's MCP gateway is a capability of Agent Gateway inside Nutanix Enterprise AI, deployed on your Kubernetes clusters and licensed as enterprise software. Waxell's MCP Gateway is a hosted product — one URL per tenant, self-serve signup — that also runs self-hosted in a customer VPC and ships inside Waxell Connect. Neither vendor copied the other; the MCP standard made the gateway pattern the natural convergence point.

Does Nutanix Agent Gateway inspect tool calls for prompt injection or data leakage?

Its published NAI 2.8 documentation and announcements describe access-layer controls — which agents reach which servers and tools, with which permissions and token budgets, with requests logged — and instruct customers to ensure the safety of remote MCP servers themselves. Prompt-injection scanning, payload redaction, and tool-description fingerprinting do not appear in that published material. If those controls matter to your deployment, ask Nutanix directly — documentation can trail the product.

Does Waxell block a tool whose description changes?

The Waxell MCP Gateway fingerprints each tool's name, description, and input schema, and a change moves the tool to Drift detected and re-runs prompt-injection scanning. Blocking is a policy decision: with a deny_drift rule configured — the starter rule set recommends one everywhere — the Gateway denies calls to drifted tools automatically. Without one, the drift is recorded and surfaced for an admin to decide, including setting the Blocked trust state. Detection is automatic; enforcement is a rule you author.

Can I use Nutanix and Waxell together?

Yes in principle — they meet at different layers. The practical split is Nutanix for the estate and model serving, Waxell for tool-call content governance and the agents you don't host. Chaining both gateways in the same MCP path would mean two policy points; most teams would pick one per path.

Sources

• Nutanix (Nicole O'Keefe), "Charting the Path to Governed Agentic AI with Nutanix Enterprise AI 2.8", August 26, 2026

• Nutanix, "Nutanix Gives Enterprises the Freedom to Run Production Agentic AI Their Way" (press release), August 26, 2026

• Nutanix (Nicole O'Keefe, Ashwini Vasanth), "Introducing Nutanix Agent Gateway", May 26, 2026

• Nutanix, Nutanix Enterprise AI 2.8 Guide — MCP Servers, Security and Configuration Considerations for MCP Servers, Agent Gateway Requirements, Licensing (portal.nutanix.com), release August 20, 2026

• Nutanix, The Forecast (Ken Kaplan), "What Is an AI Agent Gateway?", June 25, 2026

• Forbes (Janakiram MSV), "Agent Gateways Are Becoming The Control Plane For Enterprise AI" (via Yahoo News syndication), July 5, 2026

• Waxell, MCP Gateway policies documentation, 2026