AI कोडिंग एजेंट प्राइवेसी: 5 मिथक, सच्चाई परखी

हर दिन दर्जनों स्कैम ईमेल आते हैं, जिनमें आपका असली पहला और आखिरी नाम लिखा होता है, और इस लीक की वजह कोई हैक हुआ डेटाबेस या लीक हुई मार्केटिंग लिस्ट नहीं है। यह वह User-Agent हेडर है जिसे आपका AI कोडिंग एजेंट उन वेब रिक्वेस्ट में लगा देता है जिन्हें आपने कभी जानबूझकर मंज़ूर नहीं किया। डेवलपर्स ने जब एक स्पैम लहर का सुराग Claude Code तक खोजा, तो यही पता चला: वेब फ़ेच और सर्च के दौरान यह टूल यूज़र के अकाउंट का ईमेल पता बाहर जाने वाली HTTP रिक्वेस्ट पर चिपका रहा था। Anthropic की अपनी सफ़ाई बग से भी ज़्यादा परेशान करने वाली है: उन्होंने अकाउंट ईमेल को मॉडल के context में डाला था ताकि वह सही @author टैग लिख सके, और मॉडल ने, एक मददगार छोटे बॉट की तरह, यह ईमेल हर उस वेबसाइट को देना शुरू कर दिया जो कॉन्टैक्ट माँगती थी। मैंने सालों से डेवलपर मशीनों पर चलने वाले टूल्स के नेटवर्क व्यवहार का ऑडिट किया है, और यह घटना एक लगभग परफ़ेक्ट सिखाने वाला केस है। तो आइए, एजेंटिक टूल्स की प्राइवेसी के बारे में मैं जो पाँच बातें सबसे ज़्यादा सुनता हूँ, उन्हें लेते हैं और हुई घटना से हर एक को परखते हैं।

मिथक 1: "मेरा कोडिंग एजेंट सिर्फ़ मॉडल प्रोवाइडर के API से बात करता है"

लगभग हर कोई इसी मानसिक मॉडल से शुरू करता है: एजेंट आपके टर्मिनल और Anthropic (या OpenAI, या जो भी हो) के सर्वरों के बीच एक चमकदार पाइप है। आपका कोड अंदर जाता है, टोकन बाहर आते हैं, और एकमात्र नेटवर्क एंडपॉइंट जो मायने रखता है वह है api.anthropic.com।

यह ग़लत है। एक आधुनिक एजेंटिक CLI एक जनरल-पर्पस HTTP क्लाइंट है, जिसे संयोग से एक लैंग्वेज मॉडल चलाता है। इसमें WebFetch टूल है जो किसी भी URL को लाता है। WebSearch टूल है जो सर्च इन्फ़्रास्ट्रक्चर को हिट करता है। और Bash टूल है, यानी curl, wget, pip install, npm install, git clone, और आपके सिस्टम पर मौजूद हर नेटवर्क-सक्षम बाइनरी। जब उसे डॉक्युमेंटेशन, पैकेज, changelog या SEC फ़ाइलिंग की ज़रूरत लगती है, तो वह जहाँ उसे लगता है वहाँ से उसे ले आता है। हर ऐसी रिक्वेस्ट आपके IP एड्रेस से निकलती है, आपके कॉर्पोरेट नेटवर्क पर, और उन हेडरों के साथ जो मॉडल ने उस सुबह लिखने का फ़ैसला किया।

और मॉडल रचनात्मक भी हो सकता है। ईमेल वाली कहानी सामने आने के बाद, एक इंजीनियर ने अपने वेब सर्वर के लॉग चेक किए और सबएजेंट्स की ऐसी रिक्वेस्ट मिलीं जिनके User-Agent स्ट्रिंग कुछ ऐसे थे: company-helm-research/1.0 (Claude Code agent run by [name], [company] platform team; docs lookup)। इनमें उनकी कंपनी का नाम और जिस GitHub रिपॉज़िटरी पर वे काम कर रहे थे, वह भी था। एजेंट कोई कॉन्फ़िग वैल्यू लीक नहीं कर रहा था; वह context से पहचान वाले हेडर रच रहा था, जैसे कोई मददगार इंटर्न हर कोल्ड ईमेल पर अपना पूरा नाम, टीम और प्रोजेक्ट लिख दे। अगर आप देखना चाहते हैं कि आर्किटेक्चर इसे इतना आसान क्यों बनाता है, तो हमने इस पर लिखा है कि एजेंटिक कोडिंग CLI कैसे बने होते हैं। छोटे में, लूप, context और टूल सेट उतने ही शक्तिशाली हैं जितना परेशानी पैदा करने के लिए ज़रूरी है।

सही मानसिक मॉडल यह है: आपका एजेंट एक जूनियर कर्मचारी है जिसके पास कंपनी का लैपटॉप, कॉर्पोरेट नेटवर्क कनेक्शन और आपके बिज़नेस कार्डों का ढेर है। उसके context में जो भी है, वह किसी भी टूल के ज़रिए इमारत से बाहर जा सकता है।

मिथक 2: "User-Agent में कॉन्टैक्ट ईमेल डालना तो बस अच्छे बॉट शिष्टाचार की बात है"

इसमें थोड़ी सच्चाई है, और यही इसे ख़तरनाक बनाता है। एक असली परंपरा है कि अच्छे व्यवहार वाले क्रॉलर खुद की पहचान बताएँ और कॉन्टैक्ट दें। कुछ सेवाएँ इसे सख़्ती से लागू करती हैं। उदाहरण के लिए SEC की EDGAR API सामान्य curl User-Agent वाली रिक्वेस्ट को सीधे ठुकरा देती है और घोषित कॉन्टैक्ट माँगती है। यह आप दस सेकंड में खुद जाँच सकते हैं:

U='https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/Assets.json'
curl -s -o /dev/null -w '%{http_code}  default UA\n' "$U"
# 403  default UA
curl -s -o /dev/null -w '%{http_code}  declared contact\n' \
-A 'Acme Research admin@acme-research.example' "$U"
# 200  declared contact

तो जो मॉडल सीख गया है कि "कुछ API User-Agent में कॉन्टैक्ट पता चाहते हैं", वह भ्रम में नहीं है। वह असली इंटरनेट शिष्टाचार का पैटर्न पकड़ रहा है। और अगर उस मॉडल के context में आपका अकाउंट ईमेल पड़ा है, तो उसके पास बताने के लिए बस एक कॉन्टैक्ट पता है। Anthropic इंजीनियर, जिन्होंने घटना समझाई, ने यही कहा: कुछ साइटें एजेंट से कॉन्टैक्ट माँगती हैं, और Claude कभी-कभी वही ईमेल दे देता था जो उसके पास था।

यहीं मिथक टूटता है। परंपरा यह है कि बॉट ऑपरेटर अपना कॉन्टैक्ट दे, यानी क्रॉलर चलाने वाली इकाई, ताकि परेशान सिस्टम एडमिन किसी जवाबदेह व्यक्ति तक पहुँच सके। Anthropic का क्रॉलर खुद को Anthropic बताता है। Google का Google। लेकिन जब आपका एजेंट कोई पेज लाता है, तो ऑपरेटर कॉन्टैक्ट टूल बनाने वाली कंपनी का सपोर्ट URL होना चाहिए, या वह पता जो आपने जानबूझकर कॉन्फ़िगर किया हो। वह निजी अकाउंट ईमेल नहीं जिससे सब्सक्रिप्शन का भुगतान किया गया। RFC 9110 का User-Agent पर मार्गदर्शन साफ़ कहता है कि बेवजह विस्तृत पहचान वाली जानकारी से बचें, और मैं जितने प्राइवेसी इंजीनियरों को जानता हूँ, वे हेडर में बिना माँगी PII को सीधा दोष मानते हैं। बॉट शिष्टाचार कभी उस इंसान को बेनक़ाब करने के लिए नहीं बना था जो बॉट के पीछे बैठा है।

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

मिथक 3: "परमिशन प्रॉम्प्ट और सैंडबॉक्स मेरी पहचान को सुरक्षित रखते हैं"

हर एजेंटिक टूल किसी न किसी रूप का कंसेंट UX देता है: एजेंट कमांड चलाने से पहले पूछता है, दिखाता है कि वह कौन सी फ़ाइलें पढ़ रहा है, और शायद वेब एक्सेस को प्रति-डोमेन मंज़ूरी के पीछे रखता है। इससे एक मज़बूत धारणा बनती है। एक डेवलपर ने इसे यूँ बताया कि "LLM के पास सिर्फ़ वही है जो प्रोजेक्ट में साफ़ तौर पर जोड़ा गया हो।" यह धारणा ग़लत है, और ईमेल घटना इसे दो बार साबित करती है।

पहली बात, परमिशन सिस्टम कौन सा टूल चलेगा इस पर नियंत्रण रखते हैं, उन टूल रिक्वेस्ट के अंदर मॉडल क्या लिखता है इस पर नहीं। "हाँ, यह URL फ़ेच करो" को मंज़ूरी देने से आपको उस फ़ेच के लिए मॉडल द्वारा रचे गए हेडरों के बारे में कुछ पता नहीं चलता। curl चलाने वाली Bash कॉल को मंज़ूरी देने से और भी कम पता चलता है, क्योंकि कमांड स्ट्रिंग स्क्रीन से गुज़र जाती है और -A फ़्लैग कोई नहीं पढ़ता। दूसरी बात, परमिशन UI हर एक्शन पर चलता है, जबकि लीक context की एक विशेषता है। एक बार आपका अकाउंट ईमेल सिस्टम context में डाल दिया गया, जिसे यूज़र ने कभी देखा नहीं और जिससे बाहर निकल नहीं सकते थे, तो वह पूरे सेशन में हर टूल कॉल, हर सबएजेंट, हर curl वन-लाइनर के लिए उपलब्ध हो गया। सैंडबॉक्स की दीवार फ़ाइल सिस्टम के चारों ओर खींची गई थी, और डेटा बाहर जाने का रास्ता मॉडल की अपनी टेक्स्ट जनरेशन था।

इस हिस्से पर मैं साफ़ बात करना चाहता हूँ, क्योंकि यह किसी एक वेंडर के बग से कहीं आगे तक लागू होता है: एजेंट के context में जो भी है, वह एक विश्वसनीय लगने वाले निर्देश भर की दूरी पर आपकी मशीन से बाहर जा सकता है। API कुंजियाँ, इंटरनल होस्टनेम, फ़ाइल की सामग्री, आपका नाम, आपकी कंपनी, आपका ईमेल। जब मॉडल खुद डेटा बाहर ले जाने का चैनल बन जाए, तो टूल लेयर पर कंटेनमेंट मदद नहीं करता। इसीलिए मैं पहले भी तर्क दे चुका हूँ कि AI एजेंट्स के लिए कंटेनमेंट और मॉनिटरिंग अलग-अलग समस्याएँ सुलझाते हैं, और आपको पता होना चाहिए कि आपको असल में कौन सी मिल रही है। परमिशन डायलॉग दिखावे का मॉनिटरिंग है, कंट्रोल नहीं। वह आपको एक्शन दिखाता है; वह एक्शन के पैरामीटर में छिपा इरादा नहीं दिखा सकता।

निष्कर्ष: जैसा भेजा गया था, सैंडबॉक्स ने आपकी फ़ाइलें सुरक्षित रखीं। आपकी पहचान के लिए उसने कुछ नहीं किया, क्योंकि आपकी पहचान कच्चे माल की तरह मॉडल को सौंप दी गई थी।

मिथक 4: "यह बस एक सेटिंग है, टॉगल ऑन करो और सुरक्षित हो जाओ"

जब मामला सामने आया, तो मूल रिपोर्टर की माँग साफ़ थी: यह opt-out सेटिंग नहीं होनी चाहिए, इसे हार्नेस से पूरी तरह हटाना चाहिए। यह सहज प्रवृत्ति सही है, और जिस तरह फ़िक्स आया, वह समझाता है कि इस तरह की समस्या के लिए सेटिंग्स गलत प्राइमिटिव क्यों हैं।

सुधार दो हिस्सों में आया। पहला, एक बिल्ट-इन प्लगइन (cc-plugin-privacy, v2.1.317 से डिफ़ॉल्ट रूप से चालू) जो इस व्यवहार को नियतात्मक रूप से रोकता है। यह एक कठोर जाँच है, मॉडल को कोई सुझाव नहीं। दूसरा, और ज़्यादा महत्वपूर्ण, Anthropic ने अकाउंट ईमेल को मॉडल के context से पूरी तरह हटा दिया। यहाँ महत्व के क्रम पर ध्यान दें। प्लगइन आउटपुट पर एक फ़िल्टर है; context से ईमेल हटाना क्षमता को ही हटाना है। फ़िल्टर चूक सकता है। जिस मॉडल को आपका ईमेल पता ही नहीं पता, वह हेडर कितनी भी रचनात्मकता से लिखे, उसे लीक नहीं कर सकता।

डेटा एक्सपोज़र से प्रॉम्प्ट लिखकर बाहर नहीं निकला जा सकता। अगर मॉडल उसे देख सकता है, तो मॉडल उसे उत्सर्जित भी कर सकता है। एकमात्र भरोसेमंद रीडैक्शन है घटाना।

यह पैटर्न एजेंट टूलिंग में मैं बार-बार देखता हूँ, और यह उस बात से मेल खाता है जो हम उन API क्लाइंट्स के ऑडिट में कवर कर चुके हैं जो क्रेडेंशियल वॉल्ट का भी काम करते हैं। संवेदनशील सामग्री सबसे सुविधाजनक जगह (context, environment, कॉन्फ़िग फ़ाइल) में ठूँस दी जाती है, क्योंकि कोई फ़ीचर उसे एक बार चाहता था, और फिर वह हर जगह साथ चलती रहती है। टेलीमेट्री टॉगल और प्राइवेसी सेटिंग्स वह सँभालती हैं जो वेंडर ने इकट्ठा करने का फ़ैसला किया। वे इस बारे में कुछ नहीं कहतीं कि मॉडल को दी गई सामग्री से वह क्या अंदाज़ा लगाकर कर सकता है। सेटिंग्स पसंद के लिए होती हैं। प्राइवेसी के लिए नियतात्मक नियंत्रण और डेटा न्यूनीकरण चाहिए। अगर कोई वेंडर दूसरी को समस्या का हल बताकर पहली थमाए, तो पलटकर सवाल कीजिए।

मिथक 5: "वेंडर ने पैच कर दिया, अब चिंता छोड़ सकता हूँ"

श्रेय जहाँ बनता है: यहाँ प्रतिक्रिया तेज़ थी, इंजीनियरिंग स्पष्टीकरण ईमानदार था, और फ़िक्स ने लक्षण नहीं बल्कि मूल कारण पर वार किया। लेकिन "पैच हो गया" एक विशिष्ट संस्करण में एक ख़ास व्यवहार के बारे में दावा है। समस्या का वर्ग, यानी एजेंटिक टूल्स का पहचान वाली सामग्री को अनजान एंडपॉइंट्स तक भेजना, संरचनात्मक है, और यह इस टूल या किसी और में दोबारा होगा। कई यूज़र्स ने बताया कि यह Claude Code के context में बिना बुलाए अकाउंट पहचान दिखने का पहला मौका भी नहीं था; कम से कम दूसरा था।

इसके नीचे एक और कठिन सच्चाई है: क्लाइंट की तरफ़ से लीक की अनुपस्थिति को पूरी तरह सत्यापित नहीं किया जा सकता। एक लगनशील यूज़र ने फ़िक्स्ड वर्ज़न पर मैन-इन-द-मिडल प्रॉक्सी चलाई और पुष्टि की कि WebFetch टूल के ज़रिए उनकी मशीन से कुछ भी पहचानने योग्य बाहर नहीं गया। बढ़िया काम, और सही सहज प्रवृत्ति। लेकिन जैसा उन्होंने नोट किया, पहचान सर्वर-साइड पर भी हो सकती है: आपका क्लाइंट वेंडर के API को गुमनाम रिक्वेस्ट भेजता है, और वेंडर की तरफ़ का इन्फ़्रास्ट्रक्चर आपकी जानकारी के साथ तीसरे पक्षों तक पहुँचा देता है। उस बिंदु पर कोई लोकल पैकेट इंस्पेक्शन उसे नहीं देख पाएगा। आप फिर वेंडर पर भरोसा करने की स्थिति में लौट आते हैं, और यही वह स्थिति है जिसे इस घटना ने असहज साबित किया।

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

अपने एजेंट का नेटवर्क ट्रैफ़िक खुद कैसे ऑडिट करें

इसके लिए किसी सिक्योरिटी टीम की ज़रूरत नहीं। एक दोपहर और कुछ मानक टूल्स आपको किसी भी प्राइवेसी पॉलिसी से ज़्यादा बता देंगे कि आपका एजेंट क्या करता है।

1. ट्रैफ़िक इंटरसेप्ट करें। एजेंट को mitmproxy की ओर इंगित करें और उसे एक असली वर्क सेशन चलाने दें। Node-based CLI आम तौर पर प्रॉक्सी एनवायरनमेंट वेरिएबल का सम्मान करते हैं, एक बार वे आपके CA पर भरोसा कर लें:

mitmdump --listen-port 8080 -w agent-flows.mitm &
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem
# Now run your agent and do normal work.
# Afterwards, search every captured request for your identifiers:
mitmdump -nr agent-flows.mitm \
--flows \
| grep -iE 'you@company\.com|YourName|your-org'

सिर्फ़ अपना ईमेल नहीं, और भी खोजें: आपका नाम, कंपनी, संगठन का GitHub slug, इंटरनल होस्टनेम, रिपॉज़िटरी के नाम। सबएजेंट के लॉग याद रखें। मॉडल सिर्फ़ पहचान दोहरा नहीं रहा था, बल्कि उसे रच भी रहा था, इसलिए टुकड़ों को भी खोजें।

2. अपने इन्फ़्रास्ट्रक्चर के लॉग जाँचें। अगर आप कोई वेब सर्विस चलाते हैं, तो उसके एक्सेस लॉग में एजेंट के User-Agent स्ट्रिंग खोजें। मिथक 1 में रचे गए हेडर इसी तरह खोजे गए थे। इसमें कोई खर्च नहीं आता, और अक्सर वह सबएजेंट ट्रैफ़िक सामने लाता है जो लोकल कैप्चर से छूट जाता है।

3. एग्रेस सीमित करें। सबसे मज़बूत नियंत्रण है पूरी श्रेणी के लीक को असंभव बनाना। एजेंट को किसी कंटेनर या VM में चलाएँ जिसकी नेटवर्क पॉलिसी सिर्फ़ उन एंडपॉइंट्स की अनुमति दे जिनकी उसे वैध ज़रूरत है: मॉडल API, आपके पैकेज रजिस्ट्री, शायद GitHub। Docker के साथ यह एक कस्टम नेटवर्क और एग्रेस फ़ायरवॉल है; Mac पर Little Snitch या Lulu प्रति-प्रोसेस नियम देते हैं। अगर एजेंट अपने सैंडबॉक्स से मनमाने वेबसाइटों तक पहुँच नहीं सकता, तो वह आपकी पहचान भी मनमाने वेबसाइटों को नहीं दे सकता। उसे चीज़ें लाने के लिए आपसे पूछना होगा, जो असुविधा है, और असुविधा ही तो मकसद है।

4. टूल को कम से कम जानने दें। टूल अकाउंट के लिए एक समर्पित, कम-मूल्य वाला ईमेल इस्तेमाल करें, अपना मुख्य कार्य पता नहीं। एजेंट जो ग्लोबल कॉन्फ़िग फ़ाइलें पढ़ता है, उनसे पहचान वाले विवरण हटाएँ (~/.gitconfig एक आम उदाहरण है जिसे एजेंट उठाते हैं)। अगर टूल सपोर्ट करता है, तो उसे अलग OS यूज़र के तहत अपनी होम डायरेक्टरी के साथ चलाएँ। हर बार, घटाना छानने से बेहतर है।

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

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