Implementation guide
OWASP AISVS v1.01
Memory, Embeddings & Vector Database Security · Embedding Sanitization & Validation
Mask sensitive fields before embedding
Verify that sensitive fields are detected before embedding and are masked, tokenized, or dropped.
OWASP AISVS v1.01, requirement 8.2.1
In plain English
Find sensitive fields before text is turned into embeddings, and mask, replace or drop them. Embeddings are not a one-way scramble. Research on embedding inversion has shown that much of the original text can be recovered from the vectors.
What good looks like
- Personal data and secrets are detected during ingestion, before the embedding step.
- Detected values are masked, replaced with tokens or removed, by a written rule for each data type.
- The stored chunk text gets the same treatment as the vector.
- Detection has been tested against a hand-checked sample.
How teams usually do it
- A personal-data detector in the ingestion pipeline, for example Microsoft Presidio or a cloud DLP service.
- A secret scanner (for example Gitleaks or detect-secrets patterns) for keys and passwords in documents and code.
- Tokenisation where the application needs to restore the real value for authorised users. The mapping lives in a separate, protected store.
Suggested evidence
- Pipeline configuration showing detection runs before embedding.
- Detection test results.
- Sample stored chunks showing masked values.
Common mistakes
- Assuming embeddings are safe because they are "just numbers".
- Masking the vector's input and storing the original text beside it as the chunk payload.
- Sending unmasked text to a third-party embedding API.
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.