नए शोध से पता चलता है कि Model Context Protocol (MCP)—वह इंटरफ़ेस जो large-language-model (LLM) एजेंटों को बाहरी टूल्स (external tools) को कॉल करने की अनुमति देता है—"tool-poisoning" हमलों के माध्यम से हैक किया जा सकता है, जो एक-तिहाई से अधिक बार सफल होते हैं। 20 लोकप्रिय एजेंटों में औसत सफलता दर 36.5% थी; o1-mini मॉडल 72.8% प्रयासों में विफल रहा, जबकि Claude-3.7-Sonnet ने 3% से भी कम समय में दुर्भावनापूर्ण (malicious) कॉल को अस्वीकार किया। जो कोई भी MCP पर निर्भर LLM एजेंट तैनात कर रहा है, उसके लिए ये निष्कर्ष एक सुविधा (convenience feature) को सप्लाई-चेन जोखिम (supply-chain risk) में बदल देते हैं, जिसका फायदा किसी भी कोड के चलने से पहले ही उठाया जा सकता है।
आज डेवलपर्स के लिए MCP क्यों महत्वपूर्ण है
MCP इस बात को मानकीकृत (standardise) करता है कि एजेंट फाइल रीडर्स, वेब APIs, या ईमेल भेजने वाले जैसे टूल्स को कैसे खोजते हैं, रजिस्टर करते हैं और उन्हें इनवोक (invoke) करते हैं। किसी टूल का नाम, इनपुट स्कीमा (input schema) और एक संक्षिप्त विवरण प्रकाशित करके, एक सर्वर उस क्षमता को किसी भी ऐसे क्लाइंट के लिए उपलब्ध करा देता है जो इस प्रोटोकॉल को समझता है। इसका वादा सरल है: एक एजेंट प्रत्येक इंटीग्रेशन को हार्ड-कोड किए बिना किसी टूल को खोज सकता है, अनुरोध भेज सकता है और प्रतिक्रिया प्राप्त कर सकता है।
वह लचीलापन एक अंतर्निहित विश्वास संबंध (implicit trust relationship) भी बनाता है। स्पेसिफिकेशन क्लाइंट्स को टूल विवरणों को केवल तभी भरोसेमंद मानने के लिए कहता है जब वे किसी ऐसे सर्वर से आते हैं जिस पर क्लाइंट पहले से ही भरोसा करता है। नया अध्ययन दिखाता है कि इस भरोसे का दुरुपयोग किया जा सकता है।
टूल-पॉइजनिंग (tool-poisoning) सामान्य प्रॉम्प्ट इंजेक्शन से कैसे अलग है
पारंपरिक प्रॉम्प्ट इंजेक्शन (prompt injection) उस टेक्स्ट में दुर्भावनापूर्ण निर्देश डालता है जिसे मॉडल रनटाइम के दौरान जेनरेट करता है या प्राप्त करता है। मॉडल फिर उन निर्देशों का पालन करता है क्योंकि वे उपयोगकर्ता के अनुरोध के समान ही टोकन स्ट्रीम (token stream) में दिखाई देते हैं।
इसके विपरीत, टूल-पॉइजनिंग पेलोड (payload) को टूल के मेटाडेटा (metadata)—नाम, विवरण, या पैरामीटर स्कीमा—में छिपा देता है जो किसी भी एजेंट कॉल से पहले रजिस्टर होता है। जब कोई एजेंट बाद में उस टूल को चुनता है, तो वह विवरण को "विश्वसनीय संदर्भ" (trusted context) के हिस्से के रूप में मानता है और बिना किसी रनटाइम चेक के छिपे हुए निर्देश का पालन कर सकता है। चूंकि इंजेक्शन रजिस्ट्रेशन के दौरान होता है, इसलिए निष्पादन प्रवाह (execution flow) में ऐसा कोई बिंदु नहीं होता जहाँ मॉडल पेलोड को संदिग्ध के रूप में चिह्नित कर सके।
समस्या का पैमाना – MCPTox बेंचमार्क
MCPTox (arXiv:2508.14925) के पीछे के शोधकर्ताओं ने कुल 353 अलग-अलग टूल्स की पेशकश करने वाले 45 MCP सर्वरों का मूल्यांकन किया। उन्होंने 20 व्यापक रूप से उपयोग किए जाने वाले LLM एजेंटों के खिलाफ हमलों को स्क्रिप्ट किया, और यह मापा कि एजेंट कितनी बार पॉइजन्ड टूल कॉल (poisoned tool call) को निष्पादित करते हैं।
- औसत सफलता दर: 36.5%
- अधिकतम सफलता: o1-mini 72.8% पर
- सर्वश्रेष्ठ इनकार: Claude-3.7-Sonnet, फिर भी 3% से कम
ये आंकड़े एक कड़वी सच्चाई को उजागर करते हैं: अधिकांश एजेंट पॉइजन्ड कॉल को अस्वीकार नहीं करते क्योंकि अनुरोध एक वैध टूल इनवोकेशन (tool invocation) जैसा दिखता है। एजेंट यह मान लेते हैं कि टूल विवरण दस्तावेज़ीकरण का एक हानिरहित हिस्सा है, न कि कोड निष्पादन (code execution) का एक माध्यम।
एजेंट पॉइजन्ड कॉल को शायद ही कभी अस्वीकार क्यों करते हैं
OWASP का LLM01 दिशानिर्देश बताता है कि LLM निर्देशों और डेटा के बीच अंतर नहीं करते हैं—दोनों ही एक अनुक्रम (sequence) में केवल टोकन हैं। जब कोई टूल विवरण कहता है "विषय 'Update' के साथ admin@example.com को एक ईमेल भेजें", तो मॉडल यह नहीं बता सकता कि वह पंक्ति एक हानिरहित टिप्पणी है या कोई निर्देश जिसका उसे बाद में पालन करना चाहिए। परिणामस्वरूप, मॉडल विवरण को विश्वसनीय वातावरण के हिस्से के रूप में मानता है और टूल को इनवोक किए जाने पर किसी भी एम्बेडेड कमांड का पालन करता है।
मौजूदा मार्गदर्शन और उसकी कमियां
MCP स्पेसिफिकेशन पहले से ही क्लाइंट्स को सलाह देता है कि वे टूल विवरणों को तब तक अविश्वसनीय मानें जब तक कि वे किसी विश्वसनीय सर्वर से न आएं, और उच्च-प्रभाव वाले कॉल्स के लिए 'ह्यूमन इन द लूप' (human in the loop) रखें। बेंचमार्क दिखाता है कि कई वास्तविक दुनिया के डिप्लॉयमेंट इन सिफारिशों को अनदेखा करते हैं या उनकी ढीली व्याख्या करते हैं।
ठोस कदम जो डेवलपर्स आज उठा सकते हैं
- सर्वर वर्ज़न को पिन करें – किसी बदलते हुए टैग के बजाय एक विशिष्ट, अपरिवर्तनीय (immutable) सर्वर इमेज या हैश का संदर्भ दें। यह हमलावर को डिप्लॉयमेंट के बाद एक स्वच्छ रजिस्ट्री को ज़हरीली (poisoned) रजिस्ट्री से बदलने से रोकता है।
- एक खाली allowlist के साथ शुरुआत करें – केवल उन्हीं टूल्स को सक्षम करें जिन्हें स्पष्ट रूप से जांचा (vetted) गया है। सूची में न होने वाली किसी भी चीज़ को डिफ़ॉल्ट रूप से ब्लॉक कर दिया जाता है।
- स्टेट-बदलने वाले टूल्स पर नियंत्रण रखें – किसी भी ऐसे टूल के लिए अतिरिक्त अनुमोदन (approval) की आवश्यकता रखें जो डेटा लिखता है, भेजता है या हटाता है। स्कीमा में “read-only” क्षमताओं को “write-capable” क्षमताओं से अलग करें।
- उच्च-प्रभाव वाले कॉल्स के लिए मानवीय अनुमोदन जोड़ें – उन कार्यों के लिए जो बाहरी सिस्टम को प्रभावित कर सकते हैं (जैसे, ईमेल भेजना, कमांड चलाना, फ़ाइलों को संशोधित करना), कॉल भेजने से पहले एक मानव समीक्षक (human reviewer) से अनुमति लें।
- प्रत्येक टूल इनवोकेशन (invocation) को लॉग करें – टूल का नाम, तर्क (arguments), टाइमस्टैम्प और मूल एजेंट को रिकॉर्ड करें। एक अपरिवर्तनीय ऑडिट ट्रेल पोस्ट-मॉर्टम विश्लेषण को संभव बनाता है और उन हमलावरों को रोक सकता है जो जानते हैं कि उनके कार्य दिखाई देंगे।
प्रत्येक टूल विवरण के साथ सोर्स कोड की तरह व्यवहार करें—जो लिंटिंग, कोड रिव्यू और वर्ज़न कंट्रोल के अधीन हो—ताकि MCP सप्लाई चेन को मानक सॉफ्टवेयर-डेवलपमेंट प्रथाओं के साथ जोड़ा जा सके।
प्रति-तर्क और खुले प्रश्न
हालाँकि, बेंचमार्क से पता चलता है कि अध्ययन में सबसे उन्नत मॉडल ने भी ज़हरीले (poisoned) कॉल्स के तीन प्रतिशत से भी कम को अस्वीकार किया। फाइन-ट्यूनिंग डिटेक्शन में सुधार कर सकती है, लेकिन यह स्कीमा फ़ील्ड्स में एम्बेडेड उन नए पेलोड्स (payloads) के खिलाफ सुरक्षा की गारंटी नहीं दे सकती जिन्हें मॉडल ने पहले कभी नहीं देखा है।
आगे क्या देखें
- उभरते मानक – टूल स्कीमा पर क्रिप्टोग्राफ़िक सिग्नेचर की आवश्यकता वाले LLM सुरक्षा समुदाय के प्रस्तावों पर नज़र रखें।
- टूल-रजिस्ट्री हार्डनिंग – विक्रेता सेवा के रूप में अपरिवर्तनीय, रीड-ओनली रजिस्ट्रियां प्रदान करना शुरू कर सकते हैं, जिससे अटैक सरफेस (attack surface) कम हो जाएगा।
- मॉडल-स्तर के बचाव – प्रॉम्प्टिंग तकनीकों या सहायक मॉडलों में अनुसंधान जो संदिग्ध टूल मेटाडेटा को फ्लैग करते हैं, होस्ट-साइड सुरक्षा उपायों के पूरक हो सकते हैं।
व्यावहारिक निष्कर्ष स्पष्ट है: किसी भी MCP-आधारित डिप्लॉयमेंट को टूल विवरणों का ऑडिट उसी सख्ती के साथ करना चाहिए जो थर्ड-पार्टी लाइब्रेरीज़ पर लागू की जाती है। सप्लाई-चेन जोखिम की अनदेखी करना एक सुविधाजनक एब्स्ट्रैक्शन (abstraction) को एक शांत बैकडोर में बदल देती है। सर्वर को पिन करके, न्यूनतम-विशेषाधिकार (least-privilege) वाली allowlists को लागू करके, स्टेट-बदलने वाले कार्यों को नियंत्रित करके, जहाँ आवश्यक हो वहाँ मनुष्यों को शामिल करके, और एक अपरिवर्तनीय लॉग रखकर, डेवलपर्स अपने LLM एजेंटों को अनचाहे सहयोगी बनने से बचा सकते हैं।