क्यों अधिकांश AI टूल इंटीग्रेशन खतरनाक रूप से असुरक्षित हैं
सब कुछ जोड़ने की होड़
AI टूलिंग में अभी एक गोल्ड रश हो रहा है। हर कंपनी चाहती है कि उसका उत्पाद "AI-नेटिव" हो। हर डेवलपर जितनी तेज़ी से हो सके MCP सर्वर, फंक्शन-कॉलिंग एंडपॉइंट और टूल इंटीग्रेशन जोड़ रहा है।
कोई रुककर वो स्पष्ट सवाल नहीं पूछ रहा: जब कुछ गलत हो जाए तो क्या होगा?
मैं बग की बात नहीं कर रहा। बग सामान्य हैं। मैं adversarial हमलों की बात कर रहा हूं। क्या होगा जब कोई ऐसा टूल विवरण बनाए जो AI एजेंट को कुछ ऐसा करने पर मजबूर करे जो उसके उपयोगकर्ता ने कभी इरादा नहीं किया?
यह काल्पनिक नहीं है। ये हमले पहले से ही लैब में काम करते हैं। अभी तक कोई बड़ी घटना नहीं हुई इसका एकमात्र कारण यह है कि अधिकांश MCP डिप्लॉयमेंट अभी भी इतने छोटे हैं कि हमलावरों ने परवाह नहीं की।
टूल पॉइज़निंग नया SQL इंजेक्शन है
2005 में, SQL इंजेक्शन हर जगह था क्योंकि डेवलपर्स यूज़र इनपुट पर भरोसा करते थे। 2026 में, टूल पॉइज़निंग हर जगह है क्योंकि डेवलपर्स टूल विवरणों पर भरोसा करते हैं।
यह ऐसे काम करता है। एक MCP टूल का एक विवरण होता है जो AI को बताता है कि वह क्या करता है। AI उस विवरण को पढ़ता है और तय करता है कि टूल को कब और कैसे इस्तेमाल करना है। लेकिन अगर विवरण झूठ बोले तो? अगर "search_documents" नामक टूल में वास्तव में छिपे निर्देश हों जो AI को पहले सारा बातचीत संदर्भ एक बाहरी एंडपॉइंट पर भेजने को कहें?
AI अंतर नहीं बता सकता। वह विवरण पढ़ता है, निर्देशों का पालन करता है, और उपयोगकर्ता को कभी पता नहीं चलता। यह टूल पॉइज़निंग है, और यह विनाशकारी रूप से प्रभावी है।
समाधान सिद्धांत में जटिल नहीं है: सत्यापित करें कि विवरण व्यवहार से मेल खाते हैं। लेकिन लगभग कोई यह नहीं करता।
तीन हमले जिनकी आपको चिंता करनी चाहिए
MCP टूल्स के साथ निर्माण करने वाली हर टीम को तीन श्रेणियों के हमलों को समझना चाहिए।
पहला: टूल पॉइज़निंग। विवरण झूठ बोलता है कि टूल क्या करता है। सबसे आम और निष्पादित करने में सबसे आसान।
दूसरा: व्यवहार बेमेल। टूल वही करता है जो दावा करता है, लेकिन कुछ अतिरिक्त भी करता है। एक फ़ाइल रीडर जो छिपे लॉग में भी लिखता है। एक डेटाबेस क्वेरी टूल जो आपका स्कीमा भी निर्यात करता है।
तीसरा: अनुमति वृद्धि। एक टूल जो केवल-पढ़ने की पहुंच से शुरू होता है और धीरे-धीरे लिखने की पहुंच मांगता (या मान लेता) है। यह विशेष रूप से खतरनाक है क्योंकि यह अक्सर सामान्य टूल विकास जैसा दिखता है।
इनमें से प्रत्येक को पारंपरिक सुरक्षा उपकरणों से पकड़ना कठिन है। SAST स्कैनर कोड की कमजोरियों की तलाश करते हैं, विवरण और कार्यान्वयन के बीच सिमेंटिक बेमेल की नहीं।
पारंपरिक सुरक्षा उपकरण यहां क्यों विफल होते हैं
यह समस्या इतनी खतरनाक होने का कारण यह है कि यह मौजूदा सुरक्षा विषयों के बीच एक अंतर में आती है।
एप्लिकेशन सुरक्षा टीमें XSS और SQL इंजेक्शन खोजना जानती हैं। इन्फ्रास्ट्रक्चर टीमें नेटवर्क को सुरक्षित करना जानती हैं। लेकिन टूल पॉइज़निंग कोड की कमजोरी नहीं है — यह सिमेंटिक कमजोरी है। कोड तकनीकी रूप से सही है। वह वही करता है जो प्रोग्राम किया गया है। समस्या यह है कि जो प्रोग्राम किया गया है वह उससे मेल नहीं खाता जो दावा किया गया है।
इसके लिए एक नई तरह के सुरक्षा विश्लेषण की आवश्यकता है। आपको टूल विवरणों को पार्स करना होगा, समझना होगा कि वे क्या वादा करते हैं, फिर वास्तविक कार्यान्वयन का विश्लेषण करना होगा।
यह कठिन है। यह उस तरह की कठिन समस्या है जो breach होने तक अनदेखी रहती है, और फिर अचानक सब दावा करते हैं कि उन्होंने इसे आते देखा था।
आपको अभी क्या करना चाहिए
अगर आप MCP सर्वर भेज रहे हैं या उपभोग कर रहे हैं, तो यह न्यूनतम है जो आपको करना चाहिए।
डिप्लॉयमेंट से पहले हर MCP सर्वर को स्कैन करें। सिर्फ कोड कमजोरियों के लिए नहीं — विवरण और कार्यान्वयन के बीच व्यवहार बेमेल के लिए भी।
बिना सत्यापन के तीसरे पक्ष के MCP सर्वरों पर कभी भरोसा न करें। "GitHub पर लोकप्रिय" कोई सुरक्षा ऑडिट नहीं है। हर बाहरी MCP सर्वर को अविश्वसनीय API की तरह व्यवहार करें।
प्रोडक्शन में टूल व्यवहार की निगरानी करें। जानें कौन से टूल कॉल हो रहे हैं, कितनी बार, और किन पैरामीटर्स के साथ। MCP टूल उपयोग के लिए विसंगति पहचान वैकल्पिक नहीं है — यह बुनियादी आवश्यकता है।
जो टीमें सुरक्षा सही करती हैं वे सिर्फ breach से नहीं बचेंगी। वे वो विश्वास अर्जित करेंगी जो उनके टूल्स को डिफ़ॉल्ट विकल्प बनाता है।
संबंधित पोस्ट
SmeltSec आज़माने के लिए तैयार हैं?
60 सेकंड में सुरक्षित MCP सर्वर जेनरेट करें। मुफ्त में शुरू करें।