आपका MCP सर्वर ही सबसे बड़ा खतरा है

एक malicious MCP सर्वर आपकी SSH keys चुरा सकता है, बिना कोई एक भी पूरा malicious instruction लिखे। ASSET रिसर्च ग्रुप ने यह साबित किया: जब चोरी का आदेश model को एक ही ब्लॉक में दिया जाता है, तो बड़े मॉडल लगभग हमेशा मना कर देते हैं। उसी आदेश को हानिरहित दिखने वाले टुकड़ों में बाँट दो, और GPT-4o, Gemini 2.0 Flash, और Llama 3.3 100% टेस्ट किए गए मामलों में मान जाते हैं।

इस बीच, ज़्यादातर developers हर हफ्ते अपने agent में एक नया MCP सर्वर जोड़ते हैं, GitHub पर मिली config line कॉपी करके। इनमें से हर सर्वर आपकी access का एक हिस्सा रखता है: API tokens, cloud keys, service accounts। MCP उपयोगी है — इसमें किसी को शक नहीं। पर MCP सर्वर पूरे agent stack की सबसे कमज़ोर कड़ी बन चुका है।

यह लेख बताता है कि MCP सर्वर बिना पकड़े कैसे आपके secrets लीक करता है, GhostSplice अटैक जो instructions को बाँटकर model के मना करने को हरा देता है, और वो ठोस बचाव, Cloudflare WriteGuard से लेकर वो नियम जो आप आज अपने setup पर लागू कर सकते हैं।

एक MCP सर्वर आपके agent और किसी बाहरी tool के बीच का पुल है: आपका database, आपका GitHub, आपका Slack, आपका cloud। यह पुल बनाने के लिए, वह आपके लॉगिन के लिए ज़रूरी हर चीज़ रखता है — tokens, API keys, service account credentials — सादे text में, आपकी disk पर एक config file में, अक्सर बिना किसी encryption के।

एक protocol detail आगे काम आती है। जब कोई agent MCP सर्वर से जुड़ता है, सर्वर अपने tools की एक list भेजता है, हर एक के साथ free-text description जो model को बताती है कि कब और कैसे इसे इस्तेमाल करना है। वो descriptions सीधे model के context में जाती हैं, आपके खुद के instructions जितनी ही अहमियत के साथ, और tools जो नतीजे लौटाते हैं वो भी वहीं जाकर बैठते हैं। एक MCP सर्वर आपके agent से लगातार बात करता रहता है, ऐसे text में जिसे कोई दोबारा नहीं पढ़ता। यही वो बात है जो GhostSplice अटैक को मुमकिन बनाती है।

यह ecosystem भी अपनी guardrails से कहीं तेज़ बढ़ा:

संकेत	संख्या
official MCP registry में सर्वर	9,600+
मई 2025 से remote server deployments की growth	5×

कोई भी सर्वर publish कर सकता है, कोई central review नहीं है, और आपका agent हर एक पर उतना ही भरोसा करता है जितना किसी official tool पर। NSA ने मई में MCP को समर्पित एक security guide छापी, यह कहते हुए कि इस protocol की adoption इसकी सुरक्षा बनने से कहीं आगे निकल गई। जब कोई intelligence agency आपके पसंदीदा dev tool पर guide लिखे, तो वो शायद ही बधाई देने के लिए होती है।

यही हालात हैं: हज़ारों सर्वर, कोई review नहीं, और बीच में आपकी keys।

पहला छेद है credentials का plain text में रखा जाना। The Hacker News ने 17 अगस्त को इस leak की मैकेनिक्स पर एक विस्तृत रिपोर्ट छापी, और शुरुआत बिल्कुल साफ है: tokens सीधे configuration strings में चिपका दिए जाते हैं और disk पर पढ़ने लायक बने रहते हैं। एक ज़रा जल्दबाज़ी वाला commit काफी है आपके config को keys समेत Git repo में डालने के लिए। मामला और बिगड़ता है जिसे यह article "sprawl" कहता है: वही keys config files, environment variables में, और dev, staging, production की copies में बार-बार दोहराई जाती हैं। कुछ समय बाद किसी को पता नहीं होता कि secrets कहाँ हैं, तो कोई उन्हें rotate नहीं करता — और एक static key जो कभी rotate नहीं होती, अपने attacker का इंतज़ार करती है।

दूसरा छेद है over-permissioning। development के दौरान आप authorization errors से बचने के लिए अपने सर्वर को बड़े अधिकार दे देते हैं, और वही बड़े अधिकार बिना बदले production में चले जाते हैं। फिर एक अकेला compromise असली इस्तेमाल से कहीं ज़्यादा उजागर कर देता है।

तीसरा छेद है supply chain। CVE-2025-6514 ने mcp-remote को मारा, एक OAuth proxy जिसे 400,000 से ज़्यादा बार डाउनलोड किया गया, और एक malicious सर्वर को उपयोगकर्ता की मशीन पर command injection चलाने दिया — code चलाकर और credentials लेकर निकल गया। एक लोकप्रिय npm package, एक लाइन में install, और दरवाज़ा खुल गया।

चौथा छेद सबसे चालाक है: prompt injection। एक agent वो सब पढ़ता है जो उसके tools वापस लाते हैं — एक web page, एक ticket, एक internal document। अगर इनमें से किसी में छिपा हुआ instruction हो, तो agent उसे ऐसे follow कर सकता है जैसे वो आपसे आया हो, और अपने legitimate tools से वही उजागर कर दे जिसे बचाना था। यह leak किसी technical खामी से नहीं गुज़रता; यह model की भोलेपन से गुज़रता है।

किसी भी sophisticated attack से पहले, MCP सर्वर की आम ज़िंदगी — plaintext config, बड़े अधिकार, बिना जाँच की dependencies, बिना filter किया content — पहले से ही आपके secrets उजागर कर रही होती है।

GhostSplice वो नाम है जो ASSET रिसर्च ग्रुप ने एक ऐसी technique को दिया जो आपके ही agent से exfiltration करवाती है, उसके पूरे सहयोग से। सिद्धांत एक वाक्य में है: पूरा चोरी का आदेश लिखने के बजाय, malicious सर्वर उसे बाँट देता है, एक टुकड़ा किसी tool की description में डालता है, और दूसरा उस result में जो tool लौटाता है। हर टुकड़ा, अकेले पढ़ने पर, हानिरहित लगता है। पर agent अपने working context में आने वाली हर चीज़ को जोड़ लेता है: यह पूरा instruction फिर से बनाता है और उसे पूरी नेकनीयती से execute करता है — उसके नज़रिए से, वो बस वही form भर रहा है जो tool ने माँगा था।

टेस्ट के नंबर ही असली कहानी हैं:

मॉडल	एक-ब्लॉक instruction	टुकड़ों वाला instruction
GPT-4o	100% मना करता है	100% मान जाता है
Gemini 2.0 Flash	100% मना करता है	100% मान जाता है
Llama 3.3	100% मना करता है	100% मान जाता है
Claude Haiku 4.5	API के ज़रिए मना करता है	Cursor के अंदर तीन-टुकड़े वाले टेस्ट में 100% मान जाता है

Claude वाली detail किसी भी आसान नतीजे को खत्म कर देती है: एक ही model एक client में मना कर सकता है और दूसरे में लीक कर सकता है, इस पर निर्भर करते हुए कि वो client कौन सी सुरक्षा जोड़ता है या नहीं।

टेस्ट में GhostSplice जो चुराता है: SSH keys, environment secrets, source code, customer data। researchers ने fake keys वाले isolated projects पर काम किया, असली victims पर नहीं, पर यह तरीका published और reproducible है।

GhostSplice कोई पहली कोशिश नहीं है। इसी lab ने जून में Ghostcommit छापा था, एक अटैक जिसने अपने instructions project conventions से जुड़ी PNG files में छिपाए, फिर चुराए secrets को source code में integers की तरह encode किया। instruction splitting अटैक्स का एक बसता हुआ परिवार है, कोई अकेली घटना नहीं।

दो बातें इसे नज़रिए में रखती हैं। इस अटैक की दो शर्तें हैं: malicious सर्वर पहले से agent में जुड़ा होना चाहिए, और agent के पास target files पढ़ने की access होनी चाहिए। यही वजह है कि provenance इतनी मायने रखती है — आपके सर्वर कहाँ से आते हैं यही आपकी पहली सुरक्षा है। और मैकेनिक्स याद रखिए: model का alignment आपको नहीं बचाता, क्योंकि यह अटैक कभी एक टुकड़े में कुछ भी मना किया हुआ नहीं माँगता।

GhostSplice मानकर चलता है कि malicious सर्वर पहले से जुड़ा है। पर तय कौन करता है कि क्या जोड़ा जाए? एक टीम में, सच्चा जवाब है: कोई नहीं। यही वो समस्या है जिसे Cloudflare shadow MCP कहता है: वो सारे सर्वर जो developers बिना किसी security review के अपने agents से जोड़ते हैं। हाल तक वो traffic अदृश्य था — एक MCP request किसी भी आम HTTPS call जैसी दिखती है।

Cloudflare ने protocol-level detection से यह बदल दिया। spec update के बाद से, हर conforming MCP client अपने requests पर एक MCP-Protocol-Version header भेजता है, और Gateway उस header को हर TLS traffic पर देखता है जिसे वो decrypt करता है। एक security team अब कंपनी में इस्तेमाल हो रहा हर MCP सर्वर देख सकती है, एक dedicated dashboard के साथ: unique सर्वर, users, request volumes। यह header तरीका domain name से filtering से बेहतर है, क्योंकि MCP सर्वर के पास खुद को mcp-कुछ कहने की कोई ज़रूरत नहीं — protocol पहचाना जाता है वो क्या कहता है उससे, वो क्या दावा करता है उससे नहीं।

टीम कार्रवाई भी कर सकती है: एक is_mcp selector आपको किसी भी MCP traffic को block करने देता है जो approved portal से नहीं आया। portal इस setup का दूसरा आधा हिस्सा है — एक अकेला access point जो जाँचे गए सर्वरों को identity authentication के पीछे रखता है।

latest spec version visibility को और बढ़ा देता है। नए Mcp-Method और Mcp-Name headers दिखाते हैं कि कौन सा operation माँगा गया और कौन सा tool बुलाया गया, बिना firewall को request body खोलने की ज़रूरत के। एक टीम network लेवल पर ही बता सकती है कि agent एक ticket पढ़ रहा है या पचास tickets delete कर रहा है।

Cloudflare इसे दो हिस्सों में बाँटता है: pure shadow MCP, एक सर्वर जिसे कभी approve नहीं किया गया, और portal bypass, एक approved सर्वर जिसे checkpoint से सीधे bypass कर पहुँचा गया। दोनों एक ही base rule से block होते हैं। logic सीधा है: portal से गुज़रने वाली हर चीज़ जानी और log होती है, बाकी सब block होता है। किसी कंपनी के लिए, यही उस Friday रात install हुए ghost MCP सर्वर का अंत है।

approved सर्वर भी नुकसान कर सकता है, क्योंकि agent एक साथ अपने user के सारे अधिकार पा लेता है। यहीं WriteGuard काम आता है, जिसे Cloudflare ने अभी private beta में खोला है। idea यह है: हर MCP सर्वर के हर tool को एक risk tier में बाँटो, और हर tier पर अलग policy लगाओ।

• एक read बिना रोक-टोक चलती है।
• एक contained write, जैसे comment post करना, बदलाव के साथ चलती है: action को एक agent की तरफ से sign किया जाता है, किसी खास इंसान की तरफ से, और एक audit event central log में जाता है।
• एक critical action — code merge करना, production में deploy करना, mass delete करना — सर्वर तक पहुँचने से पहले ही block हो जाता है।

Cloudflare के post में दिया GitLab example इस gradation को अच्छे से दिखाता है: merge request पढ़ना चलता है, उस पर comment करना attribution के साथ चलता है, और उसे merge करना तब तक मना है जब तक कोई इंसान खुद न करे।

सबसे दिलचस्प हिस्सा है identity model। agent उस employee के permissions रखता है जिसकी वो सेवा करता है, पर अब हर write के साथ दो signatures आती हैं: इंसान की, और उसकी तरफ से काम कर रहे agent session की। downstream systems आखिरकार बता सकते हैं कि बदलाव इंसान ने किया या मशीन ने, और audit asynchronously central log में जाता है, sensitive data हटाकर। अब तक logs में agent अपने इंसान से अलग पहचाना नहीं जा सकता था; incident audit के लिए यह सब कुछ बदल देता है — एक query बता देती है कि मंगलवार वाला संदिग्ध merge किसी जल्दबाज़ी में काम करते सहकर्मी ने किया या किसी agent session ने।

Cloudflare कोई थ्योरी नहीं बेच रहा; वे अपना ही इस्तेमाल बताते हैं: उनका portal 27 MCP सर्वरों से जुड़ा है, अप्रैल के 13 से बढ़कर। यह नंबर असली कहानी बताता है — खुद Cloudflare में भी सर्वर count कुछ ही महीनों में दोगुना हो जाता है, और इसीलिए per-tool control ज़रूरी बन जाता है। industry जिस दिशा में जा रही है साफ है: पूरे सर्वर पर भरोसा करना छोड़ो, और हर action पर तय करो कि agent को क्या करने की इजाज़त है।

सीमाएँ साफ कहनी ज़रूरी हैं। WriteGuard एक signup form के पीछे private beta में है, और Gateway की detection को TLS inspection on वाला Cloudflare Zero Trust deployment चाहिए: किसी solo developer या छोटी टीम के लिए, यह उनका infrastructure नहीं है। कंपनी में भी, detection सिर्फ वही network traffic देखता है जो वो decrypt करता है — stdio पर चलने वाला local MCP सर्वर, आपकी मशीन पर एक साधारण process की तरह चला हुआ, Gateway से छिपा रहता है। और असल में ज़्यादातर सर्वर developers इसी तरीके से install करते हैं।

सबसे बड़ी बात, इनमें से कोई भी tool GhostSplice वाली मूल खामी को ठीक नहीं करता: जब तक agent अपने context में आई हर चीज़ को आज़ादी से जोड़ता रहेगा, हानिरहित टुकड़े फिर से खतरनाक instructions बनते रहेंगे। ASSET researchers खुद कहते हैं: इसका इलाज है tool output को data की तरह मानना, कभी instruction की तरह नहीं, और यह अलगाव agents में अभी natively मौजूद नहीं।

तब तक उनकी सिफारिशें तीन कदमों में सिमटती हैं: किसी एक tool से निकली values को बिना जाँचे दूसरे tool के arguments में न जाने दें, हर tool invocation को हाथ से मना करने की क्षमता रखें, और बिना जाँचे सर्वर से आई किसी भी annotation को डिफ़ॉल्ट रूप से खतरनाक मानें। इनमें से कोई भी आज automatic नहीं है: या तो आप इन्हें लागू करते हैं, या कोई नहीं करता। Cloudflare जो भी यहाँ लाया है उसे seat belt समझिए, brake नहीं — यह नुकसान सीमित करता है, टक्कर रोकता नहीं।

आज से करने के लिए:

1. Inventory। उन MCP सर्वरों की list बनाएँ जो सच में आपके agents से जुड़े हैं, और जो अब इस्तेमाल नहीं होते उन्हें हटाएँ।
2. provenance से छाँटें। किसी जाने-माने vendor का official सर्वर, हाँ। किसी thread में मिला 40-star वाला GitHub repo, नहीं — जब तक आपने न पढ़ लिया हो वो आपके data के साथ क्या करता है।
3. अधिकार सीमित करें। हर सर्वर को minimal scope वाला अपना token दें, कभी अपनी master key नहीं, और उन tokens को वैसे ही rotate करें जैसे किसी production system के लिए करते।
4. sensitive actions पर हाथ रखे रहें। जो agent लिखता है, merge करता है, या delete करता है वो आपके पास वापस आना चाहिए — यही असल में WriteGuard जो automate करता है उसका हाथ से किया version है।
5. GhostSplice वाला नियम रोज़ लागू करें। जब आपका agent बिना पूछे tool actions को जोड़ने लगे, उसे रोकें और पढ़ें कि सर्वर उसे क्या बता रहा था।

हर agent client अपने जुड़े सर्वर और उनके tools दिखा सकता है, और वो list पढ़ने में तीस सेकंड लगते हैं। वो तीस सेकंड आपके पूरे setup में सबसे बेहतरीन time-to-security ratio हैं।

अगर आप किसी कंपनी में हैं, network layer भी जोड़ें: Gateway की MCP detection और portals लगाना फायदे का सौदा है, क्योंकि shadow MCP आपके org में पहले से मौजूद है, चाहे आप उसे देखें या न देखें।

MCP समस्या नहीं है — जिस रफ्तार से हमने अपनी keys सौंपी वो है।