AID-M-002.002: Cryptographic Integrity Verification

Version 1.20261015 · Actionable sub-technique

Employs cryptographic hashing and digital signatures to create and verify a tamper-evident chain of custody for macro-scale AI artifacts throughout their lifecycle. Focuses on whole-artifact integrity for datasets, model weights, container images, and manifests to ensure you deploy exactly what you built. This technique provides artifact lifecycle integrity from creation through storage to deployment, with provenance verification to prove authenticity and origin.

Pillars: data, infra, model, app

Lifecycle: building, validation

Scope boundary

Owns creation and verification of whole-artifact cryptographic digests and signatures for stored, transferred, loaded, or admission-bound datasets, models, configurations, and related artifacts, bound to the expected identity and provenance record. It does not decide release promotion or own continuous drift monitoring.

AID-M-002.001: AID-M-002.002 proves that artifact bytes match trusted integrity metadata; AID-M-002.001 proves version identity and derivation lineage. Integrity verification and reproducible version history are complementary but independently evidenced claims.

AID-H-020.001: AID-M-002.002 verifies a complete artifact as one integrity object; AID-H-020.001 signs and verifies individual retrieval chunks so partial knowledge-base content cannot be substituted at query time. A valid whole-artifact digest does not prove the identity of each runtime-retrieved chunk, and chunk signatures do not replace release-artifact verification.

AID-D-004.001: AID-M-002.002 owns the authoritative whole-artifact digest and signature verification used at ingestion, transfer, load, or admission; AID-D-004.001 independently replays those checks over a declared candidate or deployed snapshot and emits integrity-drift findings. The same promotion-time verification cannot earn a second PASS under Detect, and a later detector result does not replace artifact admission.

AID-H-003.002: AID-M-002.002 supplies whole-artifact and signed-member integrity evidence; AID-H-003.002 owns the final model promotion, deployment, load and reload decision. A successful digest or signer verification cannot authorize a loader or earn duplicate admission credit.

Implementation guidance

AID-M-002.002-G001

Generate and verify whole-artifact checksums (e.g., SHA-256) for datasets, models, and container images at critical pipeline stages.
Concept:

We generate a cryptographic hash (e.g. SHA-256) for each critical artifact (dataset, feature store export, model weights) at ingestion/build time. We store that hash in a trusted metadata store. Any job that later consumes that artifact must recompute the hash and compare. If it doesn't match, the job stops immediately instead of silently training on or deploying a tampered file.

Step 1: Generate Hash on Data Ingestion
# integrity/hash_file.py
import hashlib

def sha256_file(path):
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for block in iter(lambda: f.read(4096), b""):
            h.update(block)
    return h.hexdigest()

if __name__ == "__main__":
    dataset_hash = sha256_file("data/creditcard.csv")
    print(f"SHA256(data/creditcard.csv)={dataset_hash}")
    # Store dataset_hash in a secure metadata store:
    # - MLflow tag
    # - signed manifest file
    # - internal registry DB
Step 2: Enforce Hash Check Before Training or Serving
# training_or_inference_gate.py
from pathlib import Path

from integrity.hash_file import sha256_file

# The protected digest file is mounted read-only only after its detached signature is verified.
EXPECTED_HASH = Path("/run/aidefend/verified/data-creditcard.sha256").read_text(encoding="ascii").strip()
if len(EXPECTED_HASH) != 64 or any(ch not in "0123456789abcdef" for ch in EXPECTED_HASH):
    raise RuntimeError("verified digest has invalid SHA-256 format")
ACTUAL_HASH = sha256_file("data/creditcard.csv")

if ACTUAL_HASH != EXPECTED_HASH:
    raise RuntimeError("Data integrity check failed: unexpected content hash")

print("Data integrity check passed; proceeding with training or inference.")
print("integrity gate completed for the verified artifact digest")

Action: Make this hash verification the very first step of any training, fine-tuning, or inference job that uses high-risk data or model weights. If verification fails, the pipeline must hard-stop and alert security. This prevents silent poisoning or corruption from propagating further.

AID-M-002.002-G002

Sign single-file artifacts or complete model bundles under a pinned identity, verify their exact byte/member integrity, and supply evidence to the canonical model release/load gate.
Step 1: Keep blob signing for a true single-file artifact
# Run in a trusted CI identity after producing the immutable artifact.
MODEL_FILE=model.safetensors
cosign sign-blob   --yes   --bundle "$MODEL_FILE.sigstore.json"   "$MODEL_FILE"

# The integrity verifier pins both identity and issuer.
cosign verify-blob   --bundle "$MODEL_FILE.sigstore.json"   --certificate-identity "https://github.com/my-org/my-repo/.github/workflows/build.yml@refs/heads/main"   --certificate-oidc-issuer "https://token.actions.githubusercontent.com"   "$MODEL_FILE"
Step 2: Sign a complete multi-file model bundle

Install model-signing from an organization-approved, hash-locked dependency file or a pinned CI image. Keep the detached signature outside the signed directory so the signature cannot accidentally become an input to its own manifest.

# File layout:
# release/model/              exact directory promoted to the registry
# artifacts/model.oms.sig    detached OMS-compatible Sigstore bundle
MODEL_DIR=release/model
OMS_SIGNATURE=artifacts/model.oms.sig
EXPECTED_IDENTITY="https://github.com/my-org/my-repo/.github/workflows/build.yml@refs/heads/main"
EXPECTED_ISSUER="https://token.actions.githubusercontent.com"

mkdir -p artifacts
model_signing digest "$MODEL_DIR" > artifacts/model.digest.txt
model_signing sign "$MODEL_DIR" --signature "$OMS_SIGNATURE"

model_signing verify "$MODEL_DIR"   --signature "$OMS_SIGNATURE"   --identity "$EXPECTED_IDENTITY"   --identity-provider "$EXPECTED_ISSUER"
Step 3: Prove the verifier rejects member tampering
# Negative test: mutate one signed member in an isolated copy.
TMP_DIR="$(mktemp -d)"
trap 'rm -rf "$TMP_DIR"' EXIT
cp -a "$MODEL_DIR" "$TMP_DIR/model"
printf '
' >> "$TMP_DIR/model/config.json"

if model_signing verify "$TMP_DIR/model"   --signature "$OMS_SIGNATURE"   --identity "$EXPECTED_IDENTITY"   --identity-provider "$EXPECTED_ISSUER"; then
  echo "ERROR: tampered model bundle verified" >&2
  exit 1
fi
Verify safely

At deployment, verify from the registry download in a clean environment and recompute the directory manifest; do not rely on the build job's self-reported success.

Integrity handoff

This primitive proves signer identity and whole-artifact/member integrity; it does not authorize model promotion, deployment or load. Supply the verified signature, digest and population result to the canonical AID-H-003.002-G003 coordinator on its same protected artifact/tree. A valid OMS or blob signature alone cannot replace composition, source-status, loader policy or final release approval.

Open-source tools

Commercial / hosted tools

Threat mappings

MITRE ATLAS

MAESTRO

OWASP LLM Top 10 2026

OWASP ML Top 10 2023

OWASP Top 10 for Agentic Applications 2026

NIST Adversarial Machine Learning 2025

Cisco Integrated AI Security and Safety Framework

Google Secure AI Framework 2.0 - Risks

Databricks AI Security Framework 3.0

AID-M-002.002: Cryptographic Integrity Verification | AIDEFEND

Loading interactive view…

AIDEFEND™

A Practical Knowledge Base for AI Security Defenses

Version

GitHub MCP Service