Implementation guide
OWASP AISVS v1.01
Model Lifecycle Management & Change Control · Model Validation & Testing
Re-check security when the provider changes the model
Verify that provider model, version, or routing changes trigger security re-evaluation before continued use.
OWASP AISVS v1.01, requirement 3.2.3
In plain English
When your provider changes the model, its version or how requests are routed, rerun your security tests before carrying on as normal. A new version can respond differently to the same jailbreaks and injections, and your defences were tuned against the old one.
What good looks like
- Model versions are pinned wherever the provider allows it.
- Provider change and deprecation notices reach a named person who acts on them.
- The security test suite reruns before traffic moves to a new model, version or routing setup, and someone reviews the results.
- A scheduled run of the same suite catches changes the provider did not announce.
How teams usually do it
- Pin dated model identifiers in API calls and upgrade on purpose, through the same pipeline as any other release.
- Subscribe to the provider's changelog and deprecation feed, and put the dates in the team calendar.
- If you use a router or gateway that picks models dynamically, restrict it to an approved list and test every model on that list.
Suggested evidence
- Configuration showing pinned versions.
- Test results tied to each model change.
- The record of the last provider notice and what was done about it.
Common mistakes
- Using an alias such as "latest" that moves to new versions without warning.
- Rerunning quality tests and skipping the security ones.
- Forgetting fallback models. A failover to a model nobody tested counts as a routing change.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.