AI एजेंट से जुड़ी 7 डेटा प्राइवेसी गलतियाँ जो चुपचाप आपकी कंपनी का डेटा लीक करती हैं (और इनसे कैसे बचें)

ज़्यादातर AI एजेंट डेटा लीक इसलिए नहीं होते कि मॉडल चुपके से आपकी कंपनी को याद कर लेता है। वे उन कॉन्फ़िगरेशन और आर्किटेक्चर गलतियों से आते हैं जिन्हें आप पहचान और ठीक कर सकते हैं। बड़ी गलतियाँ ये हैं: ऐसे कंज़्यूमर-टियर अकाउंट पर चलना जिसके डिफ़ॉल्ट आपके इनपुट पर ट्रेन करते हैं, किसी एजेंट को एक व्यक्ति की व्यापक परमिशन विरासत में लेने देना, पब्लिक के सामने रहने वाले एजेंट को आंतरिक सिस्टम से जोड़ देना, और "घातक तिकड़ी" को बरकरार छोड़ देना (निजी डेटा, अविश्वसनीय कंटेंट, और बाहर भेजने का रास्ता) ताकि एक अकेला प्रॉम्प्ट इंजेक्शन आपका डेटा पढ़कर मेल कर दे। ठीक यही पैटर्न था जिससे EchoLeak (CVE-2025-32711) ने एक तैयार किए गए ईमेल के ज़रिए Microsoft 365 Copilot से संवेदनशील डेटा उजागर किया, और इसमें किसी यूज़र को क्लिक तक नहीं करना पड़ा। समाधान कोई अजूबे नहीं हैं, और इनमें से लगभग सभी एजेंट के लॉन्च होने से पहले लिए गए फ़ैसले हैं, कुछ लीक होने के बाद थमाई गई चेकलिस्ट नहीं।

यह वही सूची है जिस पर हम तब काम करते हैं जब हम अपने बनाए किसी एजेंट को किसी दूसरी कंपनी के स्टैक के अंदर रखने वाले होते हैं, और इसे इस तरह लिखा गया है कि एक गैर-तकनीकी मालिक भी अपने सेटअप या किसी वेंडर के सेटअप में यही गलतियाँ पहचान सके। अगर आप चाहते हैं कि हम यह सीमा वहीं रखें जहाँ वह आपके लिए होनी चाहिए, तो देखिए कि हम ज़िम्मेदार AI गवर्नेंस और जोखिम को कैसे चलाते हैं। नीचे दी गई हर बात किसी भी हाल में आपके इस्तेमाल के लिए है।

सबसे पहले, एक ऐसा अंतर जिसे इस विषय पर लगभग हर लेख धुंधला कर देता है, क्योंकि इसे गलत समझना ही पहली गलती है। डेटा एजेंट के ज़रिए दो बिल्कुल अलग तरीकों से बाहर जाता है, और इन दोनों के समाधान भी पूरी तरह अलग हैं:

• प्रोवाइडर का डेटा संभालना। क्या मॉडल प्रोवाइडर आपके इनपुट को स्टोर या उन पर ट्रेन करता है? यह वह अनुबंध है जिस पर आप हस्ताक्षर करते हैं और वह अकाउंट टियर है जो आप चुनते हैं। यह शर्तों और कॉन्फ़िगरेशन से हल होता है।
• रनटाइम एक्सफ़िल्ट्रेशन। क्या एजेंट को, ठीक उस वक़्त जब वह चल रहा हो, आपका डेटा कहीं ऐसी जगह भेजने के लिए बहलाया जा सकता है जहाँ उसे नहीं जाना चाहिए? यह आर्किटेक्चर से हल होता है, अनुबंध से नहीं।

सर्वे के आँकड़े बताते हैं कि खरीदार इसे महसूस तो करते हैं, भले ही वे इसका नाम न बता पाएँ। Cloudera के शोध में, जिसमें 14 देशों के लगभग 1,500 वरिष्ठ IT लीडर शामिल थे, 96% अगले साल में AI एजेंट का इस्तेमाल बढ़ाने की योजना रखते हैं, फिर भी 53% (आधे से ज़्यादा) डेटा प्राइवेसी को अपनी प्रमुख अड़चन बताते हैं। नीचे दी गई सात गलतियाँ ठीक वहीं हैं जहाँ यह डर एक असली लीक में बदल जाता है, और जहाँ इसका समाधान भी रहता है।

गलती 1: प्रोडक्शन एजेंट को कंज़्यूमर-टियर अकाउंट पर चलाना

यह सबसे सस्ती गलती है और इसे ठीक करना सबसे आसान। कोई किसी निजी ChatGPT या कंज़्यूमर Gemini अकाउंट से एक वर्कफ़्लो जोड़ देता है क्योंकि वह पहले से मौजूद है, और अब आपका बिज़नेस डेटा उन कंज़्यूमर शर्तों के अधीन है जो उसके लिए कभी बनी ही नहीं थीं।

कंज़्यूमर और एंटरप्राइज़ टियर के बीच फ़र्क बहुत साफ़ है। एंटरप्राइज़ की तरफ़, हर प्रोवाइडर में पैटर्न एक जैसा है: डिफ़ॉल्ट रूप से आपके डेटा पर कोई ट्रेनिंग नहीं, दुरुपयोग की निगरानी के लिए एक छोटा रिटेंशन समय, और माँगने पर मज़बूत विकल्प। OpenAI API दुरुपयोग की निगरानी के लिए डेटा को 30 दिन तक रखता है और फिर डिलीट कर देता है, और डिफ़ॉल्ट रूप से उस पर ट्रेन नहीं करता। 14 सितंबर 2025 से, Anthropic ने API लॉग रिटेंशन को 30 दिन से घटाकर 7 दिन कर दिया, और API के इनपुट तथा आउटपुट कभी भी ट्रेनिंग के लिए इस्तेमाल नहीं होते। Google का Vertex AI (एंटरप्राइज़ टियर) कॉन्फ़िगर किया जा सकता है, बिना किसी ट्रेनिंग उपयोग के। कंज़्यूमर की तरफ़ डिफ़ॉल्ट उलट जाते हैं: कंज़्यूमर ChatGPT बातचीत को अनिश्चित काल तक स्टोर करता है जब तक आप उसे डिलीट न करें, और कंज़्यूमर Gemini का रिटेंशन 36 महीने तक चलता है और प्रोडक्ट सुधारने में इस्तेमाल हो सकता है।

समाधान: हर प्रोडक्शन एजेंट को एक एंटरप्राइज़ API या बिज़नेस अकाउंट पर रखें, कभी किसी निजी लॉगिन पर नहीं। टेक्नोलॉजी एक जैसी ही है। शर्तें एक जैसी नहीं हैं, और शर्तें ही वह पूरा फ़र्क हैं जो ऐसे डेटा के बीच है जो नियंत्रित रहता है और ऐसे डेटा के बीच है जो चुपचाप ट्रेनिंग मटीरियल बन जाता है।

गलती 2: बहुत व्यापक परमिशन जो एजेंट विरासत में पाता है

सबसे आम रनटाइम लीक चालाक नहीं होता। किसी एजेंट को एक कर्मचारी की पहुँच थमा दी जाती है, या उससे भी बुरा, एक एडमिन की, ताकि तकनीकी रूप से वह सब कुछ देख सके जो वह व्यक्ति देख सकता है। फिर उससे एक ऐसा सवाल पूछा जाता है, या एक ऐसे सवाल में बहलाया जाता है, जो उसके काम से कहीं आगे तक पहुँच जाता है।

Microsoft का Cloud Adoption Framework इस नियम को साफ़-साफ़ बताता है: "एजेंट को सिर्फ़ उन खास डेटा स्रोतों तक पहुँच दें जो उनके काम के लिए ज़रूरी हैं। पूरे संगठन के डेटा तक व्यापक पहुँच न दें।" एक सपोर्ट एजेंट को आपके पेरोल सिस्टम की ज़रूरत नहीं। एक शेड्यूलिंग एजेंट को कस्टमर डेटाबेस की ज़रूरत नहीं। जब कोई एजेंट किसी व्यक्ति की ओर से काम करे, तो उसे उस व्यक्ति की पहचान सुरक्षित रूप से पास करके उसकी परमिशन विरासत में लेनी चाहिए, ताकि एक हेल्पडेस्क एजेंट किसी कर्मचारी को सिर्फ़ उसका अपना HR रिकॉर्ड दिखाए, सबका नहीं।

समाधान: हर एजेंट को उसकी अपनी पहचान दें, जो लीस्ट प्रिविलेज तक सीमित हो, और उससे काम कर रहे यूज़र की परमिशन विरासत में लिवाएँ, बजाय एक स्थायी व्यापक समूह को ढोने के। परीक्षा सीधी है। अगर कल एजेंट को बहलाया जाता है, तो नुकसान उसी संकरे दायरे तक सीमित रहेगा जो उसे दिया गया था, न कि उस सब तक जहाँ एक अति-अधिकार वाला अकाउंट पहुँच सकता था।

गलती 3: पब्लिक के सामने रहने वाले एजेंट जो आंतरिक डेटा से जुड़े हों

आपकी वेबसाइट पर मौजूद एक चैटबॉट और आंतरिक रिपोर्ट तैयार करने वाला एक एजेंट, ये दो अलग-अलग सुरक्षा दुनियाएँ हैं, और लीक ठीक उसी पल होता है जब कोई उन्हें एक ही बैकएंड साझा करने देता है। एक पब्लिक एजेंट इंटरनेट पर मौजूद किसी से भी इनपुट लेता है। अगर वही एजेंट आंतरिक बिज़नेस डेटा को भी क्वेरी कर सकता है, तो आपने पब्लिक वेब से सीधे अपने निजी सिस्टम तक एक दरवाज़ा बना दिया है।

Microsoft का फ़्रेमवर्क यहाँ सबसे सख़्त लकीर खींचता है: "पब्लिक के सामने रहने वाले एजेंट को आंतरिक बिज़नेस डेटा तक पहुँच नहीं होनी चाहिए।" गोपनीय और पब्लिक को एक भौतिक या तार्किक सीमा से अलग रखें (उनके उदाहरण में अलग-अलग "corp" और "online" मैनेजमेंट ग्रुप का इस्तेमाल होता है)। बात यह है कि सीमा संरचनात्मक होनी चाहिए, यह उम्मीद नहीं कि प्रॉम्प्ट टिका रहेगा।

समाधान: उन एजेंट के बीच जो अविश्वसनीय पब्लिक इनपुट लेते हैं और उन एजेंट के बीच जो गोपनीय डेटा को छूते हैं, एक असली सीमा रखें। अगर किसी एक ही एजेंट को सचमुच दोनों काम करने ही हों, तो वह सबसे ज़्यादा जोखिम वाला डिज़ाइन है जो आप चुन सकते हैं, और इसके लिए अगली गलतियों में बताए गए तिकड़ी-तोड़ने वाले नियंत्रण चाहिए, सिर्फ़ एक सावधान सिस्टम प्रॉम्प्ट नहीं।

गलती 4: घातक तिकड़ी को नज़रअंदाज़ करना

यही वह गलती है जो पहली तीन गलतियों को एक असली एक्सफ़िल्ट्रेशन में बदल देती है। Simon Willison, वह स्वतंत्र विशेषज्ञ जिन्होंने "प्रॉम्प्ट इंजेक्शन" शब्द गढ़ा, उन्होंने AI एजेंट के लिए "घातक तिकड़ी" को नाम दिया: तीन शर्तें जो जब साथ मिल जाती हैं, तो एक अकेला इंजेक्ट किया गया निर्देश आपका डेटा चुरा लेता है।

जब तीनों मौजूद हों, तो एक हमलावर अविश्वसनीय कंटेंट के अंदर एक निर्देश छिपा देता है। मॉडल, Willison के शब्दों में, "खुशी-खुशी उन सभी निर्देशों का पालन करेगा जो मॉडल तक पहुँचते हैं, चाहे वे उसके ऑपरेटर से आए हों या किसी और स्रोत से।" यह आपका निजी डेटा पढ़ता है और बाहर भेज देता है, और प्रॉम्प्ट में कुछ भी नहीं था जो उससे कहता कि ईमेल पर भरोसा मत करो।

खरी बात, और यही वजह है कि यह आर्किटेक्चर की समस्या है, प्रॉम्प्ट-इंजीनियरिंग की नहीं: "हम अब भी नहीं जानते कि इसे 100% भरोसे के साथ कैसे रोका जाए।" प्रलेखित हमले Microsoft 365 Copilot, GitHub के MCP सर्वर, और GitLab Duo पर हो चुके हैं। जनवरी 2026 के एक ही हफ़्ते में, चार AI प्रोडक्टिविटी टूल में अप्रत्यक्ष प्रॉम्प्ट-इंजेक्शन भेद्यताएँ उजागर हुईं, सभी वही तिकड़ी वाला पैटर्न।

समाधान: एक पैर तोड़ दें। बाहर भेजने के रास्ते को बंद कर दें ताकि चुराए गए डेटा के पास जाने की कोई जगह न रहे, या ऐसे एजेंट को जो अविश्वसनीय कंटेंट पढ़ता है, कभी एक ही संदर्भ में निजी-डेटा तक पहुँच भी न रखने दें। आपको हर इंजेक्शन को पकड़ने की वह अजीत लड़ाई जीतने की ज़रूरत नहीं है। आपको बस यह पक्का करना है कि एक सफल इंजेक्शन के पास भी बाहर निकलने का कोई रास्ता न हो।

गलती 5: EchoLeak को किसी और की समस्या मानना

एक असली घटना का नाम लेना ज़रूरी है, क्योंकि "घातक तिकड़ी" तब तक अमूर्त लगती है जब तक आप उसे अंजाम पाते हुए न देख लें। EchoLeak (CVE-2025-32711) Microsoft 365 Copilot पर एक ज़ीरो-क्लिक हमला था। एक हमलावर ने एक तैयार किया गया ईमेल भेजा। Copilot ने अपना सामान्य काम करते हुए उस ईमेल को प्रोसेस किया (अविश्वसनीय कंटेंट), उसके पास यूज़र के आंतरिक डेटा तक पहुँच थी (निजी डेटा), और जानकारी बाहर भेजने का एक रास्ता था (बाहरी संवाद)। छिपे निर्देश ने संवेदनशील-डेटा को बिना किसी यूज़र इंटरैक्शन के उजागर कर दिया। किसी ने कुछ भी क्लिक नहीं किया।

यहाँ गलती यह मान लेना है कि किसी लीक के लिए एक लापरवाह कर्मचारी चाहिए। EchoLeak को किसी की ज़रूरत नहीं थी। जो बचाव मायने रखता था वह "स्टाफ़ को फ़िशिंग पहचानने की ट्रेनिंग देना" नहीं था, क्योंकि किसी इंसान के पहचानने को कुछ था ही नहीं। बचाव आर्किटेक्चर वाला था: एक ऐसा एजेंट जो हमलावर-नियंत्रित कंटेंट को पढ़ भी न सके और डेटा बाहर भी न निकाल सके, उसे इस तरह आपके खिलाफ़ नहीं मोड़ा जा सकता।

समाधान: यह मानकर चलें कि ज़ीरो-क्लिक ही ख़तरे का मॉडल है, अपवाद नहीं। अगर आपका एजेंट कुछ भी ऐसा पढ़ता है जिसे कोई बाहरी व्यक्ति प्रभावित कर सकता है (ईमेल, वेब कंटेंट, अपलोड की गई फ़ाइलें, टिकट) और वह डेटा बाहर भी भेज सकता है, तो आपके पास एक EchoLeak जैसा छेद है, जब तक आप इन दोनों में से एक क्षमता को बंद न कर दें या भेजने के रास्ते पर कड़ी बाड़ न लगा दें।

गलती 6: कोई डेटा रेज़िडेंसी या रिटेंशन सीमा न होना

कुछ लीक नाटकीय एक्सफ़िल्ट्रेशन नहीं होते, वे धीमे बहाव होते हैं। डेटा किसी ऐसे क्षेत्र में स्टोर हो जाता है जिसके लिए आपने कभी सहमति नहीं दी, या लॉग में आपकी नीति की अनुमति से ज़्यादा समय तक पड़ा रहता है, सिर्फ़ इसलिए कि किसी ने सीमा तय ही नहीं की। Microsoft का फ़्रेमवर्क इसे मुख्य गवर्नेंस के रूप में सूचीबद्ध करता है: हर डेटा स्रोत, एजेंट रनटाइम और आउटपुट स्टोरेज का स्थान पहचानें, डेटा को उन क्षेत्रों या ऑन-प्रेम में रखें जो आपकी रेज़िडेंसी नीति से मेल खाते हैं, और उसे रेस्ट पर एन्क्रिप्टेड रखें।

राहत देने वाली ख़बर, जिसे शायद ही कोई लेख साफ़-साफ़ कहता है, यह है कि आप कितना कुछ तय कर सकते हैं। हर प्रोवाइडर में एंटरप्राइज़ पैटर्न है: डिफ़ॉल्ट रूप से कोई ट्रेनिंग नहीं, साथ में एक छोटी रिटेंशन अवधि, साथ में माँगने पर मज़बूत गारंटी। Anthropic योग्य एंटरप्राइज़ को एक Zero Data Retention (ZDR) समझौता देता है, जिसके तहत इनपुट और आउटपुट उससे ज़्यादा स्टोर नहीं किए जाते जितना दुरुपयोग की जाँच के लिए ज़रूरी हो। OpenAI एक तय किए गए समझौते के ज़रिए ZDR और डेटा रेज़िडेंसी देता है। दोनों आपको यह चुनने देते हैं कि डेटा कहाँ रहे। एक ओपन मॉडल को सेल्फ़-होस्ट करना (उदाहरण के लिए Ollama के साथ) डेटा को पूरी तरह स्थानीय रखता है, जिसमें किसी तीसरे पक्ष द्वारा कोई रिटेंशन नहीं होता।

समाधान: सीमा को लॉन्च से पहले तय करें और दस्तावेज़ में लिखें। कौन-सा क्षेत्र डेटा रखता है, लॉग कितने समय तक जीते हैं, क्या आपको ZDR की ज़रूरत है, और क्या संवेदनशील रिट्रीवल आपके अपने VPC या ऑन-प्रेम में चलना चाहिए। ZDR आमतौर पर सिर्फ़ API के लिए होता है और तय किया जाता है, और जब तक आप उसे जोड़ें नहीं, यह अपने आप हर प्रोडक्ट को कवर नहीं करता, इसलिए यह बारीकी मायने रखती है।

गलती 7: प्राइवेसी को एक ऐसी चेकलिस्ट मानना जिसे आप थमा देते हैं

आख़िरी गलती संरचनात्मक है। ज़्यादातर मार्गदर्शन, बेहतरीन Microsoft फ़्रेमवर्क समेत, यह मानकर चलता है कि आप एजेंट को खुद बनाएँगे और चलाएँगे, इसलिए यह आपको Entra पहचानों, Purview लेबलों और मैनेजमेंट ग्रुप का 3,000 शब्दों का ढेर थमा देता है। एक बड़ी IT टीम के लिए यही सही जवाब है। ज़्यादातर बिज़नेस के लिए यह एक ऐसी चेकलिस्ट है जिसे पूरी तरह लागू करने का न तो किसी के पास समय है और न ही विशेषज्ञ कौशल, इसलिए यह आधी-अधूरी रह जाती है, और ठीक उन्हीं ख़ालीपन में डेटा लीक होता है।

गलती यह है कि नियंत्रणों को एक ऐसी आर्किटेक्चर के बजाय दस्तावेज़ मान लिया जाता है जिसका कोई शुरू से आख़िर तक मालिक हो। एक चेकलिस्ट जो "गोपनीय डेटा को अलग रखें" और "बाहरी इंटिग्रेशन को सिर्फ़ भरोसेमंद MCP सर्वर तक सीमित रखें" को सूचीबद्ध करती है, वह उतनी ही अच्छी है जितना वह व्यक्ति जो इसे जोड़ता है, हर बाहरी संवाद को सत्यापित करता है, और एक ऐसी इंसिडेंट योजना खड़ी करता है जिससे कुछ गलत होने पर किसी एजेंट को तेज़ी से बंद किया जा सके।

समाधान: यह पक्का करें कि कोई एक पक्ष वाकई सीमा का मालिक हो, सिर्फ़ दस्तावेज़ का नहीं। या तो आप पूरे स्टैक को लागू करने और बनाए रखने की अंदरूनी क्षमता बनाएँ, या आपके पास एक ऐसा ऑपरेटर हो जो इन विफलता-तरीकों को आर्किटेक्चर से बाहर कर दे और उन्हें चलाए, एक प्रकाशित सीमा के साथ जिसकी ओर आप इशारा कर सकें। गलत बीच का रास्ता है नियंत्रणों की एक सूची और इन्हें टिकाए रखने के लिए कोई जवाबदेह नहीं।

सात गलतियाँ और समाधान कैसे एक कतार में बैठते हैं

यहाँ सातों एक ही जगह हैं, इस आधार पर छाँटे गए कि समाधान कोई अनुबंध है जिस पर आप हस्ताक्षर करते हैं या कोई आर्किटेक्चर है जिसे आप बनाते हैं। यह बँटवारा यह जानने का सबसे तेज़ तरीका है कि हर एक का मालिक कौन-सी टीम है।

ध्यान दें कि सात में से सिर्फ़ दो ही किसी अनुबंध से हल होते हैं। बाकी पाँच आर्किटेक्चर और स्वामित्व हैं, यानी वह हिस्सा जो बेस्ट प्रैक्टिस की कोई PDF आपके लिए नहीं कर सकती। यही ईमानदार वजह भी है कि आधिकारिक स्रोत एक ख़ालीपन छोड़ देते हैं: वे आपको बताते हैं कि क्या बनाना है, यह नहीं कि आपके खास सिस्टम के अंदर इसे सही तरीके से कौन बनाएगा।

जब सीमा सही ढंग से बनी हो, तो असल में कभी क्या बाहर नहीं जाता

सात गलतियाँ पढ़कर यह नतीजा निकालना आसान है कि AI एजेंट एक प्राइवेसी बारूदी सुरंग हैं। वे नहीं हैं, जब लकीर सोच-समझकर खींची जाए। एंटरप्राइज़ शर्तों पर, आपके इनपुट ट्रेनिंग डेटा नहीं हैं, और रिटेंशन दिनों का है, हमेशा का नहीं (Anthropic API के लिए 7, OpenAI के लिए 30, उसके बाद डिलीट)। ZDR के साथ, उन्हें दुरुपयोग की जाँच से आगे स्टोर नहीं किया जाता। डेटा रेज़िडेंसी तय होने पर, वे आपके क्षेत्र में ही रहते हैं। VPC या ऑन-प्रेम रिट्रीवल के साथ, संवेदनशील डेटा आपकी परिधि से कभी बाहर ही नहीं जाता। सीमा पर रिडैक्शन के साथ, जिन फ़ील्ड को कभी सफ़र नहीं करना चाहिए, उन्हें कुछ भी भेजे जाने से पहले हटा दिया जाता है। यूज़र की परमिशन विरासत में लेने वाली लीस्ट-प्रिविलेज स्कोपिंग के साथ, एजेंट कभी सिर्फ़ उतना ही पहुँच सकता है जितना तक काम कर रहा व्यक्ति पहले से पहुँच सकता था।

यह एक ठोस, बचाव-योग्य सीमा है, और इसे साफ़-साफ़ बता पाना ही पूरी बात है। ख़तरा कभी यह नहीं था कि मॉडल चुपके से आपकी कंपनी को सोख लेगा। यह ऊपर बताई गई सात कॉन्फ़िगरेशन और आर्किटेक्चर गलतियाँ हैं, जिनमें से हर एक को पहला एजेंट लाइव होने से पहले रोका जा सकता है।

यही वह काम है जो हम दूसरी कंपनियों के स्टैक के अंदर करते हैं: शर्तें चुनना, पहचानों को स्कोप करना, पब्लिक को गोपनीय से अलग करना, तिकड़ी को तोड़ना, और सीमा का मालिक बनना ताकि वह टिकी रहे। अगर आप चाहते हैं कि इन गलतियों को आपके एजेंट से, उनके किसी असली चीज़ को छूने से पहले ही, आर्किटेक्चर के ज़रिए बाहर कर दिया जाए, तो नीचे एक मुफ़्त कंसल्टेशन बुक करें और हम मिलकर आपकी सीमा का नक्शा बनाएँगे।