Permissions-Aware RAG
OpenBase enforces document-level and field-level access controls at retrieval time, so every answer respects the same permissions your team already relies on in Confluence, SharePoint, or Google Drive.
Most RAG systems treat the knowledge base as a single shared resource. That works for public documentation. It breaks the moment your company stores contracts, HR policies, or customer data — information that different people are allowed to see.
OpenBase syncs access control lists from every connected source and applies them before retrieval. When a marketing lead asks Donna a question, the vector search only considers documents that lead is permitted to read. When a finance controller asks the same question, they see a different set of sources. The model never generates an answer from a document the user cannot access.
Permission checks happen in the retrieval layer, not as a post-filter. That means performance stays predictable even when your knowledge base contains thousands of restricted documents, and it means you can audit exactly which documents informed every answer.
Problem & solution
Unrestricted knowledge access creates liability
A shared knowledge base that ignores permissions leaks restricted information into answers. An HR lead asks about parental leave policy and the system quotes from a draft acquisition memo. A contractor asks about project timelines and sees confidential customer data. Every answer becomes a compliance risk because the system cannot distinguish between what the user is asking and what the user is allowed to know.
Permission enforcement at retrieval time
OpenBase imports access control lists from every connected source — Confluence spaces, SharePoint libraries, Google Drive folders, Notion databases. Before running a similarity search, it filters the vector index to only the documents the current user is permitted to read. The LLM never sees restricted content, so it cannot leak it. Permission changes in the source system propagate to OpenBase within minutes, and every query logs which documents were considered so you can audit access after the fact.
What you see after 90 days
- Restricted documents never appear in answers for users without access
- Permission audits trace every answer back to the ACLs that governed retrieval
- Compliance teams verify access boundaries without manual testing
- Performance remains constant regardless of permission complexity
Who benefits most
- IT and governance leads enforcing data access policies across AI tooling
- Compliance officers auditing information access for SOX, GDPR, or HIPAA
- HR and finance teams storing sensitive documents in the same workspace as public knowledge
- Multi-tenant organizations separating customer data by account or region
Frequently asked questions
How does OpenBase sync permissions from source systems?
OpenBase reads access control metadata through the same API connectors that index content. For Confluence, that means space permissions and page restrictions. For Google Drive, that means file-level sharing settings and folder inheritance. Permissions sync on the same schedule as content updates — typically every few minutes for active sources.
What happens when a document's permissions change after it's indexed?
OpenBase re-syncs permissions on every content update cycle. If a Confluence page is restricted to a new group, that change propagates to OpenBase within the next sync window. Queries run after that point will respect the updated ACL. Answers generated before the change remain in logs with the permissions that were active at query time.
Can OpenBase enforce field-level permissions within a document?
Yes, when the source system supports it. If a Notion database restricts certain properties to specific users, OpenBase will only retrieve those properties for users with access. The same applies to SharePoint columns with item-level permissions. If the source system does not expose field-level ACLs through its API, OpenBase enforces document-level permissions only.
How do permission checks affect retrieval performance?
Permission filtering happens at the vector index layer, before similarity scoring. That means the performance cost is proportional to the number of documents a user can access, not the total size of the knowledge base. A user with access to 500 documents sees the same query latency whether the full index contains 5,000 or 50,000 documents.
Does OpenBase support role-based or attribute-based access control?
OpenBase enforces whatever access model the source system uses. If your Confluence instance uses group-based permissions, OpenBase respects those groups. If your SharePoint library uses audience targeting based on department attributes, OpenBase applies those rules. The permission model is defined in the source system; OpenBase reads and enforces it.
Can I audit which documents informed a specific answer?
Every query logs the user identity, the timestamp, the documents retrieved, and the permissions that were active at retrieval time. You can export these logs for compliance review or feed them into your SIEM. The audit trail shows not just what was retrieved, but also which ACLs allowed that retrieval.
What happens if a user asks about a document they cannot access?
The document is excluded from retrieval, so the model generates an answer based only on permitted sources. If no permitted documents match the query, Donna responds that it cannot find relevant information rather than hinting at the existence of restricted content. The user never learns that a restricted document exists unless they already have access to it.
How does OpenBase handle inherited permissions from parent folders or spaces?
OpenBase resolves permission inheritance at sync time. If a Google Drive folder grants access to a group, all files in that folder inherit that permission unless explicitly overridden. OpenBase flattens the inheritance tree into a per-document ACL so retrieval does not need to walk the hierarchy at query time.
In this cluster
Hub: enterprise-rag-architecture