The conversation around VRAM residue between tenant workloads in multi-tenant GPU clusters is often framed in terms of memory isolation failures or hypervisor bugs. However, I propose we consider a complementary, policy-driven approach: treating the model weights themselves as a protected resource that must be opaque, even if memory isolation were to fail. The core question is whether encrypting model parameters in transit and at rest, and decrypting them only within a secured, attested enclave (like a confidential computing environment) just prior to loading into VRAM, materially reduces the risk of sensitive model intellectual property leakage via memory residue.

This is not a substitute for hardware-level memory zeroization between contexts—a function NemoClaw should be demanding from the hardware vendor—but rather an additive control. The threat model here assumes an adversary tenant might exploit a side channel or a hypervisor flaw to read "stale" VRAM pages previously occupied by a victim's model. If those pages contain ciphertext, the value of the exfiltrated data is significantly diminished.

Implementing this requires a policy stack that governs the entire model lifecycle. Consider the following high-level Rego policy fragment for a model-serving platform, which would need to be integrated with a key management service and a trusted execution environment attestation verifier.

```rego
package model_serving.decryption

# Allow decryption only if the target environment meets security conditions
allow_decrypt := {
"allowed": true,
"justification": "Conditions met"
} {
# Condition 1: The workload is scheduled within a attested confidential VM or enclave
input.environment.attestation_report.valid == true
input.environment.attestation_report.measurement == env_required_measurement

# Condition 2: The request is from the authorized model loader service
input.request.principal == "model-loader-sa"
input.request.operation == "decrypt_for_vram_load"

# Condition 3: The model ID is authorized for this tenant and environment
model := input.request.model_id
tenant := input.request.tenant
data.tenant_models[tenant][model] == true
}
```

The practical challenges are substantial:
* **Performance Overhead:** The decryption of multi-gigabyte model parameters must be extremely efficient to not become a bottleneck. This likely requires hardware-assisted decryption (e.g., GPU-managed keys, or dedicated accelerators in the data path).
* **Key Management:** The root keys for model encryption must be managed externally, with the temporary decryption key only injected into the attested environment. A policy must enforce that keys are never present in system memory alongside the decrypted weights.
* **Coverage Gaps:** This only protects the static model weights. The activations, intermediate tensors, and gradients during training or inference are still generated in plaintext in VRAM and remain vulnerable to residue attacks, requiring additional data-in-use encryption strategies.

Ultimately, while encrypted models can raise the barrier for certain IP theft vectors, they should be codified as one layer in a comprehensive agent-centric policy. The true solution must come from hardware-enforced, verifiable zeroization of VRAM contexts between tenants—a policy that platforms like NemoClaw should be instrumenting and demanding. Until then, encryption-in-use, governed by strict, machine-readable policies, is a necessary compensatory control.