Offline Model Registry

A cryptographic process where a private key generates a digital signature for a model artifact. Before loading, the runtime environment verifies this signature against a trusted public key to ensure the weights have not been tampered with since publication. This is the foundational integrity check for any artifact stored in an offline registry.

• Key Mechanism: Asymmetric cryptography (e.g., ECDSA, Ed25519)
• Verification: Performed client-side by the inference server before loading weights into memory
• Criticality: Prevents loading of backdoored or corrupted models in disconnected environments

A point-in-time copy of a model registry's state that cannot be altered or deleted. This provides a tamper-proof baseline for forensic analysis and rapid recovery. In an offline registry, immutability ensures that once a model version is committed, it remains auditable for the entire lifecycle of the deployment.

• Storage Backend: Write-Once-Read-Many (WORM) volumes or content-addressable storage
• Use Case: Compliance audits and rollback to a known-good state after a detected anomaly
• Integration: Often paired with cryptographic hashing for content integrity verification

An overarching concept for registries built with immutable, cryptographically signed storage for model artifacts. This ensures end-to-end auditability and integrity. An offline model registry is a specific implementation of this concept, designed to operate without external network dependencies.

• Core Properties: Immutability, cryptographic signing, and strict access controls
• Difference from Standard Registries: No dependency on external trust roots or online certificate status checks
• Operational Model: All verification materials must be co-located within the air gap

The automated process of checking a cryptographically signed manifest listing every software dependency and component against known vulnerability databases. For an offline registry, the BOM includes model weights, tokenizers, and runtime dependencies, all verified against an air-gapped vulnerability database.

• Standard: SPDX or CycloneDX formats for AI/ML artifacts
• Offline Adaptation: Vulnerability feeds are imported via sneakernet alongside model updates
• Scope: Covers Python packages, system libraries, and base container images used for serving

A container orchestration engine configured to operate without pulling images from the internet, relying solely on a local, air-gapped container registry. The model registry integrates with this runtime to ensure that serving containers and model artifacts are deployed from a unified, trusted source.

• Image Sources: All base images and model serving images are mirrored into the private registry
• Policy Enforcement: Admission controllers block any deployment referencing external registries
• Artifact Coupling: Model weights are often mounted as volumes from the registry's backing store

A root certificate authority that is kept powered down and physically secured, only brought online to issue or revoke subordinate certificates. This CA issues the code-signing certificates used to sign model weights and metadata in the offline registry, ensuring the root of trust is never exposed to a network.

• Key Ceremony: A multi-person, audited process for any CA operation
• Certificate Hierarchy: Root CA -> Subordinate CA -> Model Signing Certificates
• Revocation: Certificate Revocation Lists (CRLs) are manually transported into the air gap