Claude Code सुरक्षा गाइड: Permissions, MCP, Sandboxing

पारंपरिक चैटबॉट एक API के पीछे कॉन्फ़िगर होते हैं, इसलिए उनका सबसे बुरा असर भ्रम पैदा करना होता है। लेकिन एक AI कोडिंग एजेंट सीधे आपके रेपो, आपके टर्मिनल, और (अक्सर) आपके क्लाउड क्रेडेंशियल्स के अंदर होता है—यानी उन विशेषाधिकारयुक्त डेवलपर वातावरणों के बहुत करीब, जिन्हें हम पहले कभी चैटबॉट नहीं कहते थे।

सवाल यह है कि Claude Code को सुरक्षित रूप से कैसे इस्तेमाल करें, बिना खुद को धीमा किए। सही संतुलन के साथ permissions, MCP नियंत्रण, और sandboxing आपको वही दिलाएंगे।

इस लेख में, मैं समझाऊंगा कि Claude Code का सुरक्षा मॉडल वास्तव में कैसे काम करता है, किन जगहों पर आपको ध्यान देना चाहिए, और वे अभ्यास जो इसे उपयोगी रखते हैं—बिना उसे आपकी मंशा से अधिक पहुँच दिए।

यदि आप Claude और Claude Code में बिल्कुल नए हैं, तो हमारे निःशुल्क Claude Code 101 कोर्स में नामांकन करें और एक दोपहर में बुनियादी बातें सीखें।

Claude Code के सुरक्षा मॉडल को समझना

किसी भी नियम को ट्यून करने से पहले, आपको यह मानसिक मॉडल चाहिए कि Claude Code वास्तव में क्या नियंत्रित करता है।

यहाँ पाँच घटक हैं: एक permissions सिस्टम जो तय करता है क्या अनुमत है; टूल एक्सेस नियंत्रण जो व्यक्तिगत क्षमताओं का दायरा बाँधते हैं; बाहरी इंटीग्रेशन के लिए MCP permissions; OS-स्तरीय अलगाव के लिए sandboxing; और बाद में समीक्षा के लिए ऑडिटेबिलिटी। हर हिस्सा अलग समस्या हल करता है, पर ये एक-दूसरे पर स्टैक होते हैं।

Permissions सिस्टम

Permissions सिस्टम स्थिर परत है।

आप settings.json में तीन सूचियों—allow, ask, और deny—का उपयोग करके बताते हैं कि Claude क्या कर सकता है। नियमों का मूल्यांकन क्रम यह है: पहले deny, फिर ask, फिर allow, और पहला मिलान विजयी होता है। एक deny नियम कॉल को ब्लॉक कर देगा, भले ही कोई व्यापक allow नियम उस पर लागू होता।

यदि कोई नियम मेल नहीं खाता, तो Claude सत्र के defaultMode पर वापस जाता है (मोड्स पर अगले सेक्शन में और जानकारी)।

टूल एक्सेस नियंत्रण

Permissions टूल्स से जुड़ती हैं, पूरे एजेंट से नहीं।

Claude Code के अपने बिल्ट-इन टूल्स का सेट है—उदाहरण के लिए शेल कमांड्स के लिए Bash, फाइलसिस्टम ऑपरेशन्स के लिए Read, Edit और Write, HTTPS रिक्वेस्ट के लिए WebFetch, क्वेरी के लिए WebSearch, आदि। प्रत्येक नियम एक टूल का नाम देता है और (वैकल्पिक रूप से) कोष्ठकों में एक स्पेसिफ़ायर, जैसे Bash(git commit:*) या Read(./.env)।

यही न्यूनतम-विशेषाधिकार को संभव बनाता है। आप टेस्ट के लिए Bash(npm run:*) की अनुमति दे सकते हैं, बिना Claude को पूरा शेल एक्सेस दिए।

MCP permissions

MCP सर्वर Claude Code को ऐसे टूल्स से विस्तारित करते हैं जिनके साथ इसे मूल रूप से काम करने के लिए नहीं बनाया गया था।

हर सर्वर अपने टूल्स का सेट लाता है (GitHub सर्वर PR टूल्स जोड़ता है, डेटाबेस सर्वर क्वेरी टूल्स जोड़ता है, इत्यादि)। परमिशन सिस्टम इन्हें भी कवर करता है, पर अलग सिंटैक्स के साथ—नियमों का फ़ॉर्म mcp__servername__toolname होता है, न कि कोष्ठकों वाला स्पेसिफ़ायर।

ध्यान रखने वाली बात यह है कि MCP सवाल को लगभग दोगुना कर देता है, क्योंकि आप केवल यह नहीं तय कर रहे कि Claude आपके शेल के साथ क्या कर सकता है—आप यह भी तय कर रहे हैं कि वह हर बाहरी सिस्टम के साथ क्या कर सकता है जिसे आपने उससे जोड़ा है।

Sandboxing

Sandboxing, Bash टूल के तहत OS-स्तरीय सुरक्षा है।

Permission नियम बताते हैं Claude को क्या करना चाहिए। Sandboxing लागू करता है कि वह क्या कर सकता है—फाइलसिस्टम एक्सेस और आउटबाउंड नेटवर्क कॉल्स को ऑपरेटिंग सिस्टम स्तर पर सीमित करके। macOS पर यह Seatbelt के जरिए बॉक्स से बाहर काम करता है। Linux और WSL2 पर, पहले आपको bubblewrap और socat इंस्टॉल करने होंगे।

ये दोनों परतें समान ढंग से काम करती हैं लेकिन अलग स्थितियों को कवर करती हैं। Permissions Claude को किसी कोशिश से रोकती हैं, और यदि कोई प्रॉम्प्ट इंजेक्शन Claude को कोशिश करने के लिए मना ले, तो sandboxing उस कोशिश को सफल होने से रोकती है।

ऑडिटेबिलिटी

अंतिम हिस्सा है यह देख पाना कि हुआ क्या था।

/permissions कमांड हर सक्रिय नियम और वह किस सेटिंग फाइल से आया है, सूचीबद्ध करता है—ताकि आप यह सवाल जवाब दे सकें: "Claude ने वह क्यों चलाया?" हुक्स (PreToolUse, PostToolUse, आदि) आपको हर टूल कॉल अपने सिस्टम में लॉग करने देते हैं। टीमों के लिए, OpenTelemetry एक्सपोर्टर उपयोग और टूल-कॉल डेटा आपके मौजूदा ऑब्ज़र्वेबिलिटी स्टैक में भेजते हैं।

Claude Code Permissions और एक्सेस कंट्रोल

सुरक्षा का अधिकांश हिस्सा permission सेटिंग्स से आता है, इसलिए आप अपना अधिकतर समय यहीं ट्यूनिंग में लगाएंगे।

फाइल एक्सेस

डिफ़ॉल्ट रूप से, Claude उस डायरेक्टरी में फाइलें पढ़ और संपादित कर सकता है, जहाँ से आपने उसे लॉन्च किया।

रीडिंग Read टूल द्वारा नियंत्रित होती है, और एडिटिंग Edit और Write से। प्रत्येक कोष्ठकों में पाथ पैटर्न लेता है, gitignore-शैली सिंटैक्स का उपयोग करते हुए—उदाहरण के लिए Read(**/.env) किसी भी गहराई पर हर .env फाइल से मेल खाता है, और Edit(src/**) src/ के अंतर्गत सब कुछ से।

Read पर deny, Claude Code के अपने फाइल टूल्स (Read, Grep, Glob, LS) को कवर करता है, पर यह केवल सर्वोत्तम-प्रयास है। Bash के जरिए चलाए गए Python या Node स्क्रिप्ट अब भी फाइल खोल सकते हैं, क्योंकि वह पढ़ाई शेल के माध्यम से होती है, Claude के Read टूल से नहीं। यदि कोई सीक्रेट महत्वपूर्ण है, तो Read deny को Bash deny के साथ जोड़ें—उन पाथ्स पर cat, head, और tail को निषिद्ध करें।

वर्किंग डायरेक्टरी से आगे एक्सेस बढ़ाने के लिए, settings.json में additionalDirectories का उपयोग करें। इससे आप बिना वर्किंग-डायरेक्टरी की सीमा पूरी तरह हटाए, अपने रेपो के बाहर किसी साझा लाइब्रेरी या अपने होम डायरेक्टरी में किसी कॉन्फ़िग फाइल तक Claude को पहुँच दे सकते हैं।

कमांड निष्पादन

Bash टूल वह है जिसका दायरा आपको सबसे सावधानी से बाँधना होगा।

सादा Bash नियम हर कमांड की अनुमति देता है। Bash(npm run:*) जैसा स्कोप्ड नियम केवल मेल खाने वाली कॉल्स की अनुमति देता है। यहाँ कॉलन-स्टार पैटर्न का उपयोग करना होता है, और Claude Code शेल ऑपरेटर्स समझता है, इसलिए Bash(safe-cmd:*) जैसा नियम safe-cmd && rm -rf / से मेल नहीं खाएगा।

कुछ कमांड हर मोड में बिना प्रॉम्प्ट के चलते हैं, क्योंकि उन्हें डिफ़ॉल्ट रूप से रीड-ओनली माना जाता है। सूची में ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, और git के रीड-ओनली रूप शामिल हैं। आप इस सूची को हाथ से छोटा नहीं कर सकते, पर किसी के लिए भी ask या deny नियम जोड़कर डिफ़ॉल्ट को ओवरराइड कर सकते हैं।

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

Permission मोड्स

Permission नियम स्थिर हैं, लेकिन permission मोड्स यह बदलते हैं कि असंगत कॉल्स कैसे व्यवहार करती हैं।

कुल पाँच हैं:

• default: हर टूल के पहले उपयोग पर प्रॉम्प्ट करता है।

• acceptEdits: वर्किंग डायरेक्टरी में फाइल एडिट्स को ऑटो-अप्रूव करता है, और शेल कमांड्स पर नियंत्रण बनाए रखता है। तब उपयोगी जब आप एडिट्स पर भरोसा करते हैं, शेल पर नहीं।

• plan: Claude पढ़ और विश्लेषण कर सकता है, लेकिन फाइल एडिट या कमांड रन नहीं कर सकता। कोड रिव्यू या प्लानिंग सत्रों के लिए उपयुक्त मोड।

• dontAsk: जो allow सूची में स्पष्ट रूप से नहीं है, उसे स्वतः अस्वीकार करता है।

• bypassPermissions: हर प्रॉम्प्ट को छोड़ देता है। केवल पूरी तरह अलग-थलग वातावरण (जैसे कंटेनर या VM) में सुरक्षित।

आप सत्र के बीच में Shift+Tab से तीन मुख्य मोड्स साइकिल कर सकते हैं, या settings.json में किसी एक को डिफ़ॉल्ट चुन सकते हैं:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

टीमों के लिए, managed settings वह परत देती हैं जिसे उपयोगकर्ता ओवरराइड नहीं कर सकता। यह फाइल वही JSON फ़ॉर्मेट फ़ॉलो करती है और एक सिस्टम पाथ में मिलती है:

• /Library/Application Support/ClaudeCode/managed-settings.json (macOS)

• /etc/claude-code/managed-settings.json (Linux)

• C:\ProgramData\ClaudeCode\managed-settings.json (Windows)

Managed settings में deny नियम मशीन के हर प्रोजेक्ट पर लागू रहते हैं—इसी तरह आप "कोई .env फाइल न पढ़े" या "कोई bypassPermissions न चलाए" जैसे नियम संगठन-स्तर पर लागू करवाते हैं।

इस सब के पीछे का सिद्धांत न्यूनतम-विशेषाधिकार (least-privilege) है—वही जो आप किसी भी सर्विस अकाउंट पर लागू करते हैं। 

आपको काम चलाने के लिए आवश्यक permissions के सबसे छोटे सेट से शुरुआत करनी चाहिए, और केवल जरूरत पड़ने पर उन्हें व्यापक करना चाहिए। Anthropic का मार्गदर्शन भी यही कहता है—Claude द्वारा किए गए बदलावों की समीक्षा करें, /permissions से अपने नियमों का ऑडिट करें, और प्रोजेक्ट-विशिष्ट सेटिंग्स को वर्ज़न कंट्रोल में रखें ताकि टीम सहमत रहे कि Claude किन चीजों पर काम कर सकता है।

Claude Code Sandboxing

जितना अधिक आप Claude को स्वतः चलने देते हैं, sandboxing उतनी ही अधिक सार्थक हो जाती है।

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

एक अहम विवरण यह है कि sandbox केवल Bash और उसके चाइल्ड प्रोसेसेज़ को कवर करता है। यह Read, Edit, या Write टूल्स को प्रतिबंधित नहीं करता—वे अब भी permission सिस्टम से होकर गुजरते हैं।

नेटिव sandboxing

नेटिव sandbox, Claude Code में बिल्ट-इन है और /sandbox से चालू होता है।

macOS पर sandboxing, बिल्ट-इन Seatbelt फ़्रेमवर्क का उपयोग करता है और कुछ इंस्टॉल करने की जरूरत नहीं। Linux और WSL2 पर, आपको फाइलसिस्टम आइसोलेशन के लिए bubblewrap और नेटवर्क प्रॉक्सी के लिए socat इंस्टॉल करना होगा। नेटिव Windows समर्थित नहीं है, इसलिए आप Claude Code को WSL2 डिस्ट्रीब्यूशन के भीतर चलाएँ।

फाइलसिस्टम सीमा समझने में आसान है। रीड्स हर जगह काम करते हैं सिवाय निषिद्ध पाथ्स के, और राइट्स केवल वर्किंग डायरेक्टरी तथा आपके द्वारा अनुमत अतिरिक्त पाथ्स के अंदर। यदि आप sandbox के भीतर से ~/.bashrc में लिखने की कोशिश करते हैं, तो Claude को असफलता का पता लगने से पहले ही आपको "Operation not permitted" मिलेगा।

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

एक काम करने वाला कॉन्फ़िगरेशन कुछ ऐसा दिखता है:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Anthropic के आंतरिक उपयोग में, sandboxing परमिशन प्रॉम्प्ट्स को 84% तक घटाता है।

डेवलपमेंट कंटेनर्स

Dev कंटेनर्स अलगाव में अगला कदम हैं।

Anthropic के पास Claude Code के लिए एक रेफ़रेंस devcontainer है जो एक Ubuntu वातावरण सेट करता है, आपका रेपो माउंट करता है, और एजेंट को काम करने के लिए शेल देता है। नेटिव sandboxing की तुलना में इसका लाभ है रिप्रोड्यूसिबिलिटी—क्योंकि टीम के सभी लोग समान टूल्स और समान सेटअप वाला एक जैसा वातावरण पाते हैं।

पर नुकसान है ओवरहेड। 

कंटेनर बिल्ड, फाइल माउंटिंग, और (कभी-कभी) कंटेनर्स के साथ धीमा फ़ीडबैक लूप जोड़ते हैं। एक अकेले डेवलपर के लिए, नेटिव sandbox आमतौर पर पर्याप्त है। टीम या CI उपयोग के लिए, यह सेटअप सार्थक है।

Docker-आधारित आइसोलेशन

लंबे समय तक चलने वाले स्वायत्त एजेंट सत्रों के लिए, Docker sandboxing सीमा को और बढ़ा सकता है।

सेटअप आम तौर पर ऐसा दिखता है:

• न्यूनतम बेस इमेज: जिन पैकेज मैनेजर और नेटवर्क टूल्स की जरूरत नहीं, उन्हें हटाएँ।
• नॉन-रूट यूज़र: Claude कभी रूट के रूप में नहीं चलता—तो वह सिस्टम फाइल्स नहीं बदल सकता या ग्लोबल पैकेज इंस्टॉल नहीं कर सकता।
• रीड-ओनली रूट फाइलसिस्टम: कंटेनर रूट को रीड-ओनली माउंट करें, केवल विशिष्ट आउटपुट डायरेक्टरीज़ को राइटेबल रखें।
• ईग्रेस प्रॉक्सी: आउटबाउंड नेटवर्क को ऐसे प्रॉक्सी से रूट करें जो पैकेज रजिस्ट्रियों (npm, PyPI) को अनुमति दे और बाकी सब को रोके—ताकि npm install जैसी कमांड्स चलें पर मनमाना curl न चले।
• रिसोर्स लिमिट्स: CPU, मेमोरी, और I/O की सीमा तय करें ताकि कोई प्रोसेस होस्ट को डाउन न कर दे।

Docker Sandboxes हर सैंडबॉक्स को उसका अपना microVM देते हैं, एक निजी Docker डेमन के साथ। होस्ट डेमन docker ps में भी सैंडबॉक्सेस को नहीं देख पाता। सीमा कंटेनर की तुलना में VM के अधिक करीब होती है, जिससे अधिकांश कंटेनर-एस्केप पाथ्स बंद हो जाते हैं जिनकी डेवलपर्स को चिंता रहती है।

एंटरप्राइज sandboxing रणनीतियाँ

संगठनों के लिए सवाल यह है कि sandbox तकनीकों को कैसे लेयर करें—न कि उन्हें उपयोग करना है या नहीं।

अधिकांश इसका इस तरह उपयोग करते हैं:

• Permission नियम managed-settings.json में रहते हैं और व्यक्तिगत डेवलपर्स उन्हें ओवरराइड नहीं कर सकते।

• नेटिव sandboxing, परमिशन परत के नीचे चलती है।

• Dev कंटेनर्स या Docker, उसके नीचे चलते हैं।

• सबसे उच्च-भरोसे के परिदृश्यों (प्रोडक्शन एक्सेस, सीक्रेट्स हैंडलिंग) के लिए, बिना होस्ट फाइलसिस्टम माउंट वाला समर्पित VM अंतिम परत है।

वेब पर Claude Code, इसी विचार का मैनेज्ड संस्करण है। प्रत्येक सत्र Anthropic-प्रबंधित VM में चलता है, git टोकन्स जैसे संवेदनशील क्रेडेंशियल्स सैंडबॉक्स के बाहर एक प्रॉक्सी में रखे जाते हैं, और सीमा इन्फ्रास्ट्रक्चर द्वारा लागू की जाती है।

Claude Code में MCP सुरक्षा

MCP, Claude Code का वह हिस्सा है जो सबसे तेज़ी से बढ़ता है।

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

उदाहरण के लिए:

• GitHub MCP सर्वर Claude को pull request एक्सेस देता है।
• डेटाबेस MCP सर्वर उसे आपका स्कीमा और क्वेरीज देता है।
• Slack सर्वर उसे आपके चैनल्स देता है।

इनमें से कोई भी अपने-आप में समस्या नहीं है, पर इसका मतलब है कि MCP को अपनी गवर्नेंस चाहिए। MCP टूल से लाई गई सामग्री (कोई वेब पेज या API प्रतिक्रिया) में इंजेक्टेड निर्देश हो सकते हैं जिन्हें Claude वैसा ही चलाएगा जैसे आपने टाइप किया हो। साथ ही, हर सर्वर एक क्रेडेंशियल और एक अलग ऑथेंटिकेशन पाथ जोड़ता है, जिसे अलग से प्रबंधित करना पड़ता है।

टूल permissions

MCP टूल्स की नामकरण पद्धति बिल्ट-इन टूल्स से अलग होती है।

नियम का फ़ॉर्म है mcp__servername__toolname, बिना कोष्ठक वाले स्पेसिफ़ायर के। उदाहरण के लिए, mcp__github__create_pull_request Claude को ठीक उसी टूल को कॉल करने देता है, और mcp__github__delete_repo पर deny खतरनाक वाले को ब्लॉक करता है। Allow, ask, और deny सूचियाँ Bash या Read की तरह ही काम करती हैं।

उसी प्रीसिडेंस नियम यहाँ भी लागू होते हैं—पहले deny, फिर ask, फिर allow। mcp__github__delete_* पर managed-settings में deny मशीन के हर प्रोजेक्ट पर मान्य है।

रिसोर्स permissions

MCP सर्वर टूल्स के साथ संसाधन (resources) भी उजागर कर सकते हैं।

रिसोर्स वह डेटा होता है जिसे सर्वर Claude के पढ़ने के लिए उपलब्ध कराता है (उदाहरण के लिए किसी प्रोजेक्ट मैनेजमेंट सर्वर में एक फाइल या डेटाबेस सर्वर में एक पंक्ति)। रिसोर्स एक्सेस भी टूल कॉल्स वाले विश्वास-जांच से होकर गुजरता है, और किसी MCP सर्वर से पहली बार कनेक्शन पर, उसके किसी टूल या रिसोर्स तक पहुँच से पहले एक ट्रस्ट वेरिफ़िकेशन स्टेप चलता है।

उचित डिफ़ॉल्ट यह है कि रिसोर्सेस को भी एक और टूल मानें। यदि आप वह क्रेडेंशियल नहीं देंगे, तो रिसोर्स एक्सेस भी न दें।

स्वीकृत MCP सर्वर

Anthropic Directory उन कनेक्टर्स को सूचीबद्ध करता है जिन्हें Anthropic ने अपनी लिस्टिंग मानदंडों के अनुरूप जाँचा है।

संगठनों के लिए, एक अच्छा पैटर्न आंतरिक allowlist का उपयोग करना है। दो सेटिंग्स आपको नियंत्रण देती हैं:

• allowedMcpServers: उन सर्वरों का ग्लोब पैटर्न जिन्हें डेवलपर्स अपने प्रोजेक्ट्स में जोड़ सकते हैं (उदाहरण के लिए, केवल आंतरिक रूप से मेंटेन किए गए सर्वरों के लिए company-*)।

• deniedMcpServers: उन सर्वरों का पैटर्न जिन्हें नहीं जोड़ा जा सकता—चाहे डेवलपर कोशिश भी करे।

हर सत्र में अनिवार्य रूप से मौजूद रहने वाले सर्वरों के लिए, managed settings में स्थित managed-mcp.json फाइल के माध्यम से उन्हें भेजना सही रास्ता है। डेवलपर्स प्रविष्टियों को हटा या संशोधित नहीं कर सकते।

शेयर्ड रेपो में जिस सेटिंग से बचना चाहिए, वह है enableAllProjectMcpServers—यह .mcp.json में परिभाषित हर MCP सर्वर को स्वतः स्वीकृत कर देता है। एकल कार्य के लिए यह सुविधाजनक है, पर किसी भी चेक-इन सामग्री के लिए खतरनाक—क्योंकि कोई दुर्भावनापूर्ण PR .mcp.json में नया सर्वर जोड़ सकता है और वह बिना प्रॉम्प्ट के चल जाएगा।

न्यूनतम-विशेषाधिकार टूल एक्सेस

सिद्धांत Bash permissions जैसा ही है, बस MCP पर लागू।

शुरुआती सवाल है कि हर सर्वर के पास कौन-सा क्रेडेंशियल है। डेटाबेस MCP सर्वर को राइट-अधिकार वाले प्राइमरी की जगह रीड-ओनली एक्सेस वाली रीड-रेप्लिका से जुड़ना चाहिए। API MCP सर्वर को व्यक्तिगत फुल-ऑर्ग टोकन के बजाय, आवश्यक एंडपॉइंट्स के सबसे छोटे सेट पर स्कोप्ड टोकन इस्तेमाल करना चाहिए। और इसी तरह।

सबएजेंट्स MCP एक्सेस को स्कोप करने का एक और तरीका हैं। .claude/agents/ में एक सबएजेंट परिभाषा सटीक रूप से घोषित कर सकती है कि उसे किन टूल्स तक पहुँच है (mcp:<server>:<tool> सिंटैक्स का उपयोग करते हुए), ताकि "deploy-agent" को इन्फ्रास्ट्रक्चर सर्वर मिले, और "review-agent" को केवल Read, Grep, और Glob। एजेंट वे टूल्स नहीं कॉल कर सकता जिनकी उसे अनुमति नहीं दी गई।

MCP गवर्नेंस

स्केल पर Claude Code चलाने वाली टीम या संगठन के लिए, MCP को वही गवर्नेंस चाहिए जो किसी भी प्रोडक्शन इंटीग्रेशन को चाहिए।

इसका मतलब है स्वीकृत सर्वरों की रजिस्ट्री, नामित ओनर्स के साथ; टूल इनवोकेशंस के एंड-टू-एंड ऑडिट ट्रेल्स (कौन-से MCP टूल्स किसने, किन पैरामीटर्स के साथ कॉल किए); और स्वीकृति सूची की आवधिक समीक्षा। Claude Code में OpenTelemetry एक्सपोर्टर्स आपको ऑडिट डेटा उसी फ़ॉर्मेट में देते हैं जो आपके मौजूदा ऑब्ज़र्वेबिलिटी स्टैक में सहजता से फिट हो जाए।

बड़े संगठनों के लिए, केंद्रीकृत MCP गेटवे इसका सबसे साफ़ रूप है। 

डेवलपर्स अलग-अलग सर्वर रजिस्टर करने के बजाय गेटवे से कनेक्ट होते हैं। गेटवे ऑथेंटिकेशन संभालता है, टूल-स्तर पर रोल-आधारित एक्सेस लागू करता है, और एकल ऑडिट ट्रेल इमिट करता है। यह क्रेडेंशियल स्प्रॉल भी सुलझाता है—क्योंकि गेटवे पर क्रेडेंशियल्स का एक सेट, हर डेवलपर के पास हर API कुंजी की कॉपी होने की जगह लेता है।

सीक्रेट्स मैनेजमेंट और संवेदनशील डेटा

Claude Code वह सब पढ़ सकता है जो आप पढ़ सकते हैं—जिससे सीक्रेट्स पहुँच में आ जाते हैं।

डिफ़ॉल्ट रूप से, Claude Code हर वह फाइल पढ़ सकता है जिसे आपका यूज़र अकाउंट पढ़ सकता है। इसमें आपके प्रोजेक्ट की .env फाइलें, ~/.aws/ में AWS क्रेडेंशियल्स, ~/.ssh/ में SSH प्राइवेट कीज़, आपके शेल rc फाइल में GitHub टोकन्स, और Claude द्वारा बनाए गए किसी भी सबप्रोसेस में environment variables शामिल हैं। यह बिल्कुल सामान्य है और डिज़ाइन के अनुरूप है।

सीक्रेट्स को वर्कस्पेस से बाहर रखें

पहला कदम यह सुनिश्चित करना है कि सीक्रेट्स उन डायरेक्टरी में न हों जिन्हें Claude पढ़ रहा है।

.env फाइलें सबसे आम हैं। वे प्रोजेक्ट रूट में होती हैं, हर dev टूल द्वारा लोड की जाती हैं, और ठीक वही मान रखती हैं जिन्हें आप Claude के संदर्भ में नहीं रखना चाहते (डेटाबेस URLs और API कुंजियाँ)। 

आप ये पैटर्न अपना सकते हैं:

• सीक्रेट्स को वर्किंग ट्री के बाहर किसी डायरेक्टरी में ले जाएँ—उदाहरण के लिए ~/.config/myapp/secrets.env—और उन्हें किसी environment मैनेजर या direnv सेटअप के जरिए लोड करें जो बाहरी फाइल की ओर इशारा करे।

• कंटेनराइज़्ड काम के लिए, बाइंड माउंट के बाहर एक .secrets/ फ़ोल्डर रखें ताकि फाइल कंटेनर के अंदर से अदृश्य रहे।

• अपनी permissions.deny सूची में Read(**/.env) और Read(**/.env.*) जोड़ें, और इनके साथ Bash(cat:*/.env) जैसे denies जोड़ें ताकि शेल स्क्रिप्ट वह न पढ़ सके जिसे Read टूल नहीं पढ़ सकता।

सीक्रेट मैनेजर का उपयोग करें

डेमो प्रोजेक्ट्स से आगे की किसी भी चीज़ के लिए, सीक्रेट्स का सही स्थान एक सीक्रेट मैनेजर है।

वेंडर कोई भी हो (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical), पैटर्न एक-सा है। सीक्रेट्स मैनेजर में रखे जाते हैं। आपका शेल या रनटाइम उन्हें मांग पर प्राप्त करता है और केवल उस प्रोसेस को उपलब्ध कराता है जिसे उनकी जरूरत है। Claude कभी वास्तविक मान नहीं देखता।

विशेष रूप से Claude Code के लिए, इसका मतलब है CLAUDE_CODE_SUBPROCESS_ENV_SCRUB सेट करना—ताकि सबप्रोसेसेज़ से Anthropic और क्लाउड प्रदाता क्रेडेंशियल्स हट जाएँ—या sandbox.credentials का उपयोग कर सैंडबॉक्स्ड कमांड्स के लिए विशिष्ट वेरिएबल्स अनसेट करना। पहला आपके ANTHROPIC_API_KEY को किसी बिल्ड स्क्रिप्ट में पास होने से रोकता है, और दूसरा किसी भी संवेदनशील environment variable के शेल कमांड तक पहुँचने के व्यापक केस को कवर करता है।

रेपो एक्सेस सीमित करें

तीसरा विकल्प रेपो स्तर पर है।

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

आप दो कदम उठा सकते हैं:

• प्रोडक्शन कॉन्फ़िगरेशन को सख्त एक्सेस वाले अलग रेपो में बाँटें—ताकि जिस dev वातावरण में Claude काम कर रहा है, उसमें शुरुआत से ही प्रोडक्शन सीक्रेट्स न हों।

• किसी भी सेवा के लिए, जिससे Claude इंटरैक्ट करता है, स्कोप्ड टोकन्स का उपयोग करें। उदाहरण के लिए, कोड रिव्यू कार्य के लिए GitHub टोकन को repo:delete की आवश्यकता नहीं।

टीमों के लिए Claude Code सुरक्षा

एक अकेला डेवलपर settings.json अपनी मर्ज़ी से बदल सकता है। कोई टीम ऐसा नहीं कर सकती, क्योंकि समग्र सुरक्षा सबसे कमजोर मशीन की सबसे कमजोर कॉन्फ़िग जितनी ही मजबूत होती है। टीम और संगठन परिनियोजन के लिए, Claude Code में अलग नियंत्रण-परत है जिसे एडमिन पुश करता है और व्यक्तिगत उपयोगकर्ता ओवरराइड नहीं कर सकते।

Managed settings

Managed settings आधार हैं।

फाइल एक सिस्टम पाथ में स्थित होती है जिसे लिखने के लिए एडमिन एक्सेस चाहिए:

• /Library/Application Support/ClaudeCode/managed-settings.json (macOS)

• /etc/claude-code/managed-settings.json (Linux)

• C:\ProgramData\ClaudeCode\managed-settings.json (Windows)

इस फाइल की सेटिंग्स, यूज़र-लेवल और प्रोजेक्ट-लेवल सेटिंग्स पर प्राथमिकता रखती हैं। यहाँ रखी गई deny नियम, मशीन के हर प्रोजेक्ट पर deny नियम होते हैं—और डेवलपर उन्हें अपने settings.json को एडिट कर नहीं हटा सकता। अधिकतर संगठन यह फाइल MDM (Mobile Device Management) या उसी कॉन्फ़िगरेशन चैनल से वितरित करते हैं जिसे वे अन्य dev टूलिंग के लिए उपयोग करते हैं।

Managed परत पर कुछ उपयोगी सेटिंग्स ये हैं:

• permissions.deny नियम—संवेदनशील पाथ्स और खतरनाक कमांड्स के लिए

• defaultMode को default या plan पर सेट करें (कभी भी bypassPermissions नहीं)

• allowManagedPermissionRulesOnly: true—permission सेट को लॉक करने के लिए

• enableAllProjectMcpServers: false—स्पष्ट MCP अनुमोदन आवश्यक करने के लिए

• लॉगिंग के लिए OpenTelemetry एक्सपोर्टर कॉन्फ़िगरेशन

शेयर्ड परमिशन नीतियाँ

जो टीम इस बात पर सहमत है कि Claude क्या कर सकता है, उसे उस सहमति को वर्ज़न कंट्रोल में रखना चाहिए।

प्रोजेक्ट-लेवल सेटिंग्स रेपो रूट पर .claude/settings.json में होती हैं। यहाँ चेक-इन की गई कोई भी चीज़, उस रेपो में Claude चलाने वाले सभी पर लागू होती है। प्रोजेक्ट-विशिष्ट allow और deny के लिए यह सही स्थान है।

ध्यान रखें कि managed और project सेटिंग्स के बीच एक बँटवारा है जिसे आपको जानना चाहिए:

• Managed settings—संगठन नीति रखती हैं (कोई bypassPermissions नहीं चलाए, कोई .env न पढ़े)।

• Project settings—वर्कफ़्लो कन्वेंशन्स रखती हैं (इस रेपो के टेस्ट npm test से चलते हैं; इस रेपो की डिप्लॉय स्क्रिप्ट ऑफ-लिमिट्स है)।

टीम गवर्नेंस

टीम रोलआउट के लिए, पॉलिसी परत का एक मालिक चाहिए।

जो टीमें स्केल पर Claude Code चलाती हैं, वे आम तौर पर एक छोटी टीम बनाती हैं—आमतौर पर सिक्योरिटी और प्लेटफ़ॉर्म इंजीनियरिंग—जो managed settings, MCP allowlist, हुक स्क्रिप्ट्स, और OpenTelemetry पाइपलाइन की मालिक होती है। यही समूह अपवाद अनुरोधों की समीक्षा करता है और नए उपयोग मामलों के सामने आने पर पॉलिसी समायोजित करता है।

आपको इन हिस्सों को लिखित रूप में रखना चाहिए:

• कौन-से रेपो स्कोप में हैं और कौन-से नहीं—रिस्क-टीयर मोड्स के साथ (नियंत्रित डेटा वाले रेपो शायद plan मोड में Claude चलाएँ, जबकि मार्केटिंग साइट रेपो acceptEdits में चल सकता है)।
• कौन अपवाद दे सकता है और वे कैसे ट्रैक होते हैं।
• रिव्यू कैडेंस (तिमाही आम है) जिसमें टीम permission नियमों, MCP सर्वरों, और घटना-डेटा की पुनर्समीक्षा करती है।

ऑडिट लॉगिंग

Claude Code हर टूल निर्णय, MCP सर्वर कनेक्शन, permission मोड बदलाव, और API अनुरोध के लिए OpenTelemetry ईवेंट्स इमिट करता है। जब तक एडमिन managed settings में OTLP endpoint कॉन्फ़िगर नहीं करता, कोई डेटा फ्लो नहीं होता।

यहाँ टेलीमेट्री के लिए एक न्यूनतम managed settings ब्लॉक है:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

डिफ़ॉल्ट रूप से, प्रॉम्प्ट सामग्री और टूल पैरामीटर्स एक्सपोर्ट में शामिल नहीं होते—तो आपके पास जो ईवेंट्स आते हैं, वे मेटाडेटा होते हैं, पूरी बातचीत नहीं। प्रॉम्प्ट टेक्स्ट शामिल करने के लिए OTEL_LOG_USER_PROMPTS=1 सेट करें। टूल आर्गुमेंट्स शामिल करने के लिए (जो ऑडिट के लिए आमतौर पर चाहिए), OTEL_LOG_TOOL_DETAILS=1 सेट करें। दोनों निर्णयों के गोपनीयता निहितार्थ हैं—इसलिए अधिकांश टीमें इन्हें सोची-समझी पॉलिसी पसंद मानती हैं और स्टोरेज से पहले अपने टेलीमेट्री बैकएंड में फ़िल्टर/रिडैक्ट कॉन्फ़िगर करती हैं।

उपयोग मॉनिटरिंग

ऑडिट के पीछे वही OpenTelemetry स्ट्रीम, उपयोग मॉनिटरिंग के पीछे भी होती है।

Claude Code टोकन उपयोग, प्रति अनुरोध लागत, सत्र संख्या, और टूल निर्णय दरों के लिए मेट्रिक्स एक्सपोर्ट करता है। एग्रीगेट होने पर, ये बताते हैं कौन-सी टीमें सबसे अधिक मूल्य पा रही हैं, कौन-से वर्कफ़्लो सबसे अधिक रिजेक्शन पैदा करते हैं, और कौन-से मॉडल लागत बढ़ा रहे हैं। Datadog, Honeycomb, SigNoz, Elastic, और Splunk जैसे बैकएंड्स मानक OTLP फ़ॉर्मेट को ग्रहण करते हैं।

decision=deny के साथ permission_decision ईवेंट्स में स्पाइक का मतलब यह हो सकता है कि Claude बहुत कुछ करने की कोशिश कर रहा है—या यह भी कि टीम के allow नियम बहुत सख्त हैं।

आम Claude Code सुरक्षा गलतियाँ

Claude Code घटनाओं में कुछ ही मिसकन्फ़िगरेशन बार-बार दिखते हैं। अब मैं बताऊँगा ये क्या हैं और इनके बारे में क्या करें।

बहुत व्यापक permissions

Permission सिस्टम को कमज़ोर करने का सबसे तेज़ तरीका है बहुत कुछ allow कर देना।

प्रति-कमांड प्रॉम्प्ट घर्षण जोड़ते हैं—और आसान उपाय है एक व्यापक Bash(*) allow या defaultMode: bypassPermissions सेट करना। दोनों, permission सिस्टम की अधिकांश शक्ति को निष्प्रभावी कर देते हैं।

आपको allow नियमों को उन विशेष टूल्स और कमांड्स तक सीमित करना चाहिए जिन्हें आप वाकई उपयोग करते हैं (जैसे Bash(npm test:*) और Bash(git status))—और बाकी सब को प्रॉम्प्ट पर छोड़ देना चाहिए। शुरू में अधिक प्रॉम्प्ट मिलेंगे, पर कुछ सत्रों में ही आप अपने उपयोगी कमांड्स allow-list कर लेंगे और प्रॉम्प्ट अधिकांशतः रुक जाएंगे।

अनियंत्रित MCP एक्सेस

दूसरी गलती है MCP सर्वरों को जोड़े रखना—बिना यह देखे कि वे कौन-से क्रेडेंशियल्स उपयोग कर रहे हैं या वे कहाँ तक पहुँच सकते हैं।

यह आमतौर पर तब होता है जब कोई enableAllProjectMcpServers चालू कर देता है, सार्वजनिक MCP डायरेक्टरी से कुछ सर्वरों को जोड़ता है, और फिर उनकी समीक्षा करने नहीं लौटता। जब तक कोई कमजोर क्रेडेंशियल वाला सर्वर कुछ संवेदनशील चीज़ लीक करता है, कनेक्शन कॉन्फ़िगरेशन में इतना पीछे होता है कि किसी को याद भी नहीं रहता कि इसे कब मंजूरी दी गई थी।

उपाय permissions जैसा ही है—allowedMcpServers के जरिए स्पष्ट allowlist का उपयोग करें, सभी के लिए आवश्यक सर्वरों के लिए आंतरिक managed-mcp.json रखें, और सूची पर समय-समय पर समीक्षा करें।

Sandboxing न होना

यदि sandboxing बंद है, तो Claude और आपके फाइलसिस्टम के बीच केवल permission सिस्टम है।

यह छोटी इंटरैक्टिव सत्रों के लिए ठीक है—जहाँ आप वैसे भी हर कमांड अप्रूव कर रहे हैं। यह स्वायत्त रन, व्यापक allow नियमों वाले सत्रों, या बाहरी सोर्स कोड छूने वाले किसी भी काम के लिए ठीक नहीं है।

/sandbox इसे चालू कर देता है। यदि निर्भरताएँ इंस्टॉल नहीं हैं, तो मेन्यू आपको आपके प्लेटफ़ॉर्म के लिए क्या इंस्टॉल करना है, दिखा देगा। एक बार चालू होने पर, परमिशन प्रॉम्प्ट्स घटते हैं और OS वे मामले पकड़ता है जिन्हें आपके allow नियम कवर नहीं करते।

बिना जाँचे बदलाव स्वीकार करना

acceptEdits जितना सुविधाजनक है, उतना ही खतरनाक भी हो सकता है।

जब Claude कोई फ़ंक्शन फिर से लिख रहा हो और आप निगरानी कर रहे हों, तो ऑटो-एक्सेप्ट ठीक है। जब Claude एक घंटे में 30 फाइलों में बदलाव कर रहा हो, तो आप डिफ्स पढ़ना बंद कर देते हैं और एजेंट पर भरोसा करने लगते हैं—यहीं समस्या हो सकती है।

ये दो आदतें अपनाएँ:

• Claude को स्वायत्त रूप से चलने देने से पहले हमेशा कमिट करें—ताकि रोलबैक बस एक git reset दूर हो।

• हर Claude-लेखित कमिट से पहले डिफ की समीक्षा करें—न कि सत्र के अंत में संचयी डिफ की।

ऑडिट ट्रेल्स की अनदेखी

टेलीमेट्री के बिना Claude Code चलाने वाली टीम, "वह किस सत्र ने किया?" का जवाब नहीं दे सकती। ईवेंट्स हर मशीन पर लोकली जमा होते हैं और वहीं रहते हैं। ऑडिट ट्रेल की जरूरत पहली बार तब पड़ती है जब यह पता लगाना सबसे बुरा होता है कि आपने उसे कॉन्फ़िगर ही नहीं किया।

न्यूनतम उपयोगी आधाररेखा है—tool_decision, permission_decision, और api_request ईवेंट्स को उसी ऑब्ज़र्वेबिलिटी स्टैक में एक्सपोर्ट करना जिसे टीम पहले से चलाती है। वहाँ से, उपयोग मामलों के आते ही आप डैशबोर्ड और अलर्ट बनाते हैं।

निष्कर्ष

चैटबॉट के लिए सबसे खराब स्थिति एक गलत जवाब है। लेकिन कोडिंग एजेंट के लिए, यह आपके क्रेडेंशियल्स के साथ प्रोडक्शन पर चलने वाला शेल कमांड है।

इसीलिए ये तीन स्तंभ महत्वपूर्ण हैं:

• Permissions तय करती हैं Claude क्या करने की अनुमति रखता है
• MCP नियंत्रण तय करते हैं वह किन बाहरी सिस्टम्स तक पहुँच सकता है
• Sandboxing तय करता है जब पहले दो पर्याप्त नहीं होते तब क्या होता है

हर एक वह विफलता-दशा कवर करता है जिसे दूसरे नहीं करते। मिलकर, वे वह वास्तविक सीमा परिभाषित करते हैं जिसके भीतर Claude काम करता है।

यदि आप जनरेटिव AI में प्रमाणित होना चाहते हैं, तो यहाँ तुलना, शीर्ष कोर्स, तैयारी सुझाव, और सामान्य प्रश्न देखें: Best Generative AI Certifications in 2026.