Security teams should treat model approval as a starting state, not a permanent authorization. Any change to weights, adapters, prompts, quantization, or sampling settings should trigger re-validation before the model is allowed back into service. That approach ties governance to the actual runtime artefact instead of assuming the deployment pipeline has preserved the original security posture.
What changes when a model is no longer the same model?
Approval should be tied to the exact artefact in service, not to a model name or repository label. If the weights change, an adapter is attached, the prompt stack is altered, quantization changes behaviour, or sampling settings move outside the validated envelope, the approved state no longer holds. Security teams need a governance model that treats drift as a change event, not as an invisible deployment detail.
That distinction matters because seemingly small edits can change the model’s outputs, safety behaviour, data exposure profile, or susceptibility to prompt injection and jailbreak-style abuse. A team that approves only the initial build but not the live runtime configuration is governing intent, not actual behaviour.
Which changes should force re-validation?
Any change that can affect the model’s decisions, responses, or control boundaries should be treated as security-relevant. That includes direct model modifications such as retraining, fine-tuning, merging adapters, or swapping checkpoints, but it also includes runtime changes that alter how the same model behaves under load or in edge cases. If the output can differ materially, the approval should be revisited.
- Weight or checkpoint changes: new training data, fine-tunes, merges, or hot-swapped versions.
- Adapter and prompt changes: system prompts, templates, policies, retrieval context, or tool instructions.
- Inference changes: temperature, top-p, max tokens, and other sampling or decoding settings that alter behaviour.
- Deployment changes: quantization, serving stack, guardrail middleware, or routing logic that changes runtime outcomes.
A useful rule is to re-validate whenever the change could affect correctness, safety, confidentiality, or delegated action. That is especially important when the model can trigger tools, access data, or influence downstream systems.
How should governance work after approval?
Governance should follow the artefact lifecycle, not a one-time sign-off. The approval record should specify what was approved, what configuration was tested, what inputs and outputs were in scope, and what conditions would require renewed review. That makes the control auditable when the live model drifts away from the tested state.
Teams should also separate policy approval from operational release control. A model can remain conceptually approved while the current build is blocked until re-testing is complete. For a broader policy and exception structure, the Information Security Policy Template is a useful anchor for documenting authority, exceptions, and review cadence.
If the model is supplied by a third party or includes external components, governance should include supplier evidence and change notification. The Vendor Security Assessment Template is relevant where the approval decision depends on evidence about how the model is updated, tested, and controlled across releases.
Risk and Threat Considerations
Model drift creates a control gap between what was approved and what is actually running. That gap can expose organisations to unsafe outputs, policy bypass, data leakage, and unreviewed behavioural changes, especially when the model is allowed to act on prompts, retrieval results, or tools without fresh validation.
Failure mechanism: An attacker or internal change can modify the model or its runtime parameters after approval, then rely on the stale approval state to keep the system in production without renewed scrutiny.
Impact: The organisation may continue trusting a model whose current behaviour no longer matches the approved risk posture, which can undermine safety controls, incident response assumptions, and accountability for downstream decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | A.6.3 — AI System Requirements and Specification | Model changes alter the approved AI system specification and expected behaviour. |
| A.8.2 — AI System Change Management | The question is about controlling post-approval model changes and re-validation. | |
| Recommendation — Re-specify and re-approve the system when model behaviour or runtime settings change. Apply formal change control to retrain, retune, or redeploy models before release. | ||
| NIST AI RMF | GV.4 — Map, Measure, and Manage AI Risks | Governance must track risk as the model changes after initial approval. |
| Recommendation — Measure post-change model risk before restoring production approval. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Model weights, prompts, and inference settings are configuration changes needing control. |
| SI-7 — Software, Firmware, and Information Integrity | Changed model artefacts need integrity checks before they are trusted again. | |
| AU-2 — Event Logging | Approval and re-validation decisions need auditable records across model revisions. | |
| Recommendation — Require authorization and review for any model configuration change that affects behavior. Verify artefact integrity before returning a changed model to service. Log model version, prompt, and parameter changes alongside approval decisions. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Post-approval model changes can expand or shift delegated authority and tool access. |
| Recommendation — Reassess tool and privilege boundaries whenever the agentic model changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Runtime model settings and deployment changes can invalidate the approved security posture. |
| Recommendation — Revalidate deployment configuration whenever the live model environment changes. | ||
Practitioner Guidance
What to verify: Record the exact artefact hash, adapter set, prompt template, and inference configuration that were approved, then compare them against the live deployment before each release. If any of those elements changed, treat the approval as expired until re-validation is complete.
Decision rule: If the change can alter model output, tool use, or security-relevant behaviour, require re-testing before production use. If the change is purely operational and cannot affect behaviour, document why the original approval still stands.
Practitioner takeaway: The safest governance model is version-specific approval with enforced drift detection, because the security posture belongs to the running artefact, not to the last sign-off.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org