RESEARCH & VALIDATION
When Model Artifacts Change,
Should Access Continue?
Shared custody depends on more than who approves a release. It also depends on whether the model artifacts match what was approved.
Approval Needs an Identity.
A model builder may approve a particular model for a customer-controlled deployment. That approval needs a precise technical meaning: which encrypted package, which model inventory and which runtime configuration?
If the bytes or their expected identity change, the system needs to detect the difference. Custody decisions and artifact integrity are complementary controls. Both matter when valuable models move across organizational boundaries.
On 23 September 2026, Custodian ran a focused CPU evaluation on GCP. It exercised authenticated model-bundle opening and Linux filesystem integrity using disposable test data. The walkthrough below illustrates three observations from that evaluation.
INTEGRITY IN ACTION / GCP CPU LAB
Change the Artifact.
Watch the Check Respond.
Compare the original input with an altered or mismatched input, then replay the recorded check.
The recorded test refused the modified ciphertext and removed partial plaintext output.
Illustration of recorded CPU tests. Synthetic model and storage fixtures. No live model execution or attestation occurs in this walkthrough.
What This Adds to Shared Custody.
For Model Builders
Artifact checks help distinguish the model package you approved from bytes or identities that do not match it. The loader can refuse that mismatch before exposing a usable model bundle.
For Deploying Customers
Explicit model identities and integrity checks make deployment requirements inspectable. Both parties can reason about the same approved artifacts when investigating a failed load or planning an authorized update.
In the recorded baseline, the encrypted bundle opened and the protected test-image blocks were readable. Modified ciphertext was refused. A model identity mismatch was refused. Corrupting a block beneath a read-only dm-verity mapping caused the kernel to return an I/O error. Restoring the original test bytes restored successful opening or reading.
These results contribute to the engineering needed for controlled deployment. They support a concrete rule: successful use must depend on the approved artifacts passing their checks.
Where the Expected Identity Comes From.
An integrity check is worth only as much as the value it compares against. If the loader took the expected digest from its own configuration, whoever replaced the weights could replace the digest beside them, and the check would confirm nothing but its own inputs.
It does not. The expected digest is the model identity in the owner-signed custody policy. Before any share is released, each holder signs a release grant over that value, together with the request nonce, the runtime's attested transport key and the serving measurement. The runtime reconstructs that signed payload from its own copy of the value and verifies each holder's signature against it. If the copy has been edited, the signatures no longer match and the release is refused before a single share is opened.
The consequence is the one that matters. An attacker who substitutes the model can also edit the digest the loader will enforce. What they cannot do is obtain the key, because custody refuses first, so there is no plaintext model for the weakened check to pass on. Artifact integrity and key custody are one chain rather than two controls that happen to run side by side.
How This Is Held
Five regression tests pin the link, including the substitution itself: the expected digest is edited and the release is refused. They were verified by removing the binding and confirming that they fail.
Measured at a Defined Boundary.
The evaluation used synthetic model files and a disposable 8 MiB data image on a GCP CPU VM. It tested bundle integrity and actual kernel reads through dm-verity. It did not modify the VM’s boot disk.
Read the Test Scope
The identity check supplied an expected model-inventory digest that did not match the bundle. The filesystem check changed a byte in the test data image, then observed verification failure and a kernel I/O error. Restoring the original bytes restored verification.
dm-verity covers blocks as the kernel reads them, which is why a corrupted block beneath a read-only mapping returns an I/O error. It says nothing about model weights already decrypted into memory. Those are covered by the enclave boundary and by the key being wiped when a lease lapses, which are different mechanisms with different limits; a reader should not carry the filesystem guarantee forward into the running process.
No fresh TDX quote, GPU inference or protected GPU-serving image was part of this run. This result does not establish prevention of fine-tuning, protection from an administrator inside a running guest, or control over plaintext weights that have already been copied outside the approved runtime.
Custodian’s Qwen, Mistral and Nemotron inference demonstrations are separate hardware runs, with their own configurations and recorded scope.
Bring the Controls Together.
The next milestone is to combine an approved, restricted GPU-serving environment with holder verification and the model lifecycle: approved inference, refusal of altered deployment inputs, withdrawal, expiry, restart refusal and newly authorized recovery.
That demonstration needs the complete deployment boundary to be measured and enforced. The CPU results reported here provide evidence for part of that work.
Have a Deployment in Mind?
We’re working with model builders, sovereign AI programs and enterprises to define the conditions for shared model custody.
Explore a Design Partnership