Implementation guide
OWASP AISVS v1.01
Model Lifecycle Management & Change Control · Secure Development Practices
Keep dev, staging and production apart
Verify that AI-specific runtime components are not shared across environment boundaries (e.g., development, staging, production).
OWASP AISVS v1.01, requirement 3.4.1
In plain English
Keep AI runtime components separate between development, staging and production. That covers model endpoints, vector stores, caches, prompt stores and agent memory. If they are shared, a careless test can change production behaviour, and production data ends up where controls are weakest.
What good looks like
- Each environment has its own model endpoints, vector stores, caches and memory stores.
- Credentials and API keys for one environment do not work in another.
- Production data reaches lower environments only through an approved process that masks or samples it.
- Provider accounts or projects are split by environment, so logs, quotas and fine-tunes do not mix.
How teams usually do it
- Separate cloud accounts, subscriptions or projects per environment.
- Per-environment keys issued from a secrets manager, with separate projects or workspaces at the model provider.
- Synthetic or masked data sets for development and test.
Suggested evidence
- An architecture diagram showing the separation.
- Access policies and key inventories per environment.
- A test showing that a development credential is refused by production.
Common mistakes
- One shared vector store "to save cost", where test documents and production documents mix.
- Developers using the production API key because it has the higher rate limit.
- Pointing a staging app at the production memory store to make a demo look realistic.
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.