A semantic search system has already crossed its security boundary before generation begins: if retrieval admits another customer's chunk, no prompt can make that access legitimate afterward. Short answer: in a multi-tenant ask-your-docs SaaS, derive the customer identity from authenticated server context, bind both the embedding namespace and the mandatory metadata filter inside one retrieval interface, and make the resulting decision reconstructable from an audit record.
This architecture decision record treats similarity search as data access, not as authorization. The application may accept a question and optional within-tenant search preferences, but it must never accept the authoritative tenant identifier, namespace, or base filter from the request body. The design aims for an exactly-once effect under retries, explicit failure boundaries, and evidence that can support reconciliation without copying sensitive document text into a second store.
How should a Node.js SaaS bind each customer namespace and metadata filter for RAG?
The Node.js edge should authenticate the principal, resolve one internal tenant identifier from trusted claims, and construct an immutable request context before calling ingestion, retrieval, reranking, caching, or generation. A client field such as customer_id is merely untrusted data. Even if it happens to equal the authenticated tenant, promoting that field to authority creates a contract that a later handler, worker, or administrative path can misunderstand.
