Most RAG tutorials are demos. They show you how to index a PDF and ask questions about it. The underlying system works fine for a proof of concept, but it would not survive contact with your enterprise security team for obvious reasons: everyone can retrieve everything, nothing is logged, and the embeddings are stored in a shared vector database with no tenant isolation.

This guide covers what enterprise-grade secure RAG actually requires - and how to build it.

In a demo RAG system:

• All documents are indexed together in a shared vector store
• Any user can retrieve any chunk
• Nothing is logged
• The vector database is open or minimally secured
• Personal data and confidential documents sit alongside general content

In an enterprise RAG system, the documents are not equal. An HR policy document should be accessible to all employees. A compensation analysis should be accessible only to HR leadership. Board minutes should be accessible only to executives and their executive assistants. A customer contract should be accessible to the account team and legal - not to product engineering.

Enterprise RAG must enforce the same access controls as the source systems - with the same granularity, and at retrieval time.

Before building controls, be explicit about the threats:

Horizontal privilege escalation: A user queries the RAG system and retrieves chunks from documents they would not have access to in the source system. The most common failure mode - particularly when documents from different sensitivity levels are indexed together.

Indirect exfiltration via inference: Even if chunk-level access is controlled, a sophisticated user could ask a series of questions designed to reconstruct confidential information from partial responses. The model may confirm or deny details through its responses.

Vector database compromise: If the vector store is compromised, an attacker can extract all embeddings and - with sufficient compute - reverse engineer approximate reconstructions of the original text. For sensitive documents, embeddings should be treated as sensitive data themselves.

Insider threat via admin access: A user with admin access to the RAG platform can bypass retrieval controls by querying the vector database directly. Admin access must be tightly scoped and fully logged.

Model leakage via system prompt: If the RAG system's system prompt contains confidential information (company strategy, customer names, pricing), it can be extracted via prompt injection attacks.

The secure pattern for enterprise RAG access control:

1. Tag documents at ingestion with access metadata

Every document entering the RAG pipeline carries metadata that determines who can retrieve it:

2. Propagate access tags to chunks at index time

When the document is chunked and embedded, each chunk inherits the document's access metadata. The vector store stores both the embedding and the access tags.

3. Filter at retrieval time, not at display time

The critical design decision: access filtering must happen in the vector store query, not in the application layer after retrieval. If you retrieve all matching chunks and then filter in application code, the filtered chunks still passed through your system - and any logging gap or bug could expose them.

4. Sync access controls when source permissions change

If a user's group membership changes - they leave a team, change role, or are offboarded - the RAG system's access controls must update accordingly. This requires either real-time sync with your identity provider or a periodic re-sync job with a short enough window that access is revoked promptly.

Embeddings of sensitive documents should be treated as sensitive data. The minimum requirements:

Encryption at rest: The vector database must encrypt stored embeddings using AES-256 or equivalent. This is now standard for managed vector databases, but verify it is not an optional add-on.

Customer-managed encryption keys: For the highest sensitivity data, require that encryption keys are held by the customer (via KMS), not by the platform vendor. This means the vendor cannot decrypt your embeddings even with physical access to the storage layer.

Tenant isolation: In a multi-tenant deployment, your vector embeddings must be stored in a logically or physically isolated partition - not commingled with other organisations' data in a shared index.

TLS in transit: All queries to and from the vector store must use TLS 1.2 or higher. This should be enforced at the infrastructure level, not left to application configuration.

Access control in RAG is more nuanced than binary allow/deny. A well-designed RBAC model for enterprise RAG includes:

Document classification levels: Public / Internal / Confidential / Restricted. Access is granted at the classification level and inherited by all documents within it.

Group-based access: Documents are tagged with the groups that can access them. Group membership is synced from your identity provider (Okta, Azure AD, Google Workspace).

Contextual access: Some documents should only be retrievable in specific contexts - a medical record might be accessible to a clinician querying about their patient, but not accessible through a general knowledge base query.

Temporary access grants: For cross-functional projects, temporary access can be granted to specific document sets with an automatic expiry.

A compliant enterprise RAG system logs every retrieval event with sufficient detail to reconstruct what happened:

The audit log must be:

• Immutable: written once, cannot be modified or deleted (use append-only storage or a write-once audit log service)
• Exportable: compliance teams must be able to export logs to their SIEM in standard formats (CEF, JSON, syslog)
• Queryable: a compliance officer must be able to answer "who accessed document X in the last 30 days?" without writing SQL

Aicuflow's RAG pipeline handles all of the above without custom code. Here is the setup flow:

Step 1: Connect your document source Connect SharePoint, Google Drive, Confluence, or a custom S3 bucket. Aicuflow reads the source permissions and imports them as access metadata on each document.

Step 2: Configure classification levels Set your document classification schema in the platform. Aicuflow uses this to enforce access at retrieval time.

Step 3: Sync your identity provider Connect Okta, Azure AD, or Google Workspace. Aicuflow syncs group membership and keeps access controls current as your organisation changes.

Step 4: Enable audit logging Turn on immutable audit logging. Aicuflow writes retrieval events to an append-only log with the full metadata above. Export to your SIEM via webhook or API.

Step 5: Configure retrieval mode Choose hybrid retrieval for production - it combines vector similarity with knowledge graph context for the highest accuracy, particularly for cross-document questions in legal, compliance, and contract management use cases.

Step 6: Test with a red team query Before going live, test whether users can retrieve documents outside their access scope. Aicuflow provides a test mode that shows the access filter applied to each query and which chunks were excluded.

The result is a RAG system that behaves like your existing access control policies - consistently, at scale, with a full audit trail.