सुरक्षा और Multi-Tenancy

जहाँ डेटा है वहीं अलगाव लागू करें

Embeddings आपके दस्तावेज़ों से बनते हैं और उनके बारे में जानकारी लीक कर सकते हैं, इसलिए vectors और payloads को स्रोत डेटा जितनी सुरक्षा मिलनी चाहिए। Transit में TLS और at rest encryption उपयोग करें; हर client को authenticate करें और न्यूनतम-विशेषाधिकार roles दें (ingestion service लिख सकती है, search service सिर्फ़ पढ़ सकती है); database को निजी network पर रखें, इंटरनेट के लिए कभी खुला नहीं; और API keys secrets manager में रखें। Multi-tenancy के लिए tenant सीमा वहीं लागू करें जहाँ डेटा रहता है: PostgreSQL में row-level security या अनिवार्य tenant predicate, प्रति tenant collection या namespace, या tenant अलगाव की engine सुविधा; application prompts या UI पर निर्भर न रहें। स्वचालित जाँचों से अलगाव परखें कि tenant-A की query कभी tenant-B की rows नहीं लौटाती। Queries और प्रशासनिक कार्रवाइयाँ log करें, और retention व deletion नियम लागू करें (दस्तावेज़ हटाना उसके vectors और किसी भी caches को हटाए)।

सुरक्षित करें, बचाएँ, चुनें

Vectors अपने स्रोतों जितने संवेदनशील हैं; backups और migrations की योजना बनाएँ, फिर प्रमाण से चुनें।

PostgreSQL में row-level security (उदाहरण)

Table पर हर query session के लिए सेट tenant तक स्वतः सीमित होती है। मानक PostgreSQL सुविधा; पैटर्न के रूप में दिखाई, यहाँ चलाई नहीं गई।

ALTER TABLE docs ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON docs
  USING (tenant = current_setting('app.tenant'));

-- in each request, after authenticating the user:
--   SET LOCAL app.tenant = 'acme';
--   SELECT id, body FROM docs ORDER BY embedding <=> :q LIMIT 5;   -- can only see acme's rows

Tenant-अलगाव test लिखें

स्वचालित रूप से जाँचें कि tenant A की query कभी tenant B की row नहीं लौटाती, और CI में चलाएँ।

त्वरित जाँच: Tenant अलगाव कहाँ लागू होना चाहिए?

• सिर्फ़ UI में
• सिर्फ़ prompt में
• Database में (row-level security, collections या namespaces), स्वचालित रूप से परखा हुआ
• कहीं नहीं