AI के हाथ में चाबी देने से पहले। शुरुआती सबसे पहले निभाएँ ये 5 "हादसा न होने देने" वाले उपाय

“इस प्रोजेक्ट को ज़रा सरसरी तौर पर छाँट देना।”

हल्के मन से इतना टाइप करके, मैं कॉफ़ी बनाने चला गया। लौटा तो टर्मिनल rm -rf चलाने से ठीक एक क़दम पहले रुका हुआ था। और मेरी उँगली, अनजाने में, मंज़ूरी वाले बटन की तरफ़ बढ़ने ही वाली थी।

उस पल अगर “हाँ” दबा दिया होता, तो .env और सेटिंग फ़ाइलें, सब एक साथ मिट जातीं।

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

यह लेख बस शुरुआती के सबसे पहले निभाने लायक सुरक्षा उपायों तक सिमटा है। मुश्किल बातें बाद के लिए। पहले निभाने वाले पाँच, मेरी अपनी ग़लतियों के साथ, आसान भाषा में।

आख़िर इतना ख़तरनाक है क्या?

आम टेक्स्ट एडिटर बस अक्षर दिखाता है। पर Claude Code अलग है। आपके कंप्यूटर के अंदर, यह ऐसा सब “कर डालने” लायक औज़ार है:

• फ़ाइल पढ़ना, लिखना, मिटाना
• टर्मिनल की कमांड चलाना (rm भी कर सकता है)
• नेट पर पहुँचकर, बाहर की सेवा पर पोस्ट करना

और यह सब, आपके “हाँ” मंज़ूर करने पर चलता है। दिक्कत यह है कि मंज़ूरी वाला बटन दर्जनों बार दबाते-दबाते, अंदर देखना बंद हो जाता है। “हाँ-हाँ, ठीक है” की लय में सवार होते ही, ख़तरनाक काम सरककर निकल जाता है।

इसलिए सुरक्षा उपाय का मतलब “ख़याल रखना” नहीं है। ख़याल न भी रखें तो हादसा न हो, ऐसा इंतज़ाम पहले बना लेना। एक-एक करके देखते हैं।

ऐसी जगहों पर कलेजा मुँह को आता है (तीन उदाहरण)

शुरुआती से अक्सर हो जाने वाली “ख़तरनाक जगहें” बस तीन। इनमें कोई ख़ास बात नहीं की जा रही।

जगह 1: एरर ठीक करवाने के लिए, पूरी लॉग चिपका देना

“यह एरर ठीक कर दो” कहते वक़्त, टर्मिनल में निकले अक्षर पूरे कॉपी-पेस्ट कर देते हैं ना? पर उस लॉग में, DATABASE_URL=postgresql://user:असली-पासवर्ड@... जैसी लाइन छिपी हो सकती है। AI को देना समझा था, पर बातचीत के इतिहास और लॉग में, नंगा पासवर्ड बचा रह जाता है।

जगह 2: “सब अपने-आप” मोड में छोड़ देना

मंज़ूरी झंझट लगती है, इसलिए बिना पूछे कुछ भी चला सकने वाला मोड लगाकर, सीट छोड़ देना। AI भलाई की नीयत से git push --force ठोक देता है, और टीम के किसी का काम उड़ जाता है। बुरी नीयत शून्य। पर नतीजा बेहद बुरा।

जगह 3: मिलते-जुलते नाम वाले DB गड्डमड्ड कर देना

myapp_dev और myapp_prod। एक अक्षर का फ़र्क़। “DB का पुराना डेटा मिटा दो” बस इतना कहकर, AI ने किससे जुड़ा है यह जाँचा ही नहीं, तो—मिटने वाला असली ग्राहकों का डेटा हो सकता है।

तीनों में एक बात साझा है—इंसान के “चूकने” के पल पर AI पूरी रफ़्तार से अमल कर देता है। तो चूक भी जाएँ तो भी कुछ न बिगड़े, ऐसा रख दीजिए। यही उपाय है।

मेरी अपनी तीन ग़लतियाँ

रौब से लिख रहा हूँ, पर मैं भी शुरू में हादसों से भरा था। ईमानदारी से तीन क़बूल करता हूँ।

पहली। Qiita पर अपने-आप पोस्ट करने वाला इंतज़ाम बनाते वक़्त, टोकन सीधे प्रॉम्प्ट में चिपका दिया। “QIITA_TOKEN=xxxx से पोस्ट कर दो” यूँ। चल गया तो मैं ख़ुश था, पर बाद में पता चला। वह स्ट्रिंग बातचीत की लॉग में, और पर्दे के पीछे चलने वाले छोटे AI (सब-एजेंट) के इतिहास में भी बची रहती है। हड़बड़ाकर टोकन दोबारा बनाया। अब सोचूँ तो पसीने छूट जाते हैं।

दूसरी। जाँच के लिए “.env की सामग्री देखो” कह दिया। AI ने सीधे-सादे ढंग से सब पढ़कर सुना दिया। API key भी, DB का पासवर्ड भी, सब स्क्रीन और लॉग में। पढ़वाने के पल ही, वह “लीक” हो जाने के बराबर है। .env तो मैं इंसान ख़ुद भी आम तौर पर नहीं खोलता।

तीसरी। शौक़िया प्रोजेक्ट की ढीली सेटिंग, काम वाली रिपॉज़िटरी में कॉपी कर दी। नतीजा—काम की तरफ़ जो “असली में लिखना मना” होना चाहिए था, वह शौक़ वाली ढिलाई से लिख गया। हादसा होने से पहले भनक लग गई, पर सेटिंग दोबारा इस्तेमाल करना वाक़ई ख़तरनाक है।

ये सब, ज्ञान न होने से कम और इंतज़ाम से न रोकने से ज़्यादा हुए। असली मुद्दा यहीं से।

निभाने हैं बस ये 5। क्रम से कीजिए

उपाय 1: API key को “कोड के बाहर” रखिए

सबसे अहम। API key और टोकन, कभी कोड या प्रॉम्प्ट में सीधे मत लिखिए। .env नाम की एक ख़ास फ़ाइल में अलग-थलग रखिए, और उसे Git के दायरे से बाहर कर दीजिए। बस इतने से लीक का ज़्यादातर हिस्सा रुक जाता है।

पहले, जो नहीं करना है उसका उदाहरण।

// ग़लत: सोर्स कोड में सीधे लिखा (कमिट किया तो वहीं ख़त्म)
const client = new Anthropic({ apiKey: "असली API key सीधे चिपकाना" });

// ग़लत: प्रॉम्प्ट में मिला देना
// "QIITA_TOKEN=असली टोकन से पोस्ट कर दो" ← यही मैंने गड़बड़ की थी

सही तरीक़ा—चाबियाँ .env नाम की फ़ाइल में जमा कीजिए।

# .env (इस फ़ाइल को Git पर मत चढ़ाओ। बस अपने कंप्यूटर पर रखो)
ANTHROPIC_API_KEY=यहाँ असली मान
QIITA_TOKEN=यहाँ असली मान
DATABASE_URL=postgresql://...

और, उस .env को “Git कभी न उठाए” यूँ ऐलान कर दीजिए। यही सुरक्षा-रस्सी है।

# .gitignore में ज़रूर लिखो (चाबी ग़लती से कमिट न हो, इसका बीमा)
.env
.env.*
!.env.example   # बस सैम्पल शेयर करना ठीक है
*.pem
*.key
*-service-account.json   # क्लाउड की सर्विस अकाउंट चाबी भी न भूलें

टीम को बस “कौन-कौन सी चाबी चाहिए” इतना बताना हो, तो मान ख़ाली रखा सैम्पल रख दीजिए।

# .env.example (इसे Git पर चढ़ाना ठीक है। अंदर ख़ाली है)
ANTHROPIC_API_KEY=
QIITA_TOKEN=
DATABASE_URL=

कोड से, फ़ाइल का मान सीधे लिखे बिना, “environment variable” के तौर पर पढ़िए। चाबी का असली रूप कोड में कहीं नहीं उभरता।

// सही: environment variable से पढ़ो। मान कोड में बिल्कुल मत लिखो
import { config } from "dotenv";
config();

const token = process.env.QIITA_TOKEN;
if (!token) {
  // चाबी न हो, तो मान नहीं, बस "सेट करना भूल गए हो" इतना बताओ
  throw new Error("QIITA_TOKEN सेट नहीं है। .env जाँच लीजिए।");
}

बात बस एक है। चाबी का असली रूप सिर्फ़ .env के अंदर ही छुआ जाए। कोड, प्रॉम्प्ट और लॉग—सबको बस चाबी का “नाम” भर पता रहे। यही बुनियादी पाठ है।

उपाय 2: ख़तरनाक कमांड को “अपने-आप मंज़ूर” मत होने दीजिए

अब, rm -rf (एक साथ मिटाना) या git push --force (टीम का काम ऊपर लिख देना) जैसी लौटाई न जा सकने वाली कमांड। इन्हें “चलाने से पहले इंसान से ज़रूर पूछो” या “चलाना ही मना” पर सेट कर दीजिए।

Claude Code में, हर कमांड के लिए “ठीक है / पूछो / मना” तय करने का इंतज़ाम है। .claude/settings.json में यूँ लिखिए।

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(curl * | bash)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)"
    ]
  }
}

पढ़ने का तरीक़ा सीधा है। बस तीन डिब्बों में बाँट देना।

डिब्बा	मतलब	किसे डालें
allow	बिना पूछे चलाना ठीक	सिर्फ़ पढ़ने वाला सुरक्षित काम
ask	हर बार ढंग से पूछो	लिखना, कमिट, पुश
deny	बिल्कुल मत करने दो	मिटाना, force push, असली DB

उलझन हो तो यूँ याद रखिए। सिर्फ़ पढ़ना allow, लिखना हो तो ask, मिटाना हो तो deny। शुरू में कसकर बाँध रखिए, और “अरे, यह तो सुरक्षित है” जो निकले बस उसी काम को बाद में ask या allow के दर्जे पर चढ़ाइए। उलटी दिशा (शुरू में ढीला, बाद में कसना) हादसा खाने के बाद होती है, इसलिए हमेशा कसने वाली दिशा से शुरू कीजिए।

उपाय 3: पढ़ने-लिखने का “दायरा” सिकोड़िए

उपाय 2 के deny को ग़ौर से देखिए। शुरू में ऐसी लाइनें हैं।

"deny": [
  "Read(./.env)",
  "Read(./.env.*)",
  "Read(./secrets/**)"
]

यह “.env और secrets फ़ोल्डर पढ़ना तक मना” वाली सेटिंग है। मैंने जो “.env पढ़वाने” वाला हादसा किया, वह बस इस एक लाइन से न होता। “देखो” कहने पर भी दरवाज़े से ही लौटा दिया जाता।

दायरा सिकोड़ने का मतलब—दिखाने लायक जगह और न दिखाने लायक जगह, पहले ही लकीर खींचकर बाँट देना। चाबी वाला फ़ोल्डर, असली सेटिंग, ग्राहकों का डेटा। इन्हें “छूना ही न आए” ऐसा रख दें, तो ग़लती से माँग भी बैठें तो भी सुरक्षित।

साथ में, जिन फ़ाइलों को बिल्कुल बदलवाना नहीं चाहते, उन्हें प्रोजेक्ट के नियम (CLAUDE.md) में भी हिंदी में लिख रखिए तो निश्चिंती रहती है।

## बदलना मना फ़ाइलें (CLAUDE.md में लिखें)

नीचे की फ़ाइलें बिल्कुल मत बदलना। ज़रूरत हो तो ज़रूर मुझ (इंसान) से पूछना।
- .env (चाबी और पासवर्ड शामिल)
- wrangler.toml (असली पब्लिश सेटिंग)
- .github/workflows/*.yml (अपने-आप डिप्लॉय की सेटिंग)

सेटिंग फ़ाइल से मशीनी ढंग से रोकना, और नियम-पाठ से AI को मक़सद भी बताना। दो-तरफ़ा रखें तो छेद-छिद्र कम रहते हैं।

उपाय 4: राज़ की जानकारी लॉग में मत निकालिए

यह सेटिंग से ज़्यादा, लिखने की एक छोटी-सी आदत है। एरर मैसेज लिखते वक़्त, चाबी का “मान” साथ मत निकालिए।

// ग़लत: एरर लॉग में API key वैसी-की-वैसी निकल जाती है
throw new Error(`ऑथेंटिकेशन फ़ेल: token=${process.env.TOKEN}`);

// सही: मान मत निकालो, बस कहाँ देखना है इतना बताओ
throw new Error("ऑथेंटिकेशन फ़ेल: TOKEN environment variable जाँच लीजिए");

बस एक लाइन का फ़र्क़ है, पर ऊपर वाली लॉग किसी को दिखाने के पल ही चाबी लीक हो जाती है।

और एक बात। AI को लॉग देते वक़्त, नंगी मत चिपकाइए। चाबी और पासवर्ड वाली लाइनों का मान, ढका हुआ रूप बनाकर ही दीजिए।

# यूँ बदलकर दो। AI को बस "DB कनेक्शन की जानकारी है" इतना ढाँचा समझ आ जाए, काफ़ी
DATABASE_URL=***ढका हुआ***
QIITA_TOKEN=***ढका हुआ***

“देने लायक चीज़” और “न देने लायक चीज़” को, मोटा-मोटा एक टेबल में। इसे CLAUDE.md में चिपका रखें, तो हर बार माँगते वक़्त कसौटी याद रहती है।

देना ठीक	देना मना
एरर का किस्म, दोहराने के क़दम, फ़ाइल का नाम	API key, पासवर्ड, सेशन का cookie
.env.example, सेटिंग चीज़ों के “नाम”	असली DB का URL, ग्राहकों का डेटा
ढके हुए रूप वाली लॉग	असली टोकन, सर्विस अकाउंट की .json फ़ाइल

उपाय 5: असली वाली चीज़ों को “अलग दर्जा” दीजिए

आख़िरी। अभ्यास वाला (डेवलपमेंट) और असली (प्रोडक्शन), साफ़ बाँट दीजिए। myapp_dev और myapp_prod गड्डमड्ड होने से रोकना हो, तो असली में लिखने पर एक झंझट लगवा देना असरदार रहता है।

// scripts/db-query.mjs
const env = process.env.NODE_ENV ?? "development";

// असली में लिखने की कोशिश हो, तो ख़ास flag के बिना रोक दो
if (env === "production" && process.argv.includes("--write")) {
  console.error("असली में लिखने के लिए --force-production flag ज़रूरी है।");
  process.exit(1);
}

“ग़लती से असली” को, flag रूपी एक झंझट से ठोस रूप से रोकना। यही झंझट सुरक्षा-रस्सी है। असली डेटा, मिट जाए तो लौटता नहीं।

शुरू करना है, तो यहाँ से (क़दम)

पाँचों आज ही करना ज़रूरी नहीं। क्रम से करें तो 30 मिनट में हो जाते हैं।

1. प्रोजेक्ट में .env बनाइए, और सारी चाबियाँ वहीं ले जाइए
2. .gitignore में .env जोड़िए (उपाय 1)
3. .claude/settings.json बनाइए, और deny में rm -rf तथा .env पढ़ना डालिए (उपाय 2, 3)
4. लिखने-कमिट वाले काम ask में डालिए (उपाय 2)
5. CLAUDE.md में “देना ठीक / मना” वाला टेबल और बदलना-मना फ़ाइलें चिपकाइए (उपाय 4)

बस पहले तीन क़दम भी, शुरुआत वाला rm -rf हादसा और .env लीक रोक देते हैं। मुकम्मलता मत चाहिए, पहले एक। इतना ही काफ़ी आगे बढ़ना है।

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

असल में आज़माकर जो मिला

शुरुआत वाली rm -rf दहशत के बाद से, मैंने “AI पर भरोसा करूँ या नहीं” वाली उलझन छोड़ दी। उसकी जगह अब देखता हूँ—किस दरबान पर रुका।

deny में .env पढ़ना जोड़ने के बाद, “environment variable जाँच लो” कहने पर भी AI सीधे-सादे पीछे हटने लगा। वह असहज “सब पढ़कर सुना देना”, दोबारा नहीं होता।

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

निचोड़

शुरुआती के सबसे पहले निभाने को, बस ये पाँच काफ़ी हैं।

निभाना	तरीक़ा
API key लीक न होने देना	.env में अलग-थलग + .gitignore
ख़तरनाक कमांड बेकाबू न होने देना	deny में rm -rf / force push
पढ़ने-लिखने का दायरा सिकोड़ना	.env, secrets को deny, असली फ़ाइलें बदलना मना
राज़ की जानकारी लॉग में न निकालना	मान मत निकालो, ढककर दो
असली वाली चीज़ें अलग दर्जे पर	flag से असली में लिखना रोको

सिक्योरिटी सुनकर अकड़न आती है, पर करना बस इतना है—“हादसा न हो ऐसा इंतज़ाम पहले बना लेना”। एक बार डाल दिया, तो आगे यूँ ही छोड़ देने पर भी वह निभाता रहता है। आज 30 मिनट। इससे भविष्य का एक बड़ा हादसा मिटा दीजिए।

अगर “हमारी टीम में कहाँ तक बाँधें?” इस पर उलझन हो, तो शिक्षण सामग्री और सहारा भी तैयार है। पहले शिक्षण सामग्री की सूची पर झाँक लीजिए।