How the U.S. Wealth Management Firm Built Secure RAG for Sensitive Client Data

The client’s teams relied on a growing body of financial documents and internal knowledge to support day-to-day client work. Finding the right information often meant navigating multiple sources, checking document relevance, and confirming that the material was still current. In wealth management, finding an answer is only part of the job. The information also has to be current, attributable to the right source, and accessible to the person asking.

For years, the workaround worked.

If a document took twenty minutes to find, that was simply the cost of being careful. In wealth management, accuracy, permissions, and source validation came before retrieval speed.

But then two things happened at once.

The body of documents kept growing,  faster than the team could organize it. And the client work kept growing with it. The same people hired to advise clients spent more and more of their day acting as human search engines: locating files, checking which version was current, confirming permissions, cross-referencing sources. Valuable people. Doing work that added no value.

The pressure showed up in everyday work. The question “where is that document?” was consuming time that should have gone to “what advice should we give?”

And just as the firm started exploring generative AI as an answer, it hit a second wall,  one that would define the entire project.

A conventional AI assistant would introduce a new access path to sensitive financial information. Every document chunk sent to the LLM had to pass the same access controls as the source material. Access rights differed from user to user. An answer exposed to the wrong user or detached from its source would create a security and compliance risk.

Could the firm make its knowledge instantly accessible while preserving the controls already protecting it?

That question became the starting point for a secure RAG system that retrieves authorized information, preserves document provenance, and keeps every generated answer connected to its source.

Microsoft Entra ID supplied the user identity and group membership. FastAPI handled authenticated requests and passed the user’s access context into the retrieval layer. PostgreSQL stored document metadata and access attributes, while pgvector handled semantic retrieval over document embeddings. Azure OpenAI generated embeddings and responses. LangChain coordinated the retrieval and generation flow.

Permission filtering happened before retrieved content entered the prompt.

• Identity follows the query. Users authenticate through Microsoft Entra ID using OAuth 2.0 / OIDC. The backend receives the authenticated identity together with the group or role claims used by the client’s existing permission model. FastAPI carries that access context into every retrieval request, making identity part of the retrieval path itself.
• Permissions survive ingestion. The Python ingestion pipeline processes source documents before they enter the retrieval index. The pipeline extracts text and splits it into retrievable chunks, while document-level metadata travels with each chunk. The metadata includes the source document identifier, version, storage location, access scope, and the fields required to determine whether the material is current. Azure OpenAI generates embeddings for the chunks. PostgreSQL stores the document metadata alongside the pgvector representation.
• Filter first, rank second, generate last. A query enters the system together with the authenticated user context. The retrieval layer first constrains the searchable set by the user’s permissions through an ACL metadata filter. Semantic similarity is then calculated only across eligible chunks to derive top-k results. Only the highest-ranking authorized chunks enter the LLM context.
• Version is part of relevance. Semantic similarity can rank an outdated document highly even when a newer approved version exists. The ingestion model therefore preserves version, recency, and document-state metadata with each chunk. Retrieval uses those attributes to favor or restrict results according to the document state defined by the client. The answer then carries the relevant version context with its citation, enabling employees to distinguish semantically relevant documents from currently approved material.
• Provenance survives generation. Each retrieved chunk keeps a reference to its parent document and the metadata required to reconstruct where the evidence came from. The generation layer carries those references into the response as source citations tied to the parent document and version.
• Permission leakage treated as a system failure. The team tested retrieval with users holding different permission sets, repeating identical queries across those identities to verify that searchable corpora and results differed based on entitlement. Validation covered document versions and source references to ensure restricted chunks remained outside the generation context.
• Production architecture. FastAPI exposes the application layer, while document ingestion and retrieval remain separate from the user-facing request path. Docker packages the services consistently across environments. Source documents remain in Azure Blob Storage. PostgreSQL stores document metadata and the pgvector index used during retrieval.

Technical Results

• 0 unauthorized chunks reached the LLM across 120+ permission test scenarios. The team repeated identical queries under different user roles and verified that restricted content stayed outside the retrieval context.
• 100% source traceability across 300+ validation queries. Every generated answer retained a reference to the supporting document and its version.
• Up to 80% of the candidate document set was excluded before semantic ranking. ACL metadata filtering reduced the searchable corpus to content available to the authenticated user before pgvector similarity search ran.
• Version-aware filtering reduced outdated-document retrievals by 87%. Adding version, recency, and document-state metadata substantially reduced cases where older but semantically similar documents appeared among the top results.
• Sub-2-second p95 retrieval latency before generation. Permission filtering, pgvector search, and top-k context assembly stayed fast enough for interactive use even with authorization checks in the retrieval path.

Business Results

• From roughly 20 minutes of manual search and validation to under 30 seconds. Relevant, permission-safe information could be retrieved with its supporting source in a fraction of the previous time.
• Up to 1 hour of advisor time returned per day. Advisors spent less time locating documents, checking versions, and cross-referencing sources before client work.
• One permission model across source systems and AI retrieval. The firm avoided creating a parallel access model for generative AI and reused existing user entitlements throughout the RAG pipeline.