Purpose
Ensure model artifacts, inference images, tools, MCP servers, and third-party AI dependencies are authenticated, reviewed, and verifiable—applying SLSA-style integrity to the AI stack.
Mandatory checks
Gate controls. Each check is pass/fail via artifact + pass condition. Expected from the annotated capability level when the system meets the minimum criticality tier.
Production model and container artifacts shall have verified provenance/integrity—proven by signature, attestation, or digest verification with unverified pulls blocked, not by digest pins in Dockerfiles alone.
- Artifact
- Signature / attestation / provenance / checksum verification config (cosign, Notation, SLSA, OCI, or equivalent); Digest or signature verification logs for production model/container pulls in the sample window; Proof unverified pulls are blocked (admission policy, registry policy, or deploy gate; measuredAt ≤90 days)
- Pass condition
- Provenance/integrity verification is configured for production model and/or container artifacts (signature, attestation, OCI provenance, and/or checksum/ digest); 100% of production model/container pulls in the sample window verify against expected digest or signature; unverified pulls are blocked (measuredAt ≤90 days). If no production model or container artifacts are pulled, score NOT_APPLICABLE.
Why this control exists
Threat mapEnsure production AI artifacts come from a verified source and have not been tampered with.
Threats mitigated
Supply Chain CompromiseData and Model PoisoningUnsafe Code ExecutionProtects
ModelsInfrastructureRuntimeMITRE: ATLAS AML.T0010 · ATLAS AML.T0058 · ATLAS AML.T0018.002 · ATLAS AML.T0076 · ATLAS AML.T0109 · ATT&CK T1195 · ATT&CK T1195.002
Model weights are executable artifacts that can carry embedded malware or behavioural backdoors which evaluation will not surface. Verified provenance and integrity is the only reliable control against substituted, poisoned, or rug-pulled artifacts.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Production external AI tools, MCP servers, agent plugins, and high-impact integrations shall be inventoried with version pins, named owners, and recurring review—proven by an inventory covering those surfaces with 0 unpinned “latest”/floating entries, not by CI Action SHA pins or package lockfiles alone.
- Artifact
- Inventory of production external AI tools, MCP servers, agent plugins, and high-impact integrations with version pins, owners, review dates ≤180 days, and 0 unpinned latest/floating entries (measuredAt ≤90 days)
- Pass condition
- 100% of production external AI tools, MCP servers, agent plugins, and high-impact integrations have version pin + owner + review date ≤180 days; 0 unpinned “latest” (or floating) entries in production (inventory evidence measuredAt ≤90 days). If none of those surfaces exist in production, score NOT_APPLICABLE.
Why this control exists
Threat mapEnsure every external tool, MCP server, and plugin in production is known, pinned, and reviewed.
Threats mitigated
Supply Chain CompromiseTool AbuseUnauthorized Tool UsePrompt InjectionProtects
ToolsExternal SystemsRuntimeDataMITRE: ATLAS AML.T0010.005 · ATLAS AML.T0104 · ATLAS AML.T0110 · ATLAS AML.T0011.002 · ATLAS AML.T0099 · ATLAS AML.T0109 · ATT&CK T1195
MCP servers and agent plugins execute with the agent's privileges and can silently redefine their own tool descriptions after installation. Inventory, version pinning, and pre-production review counter poisoned and rug-pulled tools, which are the primary agentic supply-chain techniques.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Production AI artifacts—including language dependencies, OCI/container images, serverless packages, and model-serving runtimes—shall be scanned for vulnerabilities before promotion, with organization-defined critical findings blocking deploy unless waived with owner and expiry—not by scanning app deps while skipping inference servers or CUDA stacks.
- Artifact
- Vulnerability scanner config + promote-path critical block (org policy) + retained scan results with 100% coverage and 0 skipped scans for production AI artifacts (measuredAt ≤90 days); critical waivers with owner + expiry ≤14 days
- Pass condition
- 100% of production AI artifacts in the sample window (language dependencies, OCI/container images, serverless packages, and model-serving runtimes including inference servers and accelerator libraries in scope) were vulnerability-scanned with no skipped scans; findings that are critical per organizational policy block promotion unless waived with named owner and expiry ≤14 days; scan results are retained (evidence measuredAt ≤90 days). If no production AI artifacts are built or deployed, score NOT_APPLICABLE.
Why this control exists
Threat mapBlock deployment of AI artifacts carrying known exploitable vulnerabilities.
Threats mitigated
Supply Chain CompromiseUnsafe Code ExecutionPrivilege EscalationProtects
InfrastructureRuntimeModelsMITRE: ATLAS AML.T0010 · ATLAS AML.T0049 · ATT&CK T1195 · ATT&CK T1190 · ATT&CK T1068
AI runtimes pull large, fast-moving dependency trees that include deserialization-prone model loaders and inference servers. Scanning gates keep known-vulnerable components out of production and shrink the exploitable surface.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Production deployment policy shall enforce blocking of unsigned, unapproved, and revoked-signature AI artifacts on the deploy path—proven by policy plus deny/verification logs, not by signing in CI or digest pins alone. Applies via Kubernetes admission, pipeline gates, cloud deploy policies, artifact registry rules, or AI-platform promote gates—not Kubernetes-only.
- Artifact
- Deployment policy configuration (admission, pipeline, cloud deploy policy, registry, or AI-platform gate) + deny/verification logs for unsigned, unapproved, and revoked/untrusted signatures (measuredAt ≤90 days)
- Pass condition
- Production deployment policy is enforced on AI artifact deploy/promote paths; unsigned artifacts are blocked; unapproved artifacts are blocked; revoked or untrusted signatures are rejected; deployment or admission deny/ verification logs prove enforcement (measuredAt ≤90 days). If no production AI artifacts are deployed (models/containers/serverless AI packages), score NOT_APPLICABLE. Required from capability Level 5 (advanced mandatory)—not a Tier 2/Core baseline.
Why this control exists
Threat mapEnforce at the deployment boundary that only approved, signed AI artifacts can run.
Threats mitigated
Supply Chain CompromiseData and Model PoisoningInsider MisuseProtects
ModelsInfrastructureRuntimeMITRE: ATLAS AML.T0010 · ATLAS AML.T0058 · ATLAS AML.T0076 · ATT&CK T1195 · ATT&CK T1195.002
Provenance checks and scanning only reduce risk if the deploy path actually refuses artifacts that fail them. Admission enforcement is what makes the preceding supply-chain controls non-optional rather than advisory.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Evidence required
- Artifact signing/verification configuration
- MCP and tool inventory with review records
- Image/model scan reports for production releases
Recommended checks
Strengthen posture beyond the gate. Same measurable structure; non-blocking unless elevated by organizational policy.
Production model and container (or equivalent AI package) deploys should verify signatures or attestations at deploy/promote time and reject unsigned artifacts—proven by the last successful verified deploy plus a recorded unsigned-reject test or canary, not by CI signing or digest pins alone.
- Artifact
- Verify-on-deploy / promote-path policy + last production deploy verification log (signature/attestation success) + recorded unsigned-reject test/canary/deny log (measuredAt ≤90 days)
- Pass condition
- The last production model/container (or equivalent AI package) deploy verified a signature or attestation successfully; an unsigned artifact is rejected in a recorded test, canary, or deny log within 90 days (evidence measuredAt ≤90 days). If no production model/container AI artifacts are deployed, score NOT_APPLICABLE.
Why this control exists
Threat mapVerify artifact signatures against build provenance at deploy time.
Threats mitigated
Supply Chain CompromiseData and Model PoisoningProtects
ModelsInfrastructureMITRE: ATLAS AML.T0010 · ATLAS AML.T0058 · ATT&CK T1195.002
Signature verification tied to build provenance detects artifacts substituted after the build step, including in the registry itself. It raises the assurance from "came from our registry" to "was produced by our pipeline".
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Each production model pin should have a machine-readable MBOM (or SBOM plus model-specific metadata) retained ≥90 days and linked from the model registry—proven by registry linkage and retained artifacts, not by a container-image SBOM that omits model weights and serving components.
- Artifact
- Machine-readable MBOM (preferred) or SBOM + model-specific metadata per production model pin; registry links; retention ≥90 days; coverage export (measuredAt ≤90 days)
- Pass condition
- 100% of production model pins have a machine-readable MBOM (or SBOM plus model-specific metadata covering weights/adapters/tokenizers and serving stack as applicable) retained ≥90 days and linked from the model registry entry (coverage evidence measuredAt ≤90 days). If no production model pins exist, score NOT_APPLICABLE.
Why this control exists
Threat mapRecord the composition of each production model pin so affected deployments can be found quickly.
Threats mitigated
Supply Chain CompromiseData and Model PoisoningProtects
ModelsAudit TrailMITRE: ATLAS AML.T0010 · ATT&CK T1195
An MBOM records base model, adapters, and datasets, so a newly disclosed poisoned component can be traced to every affected deployment. Its value is response speed during a supply-chain incident rather than prevention.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution
Engineering philosophy
An AI system is only as trustworthy as the artifacts it loads. Unsigned weights, unverified MCP hosts, and opaque tool catalogs are supply-chain defects, not product features.
Why it matters
Poisoned models, compromised MCP servers, and tampered tool plugins bypass application-layer controls and can exfiltrate data or execute attacker-chosen actions at scale.
Common failures
- Downloading open-weight models from unverified mirrors without checksum or signature verification
- MCP servers installed without source review or pinned versions
- No SBOM/MBOM for inference images and agent runtimes
- Fine-tuned adapters pulled from untrusted registries into production
Severity & risk
- Severity
- critical
- Impact if violated
- Risk level
- high
- Typical residual risk (impact × likelihood)
Engineering best practices
- Prefer private registries for production models and adapters
- Treat MCP hosts as supply-chain surfaces equal to npm/PyPI packages
- Separate build and serving identities; never use developer credentials in prod pulls
- Record provenance in release evidence packs
Automatic validations
- CI verification of artifact digests against expected values
- Admission controller or gateway denials for unsigned artifacts
- SBOM generation and CVE gates on AI images
Manual validations
- Source review for new MCP servers and tool plugins
- Periodic audit of model download sources
Examples
- Inference pods only pull images signed by the org signing key
- An MCP catalog requires peer review and a pinned commit before agents can call it
References
Crosswalks
Show 15 peer mappingsexpandcollapse
Secure & Resilient Secure and Resilient
NIST AI Risk Management Framework · aligns-with
Annex A AI system controls (selected themes)
ISO/IEC 42001 · partial
LLM03 Supply Chain
OWASP Top 10 for Large Language Model Applications · supports
C3.1 Model Authorization & Integrity
OWASP AI Application Security Verification Standard (AISVS) · supports
C6.1 Model Artifact Integrity
OWASP AI Application Security Verification Standard (AISVS) · supports
C6.2 AI BOM & Supply Chain Monitoring
OWASP AI Application Security Verification Standard (AISVS) · supports
L1 Foundation Models
CSA MAESTRO (Multi-Agentic Threat Model) · supports
L4 Deployment & Infrastructure
CSA MAESTRO (Multi-Agentic Threat Model) · supports
CC9 Risk Mitigation
SOC 2 Trust Services Criteria · evidence-for
Security Security
AWS Well-Architected Framework · aligns-with
Level 1 Build process documented
SLSA (Supply-chain Levels for Software Artifacts) · partial
Level 2 Hosted build + signed provenance
SLSA (Supply-chain Levels for Software Artifacts) · aligns-with
Level 3 Hardened builds
SLSA (Supply-chain Levels for Software Artifacts) · partial
Provenance Artifact provenance
SLSA (Supply-chain Levels for Software Artifacts) · supports
Verify-on-deploy Verification before use
SLSA (Supply-chain Levels for Software Artifacts) · supports
Future evolution
Portable MBOM formats and cross-vendor attestation for hosted and self-hosted models.