← Domains & pillars

Model & Prompt LifecycleView domain

APRF-07

Model Governance

Own model selection, versioning, deprecation, and capability boundaries.

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.

  • MOD-M1L3 · DefinedTier 2 · ProductionhybridE3

    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 map

    Ensure production behaviour comes from an explicitly chosen, evaluated model version.

    Threats mitigated

    Supply Chain CompromiseConfiguration DriftMisinformation

    Protects

    ModelsRuntimeUsers

    MITRE: 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.

  • MOD-M2L3 · DefinedTier 2 · ProductionhybridE3

    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 map

    Require evaluation evidence before any model change is promoted to production.

    Threats mitigated

    MisinformationHarmful Content GenerationData and Model Poisoning

    Protects

    ModelsUsersSafety

    MITRE: 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
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 mappingsexpand
  • 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.