Two Designs for Multitenancy in NAI 2.8

An MSP offering starts to exist the moment two customers share the same infrastructure and neither of them can tell. After that it is bookkeeping: which resources belong to whom, and who is allowed to act on them. A platform either hands you that boundary as an object you can point at, or you assemble it yourself out of whatever primitives are available, and the second option always looks cheaper than it is. The difference comes out of your margin, spent on engineering no customer will ever see.

Nutanix Enterprise AI 2.8 ships a serious authorization model. Every action in the interface maps to a permission, roles can be composed from scratch, and policies can restrict a user to the entities that user created. For an enterprise running one AI practice, this is the least privilege model people have been asking for. For a service provider, the unit it operates on is the individual who created the resource, and that is a boundary between colleagues rather than between customers.

I have not run 2.8 in a lab. What follows is a reading of the published documentation against the multitenancy work I have been doing on Nutanix all year, and the two are worth keeping separate.

What 2.8 Actually Changed

The feature breakdown already exists and it is a good one. Laura Jordana, Principal Technical Marketing Engineer at Nutanix, published a walkthrough on August 27 covering MCP Server support reaching GA, fine-tuning for models under 8B parameters, custom inference engine parameters, and KV cache offload in tech preview. There is no reason to repeat it here.

What that walkthrough does not cover is the first item in the release notes. NAI 2.8 introduces fine-grained authorization, where each action in the interface maps to an IAM permission, together with owner-scoped access, which restricts a user to the entities that user created. For anyone building a service on top of this platform, that is the entry worth reading twice.

Authorization Without a Tenant Object

A permission pairs an entity with an operation, such as creating a model. Roles collect permissions: the four predefined ones (ML Admin, ML User, Read Only, License Manager), or a custom set you compose yourself when none of those matches the way your team is actually split up. An authorization policy then binds a role to a user or a group, and can narrow it to a specific set of entities.

Scope is where owner-scoped access lives. When a policy is scoped to the owner, every row-level action is evaluated against the identity of whoever created that entity, and list pages show only what that user made. The coverage is thorough: models, local and unified endpoints, API keys, MCP client keys, MCP servers and connectors, data sources, fine-tuning jobs, batch inference jobs. A person owns every one of those, and that consistency makes the model predictable to reason about: the finest boundary it draws is the one around whoever created the entity. A tenant, a project or a customer is a different kind of object, and it belongs to a layer above this one.

Picture one customer with two people in it. Alice creates the unified endpoint that serves that customer’s application; Bob, on the same account, is the one on call. Under an owner-scoped policy the endpoint sits on Alice’s list pages and not on his. When Alice changes jobs, I could not find a documented way to hand it over. Model sharing, new in 2.8, covers imported models selected one at a time for named users or groups, which helps with the model and not with the endpoint built on it.

Two Designs, Both Defensible

One Instance Per Customer

A dedicated NAI instance gives you a boundary that is straightforward to demonstrate to an auditor, and it comes with a bill of materials. Each instance carries its own Kubernetes 1.35 runtime with KServe, Envoy Gateway, the NVIDIA GPU Operator, cert-manager, CloudNativePG, ClickHouse and Valkey, plus a documented minimum of 130 GiB of block storage before a single model is imported. Licenses are applied per NAI cluster name or UUID and metered in vCPU and GPU GB, with the new Agent Gateway license metered separately on the access keys tied to unified endpoints and MCP connectors. The upside of that arrangement is that the Licensing tab of each instance already reports one customer’s consumption, because there is only one customer in it.

One Shared Instance

The shared design removes that duplicated platform overhead and moves the work into policy. Authorization policies bound to user groups give each customer its own view, and per-client rate limiting on unified endpoints is the closest thing to a per-tenant control the product offers today: clients can be identified by API client key or by request header value, with a default limit per header value and overrides where you need them. The control is older than this release, which extends it, and the header-based identification is the part 2.8 adds. Its maturity is harder to pin down, because the release notes leave rate limiting out of the tech preview list while the guide marks the section itself as tech preview. It bounds token consumption, so it keeps one customer from spending another customer’s budget without reserving capacity for either.

The Licensing tab here reports consumption at the instance level, so per-customer chargeback has to come from audit events and gateway metering instead. That assembly is yours for the life of the offering, and it is what the shared design trades for its cost.

The Resource No Policy Divides

GPU passthrough assigns accelerators to endpoints, and an endpoint belongs to whoever created it, so a customer ends up being a set of endpoints holding a set of accelerators. Multi-node allocation across GPU nodes arrived in 2.8 as a tech preview, and it requires speculative decoding and KV cache offloading to be switched off, which is a trade worth re-evaluating when it reaches GA. Capacity planning stays endpoint by endpoint, which is a property of the hardware and not of the policy model.

The Gateway Points Both Ways

NVIDIA NIMs can now be imported into air-gapped environments from an NFS share or an S3-compatible bucket, using a container image held in an on-premises registry, with no path out to the NGC catalog at any point. A disconnected inference stack stopped being a story about roadmaps and became something you can put in a contract.

The same unified endpoint abstraction that keeps inference local is also what routes it to Anthropic, AWS Bedrock, Azure OpenAI, Cohere, GCP Vertex AI, Google Gemini, Mistral, and OpenAI. That flexibility is the product working as designed, and it means the sovereignty of a deployment is a property of how you configured it rather than of what you installed. Whoever holds the permission to create a unified endpoint holds that decision, which puts it back inside the authorization model and makes it one of the first policies worth writing down.

The Boundary You Still Have to Build

Multitenancy on Nutanix is a control plane problem, and the control plane arrives one layer at a time. This release brought the authorization layer, and brought it well. The object that would hold a customer is still missing, which is why the boundary between customers has to be decided before the first deployment instead of configured after it.

That decision belongs next to the ones covered in Why the Tenant Exists Before the Control Plane, because the answer for a service provider is the same shape here as it is everywhere else on the platform: the tenant exists before the control plane that industrializes it.