AI on Your Data Is a Security Task: Why RAG Systems Leak Data

A language model that answers over your internal documents is, for many companies, the first tangible AI benefit: quotes, manuals, contract clauses, tickets – answered on request instead of searched for in folder structures. The technology behind it is called Retrieval-Augmented Generation (RAG): to answer a question, the model is supplied with matching excerpts from your documents and formulates the answer from them. The appeal is obvious. The risk is usually overlooked.

Because RAG is at its core a search engine with a formulation model in front of it. And a search engine over company data is only as trustworthy as the permissions it enforces. If a RAG system is built without carrying over the access rights of the source system, exactly what must happen happens: a user is served content they should never have been allowed to see. This is not an exotic special case but the most common and most expensive RAG malfunction.

The standard mistake: the permissions get left behind

In a cleanly operated file store, an access list decides who may open a document. The sales employee sees their quotes, not the management’s payroll list. When a RAG system is built, however, these documents are broken up, converted into vectors, and stored in a vector database – and at this point the permission is frequently lost. The vector database then knows only content, no access rights anymore. Whoever asks gets answered with what fits in content, not with what they are allowed to see.

The OWASP project explicitly upgraded this class of flaws in 2025. In the updated OWASP Top 10 for LLM Applications, “Sensitive Information Disclosure” moved up to rank 2, and with “Vector and Embedding Weaknesses” (LLM08) an entirely new category was added that names exactly these RAG-specific weaknesses: manipulated search, cross-tenant and cross-permission access, reconstructing plaintext from embeddings. The message is unambiguous: anyone deploying RAG has opened a new, self-contained field for attack and leakage.

Two real patterns: Copilot as a case study

How this looks in practice can be studied on Microsoft 365 Copilot – one of the most broadly rolled-out RAG systems of all.

The first pattern is the plain oversharing of rights. Copilot answers based on what a user can access according to their permissions. If these permissions have been granted generously over years within the company – the infamous SharePoint share “for everyone in the company” – AI suddenly makes this legacy burden visible and searchable. The analytics service provider Concentric found that 15 percent of business-critical resources were affected by oversharing and could be viewed by people who should not have access. The AI did not create the problem. It merely pulled it out of cover.

The second pattern is the targeted attack on the RAG chain. Under the name “EchoLeak” (CVE-2025-32711, CVSS 9.3), the security team at Aim Labs described in 2025 a zero-click attack on Microsoft 365 Copilot: a single crafted email was enough – without the recipient having to open or click it – to get Copilot to collect internal content from SharePoint, OneDrive, and Teams and exfiltrate it to a foreign server. Microsoft closed the flaw server-side and reported no exploitation in the wild. The case remains instructive: untrusted input – here an email – was able to cross the boundary into trusted internal data. A related research result from the University of Texas (“ConfusedPilot,” 2024) additionally showed how planted documents can lead a RAG system to false statements and, in doing so, exploit access-control misconfigurations.

Multi-tenant: the most expensive leak

It becomes most serious when a RAG system uses the same vector database for multiple tenants – for example a service provider making knowledge accessible for several customers. Without hard separation, the documents of different customers share the same search space, and similarity search knows no customer boundaries. A query from customer A can then return content from customer B – not because of a spectacular hack, but because the database never learned that a boundary exists.

Vector databases were in many cases not designed with document-level access control as a core function. Practitioners report cross-tenant leakage in nearly all test queries as soon as the search is performed unfiltered. And the consequences are not abstract: an access-control flaw in a widely used vector database exposed over 200,000 health records. Cross-tenant leakage is therefore not just a technical flaw but a data-protection, liability, and reputation event.

The fix is not AI magic but craftsmanship

The good news: the countermeasures are known. They are the same principles that make up a dependable security architecture outside of AI too – consistently applied to the RAG chain.

Clean up permissions first. Before data flows into a RAG system, the sharing chaos must be tidied up. RAG makes existing over-sharing visible; whoever does not clean it up beforehand exports the problem into the model.
Carry access control down to the document level. Every excerpt stored in the vector database carries its permission metadata – allowed users and groups – as an integral part. At query time, filtering is two-stage: before the search via metadata, after the search via a real permission check against the source system. If rights change, the new permission takes effect immediately, not only after the next re-indexing.
Separate tenants hard. In multi-tenant scenarios, the tenant boundary is enforced at the level of the vector index, not only in the application logic above it.
Log without gaps. Every retrieval leaves a line: who, which query, which excerpts delivered, which denied. Without this log, neither an incident can be investigated nor an audit passed.
Treat untrusted input as such. Emails, uploaded files, external web content must not cross the trust boundary into internal data unchecked – the lesson from EchoLeak.

This is, soberly viewed, classic access control, data classification, logging, and network segmentation. The ability to build a RAG architecture that survives an audit is not an AI competency. It is a security competency.

Why this is a security task, not an AI gimmick

Anyone who treats a RAG system as a data project – “we tip our documents in and put a model in front” – reliably builds a leak. Anyone who treats it as a security project asks the right questions before the first answer: what permission does the requester have? What metadata does each excerpt carry? Where does the tenant boundary run? What is in the log? These questions decide whether the productivity gain becomes a data-protection incident.

This is exactly where the paths part. Sovereign AI on your own data does not arise from a model being especially capable, but from the architecture around the model enforcing the company’s access rules – dependably, demonstrably, auditably.

How sector7 supports you

We operate secured private language models and managed RAG on our own server park in Germany – the data does not leave the environment we control. The decisive difference lies in our origin: sector7 comes from security and network practice. We build the RAG chain the way we build perimeters and backups – with document-level access control, hard tenant separation, gapless logging, and an architecture that holds up to scrutiny. This connects our sovereign AI directly with our existing cyber security practice and our vendor-certified engineering experience on Juniper, Cisco, HPE, F5, Fortinet and Palo Alto Networks. We do not train our own foundation models and promise no autonomous AI workforce; large GPU capacity we source via sovereign partners. What we deliver is what makes RAG secure: security craftsmanship. From an owner-led firm in Solingen.