Why the store needs its own test
Model and prompt testing usually leaves the store alone. Retrieval can still return a planted document or another tenant's data when the model and prompts behave.
Vector store red teaming
Find out what your vector store gives up under attack.
We test the vector stores and retrieval layer behind your RAG application, using the collections, namespaces and access paths your application uses. You get each finding with the inputs that produced it, what was retrieved, and what to change.
How an engagement runs
- 1
Scope
We agree in writing which systems, collections and access paths are in scope, and the rules of engagement.
- 2
Test
We plant and inject documents, query for stored sensitive data, and try to retrieve across tenants and namespaces, using your real stores.
- 3
Reproduce
Each finding records the exact inputs, what was retrieved and the response that came back.
- 4
Remediate
We tell you what to change in the store, the ingestion path or access controls, then re-test after you fix it.
What we test and what you receive
What we test
Document poisoning and indirect prompt injection, recovery of stored personal data through semantic queries, and leakage across tenants or namespaces, using planted canary records where useful. Generic model jailbreak testing is out of scope.
Replayable findings
Each finding includes the exact inputs, what was retrieved and the response, so your team can replay it and check the fix.
Authorisation and limits
Testing stays inside the written scope and rules of engagement. The report lists what was tested and what was left out.
Scope an engagement.
Tell us which stores and retrieval paths your application uses and we'll propose a test plan.