RAG Is Not a Security Model

Retrieval-augmented generation can make AI responses more relevant. It does not automatically determine who is allowed to see the information being retrieved.

That distinction is fundamental.

A RAG system can retrieve exactly the correct confidential document and still be insecure if the person asking the question was never supposed to access it.

OWASP specifically identifies unauthorized access and data leakage as risks in vector and embedding systems used for RAG.

What RAG actually solves

A simplified RAG flow is:

Index information → Search relevant information → Add it to model context → Generate an answer

That solves a context problem. It does not automatically solve:

• Authorization.
• Data classification.
• Retention.
• Tenant isolation.
• Prompt injection.
• Auditing.

Semantic relevance is not permission

Imagine one vector index containing:

• Public policies.
• Sales pricing.
• HR cases.
• Legal documents.
• Board materials.

A semantic search engine is designed to find relevant content. It does not inherently know whether the user is authorized to see that content.

Retrieval therefore needs an authorization layer.

Permission-aware retrieval

Possible designs include:

Filtering before retrieval — restrict eligible documents using metadata.

Separate stores — keep sensitive domains isolated.

Query the source system — use existing permission-aware APIs rather than copying everything.

Post-retrieval authorization — validate documents before they enter model context.

The implementation varies. The principle is constant: authorization must survive retrieval.

Agents increase the risk surface

An agent may combine RAG with CRM, email, files, browsers and internal APIs. That makes data access much broader.

An enterprise AI identity should therefore have a defined access scope rather than simply inheriting every permission of the user.

Prompt injection can arrive through retrieved content

OWASP warns that prompt injection can also be indirect: malicious instructions can be embedded inside documents or other external information consumed by the system. RAG and fine-tuning do not fully remove that risk. The OWASP Prompt Injection guidance documents the threat and possible mitigations.

This matters particularly when retrieved information can influence tool use.

Zero trust is a better mental model

NIST Zero Trust Architecture asks systems to authorize access based on identity and policy rather than assuming trust because something is inside a network.

For enterprise AI:

User identity → AI identity → Authorization → Permission-aware retrieval → Approved context → Model

That is much stronger than: Internal vector database = safe.

Retrieve less, not more

The goal is not to give the model as much company information as possible. It is to give it the minimum sufficient context.

That can improve privacy, relevance, cost, latency and explainability.

Logging matters

Useful logs may include:

• User.
• Agent.
• Query.
• Retrieved documents.
• Authorization result.
• Model.
• Tool calls.
• Final action.

The UK NCSC recommends monitoring AI behavior and treating logs as sensitive assets.

Mindzy perspective

Enterprise knowledge should combine:

Relevance + Permission + Provenance + Observability

RAG solves part of the relevance problem. It does not replace the other three.

That is why Mindzy treats Company Knowledge and RAG as components of an AI System—not as the security architecture itself.

Key takeaways

• RAG does not automatically enforce access control.
• Permissions should be applied before or during retrieval.
• Private deployment does not remove prompt-injection, identity or logging requirements.

Sources

1. OWASP GenAI Security Project — LLM08:2025 Vector and Embedding Weaknesses
2. OWASP GenAI Security Project — LLM01:2025 Prompt Injection
3. NIST — Zero Trust Architecture, SP 800-207
4. UK NCSC — Monitor and log user activity