Model Provenance Attestation

A unique digital fingerprint of the model's weights, architecture, and compilation artifacts is generated using a collision-resistant hash function like SHA-384. This hash acts as the model's immutable identity. Any modification, even a single weight bit-flip, produces a completely different hash, making tampering immediately detectable. The hash is computed over the entire serialized model graph, including the computation graph structure, not just the weight tensors, preventing structural attacks.

The Trusted Execution Environment generates a cryptographically signed attestation report that binds the model's identity to the enclave's identity. This report includes:

• Enclave Measurement (MRENCLAVE): The hash of the code and initial state loaded into the TEE.
• Model Measurement (MRSIGNER): The hash of the model artifact, embedded as part of the enclave's configuration.
• Hardware TCB Status: Verified firmware versions and security configurations. The report is signed by a hardware-rooted key that chains back to the CPU manufacturer, providing a mathematically verifiable guarantee that a specific model is running on genuine, trusted hardware.

Attestation extends beyond the final model to encompass the entire training lineage. This includes cryptographic proofs linking the model hash to:

• The exact dataset version and its provenance hash.
• The training code repository commit hash.
• The compiler toolchain and optimization flags used.
• The identity of the principal who initiated the training job. This creates a Software Bill of Materials (SBOM) for the model, allowing a verifier to audit the complete provenance chain and ensure no unauthorized data or code was injected during the development lifecycle.

A challenge-response protocol where a relying party (e.g., a client sending data for inference) verifies the model's identity before transmitting sensitive information. The process:

1. The client requests an attestation report from the inference endpoint.
2. The TEE generates a fresh report, binding the model hash to a cryptographic nonce provided by the client to prevent replay attacks.
3. The client verifies the signature chain against the manufacturer's certificate authority.
4. The client compares the reported model hash against an allowlist of approved model identities. Only upon successful verification is a secure channel established, ensuring data is only sent to the authenticated, unmodified model.

Provenance attestation relies on a tamper-proof, append-only registry where model hashes and their associated lineage metadata are immutably recorded. This registry acts as the source of truth for the attestation verifier. Key properties:

• Content-Addressable Storage: Models are stored and retrieved by their cryptographic hash.
• WORM Compliance: Write-Once-Read-Many policy prevents overwriting or deletion of registered models.
• Transparent Logging: A Merkle tree structure provides efficient, publicly auditable consistency proofs, allowing anyone to verify that a model hash has been continuously and consistently logged without backdated insertion.

Attestation is not a one-time event. Continuous monitoring ensures the model's integrity throughout its execution lifecycle. The TEE hardware periodically re-measures the enclave's memory pages and compares them against the initial attested state. Any detected divergence, such as a memory corruption attack or a malicious hypervisor attempting to inject code, triggers an immediate enclave termination and key invalidation. This guarantees that the attested state remains invariant from the moment of initial attestation until the secure session is torn down.