I have docs in SharePoint, Slack, Confluence, and Salesforce. How should I connect them to an LLM without exposing data users can’t see?

The safest pattern is: don’t give the LLM direct access to all source systems. Instead, put a policy-aware retrieval layer in front of it that enforces each user’s permissions at query time.

Recommended architecture

1) Use an identity-aware connector layer

Connect SharePoint, Slack, Confluence, and Salesforce through a service that can:

• authenticate the end user via SSO/OIDC/SAML
• know the user’s groups/roles/entitlements
• fetch only content the user is allowed to access
• pass the LLM only those allowed snippets

This can be your own middleware or a vendor product, but the key is: authorization happens before retrieval.

2) Store documents with access control metadata

When ingesting content, index it with:

• source system
• document ID
• channel/site/project/record ownership
• ACLs / sharing permissions / group membership
• last modified time
• classification labels if you have them

Then at search time, filter retrieval by the user’s effective permissions.

3) Prefer “retrieve then generate,” not “train on everything”

Avoid fine-tuning or embedding everything into a single model that can “remember” restricted data. Use:

• embeddings/vector search for candidate retrieval
• a permission filter before/at retrieval
• a reranker if needed
• only then send the final snippets to the LLM

4) Enforce per-source permission mapping

Each system has its own auth model:

• SharePoint: site/library/item permissions, inheritance, Azure AD groups
• Slack: workspace/channel membership, private channels, DMs
• Confluence: space/page restrictions, groups, users
• Salesforce: object/field-level security, sharing rules, role hierarchy, record access

Your connector must map each item to the actual user-visible permissions, not just “document exists.”

5) Check permissions at query time, not only ingestion time

Permissions change constantly. If you only filter at ingest, users may later gain or lose access and the index becomes stale.

Use one of these:

• dynamic ACL filtering during retrieval
• periodic permission sync plus real-time validation for sensitive sources
• short-lived permission caches

Important guardrails

Never rely on the LLM to enforce security

The LLM should be treated as a reasoning layer, not an authorization layer.
It may leak if you give it restricted context.

Minimize context

Only provide the smallest relevant snippets to the model. Don’t dump whole documents if a paragraph or two is enough.

Log and audit

Record:

• who asked
• what sources were queried
• which documents/snippets were returned
• which permissions were applied

This helps with compliance and incident response.

Handle prompt injection from documents

Content in Slack, Confluence, etc. may contain malicious instructions. Strip or sandbox retrieved text so it can’t override your system prompt or exfiltrate data.

Practical implementation options

Option A: Build your own secure RAG stack

Typical components:

• SSO/auth service
• connectors to each source
• ACL-aware ingestion/indexing
• vector DB or search engine with metadata filtering
• retrieval gateway
• LLM API

Best if you need strong control and custom policy logic.

Option B: Use an enterprise AI/search product

Some platforms support:

• source connectors
• user-level permission trimming
• audit logs
• SSO integration
• enterprise search + chat

This is faster, but verify:

• how permissions are enforced
• whether indexing copies data into the vendor environment
• how deleted/revoked access is handled
• whether Slack/SharePoint/Salesforce permissions are fully respected

A simple rule of thumb

If a user would not be able to open a document in the original system, the LLM should not be able to retrieve or see it either.

Best practice summary

Use:

1. SSO-based user identity
2. per-item ACL metadata
3. permission-filtered retrieval
4. minimal context to the LLM
5. audit logs and revocation handling

If you want, I can sketch a reference architecture diagram or a concrete implementation plan for these four systems.