Common patterns usually combine retrieval constraints with authorization at query time and answer-time grounding. The main goal is: the model should only see text the user is allowed to see, and the final answer should be based only on that text.

1) Retrieve only from approved sources

The simplest pattern is to maintain an allowlist of source systems or document collections:

• internal wiki pages
• policy docs
• ticketing/CRM records
• knowledge base articles
• specific folders in a document store

Then the retriever:

• searches only those collections
• ignores everything else
• returns citations/IDs for traceability

This works well when “approved” is static or easy to define.

2) Metadata filtering before retrieval

A very common approach is to attach metadata to each chunk/document, such as:

• source system
• department
• document classification
• region
• confidence/approval status
• created/updated time
• owner

At query time, the retriever applies filters like:

• source in ["confluence", "sharepoint"]
• classification <= user_clearance
• department == user.department
• approved == true

This is one of the most important patterns because it prevents the vector search from even considering disallowed content.

3) ACL-aware retrieval

If documents have per-item access control lists, the retriever checks the user’s identity against those ACLs:

• user/group membership
• role
• clearance level
• project membership
• tenant/org boundary

Typical implementation:

• fetch candidate docs/chunks
• discard any item the user cannot access
• only then rank and pass context to the model

For strong security, ACL checks should happen before the LLM sees the text, not after.

4) Two-stage retrieval: coarse filter, then semantic search

A robust setup is:

1. Coarse filter by source, tenant, ACL, classification, recency
2. Semantic retrieval within the allowed subset
3. Optional reranker for relevance

This improves both security and answer quality. It also reduces the chance that the top semantic match is actually disallowed.

5) Document chunk-level access control

Sometimes a document contains mixed-sensitivity content. In that case:

• apply permissions at the chunk/section level
• or split documents into separately permissioned chunks

This avoids leaking restricted sections from an otherwise allowed document.

6) “Trusted index” or curated knowledge base

Another pattern is to only index content that has already been reviewed and approved:

• editorial workflow
• legal/compliance review
• content owner approval
• automated validation rules

This is useful when you want the assistant to answer from a controlled corpus rather than from all internal content.

7) Retrieval gating by intent or question type

Some systems route questions only to certain sources based on intent:

• HR questions → HR policy corpus
• engineering questions → engineering docs
• support questions → incident/runbook corpus

This reduces noise and limits exposure to irrelevant sources.

8) Answer-time grounding and refusal

Even with good retrieval, the generation step should be constrained:

• answer only from retrieved context
• cite the supporting sources
• if context is insufficient, say “I don’t know” or ask a follow-up
• do not fill gaps with general model knowledge

A common policy is:

• no retrieved evidence → no answer
• retrieved evidence conflicts → flag uncertainty or escalate

9) Post-retrieval redaction

For borderline cases, you may retrieve a document but redact sensitive fields before sending to the model:

• remove PII
• mask secrets/tokens
• remove customer identifiers
• strip confidential sections

This is not a substitute for ACLs, but it helps reduce accidental leakage.

10) Separate indexes for different sensitivity levels

You can maintain multiple indexes:

• public/internal
• confidential
• restricted
• team-specific

The application chooses which indexes are searchable based on the user. This is simpler than filtering huge shared indexes in some environments.

11) Tenant isolation / per-customer partitioning

In multi-tenant setups, the most common rule is:

• never search across tenants
• physical or logical partitioning by tenant
• tenant ID enforced at every retrieval step

This is a foundational access-control pattern.

12) Audit logging and traceability

For compliance, log:

• who asked the question
• what sources were queried
• what documents/chunks were returned
• what filters were applied
• what answer was generated

This doesn’t enforce access control by itself, but it’s critical for investigations and governance.

---

Recommended baseline architecture

A practical secure default looks like this:

1. Authenticate user
2. Resolve entitlements
   roles, groups, tenant, clearance, department
3. Apply source allowlist + ACL filters
4. Retrieve only from permitted content
5. Rerank within the allowed set
6. Provide only grounded context to the LLM
7. Require citations
8. Refuse if evidence is insufficient
9. Log everything

---

Common mistakes

• Filtering after retrieval only: disallowed chunks may still influence ranking or leak in logs.
• Relying on prompts alone: prompts are not access control.
• Using one shared index with no metadata: hard to enforce permissions reliably.
• Mixing approved and unapproved sources: can cause accidental grounding in untrusted content.
• Not handling chunk-level permissions: document-level ACLs are often too coarse.
• No citation requirement: makes it hard to verify the answer came from approved sources.

---

Rule of thumb

If you want “only answer from approved internal sources,” the best pattern is:

Enforce access control in retrieval, not in the prompt. Prompting can guide behavior, but the security boundary should be the retriever/index/permission layer.

If you want, I can also sketch:

• a reference architecture,
• a policy model for ACLs and metadata,
• or example pseudocode for secure retrieval.