A cryptographic attestation standard for deployed AI systems.
Version 2.1 · February 2026
Technical Specification · SSRN Working Paper [link to be added]
When you interact with an AI system, you cannot independently verify:
- Which model weights are actually responding
- Which system policy is active
- Whether routing or silent model substitution occurred during your session
- Whether configuration changed between requests
Operators can claim to run any model. There is currently no cryptographic mechanism to verify this claim. MIVP solves this.
MIVP defines a deterministic, multi-layer identity model based on cryptographic hashing and Merkle tree commitments. Four hash layers combine into a single Composite Instance Hash (CIH) that uniquely identifies a deployed model instance:
| Layer | Component | What it covers |
|---|---|---|
| MH | Model Hash | Weights, tokenizer, architecture — Merkle root over chunked artifacts |
| PH | Policy Hash | System prompt, guardrail rules, moderation layer |
| RH | Runtime Hash | Temperature, top-p, max tokens, tooling, routing flags |
| CIH | Composite Instance Hash | **SHA256(MH |
Any change to weights, policy, or runtime changes the CIH. The CIH can be cryptographically signed by the operator and verified by any client.
- Silent substitution detection — compare CIH across requests; any change signals routing or model switch
- Policy change detection — PH changes when system prompt or guardrails change
- Reproducibility — same CIH guarantees identical deployment configuration
- Audit and compliance — cryptographically verifiable identity for regulated deployments
- No trusted hardware required — format-agnostic, compatible with existing deployment pipelines
MIVP does not verify correctness, alignment, or safety. It verifies identity only. Identity is the prerequisite for all higher-level guarantees.
MIVP follows the pattern of established internet trust infrastructure:
- HTTPS replaced HTTP for transport identity
- Code signing replaced unsigned executables
- Secure Boot replaced unsigned firmware
In each case, systems capable of producing verifiable identity proofs gained structural advantages. MIVP applies this pattern to AI model identity.
The full specification (MIVP_2_1_Complete_Specification.pdf) includes:
- Core protocol — four hash layers, CIH construction, attestation format, verification procedure
- Appendix A — Merkle specification for model weights (chunking, tree construction, carry-up logic, test vectors)
- Appendix B — Policy canonicalization (field-level normalization, JSON serialization rules)
- Appendix C — Composite Instance Hash specification
- Appendix D — Runtime Hash specification
- Appendix E — Instance Attestation format
- Appendix F — Session Continuity Protocol (ASK/ORK model)
- Appendix G — Normative test vectors (implementations MUST produce byte-identical CIH values)
- Appendix H — Structural adoption dynamics
- Appendix I — Implementation guidance for deterministic compliance (critical failure modes for LLM-generated code)
No reference implementation exists yet.
The specification is complete and includes normative test vectors (Appendix G) and explicit implementation constraints (Appendix I) designed to prevent the most common failure modes in LLM-assisted code generation.
If you implement MIVP, the test vectors in Appendix G are your compliance baseline: byte-identical CIH output is required for interoperability.
MIVP and the Alexandria Protocol address complementary verification problems:
- MIVP verifies which system produced a knowledge claim — model identity, policy, configuration
- Alexandria verifies the epistemic structure of the claim itself — derivation path, assumptions, revision history
Together they provide end-to-end verifiability: from the identity of the system that generated a claim, to the structural integrity of the claim itself.
H.-Steffen Rentschler
Independent researcher
SSRN author
MIT. Implement freely, cite honestly.