आपके AI कोडिंग सहायक ने अभी-अभी आपका वॉलेट पढ़ लिया

अपना AI कोडिंग सहायक खोलिए। आपके एक भी अक्षर टाइप करने से पहले वह आपकी परियोजना निर्देशिका पहले ही पढ़ चुका होता है। आपकी .env फ़ाइल। आपकी API कुंजियाँ। आपका डेटाबेस पासवर्ड। आपकी Stripe गुप्त कुंजी।

आपने उससे ऐसा नहीं कहा था। आपने अनुमति नहीं दी थी। यह एक विशेषता है, कोई त्रुटि नहीं — उपकरण को उपयोगी बनने के लिए परियोजना का संदर्भ चाहिए। इसलिए वह वह सब कुछ पढ़ता है जो एक डेवलपर पढ़ सकता है।

और एक डेवलपर सब कुछ पढ़ सकता है।

संक्षिप्त संस्करण

इस सप्ताह एक पोस्ट खूब चली, जिसे एक डेवलपर के आंतरिक मनोवचन के रूप में लिखा गया था:

> Claude Code खोलो। आपके कुछ भी टाइप करने से पहले आपकी .env पढ़ ली जाती है। आपकी API कुंजियाँ अब चैट में हैं। आप CLAUDE.md में "don't read .env" जोड़ते हो। काम नहीं करता।

उस पोस्ट को 3,80,000 लोगों ने देखा। 2,700 लोगों ने इसे बुकमार्क किया। इसलिए नहीं कि यह कोई खबर थी — इसलिए कि यह एक दर्पण था।

उसे पढ़ने वाले हर डेवलपर के मन में एक ही विचार आया: यह तो मेरा ही सेटअप है।

निर्देश काम नहीं करते

लोगों ने सबसे पहले नियम लिखने की कोशिश की। "Do not read .env files." CLAUDE.md में, AGENTS.md में, सिस्टम प्रॉम्प्ट में। सीधे, स्पष्ट निषेध।

उपकरण ने फिर भी वे फ़ाइलें पढ़ लीं।

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

एक शोधकर्ता ने पाया कि फ़ाइल-स्तरीय अस्वीकृति नियमों को भी कस्टम स्क्रिप्ट या पाइप श्रृंखलाओं के ज़रिए दरकिनार किया जा सकता है। एक अन्य ने पाया कि उनके प्रॉक्सी बिल बढ़ गए क्योंकि उनकी HTTP_PROXY साख स्वतः लोड होकर उपयोग में आ रही थी।

आपकी .env में पड़ा धन

लोग इसे गोपनीयता का मुद्दा मानते हैं। यह वित्तीय मुद्दा है।

किसी सामान्य उत्पादन परियोजना की .env फ़ाइल खोलिए:

OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
DATABASE_URL=postgresql://user:pass@...

वह OpenAI कुंजी बिना खर्च सीमा और बिना PIN वाला क्रेडिट कार्ड है। उस स्ट्रिंग वाला कोई भी व्यक्ति रातोंरात 40,000 डॉलर के API कॉल चला सकता है। Stripe कुंजी से रिफ़ंड जारी किए जा सकते हैं, शुल्क लगाए जा सकते हैं, ग्राहकों के भुगतान डेटा तक पहुँचा जा सकता है। AWS साख — IAM नीति पर निर्भर, जो लगभग तय तौर पर बहुत व्यापक होती है — GPU इंस्टेंस चला सकती है, S3 बकेट तक पहुँच सकती है, या बुनियादी ढाँचा मिटा सकती है।

यह पासवर्ड की सूची नहीं है। यह वॉलेट की सूची है, जिनमें से हर एक में अलग शेष है और कोई ताला नहीं।

फ़ुटपाथ पर पड़े 2.9 करोड़ वॉलेट

GitGuardian की नवीनतम रिपोर्ट के अनुसार 2025 में सार्वजनिक GitHub कमिट्स में 2.86 करोड़ गुप्त कुंजियाँ उजागर हुईं। पिछले वर्ष की तुलना में 34% की वृद्धि, और उनके द्वारा अब तक मापी गई सबसे बड़ी वार्षिक बढ़ोतरी।

AI-विशिष्ट आँकड़े और भी बुरे हैं। 12 लाख AI-सेवा गुप्त कुंजियाँ उजागर — वर्ष-दर-वर्ष 81% की छलांग। AI कोडिंग उपकरणों के सह-लेखक वाले कमिट्स से गुप्त कुंजियाँ सामान्य दर से लगभग दोगुनी रफ़्तार से लीक हुईं। और MCP विन्यास फ़ाइलों में 24,000 अद्वितीय गुप्त कुंजियाँ मिलीं — वही ढाँचा जो AI एजेंटों को बाहरी सेवाओं से जोड़ता है।

सबसे तेज़ी से बढ़ने वाली लीक गुप्त कुंजी श्रेणियों की शीर्ष पंद्रह में से बारह AI सेवाएँ थीं। डेटाबेस नहीं। क्लाउड प्रदाता नहीं। AI सेवाएँ।

जिन उपकरणों से हम तेज़ी से कोड लिख रहे हैं, वे उन प्रणालियों की कुंजियाँ लीक कर रहे हैं जिनसे वह कोड जुड़ता है।

असली समस्या

वह greentext थ्रेड लिखने वाले डेवलपर ने अंत में एक व्यावहारिक समाधान दिया — एक settings.json विन्यास जो फ़ाइल पठन को रोकता है। वह काम करता है। अभी के लिए, उस उपकरण के लिए।

लेकिन असली समस्या Claude Code या Cursor या Copilot नहीं है। असली समस्या यह है कि गुप्त कुंजियाँ फ़ाइलें हैं।

एक .env फ़ाइल डिस्क पर पड़ा सादा पाठ दस्तावेज़ है, जिसे आपके उपयोगकर्ता के रूप में चलने वाली कोई भी प्रक्रिया पढ़ सकती है। AI कोडिंग उपकरणों से पहले, आपकी परियोजना पढ़ने वाली प्रक्रियाएँ git, npm, node, आपका एडिटर थीं। आपने उन पर अंतर्निहित रूप से भरोसा किया। आपने इस बारे में नहीं सोचा कि आपकी गुप्त कुंजियाँ उजागर होने से एक cat कमांड दूर हैं।

AI कोडिंग उपकरणों ने अंतर्निहित को स्पष्ट कर दिया। वे आपकी परियोजना उसी तरह पढ़ते हैं जैसे हर दूसरा उपकरण पढ़ता है — बस वे संदर्भ को कहीं ऐसी जगह भेजते हैं जहाँ आप उसे देख सकें।

आपकी CI पाइपलाइन भी .env फ़ाइलें पढ़ती है। आपका टेस्ट रनर पढ़ता है। आपका लिंटर पढ़ता है। आपका Docker बिल्ड पढ़ता है। इनमें से किसी ने भी अनुमति नहीं माँगी। आपने ध्यान नहीं दिया क्योंकि उन्होंने आपको अपनी खोज का चैट प्रतिलेख नहीं दिखाया।

नीचे का ढाँचा

2022 में लीक हुई गुप्त कुंजियों का 70% आज भी सक्रिय है। बदला नहीं गया। रद्द नहीं किया गया। तीन साल बाद भी काम कर रहा है, पहुँच दे रहा है।

यही असली आँकड़ा है। 2.9 करोड़ लीक नहीं — 70% कभी ठीक नहीं किए गए। क्योंकि कुंजी बदलने का अर्थ है हर उस प्रणाली को ढूँढ़ना जो उसका उपयोग करती है, हर तैनाती को अद्यतन करना, हर एकीकरण का परीक्षण करना। कुंजी एक बार बनाई गई, .env फ़ाइल में चिपका दी गई, और फिर कभी सोचा नहीं गया। उसके लीक होने की लागत तात्कालिक है। लीक ठीक करने की लागत असीमित है।

इसलिए अधिकांश संगठन इसे ठीक नहीं करते। वे कर नहीं सकते। उन्हें नहीं पता कि कौन-सी कुंजियाँ कहाँ हैं, कौन-सी अब भी सक्रिय हैं, कौन-सी अन्य डेवलपरों द्वारा अन्य मशीनों की अन्य .env फ़ाइलों में कॉपी की जा चुकी हैं — जिन्हें शुक्रवार दोपहर को कोई सुविधा काम करानी थी।

इसका वास्तव में क्या अर्थ है

हर .env फ़ाइल एक शर्त है। इस बात की शर्त कि कोई अनधिकृत प्रक्रिया उसे कभी नहीं पढ़ेगी। इस बात की शर्त कि कोई उपकरण उसे कभी किसी अनपेक्षित जगह नहीं भेजेगा। इस बात की शर्त कि कोई डेवलपर उसे कभी ग़लती से कमिट नहीं करेगा।

पिछले वर्ष 2.9 करोड़ बार किसी ने वह शर्त हारी। अकेले सार्वजनिक GitHub पर। निजी रिपॉज़िटरी — जहाँ GitGuardian ने 35% रिपॉज़िटरी में गुप्त कुंजियाँ पाईं — गिनी भी नहीं गई हैं।

समाधान कोई settings.json नियम नहीं है। समाधान कोई .gitignore प्रविष्टि नहीं है। समाधान अपने निर्देश फ़ाइल में बड़े अक्षरों में "DO NOT READ .ENV" लिखना नहीं है।

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

अगर गुप्त कुंजी डिस्क पर है, तो वह पढ़ी जाएगी। एकमात्र प्रश्न यह है कि कब, और किसके द्वारा।

---

स्रोत

• GitGuardian — State of Secrets Sprawl 2025 — 2.86 करोड़ गुप्त कुंजियाँ लीक, AI-सेवा साख के रुझान, सुधार आँकड़े
• GitGuardian: 29M Leaked Secrets — Why AI Agent Credentials Are Out of Control — Help Net Security की रिपोर्टिंग, AI-विशिष्ट विवरण सहित
• Claude Code Can Consume, Transmit, and Compromise Your .env Files — Martin Paul Eve का लेख, CLAUDE.md के निषेधों के विफल होने पर
• Claude Code Automatically Loads .env Secrets, Without Telling You — Knostic का तकनीकी विश्लेषण, स्वचालित गुप्त कुंजी लोडिंग पर
• From .env to Leakage: Mishandling of Secrets by Coding Agents — Knostic का व्यापक विश्लेषण, Claude और Cursor दोनों में
• @zodchiii on X — वह चर्चित पोस्ट जिसने इस लेख को प्रेरित किया (3.8 लाख व्यू, 2.7 हज़ार बुकमार्क)