I need a knowledge base that respects user permissions and does not show confidential docs to everyone.

If you need a knowledge base that does not leak confidential documents, look for a permission-aware knowledge base / enterprise search system. The key requirement is not just “private storage”; it is that search and AI answers enforce the same permissions as the original documents.docs.aws.amazon.com+1

Important capabilities to look for:

Capability	Why it matters
User identity integration (SSO)	The system knows who is asking (for example, via Microsoft Entra ID, Okta, Google Workspace).
Document-level permissions / ACLs	A user who cannot open a file in the source system should not see it in search results, snippets, summaries, or AI answers.docs.aws.amazon.com
Permission-aware indexing	Permissions are carried with indexed content rather than creating a separate, easy-to-misconfigure access model.docs.aws.amazon.com+2
Query-time authorization checks	Access is checked when someone searches, reducing the risk of stale permissions exposing content.docs.aws.amazon.com+1
Audit logs	You can review who searched for or accessed sensitive material.
No unauthorized AI retrieval	If using an AI assistant, restricted documents should be filtered before they are used to generate answers.docs.aws.amazon.com+1

Common approaches:

1. Build on your existing document platform

If your organization already uses:

• Microsoft 365 / SharePoint
• Google Workspace
• Confluence
• Notion
• Jira
• Slack

you can add search or AI layers that inherit those permissions. For example, Azure AI Search supports document-level access controls, including permission metadata and query-time enforcement patterns.docs.aws.amazon.com+1

2. Use an enterprise search / AI knowledge product

Examples of products in this category include:

• Microsoft tools built around Microsoft 365 permissions
• Amazon knowledge/search services with document-level access controlsdocs.aws.amazon.com
• InSearch, which describes permission-aware search across sources such as Drive, Slack, Notion, Confluence, Gmail, Jira, and Salesforce.docs.aws.amazon.com+2
• Axero Solutions, which describes role- and space-based permissions for knowledge bases.axerosolutions.com

Architecture pattern I would recommend

User
 |
 | authenticated identity
 v
Knowledge search / AI layer
 |
 | checks permissions
 v
Document index (with ACL metadata)
 |
 v
Source systems
(SharePoint, Drive, Confluence, etc.)

Avoid designs where:

• all documents are copied into a shared index,
• permissions are added later as a UI filter,
• AI can retrieve from the full index and “promise not to reveal things.”

A good test is:

If an employee asks the same question as an executive, does the system return different answers based on what each person is allowed to access?

If yes, you are closer to a secure knowledge base.

If you tell me your environment (Microsoft 365, Google Workspace, Confluence, custom app, etc.) and approximate size (10 users vs. 10,000+), I can narrow down suitable options.

A secure knowledge base should treat permissions as part of search and retrieval, not just as a document-sharing feature. The key requirement is: a user should never retrieve, preview, summarize, or get answers generated from documents they cannot access. Permission-aware knowledge bases typically enforce this with document-level access controls (ACLs) tied to user identity and groups.AWS Documentation+1

A good architecture looks like this:

1. Use identity-based access control

Connect the knowledge base to your identity provider:

• Users authenticate through your company identity system (for example, SSO).

• Map users into groups:

• Finance

• HR

• Legal

• Engineering

• Executives

• Project teams

• Store document permissions as:

• User ACLs (specific people)

• Group ACLs (recommended for most cases)

• Roles (viewer/editor/admin)

Example:

2. Enforce permissions during retrieval

A common mistake is:

Index everything → search everything → hide the answer afterward That can leak sensitive information through:

• search snippets
• document titles
• generated summaries
• metadata
• embeddings

Instead:

1. User signs in.
2. System determines their permissions.
3. Search only considers documents they can access.
4. The AI generates answers only from authorized content.

ACL-aware systems commonly apply permissions during retrieval so users only receive documents they are authorized to access.AWS Documentation+1

3. Keep document permissions synchronized

Your knowledge base should sync changes such as:

• Someone leaves the company
• A user changes departments
• A project ends
• A confidential folder changes ownership

Consider:

• Scheduled permission synchronization
• Real-time permission checks for highly sensitive content
• Audit logs showing who accessed what

Some enterprise systems combine synced ACLs with query-time verification to handle permission changes more accurately.AWS Documentation+1

4. Add document classification

Use sensitivity levels:

• Public
• Internal
• Confidential
• Highly Confidential

Then apply policies:

Example:

Highly Confidential
├── Only Legal + Executives
├── No external sharing
├── Audit every access
└── Require MFA

Classification systems can automatically apply restrictions to sensitive documents.Microsoft Learn

5. Separate knowledge-base administration from document access

These are different permissions:

• Who can use the knowledge base?
• Who can see individual documents?
• Who can upload documents?
• Who can change permissions?
• Who can publish content?

A user might be allowed to search the knowledge base but still not see HR or legal documents.

6. Add security controls for AI answers

For an AI-powered knowledge base, include:

• Permission-filtered retrieval
• Source citations in answers
• "I don't have access to that document" responses instead of guessing
• No training/fine-tuning on confidential documents without authorization
• Logging of prompts and retrieved sources (with appropriate privacy controls)

7. Test for leakage

Before launch, test with accounts such as:

• Regular employee
• Contractor
• Manager
• HR user
• Admin

Try queries like:

• "What are the upcoming layoffs?"
• "Show me executive compensation"
• "Find the acquisition documents"

Verify unauthorized users get no content, not just no final answer.

A practical stack usually combines:

• document storage with permissions (SharePoint, Google Drive, S3, Confluence, etc.)
• identity provider (Okta, Entra ID, Google Workspace, etc.)
• search/vector index with ACL filtering
• AI layer that only receives authorized context

The most important design rule: never rely on the AI model itself to decide what is confidential; enforce access before content reaches the model.

To keep confidential documents secure while empowering your team, you need a knowledge base that supports role-based access control (RBAC) and granular permissions (ideally down to the folder, space, or page level).reddit.com+1

Here are the top options tailored for permission-aware knowledge management, broken down by hosting type:

• BookStack (Open Source / Self-Hosted)
  • Overview: A free, open-source platform structured like a physical library (Shelves, Books, Chapters, and Pages).
  • Permissions: Features a robust role-based permission system where you can restrict entire books or individual pages so specific teams (like HR or Finance) can't see other departments' sensitive notes. It also supports enterprise authentication like LDAP, SAML, and Okta.docmost.com+1
• XWiki (Open Source / Enterprise)
  • Overview: A powerful, highly customizable Java-based wiki and knowledge management platform suited for scaling organizations.
  • Permissions: Offers an extremely fine-grained rights management system. You can explicitly allow or deny view, edit, and admin rights at the global, space, or individual page level, and cleanly sync it with Active Directory or OIDC/SAML.docmost.com
• Docmost (Open Source / Self-Hosted)
  • Overview: A modern, open-source collaborative workspace and alternative to Notion, built for real-time editing and documentation.
  • Permissions: Allows permissions to be managed cleanly at both space and page levels with user group support, alongside LDAP integration for corporate governance.reddit.com+1
• Notion (Enterprise) (Cloud-Hosted SaaS)
  • Overview: The popular all-in-one workspace that doubles as a company wiki.
  • Permissions: Higher-tier plans feature advanced user management via SCIM APIs, workspace rules, guest restrictions, and page-by-page sharing limitations to prevent unauthorized internal or external access.
• Confluence (Cloud or Data Center)
  • Overview: The industry standard for enterprise documentation and team wikis.
  • Permissions: Uses a three-tier permission structure (Global application access → Space-level permissions → Page-level content restrictions) to ensure absolute isolation of confidential strategy or engineering docs.medium.com

To help narrow down the ideal choice, do you prefer a self-hosted/open-source solution (like BookStack or XWiki) or a cloud-hosted SaaS tool (like Confluence or Notion), and what authentication provider (e.g., Google, Okta, Azure AD) do you use?

Yes. The key design principle is permission-aware retrieval, not merely hiding documents in the UI.

Recommended architecture

User
  │
  ▼
Authentication / SSO
  │
  ▼
Authorization service
  │   user_id, groups, roles, tenant, clearance
  ▼
Permission-aware query
  │
  ▼
┌───────────────────────────────┐
│ Knowledge Base                │
│                               │
│ Document chunks + ACL metadata│
│                               │
│ doc_id                        │
│ tenant_id                     │
│ allowed_users                 │
│ allowed_groups                │
│ classification                │
└───────────────────────────────┘
  │
  │ retrieve ONLY authorized chunks
  ▼
Reranking
  │
  ▼
LLM
  │
  ▼
Answer + citations to authorized docs

The important part

Every document/chunk should carry its access metadata, for example:

{
  "document_id": "contract-482",
  "tenant_id": "acme",
  "classification": "confidential",
  "allowed_groups": ["legal", "executives"],
  "allowed_users": [],
  "denied_users": []
}

When Alice searches, the retrieval query should effectively become:

search("customer contract")
WHERE tenant_id = Alice.tenant_id
AND Alice/user's groups satisfy the document ACL
AND document is not explicitly denied

Do this before the content reaches the LLM. Don't retrieve confidential documents and then tell the model "don't mention them." Permission filtering at retrieval time prevents unauthorized text from becoming model context in the first place. AWS's ACL-aware knowledge-base documentation describes the same pre-retrieval filtering pattern.AWS Documentation+1

Security rules I'd build in

• Deny by default. Missing or ambiguous permissions should mean no access. OWASP explicitly recommends deny-by-default and least privilege.OWASP Cheat Sheet Series+1
• Authenticate outside the knowledge base. The KB should receive a verified user identity/claims; don't trust a client-supplied user_id. AWS specifically notes that ACL-aware retrieval itself isn't authentication or a security boundary.AWS Documentation
• Filter before vector search results reach the application/LLM.
• Carry permissions into the index. If a document's permissions change, update its indexed metadata promptly.
• Support groups as well as individual users.
• Keep tenant isolation explicit if this is multi-tenant.
• Log authorization decisions and which document IDs contributed to an answer. OWASP recommends logging authorization events and testing authorization rules.

A useful rule is:

If the user couldn't open the original document, the AI should never be able to use that document to answer them. If you're building this from scratch, I can also lay out a concrete Postgres + pgvector / OpenSearch + SSO + RAG architecture, including the schema and retrieval pseudocode for enforcing these permissions.

Yes. The key design principle is: permissions must be enforced before retrieval, not after the LLM has already seen the document. Current enterprise knowledge-base systems use this pattern with document-level ACLs.AWS Documentation+1

Recommended architecture

User
  │
  ▼
Authenticate with SSO / IdP
  │
  ▼
Authorization context
(user ID, groups, roles, tenant, attributes)
  │
  ▼
Permission-aware retrieval
  ├── tenant / department filters
  ├── document ACL filters
  ├── group membership
  └── current-access verification
  │
  ▼
Only authorized chunks
  │
  ▼
LLM / RAG generation
  │
  ▼
Answer + only safe citations

1. Preserve permissions during ingestion

For every document/chunk, keep authorization metadata alongside the content:

{
  "document_id": "doc-123",
  "chunk_id": "doc-123-07",
  "allowed_users": [],
  "allowed_groups": ["finance", "executives"],
  "denied_groups": ["contractors"],
  "classification": "confidential",
  "source": "sharepoint"
}

Prefer storing groups/roles and source ACL identifiers rather than flattening everything into a list of users, because memberships change frequently.

2. Filter before semantic retrieval

Don't do this:

search everything → retrieve confidential chunk → check permission → discard

Instead:

authenticate user
→ resolve permissions
→ constrain search space
→ vector/keyword search
→ return authorized chunks

This prevents confidential material from entering the model's context in the first place. AWS and Microsoft both document document-level filtering at retrieval time for this reason.AWS Documentation+1

3. Fail closed

If permissions are missing, stale, or cannot be evaluated, don't treat the document as public. For example, Bedrock's ACL-aware retrieval treats missing ACL metadata as inaccessible and fails closed when ACL evaluation encounters an error.AWS Documentation+1

That's especially important during ingestion failures or permission-sync delays.

4. Authenticate separately from authorization

Your application should authenticate the user with your identity provider and pass a verified identity to the retrieval layer. An ACL-aware search system shouldn't be trusted to authenticate whoever supplied the user ID.AWS Documentation

For example:

Microsoft Entra / Okta / Google Workspace
              ↓
        verified user identity
              ↓
        authorization service
              ↓
       permission-aware RAG

5. Handle permission changes

You need a strategy for revocations:

• Fast path: check the source system's current permissions at query time where possible.
• Fallback: synchronize ACL changes into your index.
• Fail closed: uncertain permission state means no retrieval.
• Audit: record which identity queried which documents and which documents were actually returned.

Real-time verification is supported by some current enterprise knowledge-base integrations, while others rely on synchronized ACL metadata.AWS Documentation+1

6. Don't leak restricted documents indirectly

A user shouldn't be able to discover a confidential document through:

• Search-result titles
• Citation lists
• Snippets
• Document counts
• "I found a confidential HR document..." responses
• LLM-generated summaries based on restricted context

The model should receive only authorized content, and your citation layer should likewise expose only authorized source identifiers.

7. Test it as a security boundary

Create test users such as:

Alice    → Engineering
Bob      → Finance
Carol    → HR
Dave     → Contractor
Admin    → All

Then create documents with overlapping permissions and test:

Can Alice retrieve engineering.doc?       YES
Can Alice retrieve finance.doc?           NO
Can Dave retrieve confidential-hr.doc?    NO
Can Bob retrieve finance.doc?             YES
Can a revoked user retrieve old chunks?   NO
Can an LLM prompt reveal hidden content?  NO

Also test permission revocation, inherited permissions, nested groups, deleted documents, renamed users, and stale indexes.

If you're building this yourself, I'd structure the system around an IdP + authorization service + ACL-aware search index + RAG layer, rather than trying to make the LLM itself responsible for security. Current enterprise implementations similarly treat ACL filtering as part of the retrieval infrastructure rather than a prompt-level instruction.AWS Documentation+1

If you tell me your stack—e.g. SharePoint + Microsoft 365, Google Drive, S3, PostgreSQL, Azure AI Search, OpenSearch, or a custom vector DB—I can sketch the concrete schema and retrieval flow for it.

Yes. The key is to make permissions part of retrieval, not something you apply after the AI has searched the whole corpus.

Recommended architecture

User
  │
  ▼
Authenticate (SSO / Entra / Okta / etc.)
  │
  ▼
Resolve user + groups + document permissions
  │
  ▼
Permission-aware retrieval
  │
  ├── Public/team documents
  ├── Department-restricted documents
  ├── Project-restricted documents
  └── Confidential documents
  │
  ▼
LLM receives ONLY authorized chunks
  │
  ▼
Answer + citations only from authorized sources

The important rules

• Authenticate the user upstream. The knowledge base should receive a verified user identity; an ACL filter by itself is not authentication or authorization.AWS Documentation+1
• Store ACL metadata with every document/chunk. For example:

{
 "document_id": "hr-2026-0142",
 "allowed_users": [],
 "allowed_groups": ["hr", "executives"],
 "classification": "confidential"
}

• Filter before retrieval. The vector/keyword search should only search documents the current user can access. Document-level access control is specifically designed for this pattern.Microsoft Learn+1
• Fail closed. If permission metadata is missing or cannot be evaluated, return no document rather than treating it as public. AWS's ACL-aware retrieval, for example, explicitly uses this behavior.AWS Documentation
• Apply permissions again at answer time when possible. If the underlying repository supports real-time permission verification, use it so permission changes aren't dependent solely on an index refresh.AWS Documentation+1
• Never put unauthorized text into the LLM context and then try to hide it afterward. That creates unnecessary leakage risk.
• Test with representative users. Test ordinary employees, managers, contractors, users with multiple groups, revoked users, and users whose permissions recently changed. AWS likewise recommends testing document access before broadly sharing an ACL-aware knowledge base.AWS Documentation

A practical permission model

I'd use RBAC + document ACLs:

Groups handle the common cases; individual document ACLs handle exceptions.

One particularly important operational detail is permission synchronization. If someone is removed from a group or loses access to a document, your index must reflect that change promptly. Some systems combine indexed ACL filtering with a real-time source check specifically to handle this.AWS Documentation

If you're building this yourself, I can also lay out a concrete Postgres + pgvector / Elasticsearch / OpenSearch architecture, including the permission schema, ingestion pipeline, retrieval query, and API flow.