A green policy screen proves that somebody configured a control. It does not prove that the control held while two customers shared the same accelerator.
That distinction sits behind the Rafay and Stealthium integration announced on 1 September 2026. Rafay manages tenant access, workload placement and GPU sharing; Stealthium says it observes GPU memory activity, CUDA kernel execution and workload attribution, then sends detections to existing security systems. The proposition is straightforward: compare intended isolation with observed execution.
Buyers should take the requirement seriously without treating the announcement as independent proof. The integration description comes from the vendors, and neither the announcement nor the linked material publishes an external assessment of the combined product. It is a useful reason to strengthen an acceptance plan, not a reason to skip one.
Quick answer
If a provider shares GPUs between customers, ask for evidence from below the Kubernetes namespace and control plane. Identity records, scheduler events and network policy show who should have accessed a resource. They cannot, by themselves, show which process touched GPU memory or which kernel ran on the device.
The minimum assurance package should join both sides of the record: configured policy and runtime observation. Where the workload contains regulated data, valuable model weights or secrets that cannot share a physical failure domain, use dedicated GPUs unless the provider can demonstrate an isolation model that your security team accepts.
What the Rafay and Stealthium announcement covers
Rafay describes its platform as the governance layer. It handles virtual clusters, workload placement, RBAC and OPA policy, Kata Containers, MIG or time-sliced GPU sharing, audit logging and tenant access. Stealthium adds instrumentation within the NVIDIA GPU and CUDA runtime, according to the announcement, with visibility into memory activity, kernel execution and process attribution.
The vendors make a careful distinction that procurement teams should preserve: Rafay's controls operate independently, while Stealthium adds an observation layer. Observation may detect a mismatch; it does not replace sound partitioning, patching, identity or network controls.
The post also says a future reference blueprint will address shared model instances, including admission, residency, eviction and teardown. That capability is described as planned work, not a shipped feature. Do not write it into a current compliance response as though it exists today.
Isolation has several boundaries
Shared GPU services cross more boundaries than a conventional virtual machine estate. A single user request can pass through an API gateway, model router, scheduler, container, CUDA runtime and physical GPU before its data reaches HBM. KV cache and model weights may remain resident between requests unless the serving system manages their lifetime correctly.
| Layer | What it should establish | Evidence worth requesting | | --- | --- | --- | | Identity and API | Which tenant submitted the request | Auth decision, tenant ID and request correlation ID | | Orchestrator | Where the workload should run | Admission result, placement event and policy version | | Container or VM | Process and operating-system boundary | Runtime identity, image provenance and host assignment | | GPU partition | Assigned compute and memory resources | MIG or vGPU profile, device mapping and configuration state | | GPU execution | What ran and which memory region it accessed | Attributed kernel and memory events with timestamps | | Network and storage | Which data paths the tenant could reach | Flow, volume, object and credential access records |
No single tool owns the whole table. That is why correlated evidence matters.
What MIG does and does not answer
NVIDIA documents Multi-Instance GPU as a hardware partitioning system that assigns separate GPU compute resources and isolated paths through the memory system. L2 cache banks, memory controllers and DRAM address buses are allocated to a GPU instance, which supports predictable service and fault isolation between clients.
MIG is a stronger boundary than simple time-slicing, but the word "MIG" in a proposal still does not answer every security question. The buyer needs the supported GPU model, profile, orchestration method, virtualisation mode, driver and firmware baseline, reset behaviour and operational process for reassigning an instance. Identity, storage and network isolation remain outside the GPU partition.
Time-slicing is different. It shares the device over time and may improve utilisation, yet it should not be described as equivalent to hardware memory partitioning. If a provider offers both, its service description must say which one each customer receives.
Configuration evidence versus runtime evidence
Suppose a tenant policy requires workload A to use GPU instance 2. The control-plane record may show that placement succeeded. Runtime evidence should let the operator check whether the expected process and kernels executed on that allocation and whether an unexplained process touched the relevant device or memory region.
That comparison needs a common clock, stable workload identity and enough retention for an investigation. A stream of uncorrelated device events is telemetry, not proof. An auditor should be able to start with a tenant request and follow it through admission, placement, process identity and GPU execution without relying on an operator's memory.
The same principle applies to automated operations. Our article on agent-native infrastructure telemetry explains why a system should preserve the decision, action and observed result rather than logging only a final state.
Procurement questions for a shared GPU service
Ask the provider to answer these questions against the service you will actually buy:
- Is the GPU dedicated, MIG-partitioned, virtualised or time-sliced? Do not accept "isolated" as the whole answer.
- Which controls prevent one tenant from changing device assignment, runtime configuration or monitoring scope?
- Can runtime events be tied to tenant, request, process, node, GPU and partition without manual reconstruction?
- What happens to HBM, KV cache, local NVMe and host memory when a tenant leaves or a workload is rescheduled?
- Which logs can the customer export, how long are they retained and who can alter them?
- How does the provider test a failed isolation control, and what evidence is produced during the test?
- Which parts of the assurance story come from vendor statements, internal testing or an independent assessment?
Answers should refer to artefacts and test results. Marketing adjectives do not survive an incident review.
Acceptance evidence before production
A buyer does not need exploit instructions to test whether the service has a coherent assurance model. Start with benign, labelled workloads across two test tenants. Confirm that each request produces the expected identity, placement and device records; then introduce approved policy failures in a non-production environment and check whether the control blocks them or the monitoring layer detects them.
The acceptance record should show timestamps, policy versions, device assignments, alerts and the operator's response. It should also show negative results: one tenant must not receive another tenant's logs, hostnames, metrics, object names or model-serving metadata.
Run those tests again after driver, firmware, orchestrator or serving-stack upgrades. GPU isolation is a maintained property, not a certificate placed in a procurement folder.
Dedicated GPUs remain the simpler boundary
Sharing improves utilisation when workloads are small, bursty or uneven. Our analysis of multi-tenant inference latency covers the performance side of that bargain. Security creates a separate decision.
Dedicated devices remove several co-residency questions and make performance accounting easier, although they do not remove host, network, storage or operator risk. They are often the sensible default for untested software, highly sensitive weights, strict contractual separation or workloads whose incident cost dwarfs idle GPU cost.
MIG-backed sharing can suit controlled enterprise services where the supported hardware and software path is clear. Time-slicing belongs in lower-risk environments unless stronger boundaries exist elsewhere. Shared model instances need the closest review because prompts, weights and cache may coexist inside one serving process.
What buyers should ask GPUMachines to design
The hardware decision follows the isolation decision. A private single-tenant deployment may use a smaller PCIe GPU server, while high-memory multi-GPU jobs may require an HGX platform. Hosting can preserve equipment ownership and a dedicated physical boundary without placing high-density systems in an office; see Buy & Host.
Before choosing the chassis, write down the tenancy model, acceptable co-residency, audit evidence, retention period and upgrade-test process. Otherwise the server bill of materials will arrive before the security design.
GPUMachines view
The Rafay and Stealthium announcement points at a real gap: operators often know what the control plane intended but cannot show what happened inside the accelerator. Device-level observation can improve that record, provided buyers validate coverage, correlation and failure behaviour rather than accepting the vendor description at face value.
For valuable or regulated workloads, evidence beats feature lists. If the provider cannot produce it, buy a dedicated boundary or keep the workload elsewhere.