OWASP MCP Top 10: हर जोखिम उदाहरणों के साथ समझें

एक अकेला MCP सर्वर एक ही दोपहर में AI एजेंट को आपकी रिपॉज़िटरी, आपका इनबॉक्स और आपका डेटाबेस सौंप सकता है, और उसे मंज़ूरी देने में अक्सर बस एक क्लिक लगता है। ठीक यही सुविधा वह चीज़ है जिसका विरोध करने के लिए OWASP MCP Top 10 बना है। यह दस उन जोखिमों के नाम बताता है जो Model Context Protocol की किसी भी तैनाती को डुबो सकते हैं, लीक हुए टोकन से लेकर ऐसे सर्वरों तक जिनके बारे में सिक्योरिटी टीम में किसी को पता नहीं होता। यह लेख हर प्रविष्टि को क्रम से देखता है, दिखाता है कि असली या दस्तावेज़ित उदाहरण में हमला कैसा दिखता है, और हर सेक्शन के अंत में वह फ़िक्स बताता है जो सबसे पहले करना चाहिए।

यह सूची OWASP MCP Top 10 प्रोजेक्ट, संस्करण 2025 से ली गई है, जिसका नेतृत्व Vandana Verma Sehgal कर रही हैं। प्रोजेक्ट पेज पर अभी इसे बीटा और पायलट टेस्टिंग चरण में बताया गया है, इसलिए शब्दों और क्रम में बदलाव हो सकता है। इन दस प्रविष्टियों को एक साझा शब्दावली की तरह लें, अंतिम मानक की तरह नहीं।

OWASP MCP Top 10 क्या है

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

Top 10 उन जगहों को दिखाता है जहाँ यह भरोसा टूटता है। एक नज़र में सभी दस यहाँ हैं:

💡 Naming note: प्रोजेक्ट का ओवरव्यू पेज छठी प्रविष्टि को "Prompt Injection via Contextual Payloads" कहता है, जबकि MCP06 का डिटेल पेज इसे "Intent Flow Subversion" शीर्षक देता है। दोनों एक ही स्थान की ओर इशारा करते हैं, और यह लेख डिटेल पेज वाला शीर्षक इस्तेमाल करता है।

सीक्रेट, परमिशन और ज़हरीले टूल

MCP01: टोकन का गलत प्रबंधन और सीक्रेट का उजागर होना

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

OWASP का परिदृश्य: एक डेवलपर टेस्टिंग के दौरान सीक्रेट कमिट कर देता है, MCP सर्वर उसे स्टार्टअप पर पढ़ लेता है, और बाद में असिस्टेंट किसी दूसरे व्यक्ति के जवाब में उसे प्रिंट कर देता है।

क्या करें:

• स्थायी टोकन की जगह शॉर्ट-लिव्ड, सीमित दायरे वाले टोकन जारी करें।
• रिपॉज़िटरी और CI पाइपलाइन पर सीक्रेट स्कैनिंग चलाएँ।
• सीक्रेट को टूल विवरण, सिस्टम प्रॉम्प्ट और उदाहरण पेलोड से बाहर रखें।
• किसी संदिग्ध लीक के बाद तुरंत रोटेट करें।

💡 टिप: जिन सीक्रेट का कोई तय प्रीफ़िक्स होता है, उन्हें ढूँढना आसान होता है। PicassoIA API सीक्रेट pia_sk_ से शुरू होते हैं, इसलिए एक लाइन का स्कैनर नियम किसी भी रिपॉज़िटरी में उन्हें फ़्लैग कर सकता है। आप जिस भी प्रोवाइडर का इस्तेमाल करते हैं, उसके लिए ऐसा ही नियम जोड़ें।

MCP02: Privilege Escalation via Scope Creep

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

OWASP का परिदृश्य: एक सार्वजनिक GitHub इश्यू में छिपा प्रॉम्प्ट इंजेक्शन एक ऐसे एजेंट को मोड़ देता है जिसके पास व्यापक रिपॉज़िटरी एक्सेस है, और वह एजेंट निजी कोड को एक सार्वजनिक pull request में कॉपी कर देता है।

क्या करें:

• लीस्ट प्रिविलेज के हिसाब से डिज़ाइन करें: हर टास्क के लिए एक स्कोप, न कि हर टीम के लिए एक स्कोप।
• हर ग्रांट पर अपने-आप एक्सपायरी लगाएँ।
• रीड टूल्स को राइट टूल्स से अलग करें, ताकि उनकी मंज़ूरी अलग-अलग हो सके।
• एजेंट की परमिशन की समीक्षा तय समय पर करें, ठीक वैसे ही जैसे इंसानी एक्सेस की करते हैं।

MCP03: Tool Poisoning

मॉडल टूल के नाम और विवरण पढ़कर उन्हें चुनते हैं, इसलिए ये विवरण ही हमले की सतह बन जाते हैं। एक ज़हरीला टूल अपने मेटाडेटा, स्कीमा या आउटपुट में निर्देश छिपा देता है। अप्रैल 2025 में Invariant Labs ने इस हमले को एक मासूम दिखने वाले जोड़ (addition) टूल से दिखाया, जिसके छिपे विवरण ने एजेंट को एक लोकल MCP कॉन्फ़िग फ़ाइल और एक SSH प्राइवेट फ़ाइल पढ़ने, और उनकी सामग्री एक अतिरिक्त पैरामीटर में आगे भेजने को कहा, जबकि जवाब में गणित की बातें हो रही थीं।

इसका एक और खतरनाक रूप rug pull है: कोई टूल जब आप उसे मंज़ूर करते हैं, तब ठीक व्यवहार करता है, फिर इंस्टॉल होने के बाद अपना विवरण बदल देता है।

क्या करें:

• टूल के वर्ज़न पिन करें और मंज़ूरी के समय हर विवरण का हैश सहेजें।
• विवरण या स्कीमा में किसी भी बदलाव पर अलर्ट दें।
• उपयोगकर्ताओं को छोटा सारांश नहीं, बल्कि टूल का पूरा विवरण दिखाएँ।
• ऐसे पब्लिशर के साइन किए टूल को प्राथमिकता दें जिनका नाम आप बता सकें।

MCP04: सप्लाई चेन हमले और डिपेंडेंसी से छेड़छाड़

MCP सर्वर किसी और का लिखा कोड होता है, जिसे एक रजिस्ट्री से खींचा जाता है। एक समझौता किया गया या नकली पैकेज वही एक्सेस पा लेता है जो आप असली पैकेज को देते हैं। सितंबर 2025 में postmark-mcp नाम का एक npm पैकेज एक असली Postmark इंटीग्रेशन की नकल था, जिसमें एक अतिरिक्त लाइन जोड़ी गई थी जो हर बाहर जाने वाले ईमेल की एक ब्लाइंड कॉपी एक ऐसे पते पर भेजती थी जिसे हमलावर नियंत्रित करता था। Koi Security के शोधकर्ताओं ने इसे असल इस्तेमाल में देखा गया पहला दुर्भावनापूर्ण MCP सर्वर बताया, और Snyk के लेख में इसकी विस्तृत जानकारी है। इसे हटाए जाने से पहले यह हर हफ़्ते लगभग 1,500 डाउनलोड खींच रहा था।

क्या करें:

• AI बिल ऑफ़ मटीरियल्स रखें: हर सर्वर, उसका वर्ज़न और उसका स्रोत।
• सटीक वर्ज़न पिन करें और हर अपग्रेड से पहले डिफ़ पढ़ें।
• केवल उन्हीं पब्लिशर से इंस्टॉल करें जिन्हें आप सत्यापित कर सकें, और साइन किए रिलीज़ को प्राथमिकता दें।
• सर्वर मंज़ूर होने से पहले डिपेंडेंसी स्कैनिंग चलाएँ, और अनजाने सर्वरों को समीक्षा तक बिना नेटवर्क एक्सेस वाले कंटेनर में चलाएँ।

MCP05: कमांड इंजेक्शन और एक्ज़ीक्यूशन

एजेंट टेक्स्ट से कमांड बनाते हैं। जब वह टेक्स्ट हमलावर के नियंत्रण में हो (कोई इश्यू कमेंट, फ़ाइल का नाम या कोई वेब पेज), तो बाकी काम शेल कर देता है। Cycode के इस सूची के विश्लेषण के अनुसार, mcp-remote में CVE-2025-6514 का CVSS स्कोर 9.6 था, यह एक ऐसे पैकेज को प्रभावित करता था जिसके 4,37,000 से ज़्यादा डाउनलोड थे, और इससे OS कमांड इंजेक्शन संभव था। यह इस प्रविष्टि और MCP04 की सीमा पर बैठता है।

जोखिम भरे और सुरक्षित तरीके में अंतर अक्सर एक ही लाइन का होता है:

import re
import subprocess

# Risky: untrusted text is spliced into a shell string
subprocess.run(f"git log --author={author}", shell=True)

# Safer: fixed command, argument list, validated input, no shell
if not re.fullmatch(r"[A-Za-z0-9._@][A-Za-z0-9 ._@-]{0,63}", author):
    raise ValueError("invalid author")
subprocess.run(["git", "log", "--author", author], shell=False, check=True)

प्रॉम्प्ट कॉपी करें

क्या करें:

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

हाईजैक्ड इरादा और खुले दरवाज़े

MCP06: Intent Flow Subversion

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

सबसे स्पष्ट असली मामला मई 2025 में Invariant Labs का था, जो आधिकारिक GitHub MCP सर्वर के खिलाफ़ था। एक हमलावर एक सार्वजनिक रिपॉज़िटरी में दुर्भावनापूर्ण इश्यू खोलता है। जब मालिक अपने एजेंट से खुले इश्यू देखने को कहता है, तो एजेंट वह इश्यू पढ़ता है, इंजेक्ट हो जाता है, निजी रिपॉज़िटरी से डेटा अपने कॉन्टेक्स्ट में खींचता है, और उसे सार्वजनिक रिपॉज़िटरी के एक pull request में प्रकाशित कर देता है। शोधकर्ताओं ने इसे एक ज़हरीला एजेंट फ़्लो कहा, बताया कि यह सर्वर कोड के बग के बजाय एक आर्किटेक्चर की समस्या है, और अनुमान लगाया कि कई लोग "हमेशा अनुमति दें" वाली मंज़ूरी नीति चुनते हैं, जो इंसानी जाँच को हटा देती है।

क्या करें:

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

💡 टिप: क्लासिफ़ायर एक परत है, पूरी सुरक्षा नहीं। PicassoIA पर Llama Guard 4 12B एक कंटेंट मॉडरेशन मॉडल है जो टेक्स्ट को आपके एजेंट तक पहुँचने से पहले स्क्रीन कर सकता है, लेकिन यह एक सेफ़्टी क्लासिफ़ायर है, कोई समर्पित इंजेक्शन डिटेक्टर नहीं, इसलिए मंज़ूरी और लीस्ट प्रिविलेज को बनाए रखें।

MCP07: अपर्याप्त ऑथेंटिकेशन और ऑथराइज़ेशन

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

इसका एक ठोस उदाहरण Anthropic के MCP Inspector में CVE-2025-49596 है, जिसे CVSS 9.4 रेट किया गया था। 0.14.1 से पहले के वर्ज़न में Inspector क्लाइंट और उसके प्रॉक्सी के बीच कोई ऑथेंटिकेशन नहीं था, इसलिए बिना प्रमाणीकरण के अनुरोध stdio पर कमांड चला सकते थे। एक ब्राउज़र की खामी और cross-site request forgery के साथ जुड़कर, बस एक दुर्भावनापूर्ण वेबसाइट खोलने से डेवलपर की मशीन पर कोड चल सकता था।

क्या करें:

• लोगों के लिए मल्टी-फ़ैक्टर ऑथेंटिकेशन के साथ OAuth 2.1 इस्तेमाल करें।
• हर सर्वर के लिए टोकन की ऑडियंस वैलिडेट करें, ताकि एक सर्वर के लिए बना टोकन दूसरे पर विफल हो जाए।
• साझा खातों की जगह सेवाओं को मैनेज्ड आइडेंटिटी दें।
• लोकल सर्वरों को localhost तक सीमित रखें और वहाँ भी टोकन ज़रूरी करें।
• परमिशन हर टूल कॉल पर जाँचें, न कि सेशन में एक बार।

नज़र से छूटी कमियाँ और शैडो सर्वर

MCP08: ऑडिट और टेलीमेट्री की कमी

लॉग के बिना, इस सूची का बाकी हर जोखिम अदृश्य हो जाता है। टोकन की चोरी, कमांड इंजेक्शन और प्रॉम्प्ट इंजेक्शन, सब बिना किसी रिकॉर्ड के हो सकते हैं, और घटना की जाँच अंदाज़े का खेल बन जाती है। यह प्रविष्टि बाकी नौ को और बढ़ा देती है।

एक काम का टूल-कॉल लॉग छोटा होता है। हर कॉल के लिए ये रिकॉर्ड करें:

क्या करें:

• लॉग ऐसे इमेज़्युटेबल स्टोरेज में लिखें जिसे एजेंट बदल न सके।
• पैटर्न पर अलर्ट दें, जैसे निजी डेटा के कई रीड के बाद किसी सार्वजनिक जगह पर लिखना।
• अलग-अलग कॉल के बजाय पूरी कार्रवाई की श्रृंखलाएँ देखें।

MCP09: Shadow MCP Servers

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

पहले कहाँ देखें:

• डेवलपर के लैपटॉप और साझा रिपॉज़िटरी की MCP कॉन्फ़िग फ़ाइलें।
• CI/CD पाइपलाइन और कंटेनर रजिस्ट्री।
• क्लाउड अकाउंट, असामान्य पोर्ट पर सुनने वाले लिस्नर के लिए।
• डेस्कटॉप ऐप और एडिटर एक्सटेंशन, जो अपनी सर्वर एंट्री जोड़ सकते हैं।

क्या करें:

• इन जगहों की लगातार स्कैनिंग चलाएँ, सालाना ऑडिट नहीं।
• allowlist लागू करें ताकि क्लाइंट अज्ञात सर्वरों को मना कर दे।
• प्लेटफ़ॉर्म स्तर पर डिफ़ॉल्ट क्रेडेंशियल पर रोक लगाएँ।

MCP10: कॉन्टेक्स्ट इंजेक्शन और ओवर-शेयरिंग

साझा या लगातार चलने वाली कॉन्टेक्स्ट विंडो लीक होती हैं। जब एक एजेंट कई यूज़र या टेनेंट की सेवा करता है और कॉन्टेक्स्ट अलग नहीं होता, तो एक व्यक्ति का डेटा दूसरे व्यक्ति के सेशन में दिख सकता है। OWASP का परिदृश्य एक ऐसा एजेंट है जो कई यूज़र की सेवा करता है और एक यूज़र का निजी डेटा किसी दूसरे सेशन में लीक कर देता है।

यह एक असली प्रोडक्ट के साथ हो चुका है। BleepingComputer ने रिपोर्ट किया कि जून 2025 में Asana ने यूज़र को चेताया कि उसके नए MCP फ़ीचर की एक लॉजिक खामी ने कुछ संगठनों का डेटा दूसरों के सामने खोल दिया। लगभग 1,000 ग्राहक प्रभावित हुए, और Asana ने बग ठीक करते समय 5 जून से 17 जून तक यह फ़ीचर बंद रखा। यह एक लॉजिक एरर था, हैक नहीं, और यह खामी Asana के इसे पकड़ने से पहले लगभग एक महीने तक सक्रिय रही।

क्या करें:

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

किन जोखिमों को पहले ठीक करें

आप दस को एक हफ़्ते में बंद नहीं कर सकते, इसलिए वहीं से शुरू करें जहाँ नुकसान सबसे बड़ा है और काम सबसे छोटा।

सबसे ज़्यादा असर, सबसे कम मेहनत

• MCP01: सीक्रेट स्कैनिंग चालू करें और टोकन की अवधि घटाएँ।
• MCP07: हर सर्वर के सामने ऑथेंटिकेशन लगाएँ, localhost वालों समेत।
• MCP09: आज आपकी टीम जितने सर्वर चलाती है, उन सबकी सूची बनाएँ। जिसे आपने गिना नहीं, उसकी सुरक्षा नहीं कर सकते।

धीमे पर ज़रूरी

• MCP03 और MCP04: पिनिंग और हैशिंग के लिए असली सेटअप चाहिए, लेकिन ये चुपचाप होने वाले बदलाव रोकते हैं।
• MCP06: मंज़ूरी और गार्डरेल को डिज़ाइन और लगातार ट्यूनिंग चाहिए।
• MCP08 और MCP10: लॉगिंग और आइसोलेशन आर्किटेक्चर को छूते हैं, इसलिए इन्हें प्रोजेक्ट की तरह प्लान करें।
• MCP02 और MCP05: ये बीच में आते हैं; हर सर्वर की समीक्षा करते समय स्कोप कसें।

एक-हफ़्ते की हार्डनिंग योजना

💡 आम गलतियाँ: क्लिक कम करने के लिए "हमेशा अनुमति दें" मंज़ूर करना, केवल ज़्यादा डाउनलोड होने के कारण किसी सर्वर पर भरोसा करना, और वे टूल आर्गुमेंट छोड़कर सब कुछ लॉग करना जो मायने रखते हैं।

अपने सिक्योरिटी विज़ुअल खुद बनाएँ

सिक्योरिटी चेकलिस्ट तब ज़्यादा असर करती है जब लोग उसे मन में तस्वीर की तरह देख सकें। इस लेख की हर इमेज एक अमूर्त खामी के लिए एक सरल, भौतिक प्रतीक इस्तेमाल करती है: स्कोप क्रीप के लिए टैगों से भरा हुआ छल्ला, कमज़ोर ऑथेंटिकेशन के लिए खुला दरवाज़ा, और ऑडिट ट्रेल की कमी के लिए खाली लॉगबुक। आप ऐसे ही विज़ुअल अपने थ्रेट मॉडल, ट्रेनिंग डेक और इंटरनल विकी के लिए बना सकते हैं।

PicassoIA पर आज़माएँ। Seedream 5 Pro, Qwen Image 3 या GPT Image 2 जैसा टेक्स्ट-टू-इमेज मॉडल खोलें, एक असली वस्तु बताएँ जो आपके जोखिम का प्रतीक बने, और जो रोशनी व लेंस चाहिए वे जोड़ें। कुछ वेरिएशन जनरेट करें, सबसे साफ़ चुनें और उसे अपनी अगली समीक्षा में लगाएँ। अगर आप दस्तावेज़ भी लिखते हैं, तो PicassoIA के लार्ज लैंग्वेज मॉडल पहला ड्राफ़्ट बनाने में मदद कर सकते हैं, जिसे आप बाद में हाथ से संपादित कर सकते हैं।