Skip to main content
ScopeRAG is built so that access is a property of retrieval, not a filter applied after the fact. A user’s permissions decide which passages are even eligible to be retrieved, so out-of-scope content never enters the model’s context and cannot appear in an answer. This page explains the enforcement mechanism, how access is calculated, where your data lives, and what leaves your boundary.

​
How enforcement works

Access is enforced at the chunk level, before retrieval, on every query.
1

Chunks inherit the document's access metadata

When a file is processed, it is split into chunks for embedding. Each chunk carries the parent document’s classification rank and categories as metadata alongside its vector.
2

Every request resolves the user's effective scope

On each query, ScopeRAG resolves the signed-in user’s groups into an effective scope: the set of categories they may see and the maximum classification rank they may read. Composer filters can only narrow this scope further.
3

Scope becomes a filter on the vector search

The effective scope is compiled into a metadata filter that is applied to the similarity search itself. Chunks outside the user’s categories or above their classification ceiling are excluded from the candidate set — they are never scored, never ranked, and never returned.
4

Only in-scope passages reach the model

The model receives only passages that survived the filter. Because exclusion happens before retrieval, no out-of-scope text is ever placed in the prompt, and citations can only reference documents the user is allowed to open.
The security consequence of pre-filtering: even a prompt-injection or jailbreak attempt cannot surface content the user lacks access to, because that content was never a retrieval candidate for their request. The model cannot reveal what it was never given.

​
How access is calculated

A user’s access is the resolved combination of every group they belong to. The combination follows fixed rules: A chunk is retrievable for a user only when both conditions hold: its category is in the user’s category union and its classification rank is at or below the user’s ceiling. The two axes are combined with AND, never OR.
Because classification uses the maximum across groups, adding a user to a group with a higher ceiling raises their ceiling everywhere, not only for that group’s categories. Review group ceilings before broad group assignments.
Administrators and owners are not group members; their access is granted by role rather than resolved from groups. See Access and permissions for the role model.

​
Deployment models

ScopeRAG runs in whichever boundary your compliance posture requires.

Managed cloud

Multi-tenant SaaS operated by ScopeRAG. Fastest to start. Each organization’s documents, chunks, and vectors are isolated per tenant.

On-premises / private

Deployed inside your own cloud account or data center. Documents, embeddings, and the vector store never leave your infrastructure. Suited to regulated institutions with data-residency obligations.
On-premises deployment keeps document content, extracted chunks, and vectors within your boundary. What leaves the boundary is limited to model inference — and that too can be kept internal with a self-hosted model. See below.

​
Data flow to the model provider

Generating an answer sends the user’s question and the retrieved in-scope passages to a chat model. Where that model runs depends on your configuration.
Retrieved passages are only ever in-scope for the requesting user, so the model never receives content that user could not already read. Choosing BYOK or a self-hosted model controls which third party, if any, sees that in-scope content.
Only classifications and categories the user is cleared for can appear in a prompt, but the passages themselves are real document text. For workloads where no content may reach an external provider, use a self-hosted model.

​
Data at rest and in transit

  • Documents, extracted text, and vectors are encrypted at rest.
  • Traffic is encrypted in transit over TLS.
  • Provider API keys supplied for bring-your-own-key are stored encrypted and are never returned to the client or placed in prompts.
Do not paste API keys, credentials, or secrets into chat or documents. Store provider keys only on the Models page.

​
Deletion and retention

Deleting a document removes the file and its derived chunks and vectors, so the content is no longer a retrieval candidate for any user.
Deletion affects future retrieval. It does not rewrite past chat transcripts, which may still quote passages from a document that has since been deleted. Delete conversations separately if a transcript must not retain quoted content.
Retention of documents, conversations, and audit records follows your plan and, for on-premises deployments, your own storage lifecycle.

​
Access and change auditing

Security-relevant activity is recorded in the Audit log: sign-ins, invitations, role and group changes, and document create, edit, and delete events. Filter by actor, action, and date range, and export the current view for review or evidence.

​
Common questions

No. Composer filters can only narrow retrieval within your resolved scope, and enforcement happens before retrieval, so no prompt can cause out-of-scope passages to be retrieved or cited.
Per chunk. Each chunk carries its parent document’s classification and categories, and the retrieval filter is applied at the chunk level, so a document’s passages are only ever eligible for users cleared for that document.
In managed cloud, retrieved in-scope passages are sent to the configured model provider to generate answers. With bring-your-own-key this goes through your own provider account; with a self-hosted model or an on-premises deployment, content stays within your boundary.