The prevailing assumption when deploying multi-tenant GPU workloads, particularly with NVIDIA's vGPU software stack (GRID, vComputeServer), is that the hypervisor-mediated memory management unit (GPU MMU) provides a complete isolation boundary equivalent to a CPU's IOMMU. This assumption is flawed and dangerous for high-assurance environments. The core question is not about allocation isolation—which is largely robust—but about the lifecycle of data within allocated memory blocks and the hardware's actual commitment to zeroization.

From a threat modeling perspective, we must differentiate between three distinct phases where VRAM data leakage can occur:

1. **Intra-Session Isolation:** The vGPU scheduler's time-slicing prevents concurrent workloads from accessing each other's memory. This is generally sound.
2. **Inter-Session Reallocation:** What happens when a GPU context is destroyed and its memory is returned to the pool for a new tenant? The hardware MMU may remap physical pages, but does not guarantee the scrubbing of the underlying data.
3. **Cold Boot & Direct Memory Access:** The risk of physical access or DMA-capable attackers extracting residual data from VRAM chips, even after a host reset.

NVIDIA's documentation emphasizes isolation but is deliberately vague on data persistence. My analysis of the data flow suggests the following trust boundaries are potentially weaker than advertised:

* The **vGPU manager** (in the hypervisor) controls page tables but is not necessarily a data sanitization agent.
* The **GPU driver** in the guest VM operates with a translated view of memory, but the backing physical VRAM frames are managed by the host driver.
* The **hardware GPU MMU** performs address translation but lacks the semantic context to know if a page contains sensitive data that must be purged upon de-allocation.

A simplified STRIDE analysis for the reallocation phase yields:

* **Spoofing:** Not applicable to memory residue.
* **Tampering:** Not the primary threat.
* **Repudiation:** Difficult to prove data leakage occurred.
* **Information Disclosure:** This is the critical threat. Former tenant's model weights, inference inputs, or generated text may be partially or fully readable by a subsequent malicious tenant who performs low-level memory dumps.
* **Denial of Service:** Not applicable.
* **Elevation of Privilege:** Could be a vector if residual data includes control structures or tokens.

The mitigation often cited is driver-level "clearing" of memory before re-use. However, this is a software-controlled policy, not a hardware-enforced guarantee. In a compromised hypervisor scenario, or under extreme memory pressure, can we audit that this zeroization always occurs? Furthermore, the guardrails for DMA attacks (like NVIDIA's GPU IOMMU) are designed for access control, not for purging memory residues on power cycles.

Therefore, the secure architecture for NemoClaw must assume vGPU provides allocation isolation but **not** automatic cryptographic erasure. Compensating controls are required:

* Implement tenant-aware GPU memory pre-zeroization via a trusted hypervisor module, with attestation.
* Mandate workload-level encryption for sensitive data in VRAM, treating GPU memory as untrusted storage.
* Segment physical GPU pools by sensitivity tier, avoiding reallocation across trust zones.

The community's experience with tools like `nvidia-smi` for inspecting memory contents post-deallocation would be valuable. Has anyone conducted empirical testing to see if fragments of prior tensors are recoverable from a newly allocated vGPU instance?