AI Model Identity Verification: Verify the Model Running
Learn how AI model identity verification uses signed, fresh attestation, trusted measurements, and artifact hashes to confirm what runs - and understand its limits.
Table of Contents
Quick Answer
To verify which AI model is running, validate fresh, signed attestation evidence and compare its measurements with trusted expected values. Confirm that the evidence covers the model artifacts and the workload serving requests, because a model name or weights hash alone does not prove what is running.
This matters when handling sensitive data, meeting compliance requirements, or checking that a service runs the model revision it claims to use. The steps below explain what to ask for and what the evidence can establish.
A model name is not proof of model identity
A model card can describe intended uses, training details, evaluations, and limitations. It helps you assess a model, but it is documentation, not proof that a particular deployment is running the described model.
Behavioral tests can offer clues. For example, you might check how a model handles a known prompt or compare its outputs across versions. But outputs can vary, and a service can imitate expected behavior. Such tests do not cryptographically establish which model ran.
For stronger AI model identity verification, you need evidence tied to the running workload - not just its name, documentation, or responses.
What cryptographic model verification can establish
A measurement is a value recorded for software or configuration in a running environment. Attestation is a signed statement that reports measurements and information about that environment. A verifier checks the signature and decides whether the evidence meets its requirements.
Hardware-backed attestation can provide evidence that a workload is running inside a trusted execution environment (TEE), such as a confidential-computing enclave. The hardware and platform establish a root of trust; the attestation can report measurements of the environment and, depending on the platform and setup, additional workload information.
The key question is whether the evidence connects the model artifact to the workload that is actually serving requests. A model weights hash is useful only when trusted evidence shows that the measured workload loaded or otherwise used those exact bytes. Check whether the attestation covers the model files, serving code, runtime, configuration, and relevant deployment components - and how each measurement is produced.
Follow a practical AI model attestation workflow
Do not treat a provider's screenshot or a statement that its service is “attested” as a substitute for evidence you can validate. If independent verification is unavailable, ask what checks the provider performs and what evidence it is willing to share.
Also ask how the service handles multiple replicas, model updates, and request routing. One attested instance does not necessarily prove that every instance serving your traffic runs the same revision. You may need evidence per deployment or a documented mechanism that binds requests to verified instances.
Verify model provenance before and during deployment
For a self-hosted model, a practical record might include the model revision, weights digest, container or package digest, runtime version, configuration, and the release that approved them. Re-check those values when deploying updates. Provenance supports the chain of trust, while runtime attestation helps establish what is executing now. Neither replaces the other.
Know the limits of attestation before relying on it
Ask a provider:
- Which model artifacts and software components are measured?
- How are model revisions mapped to reported measurements?
- Is evidence available for each serving instance, and how is traffic linked to those instances?
- Can you verify the signature, certificate chain, freshness, and nonce independently?
- How are updates, configuration changes, and failures handled?
- What trust assumptions or components are outside the attestation's scope?
Before relying on an AI model identity verification claim, document what you need to prove and decide which evidence would satisfy that requirement. Ask your provider for the attestation evidence, measurement scope, and verification instructions behind its model identity claims. If you operate models yourself, retain expected artifact digests and compare them with fresh, signed runtime evidence.
Step-by-Step Guide
Request the attestation evidence
Ask the provider for the attestation document, verification instructions, measurement scope, and details about how evidence maps to model revisions and serving instances.
Verify the signature and issuer
Validate the document using the platform's documented method. Confirm that the certificate chain leads to a root of trust you accept and that the issuer and platform are appropriate for the claim.
Check freshness and replay protection
Confirm the evidence is recent enough for the deployment you are evaluating. Where supported, send a unique nonce and verify that it is included in the signed evidence.
Apply your verification policy
Check platform identity, security properties, and configuration against your requirements. A valid signature confirms the source signed the evidence; it does not establish that the environment meets your policy.
Compare measurements with trusted values
Match reported measurements to expected digests and values from an approved release or deployment record. Identify which measurements cover model artifacts, runtime, serving code, and configuration.
Confirm coverage across serving instances
Ask how updates, replicas, and request routing are handled. Determine whether evidence is available for each instance or whether requests can be linked to verified deployments.
Key Statistics
- SHA-256 produces a 256-bit message digest.NIST specifies SHA-256 in Secure Hash Standard FIPS PUB 180-4. A matching digest can help identify identical bytes, but does not by itself prove those bytes were loaded or used by a running service.
- The article's attestation workflow covers four verification checks: signature and issuer, freshness, policy, and measurement comparison.These four checks are drawn from the practical workflow described in this guide. They are a verification framework, not a claim that completing them proves model accuracy or safety.
Frequently Asked Questions
How can you verify which AI model is running?
What does AI model attestation prove?
Does a model weights hash prove which AI model is running?
How do you check whether AI attestation evidence is trustworthy?
Key Takeaways
- A provider's model name, model card, or behavioral test does not cryptographically prove which model artifacts are serving requests.
- A model weights hash identifies specific bytes, but does not prove those bytes were loaded or used by the service.
- Verify the attestation signature, issuer and certificate chain, freshness, nonce when supported, and compliance with your verification policy.
- Compare reported measurements with expected values from a trusted release or deployment process, and check whether the evidence covers the model, runtime, serving code, and configuration.
- Attestation can provide evidence about measured software and its environment, but it does not prove model accuracy, safety, fairness, or the truth of an answer.