Secure SharePoint RAG Architecture: ACLs, Citations, and Evaluation

That requires authorization filtering before retrieval, source lineage through the entire pipeline, and explicit grounding gates—not just a prompt telling the model to “use the documents.”

Who this is for

This guide is for Engineering Directors, Azure Platform Leads, Microsoft 365 owners, and IT or Security Architects building an internal knowledge copilot on SharePoint and Microsoft Entra ID. The design applies whether retrieval is implemented with Azure AI Search or a PostgreSQL/pgvector-based service, although the filtering and operational details differ by platform.

The failure modes to design out

1. Late-binding authorization leaks

A common proof-of-concept pattern retrieves from a shared vector index and asks an LLM or post-processing layer to decide what the user should see. That is the wrong boundary.

If unauthorized chunks enter the candidate set, they can influence the answer even if the final UI tries to hide a source link. Authorization must constrain which chunks are eligible for retrieval in the first place.

2. Vector-only retrieval misses exact operational language

Dense embeddings are useful for semantic similarity, but many enterprise questions depend on exact terms: error codes, policy identifiers, product SKUs, version strings, project names, and legal or technical phrases. A vector-only query can miss those signals.

Hybrid retrieval combines lexical search, such as BM25/full-text search, with vector retrieval so the system can handle both exact terminology and semantically related language.

3. “Answer only from context” is not a grounding control

A prompt can encourage the model to cite sources. It cannot establish whether the sources are sufficient, whether a material claim has evidence, or whether conflicting documents require an abstention.

The answer path needs deterministic checks outside the model: retrieval thresholds, citation coverage checks, and a clear no-evidence response.

Recommended architecture

                         INDEXING PATH

SharePoint document libraries
  -> Microsoft Graph delta query
  -> content extraction and normalization
  -> chunking and stable source identifiers
  -> resolve effective read-access metadata
  -> write chunks, vectors, text fields, source links, and ACL metadata
  -> Azure AI Search or PostgreSQL/pgvector

                         QUERY PATH

User
  -> Microsoft Entra ID sign-in
  -> application/API validates the user token
  -> verified user ID and effective group IDs
  -> server-side pre-retrieval authorization filter
  -> hybrid retrieval: BM25/full-text + vector search
  -> RRF fusion
  -> semantic ranker or cross-encoder reranking
  -> citation/evidence validation
  -> grounded answer with source links
     OR deterministic abstention

Keep the index current with delta queries

Do not recrawl an entire SharePoint library for every sync cycle. Microsoft Graph delta query is designed to identify new, updated, and deleted resources since the last checkpoint. For a document-library ingestion flow, start with GET /drives/{drive-id}/root/delta, follow every @odata.nextLink until Graph stops returning one, and persist the returned @odata.deltaLink after that cycle’s changes have been applied to local state. Later cycles start from that durable delta link. Microsoft Graph documents that deleted driveItem objects are returned with a deleted facet and should be removed from local state.

A practical ingestion record should retain the source tenant, site, drive, item ID, source URL, content version, and a stable chunk ID. When a deletion arrives, remove or tombstone every chunk for that document. Make writes idempotent. Honor Retry-After on HTTP 429 responses; if Graph omits that header, fall back to exponential backoff. Add a periodic reconciliation job. Delta tracking is a change-detection mechanism; it does not remove the need for operational monitoring and recovery. If a stored token is no longer valid, Graph can return HTTP 410 Gone and require a fresh enumeration—treat that as a first-class recovery path, not an unexpected error.

Graph delta page
  -> changed or new file: extract -> chunk -> tag ACLs -> upsert index
  -> deleted file: locate document chunks -> delete or tombstone index entries
  -> nextLink present: continue
  -> deltaLink present: commit checkpoint after successful processing

Permissions, app models, and tenant policy still vary. Select least-privileged Graph permissions and validate behavior against the target SharePoint topology rather than assuming one connector configuration fits every tenant.

Bind access controls to every retrievable chunk

Every chunk that can be retrieved must carry the authorization metadata needed to determine whether the active user can access it. Use immutable Microsoft Entra object IDs and security-group object IDs—not names or email strings.

A simplified chunk record might include:

{
  "chunk_id": "tenant:drive:item:version:chunk",
  "source_url": "https://tenant.sharepoint.com/sites/...",
  "content_version": "etag-or-version",
  "acl_user_ids": ["entra-user-object-id"],
  "acl_group_ids": ["entra-security-group-object-id"],
  "visibility_scope": "restricted"
}

The exact field names are not important. The control is: security metadata must be filterable in the retrieval layer, present at the same granularity as the returned content, and updated when the source document’s effective access changes.

For Azure AI Search, this usually means filterable security fields and a server-generated OData filter. For PostgreSQL/pgvector, it means applying authorization predicates in SQL at or before vector candidate selection, then validating query plans under production-like data volumes.

Use Entra identity claims to filter before retrieval

The application should validate the user’s Entra token server-side, normalize the user’s object ID and effective group IDs, then construct the index filter before retrieval executes. Do not let a browser provide its own claimed roles or group IDs as a security input.

The OAuth 2.0 On-Behalf-Of flow is useful when a middle-tier API needs to call a downstream protected API with delegated user context. It describes a web API calling another web API on behalf of a signed-in user; it does not replace the need to enforce authorization in your own retrieval system. Microsoft Entra On-Behalf-Of flow documentation

Conceptually, the retrieval request should look like this:

Authorized when:
  document is tenant-visible
  OR current user object ID is in acl_user_ids
  OR an effective user group ID is in acl_group_ids

For users with large or complex group memberships, plan explicitly for group-claim overage, nested groups, filter-size limits, permission freshness, and a defensible fallback strategy. Those details are not edge cases in enterprise tenants; they are part of the authorization design.

Combine lexical and vector retrieval, then rerank

A secure candidate set still needs useful ranking. Run lexical and vector retrieval within the authorization boundary, then combine their ranked lists with Reciprocal Rank Fusion (RRF).

RRF(d) = Σ_{q ∈ Q} 1 / (k + rank_q(d))

Where Q is the set of ranked retrieval lists, rankq(d) is the one-based rank of document d in a list, and k is a rank-smoothing constant. Azure AI Search documents the same idea as 1/(rank + k) with a service-controlled k. This formula explains the concept; it does not fully specify Azure’s managed implementation.

Azure AI Search uses RRF when multiple queries execute in parallel, including hybrid search. Its semantic ranker runs after the initial fusion/retrieval stage as an L2 reranker and reports a separate @search.rerankerScore. A self-hosted cross-encoder is a separate implementation option, not the same component. Azure AI Search hybrid-search ranking documentation

User query within ACL filter
  -> lexical retrieval for exact terms
  -> vector retrieval for semantic matches
  -> RRF fusion
  -> bounded authorized candidate set
  -> semantic ranker or cross-encoder reranker
  -> evidence selection

This sequence helps preserve exact-match recall without giving up semantic retrieval. It also ensures the reranker and generator see only candidates that have already passed the access-control boundary.

Require evidence before generating an answer

Treat citation grounding as a system behavior, not a model preference. Before returning an answer, check that the retrieval stage found sufficient authorized evidence and that material claims map to citations.

A simple policy is:

If no authorized chunk meets the retrieval threshold:
  return: "I could not find authorized source material that supports an answer."

If a material claim has no supporting source:
  regenerate only with explicit evidence, or abstain.

If authoritative sources conflict:
  cite the conflict, ask for clarification, or abstain.

Otherwise:
  return the answer with inspectable source links.

The thresholds are implementation and domain specific. They should be chosen through an evaluation set, not invented once in a prompt. The goal is not to claim that a copilot never makes a mistake. The goal is to make unsupported answers a measurable failure condition and to reduce the system’s willingness to fabricate certainty.

Naive proof of concept vs. enterprise grounded RAG

Production checklist

Before releasing an internal SharePoint copilot, verify these four controls:

1. Delta sync and lifecycle handling — The ingestion service persists delta checkpoints after a successful cycle, handles deletions via the deleted facet, retries throttled calls using Retry-After, and can reconcile after failure or a 410 Gone token reset.
2. Chunk-level authorization metadata — Every retrievable chunk has current, filterable ACL metadata derived from the source system’s effective permissions.
3. Pre-retrieval security enforcement — The server constructs the filter from verified identity data before lexical or vector candidates are selected.
4. Evaluation and boundary testing — The release gate includes authorized/unauthorized retrieval tests, citation-support checks, stale-content cases, exact-term queries, and no-evidence abstention tests.

Implementation note

Do not assume there is a universal latency cost for authorization filtering. Its impact depends on index structure, cardinality, group membership, filter construction, query type, and data volume. Measure it with the production-like workload and treat it as a retrieval performance requirement.

The more important design point is architectural: a late LLM-based “permission check” happens after sensitive content may already have entered the model context. Pre-retrieval filtering prevents that exposure path rather than trying to clean it up afterward.

Related reading

• Designing Citation-Grounded RAG for Microsoft 365: Permissions, Retrieval, and Evidence
• Why Enterprise RAG Pilots Fail After the Demo (And How to Fix Retrieval Latency)
• RAG Knowledge Copilot Pilot