Purpose
Control which models (hosted or self-hosted) may be used in which environments, how they are versioned, evaluated, deprecated, and constrained by capability.
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.
Critical production AI paths shall reference immutable, pinned model identifiers, and shall not use floating aliases such as “latest” (or equivalent provider defaults that can change without a deploy).
- Artifact
- Production model pin config (or registry) listing immutable model IDs on critical paths + Lint or CI rule that rejects “latest”/floating aliases on those paths
- Pass condition
- 0 “latest”/floating aliases on critical production paths; 100% of those paths reference immutable model IDs; lint or CI rejects floating aliases (pin evidence measuredAt ≤90 days). If no production AI paths call hosted or self-hosted models, score NOT_APPLICABLE.
Why this control exists
Threat mapEnsure production behaviour comes from an explicitly chosen, evaluated model version.
Threats mitigated
Supply Chain CompromiseConfiguration DriftMisinformationProtects
ModelsRuntimeUsersMITRE: ATLAS AML.T0109
Floating aliases such as "latest" let a provider-side or registry-side change alter production behaviour with no review and no evaluation. Pinning defeats rug-pull style substitution and keeps evaluation evidence attached to the artifact that actually serves traffic.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Every production model promotion (version bump, pin change, or registry cutover) shall link a passing eval artifact, and the promotion path shall block promote-without-eval—not rely on informal review alone.
- Artifact
- Promotion policy or CI/registry rule requiring an eval pass artifact on model version bumps + Promotion log (or CI matrix) for the last 30 days showing linked eval pass artifacts; 0 promote-without-eval
- Pass condition
- 100% of production model promotions in the last 30 days have linked eval pass artifacts; promote-without-eval is blocked by gate (promotion evidence measuredAt ≤90 days). If no production model promotions occur (pin changes, registry cutovers, or version bumps), score NOT_APPLICABLE.
Why this control exists
Threat mapRequire evaluation evidence before any model change is promoted to production.
Threats mitigated
MisinformationHarmful Content GenerationData and Model PoisoningProtects
ModelsUsersSafetyMITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.
Requiring evaluation evidence stops unmeasured model swaps from reaching users. This is deliberately not mapped to poisoning techniques: behavioural evaluation does not reliably detect backdoored weights, which is why the SCI-M1 provenance controls remain necessary.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Evidence required
- Model inventory and version pins
- Change records for model promotions
- Eval comparisons for model swaps
Recommended checks
Strengthen posture beyond the gate. Same measurable structure; non-blocking unless elevated by organizational policy.
Production systems should publish a deprecation and sunset policy for models and embeddings that defines notice periods and forced-sunset rules, record sunset dates for superseded production pins in the registry, and keep undocumented pins past sunset at zero (exceptions time-boxed).
- Artifact
- Model/embedding deprecation and sunset policy (notice period + forced-sunset rules) + Registry export showing sunset dates for superseded pins; query of undocumented pins past sunset = 0
- Pass condition
- Policy defines notice period and forced-sunset rules; ≥1 superseded production model/embedding has a sunset date in the registry; undocumented pins past sunset = 0 without exception (deprecation evidence measuredAt ≤90 days). If production uses no hosted or self-hosted models/embeddings that can be superseded, score NOT_APPLICABLE.
Why this control exists
Threat mapManage model and embedding deprecation before a provider withdrawal forces it.
Threats mitigated
Configuration DriftDenial of ServiceProtects
ModelsAvailabilityMITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.
Unmanaged provider deprecations cause abrupt production failures when a pinned model is withdrawn on the vendor's schedule. A sunset policy makes migration planned rather than reactive; no adversary technique maps.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Each production AI workload should declare an explicit allowlist of model capabilities it may use (for example code execution, vision, browsing, or tool-calling modes), and denied capability attempts should be recorded in test or production within 90 days.
- Artifact
- Per-workload capability allowlist config (code execution, vision, browsing, etc.) + Deny log or test fixture showing a denied capability attempt within 90 days
- Pass condition
- Each production workload has an explicit capability allowlist; ≥1 denied capability attempt is recorded in test or prod within 90 days (allowlist evidence measuredAt ≤90 days). If models are text-only with no optional capabilities, score NOT_APPLICABLE.
Why this control exists
Threat mapGrant each workload only the model capabilities it actually needs.
Threats mitigated
Unsafe Code ExecutionExcessive AgencyPrompt InjectionTool AbuseProtects
ModelsRuntimeToolsInfrastructureMITRE: ATLAS AML.T0050 · ATLAS AML.T0102 · ATLAS AML.T0053 · ATT&CK T1059
Capabilities such as code execution, browsing, and file access turn a text generator into an execution surface. Restricting them per workload means an injection cannot reach an interpreter that was never enabled for that workload.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Every open-weight or fine-tuned model in production should have a completed license and provenance review ≤12 months old, and any blocked or restricted licenses should carry a documented exception with owner and expiry.
- Artifact
- License/provenance review checklist (or registry fields) for open-weight and fine-tuned models + Completed reviews ≤12 months old for each such production model; exceptions for blocked licenses with expiry
- Pass condition
- 100% of open-weight/fine-tuned production models have a license+provenance review ≤12 months old; blocked licenses have documented exceptions with expiry (review evidence measuredAt ≤90 days). If all production models are proprietary hosted APIs with no local/fine-tuned weights, score NOT_APPLICABLE.
Why this control exists
Threat mapReview the license and provenance of open-weight and fine-tuned models before adoption.
Threats mitigated
Supply Chain CompromiseData and Model PoisoningProtects
ModelsDataMITRE: ATLAS AML.T0058 · ATLAS AML.T0010 · ATT&CK T1195
Open-weight models from public hubs carry both licensing and poisoning risk that is invisible at inference time. Provenance review is the checkpoint at which published poisoned models can be rejected before they enter the pipeline.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Production AI systems should keep a queryable model inventory (or registry) in which every production model records a named owner, data-residency constraint, and intended use—with zero incomplete rows on those fields.
- Artifact
- Model inventory / registry export listing production models + Query or attestation showing 0 incomplete owner/residency/intended-use rows
- Pass condition
- 100% of production models have owner, residency, and intended-use fields; inventory query returns 0 incomplete rows (inventory evidence measuredAt ≤90 days). If no production AI paths call hosted or self-hosted models, score NOT_APPLICABLE.
Why this control exists
Threat mapMaintain an accurate inventory of the models running in production and their intended use.
Threats mitigated
Shadow AgentsConfiguration DriftSensitive Information DisclosureProtects
ModelsDataAudit TrailMITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.
A model inventory is the precondition for pinning, residency enforcement, and deprecation tracking, none of which can be applied to a model nobody knows about. This is asset management with no direct adversary technique mapping.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution
Engineering philosophy
Models are dependencies with behavioral contracts. Pin versions, document capabilities and known failure modes, and never silently change the production model under a customer-facing workload.
Why it matters
Provider default model changes, shadow upgrades, and unvetted open weights introduce quality, cost, security, and compliance regressions that teams discover only after incidents.
Common failures
- Using 'latest' model aliases in production
- No inventory of models and where they run
- Self-hosted models without supply-chain or license review
- Routing to cheaper models without eval coverage for those routes
Severity & risk
- Severity
- high
- Impact if violated
- Risk level
- high
- Typical residual risk (impact × likelihood)
Engineering best practices
- Abstract provider SDKs behind an internal model gateway with policy
- Track embedding model versions separately—index rebuilds are part of change
- Document fallback models and degraded modes
- Separate experimental models into non-production projects
Automatic validations
- Config lint rejecting unpinned model IDs in production configs
- Gateway deny rules for unapproved models
- CI requiring eval artifact for model version bumps
Manual validations
- Architecture review when introducing a new model family
- Legal/compliance review for data-processing terms of new providers
Examples
- Production chat uses provider-model-2025-03-01; canaries test the next pin before cutover
- A coding agent is restricted to models that meet internal code-exfiltration evals
References
Crosswalks
Show 25 peer mappingsexpandcollapse
GOVERN Govern
NIST AI Risk Management Framework · supports
MAP Map
NIST AI Risk Management Framework · supports
§8 Operation
ISO/IEC 42001 · supports
Annex A AI system controls (selected themes)
ISO/IEC 42001 · partial
LLM03 Supply Chain
OWASP Top 10 for Large Language Model Applications · supports
LLM04 Data and Model Poisoning
OWASP Top 10 for Large Language Model Applications · supports
C1.1 Training Data Origin & Data Security
OWASP AI Application Security Verification Standard (AISVS) · supports
C1.3 Training Data Quality and Security Assurance
OWASP AI Application Security Verification Standard (AISVS) · supports
C3.1 Model Authorization & Integrity
OWASP AI Application Security Verification Standard (AISVS) · supports
C3.2 Model Validation & Testing
OWASP AI Application Security Verification Standard (AISVS) · supports
C3.3 Controlled Deployment & Rollback
OWASP AI Application Security Verification Standard (AISVS) · partial
C3.4 Secure Development Practices
OWASP AI Application Security Verification Standard (AISVS) · partial
C3.5 Pipeline Fine-Tuning
OWASP AI Application Security Verification Standard (AISVS) · partial
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
C11.1 Model Alignment, Safety, and Robustness Testing and Training
OWASP AI Application Security Verification Standard (AISVS) · supports
C11.2 Membership-Inference and Model-Inversion Mitigation
OWASP AI Application Security Verification Standard (AISVS) · partial
C11.3 Model-Extraction Defense
OWASP AI Application Security Verification Standard (AISVS) · partial
C11.4 Model Runtime Anomaly Detection
OWASP AI Application Security Verification Standard (AISVS) · supports
L1 Foundation Models
CSA MAESTRO (Multi-Agentic Threat Model) · supports
CC8 Change Management
SOC 2 Trust Services Criteria · evidence-for
Sustainability Sustainability
AWS Well-Architected Framework · partial
Generative AI Lens Generative AI Lens (themes)
AWS Well-Architected Framework · aligns-with
Level 1 Build process documented
SLSA (Supply-chain Levels for Software Artifacts) · partial
Provenance Artifact provenance
SLSA (Supply-chain Levels for Software Artifacts) · supports
Future evolution
Model bill of materials (MBOM) standards and portable evaluation attestations across vendors.