Can an Attestation Token Prove Which AI Model Weights Were Loaded?

August 19, 2026

Sometimes—but only when the exact weight artifact is measured or its verified digest is bound to fresh evidence, key release, and the inference request.

Sometimes. An attestation token can help prove which AI model weights were loaded only when the exact weight bytes are inside a measured artifact, or when trusted loading code verifies a separate model digest and cryptographically binds that result to fresh attestation evidence and key release. A token that names only a confidential VM, GPU mode, or inference-container digest usually proves the environment—not the model files fetched after launch.

That distinction matters because an AI service can attest the same approved inference server while switching among different checkpoints, quantizations, adapters, tokenizers, or model aliases. The right question is not merely, “Is this server attested?” It is, “Which exact model artifact did the evidence identify, who approved that identity, and what prevents the workload from loading something else?”

Who This Guide Is For

This guide is for security teams, AI buyers, model owners, and builders evaluating confidential inference, verifiable AI, trusted execution environments, confidential GPUs, or model-weight protection.

It focuses on artifact identity. It does not claim that attestation proves a model is accurate, safe, licensed, unbiased, free of backdoors, or the model that produced every response attributed to it.

What Is Confirmed

Remote attestation can provide signed, fresh evidence about a measured execution environment. The IETF's Remote ATtestation procedureS architecture separates the attester that produces evidence, the verifier that appraises it against reference values and policy, and the relying party that uses the result to make a trust decision.

Current platforms expose useful but different measurements:

• Google Confidential Space tokens can include the workload container's image_digest, image reference, launch arguments, selected environment variables, debug status, trusted-computing-base information, and GPU confidential-computing claims. Google's token-claims reference identifies each claim precisely.
• Microsoft Azure Attestation exposes an SEV-SNP launch measurement, guest-image identity, debug state, policy hash, report data, initialization claims, and runtime claims supplied from the attested environment.
• AWS Nitro Enclaves documents PCR0 as a measurement of the enclave image file and PCR2 as a measurement of its applications. The signed attestation document can also carry a nonce, public key, and user data for a protocol defined by the enclave and relying party.
• NVIDIA's current confidential AI deployment architecture describes a verifier checking CPU, GPU, guest, workload, runtime-policy, and identity evidence before a key broker releases the model-decryption key into a confidential guest.

These mechanisms can support a strong model-identity claim. None creates that claim automatically. The model artifact must be within the measurement or explicitly joined to it through a verifiable protocol.

Four Different Claims Hidden Inside “The Model Was Loaded”

Before evaluating evidence, separate four statements that vendors often compress into one.

1. Artifact Identity

The service obtained a specific set of bytes: for example, a manifest naming every weight shard, configuration file, tokenizer, adapter, and custom-code dependency by digest.

2. Artifact Integrity

Those bytes matched approved reference digests and were not modified between publication, storage, transfer, decryption, and loading.

3. Runtime Selection

The attested process actually selected that artifact rather than another checkpoint already on disk, a fallback model, a different quantization, or a remote API.

4. Request Binding

The response a buyer received came from the attested instance using that selected artifact. A valid token from one machine does not automatically prove that an unrelated request was routed to it.

An image digest can be excellent evidence for the first two claims when the weights are part of the image. It says less about runtime selection and request binding unless the surrounding protocol closes those gaps.

When a Container Image Digest Includes the Weights

If the model files are built into the attested container image, an exact image digest can indirectly identify them. The Open Container Initiative image specification defines an image through a manifest, configuration, and content-addressed filesystem layers. A changed weight shard changes a layer digest and therefore changes the image's content identity.

This is the simplest case:

1. Build the inference code and exact model artifacts into one immutable image.
2. Record the approved image digest and its model manifest.
3. Attest that digest with debugging disabled and expected launch settings.
4. Release the model or request-decryption key only when the evidence matches policy.
5. Reject startup if any expected file or runtime condition differs.

The conclusion can then be strong: the workload launched from an image whose content-addressed layers included the approved model bytes.

But even this does not prove the inference process used every included file. An image can contain several checkpoints, fallback paths, adapters, or remote-provider clients. Reviewed startup behavior and negative tests are still needed to show which artifact the service selected.

When the Weights Are Downloaded After Attestation

This is the more common gap.

Large models are often too operationally awkward to bake into every application image. The inference container may start first, then mount encrypted storage or fetch weights from an artifact service. NVIDIA's workload and model lifecycle explicitly allows encrypted weights to ride inside an image, mount from encrypted storage, or arrive after boot from an artifact service.

When weights arrive after launch, a token containing only the container digest proves the identity of the loader—not the identity of the downloaded model.

That loader might be perfectly trustworthy and still accept:

• a mutable model name such as production-latest;
• a repository tag that now points to a different revision;
• a different quantization with the same marketing name;
• an unapproved LoRA or other adapter;
• modified tokenizer or chat-template files;
• custom model code from a moving branch;
• a cached fallback checkpoint; or
• a hosted API selected when local loading fails.

To close the gap, the measured loader must verify an immutable model manifest inside the trusted boundary. That manifest should cover every file that can materially change inference, not just the largest weight shard.

The Stronger Pattern: Bind the Model Manifest to Key Release

A defensible design treats model identity as an authorization condition.

1. The model owner publishes an immutable manifest containing cryptographic digests for the checkpoint shards, configuration, tokenizer, templates, adapters, and allowed custom code.
2. The approved, measured loader obtains the encrypted artifacts.
3. Inside the trusted environment, it verifies every file against the manifest before use.
4. It binds the verified manifest digest to fresh evidence, a proof-of-possession key, or the key-release request.
5. A separate key broker checks the environment claims, model-manifest identity, freshness, debug state, and policy version.
6. The broker releases a model-decryption key only for the approved combination.
7. Startup fails closed if the model digest, workload image, runtime policy, or platform state differs.

NVIDIA's lifecycle guidance says model-artifact rotation changes the artifact digest, key ID, or release policy and therefore requires new artifact metadata and an updated key policy. Its acceptance-test appendix expects unapproved images or runtime policies to be denied, retired model keys to become unavailable, and artifact rotations to retain new measurements, digests, and audit records.

This design is materially stronger than placing a model name in an unsigned launch argument or dashboard. It makes substitution change a value the verifier or key broker must reject.

Why a Self-Reported Model Hash Is Not Enough

Some attestation formats let software inside the trusted environment add runtime or user-defined claims. Azure, for example, supports runtime claims from the attested environment, while AWS attestation documents can include user data.

That can carry a model-manifest digest, but the field does not become trustworthy merely because it is signed inside a token. The relying party must know which measured code generated the claim and whether that code actually hashed the loaded files.

A malicious or careless loader could report the approved digest while opening different bytes. A trustworthy binding therefore requires:

• measured claim-generation code;
• a clear definition of exactly which files are hashed;
• verification after decryption and before loading;
• protection against replacement after verification;
• fail-closed behavior; and
• a policy that rejects missing, stale, or unapproved model claims.

Attestation protects a truthful statement only when the measured software is designed to make it truthfully.

The WEIGHTS Verification Test

Use this seven-part test when a vendor says it can prove which model served a request.

W — Weight Manifest

Ask for an immutable manifest that covers the complete model package. One model identity may require dozens or hundreds of shards plus configuration, tokenizer, chat template, adapters, and model-specific code.

E — Evidence Scope

Read the token schema. Does it name only the hardware and guest, or also the workload image, launch configuration, model-manifest digest, debug state, policy version, freshness value, and proof-of-possession key?

I — Image Mapping

Map every accepted image digest or launch measurement to a reviewed build. A hash identifies bytes; it does not explain them. Require provenance, version history, and an approval owner.

G — Gated Keys

Determine what the evidence controls. The strongest answer is that an independent key service will not release model-decryption keys to an unapproved environment-model combination. A token displayed after startup is weaker.

H — Hash And Load

Verify where and when hashes are calculated. For runtime-fetched models, checking encrypted archive bytes outside the enclave is not necessarily the same as checking the plaintext files the loader uses. The service should verify the relevant representation inside the protected boundary and prevent post-check substitution.

T — Time And Request Binding

Require a nonce, short validity period, proof-of-possession key, and a channel that binds the client's request to the attested workload. Otherwise, a valid old token or token from another instance may be replayed beside an unverified response path.

S — Substitution Tests

Test failure, not just success. Change one shard, adapter, tokenizer file, launch argument, image digest, or model key. The service should refuse key release or fail startup with evidence showing which policy check failed.

What an Attestation Token Still Does Not Prove

Even a well-bound model digest does not prove that the model is:

• the vendor's advertised capability tier;
• free from malicious training, backdoors, or unsafe behavior;
• trained on lawfully obtained data;
• covered by a particular license;
• accurate for a buyer's task;
• running without application-level logging;
• isolated from every side channel; or
• the only component that handled the request.

Artifact identity is valuable precisely because it is narrow. It lets a buyer test whether known bytes and approved code were present. Separate evaluation, governance, privacy, and safety evidence must support the larger claims.

This is also why remote attestation does not by itself prove an AI service is not logging prompts. The correct model can still be wrapped in software that retains inputs, emits telemetry, or calls downstream services.

What Is Still Unclear

Most public confidential-AI descriptions do not yet give ordinary buyers a per-request proof chain for model identity. For a specific service, ask the provider to document:

• whether weights are inside the measured image, mounted, or downloaded after launch;
• the exact manifest that defines one model version;
• whether quantizations, adapters, tokenizers, templates, and custom code have separate identities;
• who approves reference digests and who can change key-release policy;
• whether plaintext or encrypted artifact bytes are being identified;
• how a verified digest is bound to the token and client request;
• whether routing, batching, caching, and fallbacks stay inside the attested path;
• what happens during model, key, driver, firmware, or runtime rotation; and
• whether customers can run negative substitution tests.

Without those answers, absence of evidence that a different model was loaded is not proof that the advertised model was used.

A Buyer-Friendly Evidence Statement

A good vendor statement should sound specific:

A fresh token identifies workload image digest X and model-manifest digest Y. The measured loader verified every plaintext artifact in manifest Y inside the confidential guest. Key service Z released decryption key K only after validating those claims, and the client's request channel was bound to the attested proof-of-possession key.

A weak statement sounds broad:

Our GPUs support confidential computing, so the model is verified.

The first statement can be tested. The second leaves model identity, policy, routing, and request binding unresolved.

Where OpenVeil Fits

OpenVeil provides a privacy-focused hosted workspace for chat, files, search, voice, images, and video. Normal chat history is stored in the browser rather than as a server-side chat-history record, and OpenVeil says prompts, uploads, media, and outputs are not used to train foundation models.

OpenVeil is not fully offline. Active requests require processing by OpenVeil and necessary providers, and limited operational, billing, security, and abuse-prevention records can exist. OpenVeil does not currently claim that every request carries customer-verifiable remote attestation, that a token proves exact model-weight identity, or that provider processing is eliminated.

If those documented boundaries fit your work, you can try OpenVeil without treating a privacy-focused workflow as proof of an attestation feature the product does not claim.

Frequently Asked Questions

Does a container image digest prove which model is loaded?

Only when the exact model artifacts are part of that immutable image and approved startup code selects them. If the container downloads or mounts weights after launch, its image digest usually identifies the loader rather than the downloaded model.

Can an attestation token include a model hash?

Yes. A platform may support runtime or user-defined claims, and measured code can bind a verified model-manifest digest into the evidence or key-release protocol. The verifier must still trust the measured code that calculated and reported the hash.

Does GPU attestation identify model weights in GPU memory?

Not automatically. GPU attestation commonly reports hardware, firmware, driver, and confidential-computing state. Proving the model artifact requires an additional measured-loading and digest-binding protocol.

What if the model has many weight shards?

Use a signed or otherwise approved manifest that names every shard and all inference-relevant companion files by digest. Bind the manifest digest—not a mutable model name—to attestation and key-release policy.

Can attestation prove which model produced one response?

It can strengthen that conclusion when a fresh token, proof-of-possession key, request channel, router, and attested inference instance are cryptographically connected. A standalone token from an unspecified instance is not enough.

Is a signed model the same as an attested model?

No. A signature can establish who approved an artifact and whether its bytes changed. Attestation can establish claims about the environment running it. Strong verifiable inference uses both and binds them to policy.

Bottom Line

An attestation token can help prove which AI model weights were loaded, but only if model identity is inside the measured artifact or is separately verified and bound to fresh evidence, conditional key release, and the request path.

If the token names only the confidential environment or inference container while weights arrive later, it proves the loader—not the loaded model. Require an immutable model manifest, measured verification code, fail-closed key policy, freshness and request binding, and negative substitution tests before treating “attested AI” as evidence of exact model-weight identity.