OWASP released a new version of the Top 10 LLM risks in November 2024, adding a new category: Vector and Embedding Weaknesses. RAG pipelines using Vector DB are increasingly deployed to ground LLMs with enterprise knowledge. The section LLM08:2025 Vector and Embedding Weaknesses in OWASP Top 10 highlights the risks associated with such pipelines, broadly related to permission bypass, sensitive data exposure, and cross-context information leaks. In this blog we look at different methods to remediate these risks.
Consider an enterprise with a SharePoint site for sales. This site contains document libraries, folders, and files for salespeople in different regions and roles, with permissions set at folder and file levels. When deploying a RAG pipeline, documents from the SharePoint site are ingested, vectorized, and stored in a VectorDB, making them available to a GenAI chatbot or agent.
Neither GenAI applications nor Vector databases natively enforce permissions and data filtering, leading to unauthorized access, data leakage, and context leakage in multi-tenant environments, as highlighted in OWASP LLM08.
You can use this method if you want to control access at a department level or a broad user group. Data from the document store is aggregated into multiple indexes/collections in the vector store, where each index/collection is for a department. For example, in a sales SharePoint site, there would be one index for each region, connected to a GenAI app serving that region.
Now all users from a given region will have access to their data but cannot access another index and hence another region’s sales data.
This approach is easy to implement at Vector store level. The disadvantage lies in additional work involved to carefully segregate documents for each region before vectorizing them. Another problem is that it limits the business use case as only those documents where all users have same permissions can be brought into VectorDB for a group. For example, within a region, if there are some documents that a junior account manager should not access but top management can access, this method will require another index for top management documents. In essence you can only bring in documents with least common denomination of permissions. This approach involves additional work in segregating documents and limits business use cases on what can be queried.
The fine grained approach solves the problems of above coarse grained method, allowing all documents to be brought in and having a single index across users. This approach retains the permission lists for each vector as in the original document, allowing all documents to be vectorized while maintaining permissions. Essentially, each vector inherits the same permissions as the original document so users will only get those vectors where they had permissions to original document.
In the sales SharePoint example, there would be one index containing all documents, and permissions from the original document store are ingested into each vector. We also need only one sales agent. So when top management queries, GenAI can get data from all documents but when a junior person in a specific region queries, the answers are limited to documents for a region and within that documents relevant to the role of the junior role.
This method unlocks a broad set of business use cases and doesn’t require curating documents into indexes.
Data filtering prevents over exposure of data in both coarse grained and fine grained implementation. During vector retrieval for answering an user query, it is possible that the retrieved vectors contain sensitive information. As an example, the retrieved vector could contain privacy information such as age, zipcode or gender that you don’t want to go to GenAI applications. Or, retrieved vectors could contain sales discount information that you don’t want to expose without additional authorization.
This where a policy based filtering solution is needed between the vectorstore and GenAI application that can identify such sensitive information. Once identified, the solution can be anonymize or tokenize based on policies or regulatory requirements.
Mitigation measures can be built into each GenAI app/agent, but this is effort-intensive and inefficient at scale. Instead, a common broker for all agents, separating the authorization and data filtering layer, enables easy centralized implementation of permissions and data protection across GenAI agents and users.
Ackuity (www.Ackuity.ai) implements such a security broker layer, mitigating risks of permission bypass and sensitive data exposure. It automatically learns user permissions from the original document store and applies the same permissions for users accessing the vector store. Ackuity also enables policy-based data filtering compliant with various regulations, including GDPR, CCPA, and HIPAA.