Implementation guide
OWASP AISVS v1.01
Memory, Embeddings & Vector Database Security · Memory Expiry & Revocation
Memory can be reset
Verify that memory can be reset.
OWASP AISVS v1.01, requirement 8.3.2
In plain English
You need to be able to wipe an agent's or user's memory, on request or when you suspect it has been poisoned. If the only fix for bad memory is rebuilding the system, you will put up with bad memory for far too long.
What good looks like
- Memory can be reset for one user, one session or agent, or in full.
- A reset clears every place memory lives: stores, caches, summaries and derived indexes.
- Resets are logged with who asked and why.
- Users have a way to see and clear what is remembered about them.
How teams usually do it
- An admin function and API that deletes the relevant records by user, tenant or agent ID.
- A user-facing "forget" control, which also helps meet data protection erasure rights.
- A tested runbook for resetting memory during an incident, including how to stop it refilling from the same poisoned source.
Suggested evidence
- The reset procedure.
- A test record showing memory is empty afterwards, caches included.
- Reset log entries.
Common mistakes
- Clearing the main store and missing caches, summaries or backups that put the content back.
- A reset that needs an engineer with database access.
- Restoring poisoned memory from backup during recovery.
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.