The controls outside the model hold. The ones written into a prompt do not, and cannot be shown to. Draw that line on paper before your next upgrade. Anything enforced by code the model calls through survives a swap untouched, and the existing evidence still stands. Anything enforced by asking the model nicely has to be rebuilt from nothing. What was tested is not what is running now. Treat the model version as configuration, because that is what it is. If a control depends on a version, your evidence has to name the version it was established under.
Related: How do I show that a prompt change didn't weaken a control?, How often does a control on an AI system need re-verifying?
If your control lives in the prompt, you cannot. That is the finding. Re-run the denial cases and you have shown it held for those cases, on that model, that day. That is not the same as showing it holds. The input space is not enumerable and the thing under test is not deterministic. So call the result a sample, and say so plainly. Or move the control out of the prompt, and the question stops being interesting. A permission check in code does not care what happened to a paragraph. The evidence already held for it needs no regenerating.
Related: My agent behaves differently after a model change. Do my controls still hold?, How do I test that a guardrail holds, rather than that it exists?
Tie it to change, not to the calendar. A quarterly review of a system whose model was swapped in week two reviews something that no longer exists. Worse, the date on it hides the staleness instead of showing it. The events worth re-verifying on are the ones that change behaviour without changing your code. A model version change. A prompt or tool-definition edit. A permission grant. A new tool your agent can reach. How long a verification stays good after one of those is not something anybody has measured properly. So record when you checked, and what against, and let your reader judge the age.
Related: My agent behaves differently after a model change. Do my controls still hold?, How do I show that a prompt change didn't weaken a control?
Put it in source control and stop treating it as configuration. A prompt living in a database row or a vendor console changes with no diff, no reviewer and no date. That is a change to your system's behaviour with none of the machinery you apply to code. In the repository it gets a commit, an author and a review. You can answer what it said on the day of the incident. Then record which version was live for a run. Without that link you have a history of prompts, a history of runs, and no join.
Related: My agent behaves differently after a model change. Do my controls still hold?, How do I show that a prompt change didn't weaken a control?
Your boundary evidence survives. Anything resting on the provider does not. Access control, logging, attribution and your permission checks are yours and carry over untouched. That is the argument for putting controls there in the first place. What you redo is the provider-shaped half. Their report. Their subprocessor position. Their retention and training terms. Any statement you made to a customer naming them. Check your own trust page and questionnaires for the old name before you migrate. That is where a stale claim survives longest.
Related: My agent behaves differently after a model change. Do my controls still hold?, My model provider changed their terms. What do I actually need to check?