KENSAI रिसर्च: RAG बैकएंड लीक एक architecture failure है, prompt accident नहीं

RAG systems इसलिए leak नहीं करते कि एक prompt एक बार अजीब हो गया। वे इसलिए leak करते हैं क्योंकि teams backend wiring, debug traces और conversation residue को client layer तक भेज देती हैं और उसे implementation detail कहती हैं।

आज यह signal क्यों मायने रखता है

एक medical RAG chatbot की हाल की audit इसलिए महत्वपूर्ण है क्योंकि उसने दिखाया कि साधारण client-visible surfaces से prompts, configuration details, schemas, metadata और पास की conversation history तक लीक हो सकती है। इसके लिए किसी cinematic jailbreak की जरूरत नहीं पड़ी। सिर्फ curiosity और browser inspection काफी थे।

असल में क्या टूटा

मुख्य failure सिर्फ model output में नहीं था। Product ने backend artifacts को उन paths से expose कर दिया जिन्हें client inspect कर सकता था, और private operating details public hints बन गए। उसके बाद attacker समझ सकता है कि system sensitive context को कैसे retrieve, route और store करता है।

यह architecture bug क्यों है

अगर prompts, routing rules, retrieval metadata और recent session traces frontend के बहुत करीब बैठे हों, तो user interface जितना दिखाना चाहती है उससे ज्यादा दिख जाता है। यह wording problem नहीं है। यह state-boundary problem है। Loose plumbing future prompt injection, steering और exfiltration के मौके बनाती है।

Teams को अब क्या करना चाहिए

Client-visible metadata कम करो, debug surfaces को user delivery से अलग करो, transient traces को जल्दी expire करो, और browser-visible payloads को hostile disclosure की तरह inspect करो। जो field user action के लिए जरूरी नहीं है, उसे convenience के लिए साथ नहीं भेजना चाहिए।

KENSAI takeaway

Agent privacy interfaces, headers, payloads और state boundaries में जीती जाती है। अगर browser user की जरूरत से ज्यादा देख सकता है, तो system पहले से ही ढीला है। Secure RAG सही तरीके से boring होता है: कम exposure, tighter seams, कम surprises।