MCP सर्वर AI मॉडल को आपके सिस्टम के अंदर काम करने देते हैं, जिससे टूल पॉइज़निंग, प्रॉम्प्ट इंजेक्शन और लीक हुए टोकन असली जोखिम बन जाते हैं। यहाँ सात ज़रूरी खतरे देखें, एक्सेस, हार्डनिंग और डेटा फ़्लो के लिए 20 पॉइंट की चेकलिस्ट, और एक दोपहर में पूरा होने वाला ऑडिट रूटीन।
MCP सर्वर आपके सिस्टम का एक ऐसा दरवाज़ा है जिसे AI मॉडल खुद खोल लेता है। जैसे ही कोई क्लाइंट, जैसे चैट असिस्टेंट या कोड एडिटर, जुड़ता है, मॉडल फ़ाइलें पढ़ सकता है, डेटाबेस से क्वेरी कर सकता है, इंटरनल API कॉल कर सकता है और संदेश भेज सकता है, आमतौर पर उस व्यक्ति की अनुमतियों के साथ जिसने सर्वर इंस्टॉल किया था। इसलिए MCP सुरक्षा के सर्वोत्तम तरीके पोस्टमॉर्टम में नहीं, बल्कि पहले स्प्रिंट में आने चाहिए। यह लेख उन जोखिमों का नक्शा बनाता है जो प्रोडक्शन में सचमुच सामने आते हैं, 20 पॉइंट की एक चेकलिस्ट देता है जिसे आप सीधे टिकट में चिपका सकते हैं, और एक ऐसे ऑडिट से गुज़रता है जिसे आपकी टीम एक दोपहर में पूरा कर सकती है।
अगर आप जल्दी में हैं, तो छोटा सार यह है: हर टूल विवरण को अविश्वसनीय इनपुट मानें, हर सर्वर को सबसे छोटा अनुमति सेट दें जो काम करे, सीक्रेट्स को मॉडल की पहुँच से बाहर रखें, और हर टूल कॉल को लॉग करें ताकि बाद में देखा जा सके कि क्या हुआ था।
क्लासिक API सुरक्षा यह मानकर चलती है कि आपके एंडपॉइंट को कॉल करने वाला कोड किसी डेवलपर ने लिखा है। MCP यह धारणा तोड़ता है। Model Context Protocol किसी भाषा मॉडल को रन टाइम पर, उस टेक्स्ट के आधार पर, टूल चुनने देता है जो वह पढ़ता है। टेक्स्ट जाली हो सकता है, और मॉडल भरोसे के साथ नहीं बता सकता कि कोई निर्देश वैध है या चुपके से डाला गया है। इसी कारण MCP सर्वर सुरक्षा REST API को लॉक करने से अलग समस्या है।
सामान्य इंटीग्रेशन में कोड भेजे जाने से पहले कोई इंसान उसके कोड पाथ की समीक्षा करता है। MCP में कॉलर एक प्रोबेबिलिस्टिक सिस्टम है जो टूल के नाम, विवरण और नतीजों को अपने प्रॉम्प्ट के हिस्से के रूप में पढ़ता है। टूल विवरण में छिपा एक वाक्य लगभग उतना ही वज़न रखता है जितना आपके अपने सिस्टम प्रॉम्प्ट का कोई वाक्य। यही एक तथ्य ज़्यादातर MCP घटनाओं को समझा देता है।
इससे यह भी बदल जाता है कि हमलावर कौन माना जाए। आपको सर्वर तक पहुँच की ज़रूरत नहीं है। जो भी मॉडल के सामने टेक्स्ट रख सकता है, वह उसे दिशा देने की कोशिश कर सकता है: किसी वेब पेज का लेखक, सपोर्ट टिकट दर्ज करने वाला ग्राहक, या सार्वजनिक रिपॉज़िटरी पर इश्यू खोलने वाला कोई अजनबी। अच्छी AI एजेंट सुरक्षा की शुरुआत इस स्वीकार से होती है कि इनपुट का रास्ता पूरी दुनिया के लिए खुला है।
कॉन्फ़िग की एक भी लाइन लिखने से पहले चार बाउंड्री खींच लें:
| बाउंड्री | क्या पार करता है | किस पर भरोसा है |
|---|---|---|
| यूज़र से क्लाइंट | प्रॉम्प्ट और मंज़ूरियाँ | साइन-इन यूज़र |
| क्लाइंट से सर्वर | टूल कॉल और नतीजे | केवल वे सर्वर जिन्हें आपने जाँचा है |
| सर्वर से बैकएंड | क्वेरी, फ़ाइलें, API कॉल | सीमित दायरे वाली सर्विस आइडेंटिटी |
| सर्वर से इंटरनेट | फ़ेच किए गए पेज, webhooks | कोई नहीं |
ट्रांसपोर्ट भी मायने रखता है। stdio पर लॉन्च किया गया लोकल सर्वर यूज़र की मशीन पर चल रही एक प्रोसेस है जो यूज़र की अनुमतियों के साथ चलती है, इसलिए कोई दुर्भावनापूर्ण पैकेज व्यावहारिक रूप से मनमाना कोड चलाने जैसा है। HTTP पर चलने वाला रिमोट सर्वर नेटवर्क एक्सपोज़र, ऑथेंटिकेशन और सेशन हैंडलिंग जोड़ता है। हर ट्रांसपोर्ट का अपना थ्रेट मॉडल चाहिए, और जो सर्वर दोनों देता है उसकी दो समीक्षाएँ होनी चाहिए।
💡 टिप: सबसे जोखिम भरा सेटअप वह है जिसमें एक एजेंट निजी डेटा पढ़ सकता है, अविश्वसनीय कंटेंट पढ़ सकता है और डेटा बाहर भेज सकता है। सुरक्षा शोधकर्ता इस संयोजन को "lethal trifecta" कहते हैं। इसका कम से कम एक हिस्सा हटा दें, और ज़्यादातर डेटा-लीक के रास्ते बंद हो जाते हैं।
हर खतरे को बराबर ध्यान नहीं चाहिए। ये सात बार-बार सार्वजनिक MCP शोध और घटना रिपोर्टों में दिखते हैं, और इनमें से हर एक नीचे की चेकलिस्ट के आइटमों से जुड़ता है।
| # | जोखिम | क्या होता है | आम असर |
|---|---|---|---|
| 1 | प्रॉम्प्ट इंजेक्शन | मॉडल किसी पेज, टिकट या फ़ाइल में छिपे निर्देश का पालन कर लेता है | डेटा लीक, अनचाही कार्रवाइयाँ |
| 2 | टूल पॉइज़निंग | टूल विवरण के अंदर दुर्भावनापूर्ण निर्देश होते हैं | चुपचाप डेटा चोरी |
| 3 | रग पुल | मंज़ूरी के बाद सर्वर अपने टूल बदल देता है | मंज़ूर किया गया अब मौजूदा जैसा नहीं रहा |
| 4 | लीक हुए क्रेडेंशियल | टोकन कॉन्फ़िग, लॉग या मॉडल कॉन्टेक्स्ट में पहुँच जाते हैं | अकाउंट पर कब्ज़ा |
| 5 | ज़रूरत से ज़्यादा अनुमतियाँ | सर्वर एडमिन स्कोप के साथ चलता है | एक गलती बड़ा उल्लंघन बन जाती है |
| 6 | टोकन पासथ्रू | सर्वर ऐसे टोकन आगे भेजता है जो उसके लिए जारी नहीं हुए थे | इरादे से परे पहुँच |
| 7 | सप्लाई चेन | मिलते-जुलते नाम वाले या बैकडोर वाले सर्वर पैकेज | कोड आपकी मशीन पर चलता है |
प्रॉम्प्ट इंजेक्शन सबसे बड़ा जोखिम है, क्योंकि इसके लिए किसी एक्सप्लॉइट कोड की ज़रूरत नहीं होती। 2025 में शोधकर्ताओं ने दिखाया कि एक GitHub इंटीग्रेशन को सार्वजनिक रिपॉज़िटरी के एक दुर्भावनापूर्ण इश्यू से इस तरह मोड़ा जा सकता था कि वह निजी रिपॉज़िटरी पढ़े और उसकी सामग्री वापस पोस्ट कर दे। मॉडल ने ठीक वही किया जो उससे कहा गया था। बस अनुरोध एक हमलावर की तरफ़ से आया था।
बचाव के तरीके जो काम करते हैं:
टूल पॉइज़निंग में निर्देश किसी टूल के विवरण या स्कीमा के अंदर छिपे होते हैं। आपको एक हानिरहित "दो संख्याएँ जोड़ें" टूल दिखता है। मॉडल को उसमें एक अतिरिक्त पैराग्राफ़ दिखता है जो उससे कहता है कि क्रेडेंशियल फ़ाइल पढ़े और उसकी सामग्री एक पैरामीटर के रूप में भेजे। रग पुल इसका धीमा रूप है: सर्वर समीक्षा के दौरान सामान्य व्यवहार करता है, फिर आपकी मंज़ूरी के बाद चुपचाप अपनी टूल परिभाषाएँ बदल देता है।
इसका उपाय उबाऊ है, लेकिन असरदार है। मंज़ूरी के समय पूरे टूल मैनिफ़ेस्ट (नाम, विवरण और स्कीमा) का हैश बनाएँ, हर कनेक्शन पर उसकी तुलना करें और हैश बदलने पर चलने से मना कर दें। यूज़र को छोटा सारांश नहीं, पूरा विवरण दिखाएँ।
सप्लाई चेन को अलग से देखना चाहिए। 2025 में npm पर प्रकाशित एक मिलते-जुलते नाम वाले ईमेल सर्वर के बारे में रिपोर्ट आई कि एक नियमित अपडेट के बाद वह आउटगोइंग संदेशों को एक बाहरी पते पर भेज रहा था। वर्ज़न पिन करना और allow-list रखना (चेकलिस्ट आइटम 9 और 10) इसका बचाव है।
सीक्रेट्स साधारण तरीकों से लीक होते हैं: कोई टोकन कॉन्फ़िग फ़ाइल में चिपका रह जाता है जो कमिट हो जाती है, कोई एनवायरनमेंट वेरिएबल डीबग लॉग में दिख जाता है, या डेटाबेस पासवर्ड किसी टूल नतीजे में लौटकर अब पूरे सेशन के लिए मॉडल के कॉन्टेक्स्ट में पड़ा है। एक बार सीक्रेट कॉन्टेक्स्ट में आ जाए, तो बाद का कोई भी इंजेक्शन मॉडल से उसे दोहराने को कह सकता है।
सीक्रेट्स को वॉल्ट या आपके ऑपरेटिंग सिस्टम के क्रेडेंशियल स्टोर में रखें, उन्हें सर्वर प्रोसेस को स्टार्ट-अप पर दें, और उन्हें आउटपुट में कभी वापस न लौटाएँ। ऐसे शॉर्ट-लिव्ड टोकन चुनें जो मिनटों में एक्सपायर हो जाएँ, क्योंकि चोरी हुआ टोकन जो दोपहर के खाने तक खत्म हो जाए, वह छोटी समस्या है।
एक सर्वर जिसे "बस टिकट पढ़ने हैं" अक्सर एडमिन टोकन के साथ आता है, क्योंकि डेमो तक पहुँचने का सबसे तेज़ रास्ता वही था। फिर एक इंजेक्टेड निर्देश टिकट बंद कर सकता है, ग्राहक सूचियाँ निर्यात कर सकता है या सेटिंग्स बदल सकता है। अनुमतियाँ ही ब्लास्ट रेडियस हैं, और उसका आकार आप पहले ही दिन चुनते हैं।
न्यूनतम विशेषाधिकार को सबसे संकीर्ण क्रिया तक लागू करें: पढ़ना, लिखना नहीं; एक प्रोजेक्ट, पूरा वर्कस्पेस नहीं; एक टेबल, पूरा डेटाबेस नहीं। जब कोई वेंडर केवल सब-या-कुछ-नहीं वाला टोकन दे, तो उसके सामने एक पतला प्रॉक्सी सर्वर रखें जो केवल वही कॉल दिखाए जिन्हें आप स्वीकार करते हैं।
इसे अपने ट्रैकर में चिपकाएँ और हर सर्वर को इसके आधार पर स्कोर करें। जो आज टिक न हो सके, वह एक ऐसा टिकट बन जाए जिसका ओनर और तारीख हो।
💡 टिप: आइटम 5, 11 और 17 लागू करने में सबसे सस्ते हैं और सबसे खतरनाक रास्ते बंद करते हैं: बिना मंज़ूरी की कार्रवाइयाँ, चुपचाप बदले गए टूल और नेटवर्क से बाहर जाता डेटा। अगर इस हफ़्ते समय कम है, तो वहीं से शुरू करें।
ऑडिट एक सवाल का जवाब देता है: मॉडल अभी क्या कर सकता है, और इसे किसने मंज़ूरी दी? एक दोपहर तय करें, एक इंजीनियर और एक सिक्योरिटी रिव्यूअर को बुलाएँ, और तीन चरणों में काम करें। पहले चरण से पहले एक पेज का थ्रेट मॉडल लिखें जिसमें चार सवालों के जवाब हों: एजेंट किस डेटा तक पहुँच सकता है, वह कौन सा अविश्वसनीय कंटेंट पढ़ता है, वह डेटा कहाँ भेज सकता है, और कौन सी कार्रवाइयाँ अपरिवर्तनीय हैं।
जिसकी सूची नहीं बनी, उसकी सुरक्षा नहीं हो सकती। क्लाइंट कॉन्फ़िग फ़ाइलों, IDE सेटिंग्स, साझा टीम रिपॉज़िटरी, CI पाइपलाइनों और उन "अस्थायी" सेटअप से सर्वर इकट्ठा करें जो कभी हटाए नहीं गए। हर एक के लिए यह दर्ज करें:
| फ़ील्ड | उदाहरण |
|---|---|
| नाम और स्रोत | वेंडर पैकेज, इंटरनल रिपॉज़िटरी या कम्युनिटी प्रोजेक्ट |
| ट्रांसपोर्ट | लोकल stdio या रिमोट HTTP |
| इस्तेमाल की गई पहचान | सर्विस अकाउंट, निजी टोकन या कोई नहीं |
| दिए गए स्कोप | टिकट पढ़ना, फ़ाइलें लिखना, एडमिन |
| जिस डेटा तक पहुँच है | ग्राहक रिकॉर्ड, सोर्स कोड, सार्वजनिक वेब |
| ओनर | एक नामित व्यक्ति, टीम एलियास नहीं |
अचंभों की उम्मीद रखें। टीमों को अक्सर ऐसे सर्वर मिलते हैं जिन्हें किसी को याद नहीं होता कि इंस्टॉल किए गए थे, और जो किसी निजी एडमिन टोकन के साथ चल रहे होते हैं।
पिछले तीस दिनों की टूल कॉल निकालें और उन पैटर्न को खोजें जो नहीं होने चाहिए: अजीब समय पर कॉल, असामान्य रूप से बड़े नतीजे, एजेंट द्वारा किसी बाहरी पेज को पढ़ने के ठीक बाद चलने वाले टूल, और ऐसे आर्गुमेंट जिनमें फ़ाइल पाथ या URL हों जिनका यूज़र ने ज़िक्र नहीं किया था। बड़े पैमाने पर ट्रायेज के लिए Claude Sonnet 5 जैसा मॉडल हज़ारों कॉल को अजीबियों की एक छोटी सूची में समूहित कर सकता है, बशर्ते कुछ भी भेजने से पहले आप सीक्रेट्स और निजी डेटा हटा दें।
हर निष्कर्ष को गंभीरता और डेडलाइन दें। पैमाना छोटा रखें ताकि लोग उसे सच में इस्तेमाल करें:
| गंभीरता | उदाहरण निष्कर्ष | ठीक करने की अवधि |
|---|---|---|
| गंभीर | साझा कॉन्फ़िग फ़ाइल में एडमिन टोकन | 24 घंटे |
| उच्च | बाहर जाने वाले ईमेल के लिए कोई मंज़ूरी स्टेप नहीं | 1 सप्ताह |
| मध्यम | बिना पिन किया गया सर्वर वर्ज़न | 30 दिन |
| कम | टेस्ट सर्वर पर ओनर नहीं | अगली समीक्षा |
हर बड़े बदलाव के बाद और कम से कम तिमाही में एक बार ऑडिट दोबारा चलाएँ। जनवरी में साफ़ रही सर्वर सूची जून में शायद ही साफ़ रहती है।
रोकथाम आखिरकार विफल होती है, इसलिए उस दिन की योजना बनाएँ। लक्ष्य है मिनटों में पता लगाना और एक घंटे के भीतर उसे रोक देना।
इतना लॉग करें कि सीक्रेट्स स्टोर किए बिना सेशन दोबारा बनाया जा सके। यूज़र, क्लाइंट, सर्वर, टूल नाम, आर्गुमेंट का हैश, नतीजे का आकार, लेटेंसी और मंज़ूरी का फ़ैसला दर्ज करें। पहले तीन संकेतों पर अलर्ट रखें: किसी एक टूल पर कॉल की बाढ़, किसी ऐसे टूल की कॉल जो पहले कभी इस्तेमाल नहीं हुआ, और एजेंट द्वारा बाहरी कंटेंट लाने के थोड़ी देर बाद आने वाले बड़े नतीजे।
हर सर्वर के पास एक ऑफ़ स्विच होना चाहिए जिसे एक व्यक्ति बिना डिप्लॉय के बंद कर सके। उसके टोकन रद्द करें, उसे allow-list से हटाएँ और उसने जिन सीक्रेट्स को छुआ था उन्हें रोटेट करें। फिर आखिरी ज्ञात-ठीक मैनिफ़ेस्ट हैश बहाल करें। यह हर तिमाही अभ्यास करें, ताकि पहली असली कोशिश ही पहला अभ्यास न बन जाए।
💡 प्लेटफ़ॉर्म की तरफ़ से एक सीमा भी मदद करती है। उदाहरण के लिए PicassoIA हर अकाउंट को हर कनेक्शन पर कुल 5 एक साथ चल रहे प्रेडिक्शन तक सीमित रखता है, ताकि कोई बेकाबू एजेंट कतार को न भर दे। अपने वेंडरों से पूछें कि उनकी सीमाएँ क्या हैं।
एक सेफ़्टी क्लासिफ़ायर अनुमतियों और मंज़ूरियों की जगह नहीं ले सकता, लेकिन यह एक उपयोगी फ़िल्टर जोड़ता है। Llama Guard 4 12B टेक्स्ट या इमेज पढ़ता है और संबंधित हानि श्रेणी के साथ safe या unsafe फ़ैसला लौटाता है, जिसमें हिंसा, नफ़रत और खतरनाक निर्देश जैसे क्षेत्र शामिल हैं। यह कोई समर्पित प्रॉम्प्ट इंजेक्शन डिटेक्टर नहीं है, इसलिए इसे ऊपर के नियंत्रणों के साथ एक परत के रूप में इस्तेमाल करें, जैसे यूज़र द्वारा भेजी गई चीज़ों और आपके एजेंट द्वारा वापस भेजे जाने वाले जवाब की जाँच के लिए।
| पैरामीटर | सुझाया गया मान | क्यों |
|---|---|---|
| Temperature | 0 | वही इनपुट, वही फ़ैसला |
| Max Completion Tokens | 64 से 128 | फ़ैसला छोटा होता है |
| System Prompt | पॉलिसी और सख्त आउटपुट फ़ॉर्मेट | कोड में पार्स करना आसान |
| Top P | 1 (डिफ़ॉल्ट) | Temperature 0 होने पर इसे न छुएँ |
| Image Input | जाँचने के लिए स्क्रीनशॉट | वैकल्पिक |
सुरक्षा का काम ज़्यादातर अदृश्य होता है, इसलिए उसे समझाना मुश्किल होता है। अच्छी विज़ुअल्स मदद करती हैं: रनबुक के लिए फ़ोटो हेडर, ट्रेनिंग स्लाइड के लिए परिदृश्य वाली तस्वीर, या इंटरनल विकी के लिए डेटा सेंटर का गलियारा। PicassoIA टेक्स्ट प्रॉम्प्ट को फोटोरियलिस्टिक इमेज और छोटे वीडियो में बदलता है, बिना किसी डिज़ाइन सॉफ़्टवेयर और बिना किसी स्टॉक फ़ोटो लाइसेंस का हिसाब रखे।
अभी जो विषय आपने पढ़ा है, उसी के साथ इसे आज़माएँ। कोई दृश्य बताएँ, जैसे "एक शांत सर्वर रूम में प्रिंट की हुई चेकलिस्ट देखता एक सिक्योरिटी इंजीनियर, नरम खिड़की की रोशनी, 35mm लेंस", उसे चलाएँ, फिर एंगल, रोशनी और लेंस तब तक बदलें जब तक वह आपके दस्तावेज़ में फ़िट न हो जाए। PicassoIA खोलें, पूरी मॉडल सूची देखें और आज ही अपने प्रॉम्प्ट्स के साथ प्रयोग करें।
अपनी भाषा चुनें
