Model Provenance

Every model artifact is bound to a verifiable digital identity. Before deployment, a model's weights, architecture, and metadata are hashed and signed using a private key held by the authorized builder. This creates a tamper-evident seal. Any subsequent modification—whether a single weight change or a full retraining—invalidates the signature, immediately signaling a breach in the supply chain. This process relies on hardware roots of trust and key management services (KMS) to protect the signing keys from exfiltration.

Provenance is not a static label; it is a dynamic, append-only log of a model's entire lifecycle. This includes:

• Training Data Digest: A cryptographic hash of the exact dataset version used.
• Code & Environment Hash: A fingerprint of the training script, dependencies, and container image.
• Transformation History: A record of every fine-tuning, quantization, or pruning operation. This lineage is often anchored to an immutable ledger or a Supply Chain Attestation framework like SLSA, ensuring the history cannot be rewritten retroactively.

Provenance extends beyond the file to the runtime environment. Using Trusted Execution Environments (TEEs) like Intel SGX or AMD SEV, a model can generate a remote attestation report. This report cryptographically proves that a specific, unmodified model is running on genuine, secure hardware. This closes the gap between a verified artifact at rest and a verified process in use, assuring consumers that the inference endpoint is not a spoofed or compromised instance.

A model's integrity is only as strong as its weakest dependency. True provenance requires a Software Bill of Materials (SBOM) for the entire ML pipeline. This includes:

• Base Model Origin: Verifying the hash of a pre-trained foundation model.
• Library Integrity: Ensuring no compromised PyTorch or TensorFlow version was used.
• Data Source Authentication: Proving the training data originated from a trusted, audited source and was not poisoned. This transitive trust model prevents a single compromised upstream component from invalidating the entire system.

Provenance is not a one-time check; it is a continuous policy. Admission controllers in a Confidential Orchestration platform can be configured to reject any model that lacks a valid, up-to-date provenance attestation. This includes:

• Signature Expiry: Forcing periodic re-validation.
• Revocation Checks: Blocking models built with a dependency that has since been flagged as vulnerable.
• Compliance Gates: Ensuring only models trained on data from approved jurisdictions are deployed in specific geographic regions.

Beyond the data and code, provenance captures the process. This includes cryptographically signed statements about the training hyperparameters, the random seed used for initialization, and the differential privacy parameters (ε, δ) applied. For federated learning scenarios, provenance tracks the contribution of each decentralized node and the aggregation protocol used. This level of detail is essential for regulatory audits, allowing an organization to prove a model was trained fairly and securely without revealing the underlying proprietary data.

A TEE-specific operation that encrypts data and binds it to the specific enclave identity and platform that created it. In model provenance, sealing protects the model's lineage metadata by ensuring it can only be decrypted by the exact same enclave on the exact same hardware. If an attacker clones the model artifact to another machine, the sealed provenance record becomes permanently inaccessible, providing tamper-evident storage for audit trails.

A security property allowing a relying party to verify that the code executing inside a TEE is exactly what they expect. For model provenance, this means publishing a cryptographic hash of the training or inference code and including it in the attestation report. A verifier can then confirm that the model was produced by a specific, audited codebase—not a backdoored variant—closing a critical gap in the trust chain.

A physically immutable, inherently trusted source within a computing platform that serves as the foundation for all subsequent security operations. In the context of model provenance, this is the silicon-anchored starting point for the entire chain of trust. It ensures that:

• Secure boot verified the firmware
• Measured boot logged every component
• The TEE's attestation key was derived from a genuine, unclonable hardware identity Without this, all higher-level provenance claims are built on sand.

The process of securely injecting secrets, configuration data, and cryptographic keys into a TEE only after its identity and integrity have been verified through remote attestation. For model provenance, this ensures that signing keys used to certify a model's origin are never exposed to the host OS or cloud provider. The enclave receives its signing key only after proving it is running the correct, unmodified provenance-logging code.