आपका MCP सर्वर सुरक्षित है। इसके पीछे की बही सुरक्षित नहीं है।

Unite.AI पर हाल ही में प्रकाशित एक लेख में Gil Feig ने सुरक्षित MCP सर्वर बनाने के छह सर्वोत्तम तरीके बताए। ये सुझाव सही हैं और MCP सर्वर जारी करने वाले हर व्यक्ति को इनका पालन करना चाहिए। हर इंटीग्रेशन को “अपनी अलग, सूक्ष्म स्तर पर निर्धारित भूमिका दें, जो केवल ज़रूरी अनुमतियों तक सीमित हो”—उनकी यह सलाह बिल्कुल सही है। लेकिन इसमें यह मान लिया गया है कि दूसरी ओर मौजूद सिस्टम में भी सूक्ष्म स्तर पर निर्धारित भूमिकाएँ उपलब्ध हैं। इससे एक ऐसी व्यापक धारणा का पता चलता है जिसका ज़िक्र शायद ही कभी होता है: सर्वर के पीछे मौजूद सिस्टम को भी उसी मानक के अनुसार सुरक्षित किया जा सकता है।

व्यावसायिक सॉफ़्टवेयर में अक्सर ऐसा संभव नहीं होता। मैं उस इंजीनियरिंग टीम का नेतृत्व करता हूँ जो एक इंटीग्रेशन लेयर बनाती है। यह लेयर 32 लेखांकन और ERP सिस्टम से जुड़ती है, और इसके ऊपर MCP सर्वर का विकल्प भी उपलब्ध है। हम अक्सर ऐसे एजेंट देखते हैं जिन्हें हमारी ओर से अच्छी तरह प्रमाणित किया गया होता है, जिनकी पहुँच का दायरा ठीक से सीमित होता है और जिनकी गतिविधियों का पूरा रिकॉर्ड रखा जाता है, लेकिन वे ऐसे सिस्टम में डेटा लिख रहे होते हैं जिन्हें यह पता ही नहीं चल सकता कि इसमें किसी एजेंट की भूमिका थी।

यह लेख समस्या के दूसरे पहलू पर है: अपस्ट्रीम सिस्टम वास्तव में क्या सुविधाएँ देते हैं, इंटीग्रेशन लेयर से आप किन चीज़ों को नियंत्रित कर सकते हैं और उस नियंत्रण की सीमा कहाँ आ जाती है।

MCP विनिर्देश की सीमा कहाँ आती है

यह MCP प्राधिकरण विनिर्देश अपनी सीमा को लेकर स्पष्ट है। MCP सर्वर अपने क्लाइंट्स के लिए OAuth संसाधन सर्वर है। जब वह किसी अपस्ट्रीम API को कॉल करता है, तो वह एक अलग OAuth क्लाइंट के रूप में काम करता है और उसे अपस्ट्रीम सिस्टम द्वारा जारी किया गया अलग टोकन मिलता है। क्लाइंट का टोकन आगे भेजना स्पष्ट रूप से निषिद्ध है।

यह सही डिज़ाइन है। इसका यह भी मतलब है कि अपस्ट्रीम कॉल से जुड़ी हर बात—जिसमें यह भी शामिल है कि किसे क्या करने की अनुमति है और उसका रिकॉर्ड कैसे रखा जाता है—पूरी तरह अपस्ट्रीम सिस्टम पर निर्भर करती है। विनिर्देश उस चीज़ को ठीक नहीं कर सकता जो अपस्ट्रीम सिस्टम उपलब्ध ही नहीं कराता।

यही बात अत्यधिक एजेंसी को लेकर OWASP के दिशा-निर्देशोंपर भी लागू होती है। इनमें सुझाव दिया गया है कि एजेंट के एक्सटेंशन को दूसरे सिस्टम में केवल उतनी ही अनुमतियाँ दी जाएँ जितनी ज़रूरी हों, और कार्रवाइयाँ उस उपयोगकर्ता के संदर्भ में की जाएँ जिसकी ओर से एजेंट काम कर रहा है। दोनों ही अच्छी सलाह हैं। लेकिन दोनों यह मानकर चलते हैं कि दूसरे सिस्टम में न्यूनतम अनुमतियाँ और उपयोगकर्ता का संदर्भ दर्ज करने का कोई तरीका मौजूद है।

अपस्ट्रीम सिस्टम वास्तव में क्या सुविधाएँ देते हैं

यहाँ बताया गया है कि जिन 32 लेखांकन और ERP सिस्टम से हम जुड़ते हैं, वे इंटीग्रेशन करने वाले की नज़र से कैसे दिखते हैं।

एक-तिहाई में OAuth बिल्कुल नहीं है

32 में से 21 सिस्टम OAuth का इस्तेमाल करते हैं। बाकी 11 स्थिर क्रेडेंशियल पर निर्भर हैं: API कुंजियों, उपयोगकर्ता नाम और पासवर्ड, या टोकन की एक जोड़ी पर। इनमें से कुछ कुंजियाँ कभी समाप्त नहीं होतीं। व्यापक रूप से इस्तेमाल किया जाने वाला एक सिस्टम बताता है कि उसके API टोकन तब तक असीमित अवधि के लिए मान्य रहते हैं, जब तक उपयोगकर्ता का खाता मौजूद है।

लंबी अवधि, निरस्त करने के सीमित विकल्प

OAuth से उतनी मदद नहीं मिलती जितनी आप उम्मीद कर सकते हैं। एक प्रदाता ऐसे रीफ़्रेश टोकन जारी करता है जिनकी वैधता अवधि लगभग 20 वर्ष होती है। यह ऐसा क्रेडेंशियल है जिसे इस्तेमाल करने वाले एजेंट, उस एजेंट को बनाने वाले फ़्रेमवर्क और संभवतः “अनुमति दें” पर क्लिक करने वाले व्यक्ति से भी ज़्यादा समय तक बने रहने के लिए तैयार किया गया है। एक अन्य सिस्टम में, एक्सेस टोकन भी कभी समाप्त नहीं होते।

और जब कोई क्रेडेंशियल जारी हो जाता है, तो सवाल यह है कि उसे बंद कौन कर सकता है। इसके लिए मानक, OAuth टोकन निरस्तीकरण (RFC 7009), 2013 से मौजूद है। फिर भी, लगभग दस में से चार सिस्टम इंटीग्रेशन करने वाले को क्रेडेंशियल निरस्त करने का कोई तकनीकी तरीका नहीं देते। API कुंजी वाले सभी सिस्टम इसी समूह में आते हैं। ऐसे में बस यही विकल्प बचता है कि ग्राहक से पहुँच को खुद हटाने के लिए कहा जाए।

सीमित दायरे वाली अनुमतियाँ, एजेंट की पहचान नहीं

ज़्यादातर स्थिर कुंजियों को बनाने वाले उपयोगकर्ता के सभी अधिकार अपने-आप मिल जाते हैं; केवल कुछ ही सिस्टम आपको कुंजी को अलग-अलग एंडपॉइंट तक सीमित करने देते हैं। कई OAuth सिस्टम में दायरे निर्धारित करने की सुविधा है, लेकिन वे आम तौर पर बहुत व्यापक होते हैं, जैसे “लेखांकन—पढ़ने और लिखने की अनुमति।” और इन 32 में से किसी भी सिस्टम में हमें API के ज़रिए एक ही लेन-देन में एजेंट और उस व्यक्ति—दोनों को दर्ज करने का तरीका नहीं मिला जिसकी ओर से एजेंट काम करता है। बाहरी एजेंट या तो उन्हें जोड़ने वाले उपयोगकर्ता के रूप में दिखाई देते हैं या सामान्य सिस्टम उपयोगकर्ता के रूप में। गौरतलब है कि जब किसी विक्रेता ने अपने उत्पाद में एजेंट बनाए हैं, जैसा कि Microsoft ने Business Central में किया है, तो उसने एजेंटों के लिए अलग उपयोगकर्ता खाते बनाए हैं। यही तरीका है जिसकी मैं नीचे अनुशंसा करता हूँ, बस यहाँ यह सुविधा केवल विक्रेता के अपने एजेंटों के लिए रखी गई है।

इंटीग्रेशन लेयर क्या लागू कर सकती है

इनमें से किसी भी बात का यह मतलब नहीं है कि हमें हार मान लेनी चाहिए। एजेंट और लेखांकन सिस्टम के बीच लगभग हर चीज़ आपके नियंत्रण में है:

• आपकी अपनी लेयर तक पहुँचने के लिए हर एजेंट के अलग क्रेडेंशियल
• आपके अपने दायरा-नियम, जैसे इनवॉइस तक केवल पढ़ने की पहुँच
• हर एजेंट कॉल का ऑडिट लॉग, जिसमें उस व्यक्ति का नाम हो जिसकी ओर से एजेंट ने काम किया
• इडेम्पोटेंसी कुंजियाँ, ताकि दोबारा प्रयास करने वाला एजेंट एक ही इनवॉइस दो बार दर्ज न करे
• हर एजेंट के लिए अनुरोधों की दर की सीमा
• कोई भी डेटा लिखने से पहले अनुमोदन के चरण

इनमें से किसी भी चीज़ का लक्ष्य सिस्टम की सुविधाओं पर निर्भर होना ज़रूरी नहीं है। इंटीग्रेशन स्तर पर सक्षम पहुँच लेयर आज ही बनाई जा सकती है; और अगर आप एजेंटों को वित्तीय डेटा के आसपास भी काम करने देते हैं, तो आपको ऐसी लेयर बनानी चाहिए।

यह नियंत्रण कहाँ तक काम करता है

आप उस परत को सिस्टम की सीमा के पार नहीं बढ़ा सकते। वहाँ तीन समस्याएँ सामने आती हैं।

कार्रवाई का स्रोत

लेखा प्रणाली में एजेंट द्वारा की गई प्रविष्टि, कनेक्शन को अधिकृत करने वाले व्यक्ति के नाम से या किसी तकनीकी उपयोगकर्ता के नाम से दिखाई देती है। इस प्रणाली का ऑडिट करने वाले किसी भी व्यक्ति को उस उपयोगकर्ता के नाम से की गई प्रविष्टि ही दिखती है। वे यह नहीं बता सकते कि प्रविष्टि किसी व्यक्ति ने की थी या एजेंट ने। लेजर के लिए, सुबह 3 बजे 400 इनवॉइस दर्ज करने वाला एजेंट बिल्कुल किसी बेहद मेहनती वित्त प्रबंधक जैसा दिखता है। यह पता लगाने के लिए इंटीग्रेटर के लॉग देखने पड़ते हैं, जो आधिकारिक रिकॉर्ड रखने वाली प्रणाली से अलग भरोसे की कड़ी है। फॉरेंसिक जाँच या ऑडिट के लिहाज़ से यह स्थिति कमजोर है।

ज़्यादातर संगठन भी इस मामले में आगे नहीं हैं। Cloud Security Alliance के एक सर्वेक्षण में, केवल 28% उत्तरदाताओं ने कहा कि वे सभी परिवेशों में एजेंट की कार्रवाइयों का भरोसेमंद ढंग से किसी व्यक्ति या सिस्टम तक पता लगा सकते हैं, और 44% अपने एजेंटों के लिए स्थिर API कुंजियों का इस्तेमाल करते हैं या करने की योजना बना रहे हैं।

न्यूनतम आवश्यक विशेषाधिकार

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

पहुँच रद्द करना

आप अपने एजेंट की पहुँच तुरंत रोक सकते हैं। लेकिन अगर लक्ष्य प्रणाली के क्रेडेंशियल ही चोरी हो जाएँ, तो इससे कोई मदद नहीं मिलेगी। और जिन दस में से चार प्रणालियों में पहुँच रद्द करने का एंडपॉइंट नहीं है, उनमें आपातकालीन रोक के लिए ग्राहक को ईमेल करना पड़ता है।

व्यावहारिक उपाय: एजेंट के लिए अलग उपयोगकर्ता

आज आप जो सबसे उपयोगी काम कर सकते हैं, वह भले ही बहुत आकर्षक न लगे। लक्ष्य प्रणाली में एजेंट के लिए एक अलग उपयोगकर्ता बनाएँ और एजेंट को केवल उसी उपयोगकर्ता के ज़रिए कनेक्ट करें।

यह उन सभी प्रणालियों में काम करता है जहाँ उपयोगकर्ता बनाए जा सकते हैं, और इससे वे तीन सुविधाएँ मिलती हैं जो इंटीग्रेशन की परत नहीं दे सकती:

• आधिकारिक रिकॉर्ड रखने वाली प्रणाली में कार्रवाई का स्रोत पता चलता है। प्रविष्टियाँ “AP agent” के नाम से दिखाई देती हैं, न कि उस वित्त प्रबंधक के नाम से जिसने छह महीने पहले “कनेक्ट” पर क्लिक किया था।
• पहुँच रद्द करने का एक तरीका, भले ही उसके लिए कोई API न हो। ग्राहक इंटरफ़ेस में उपयोगकर्ता को निष्क्रिय कर सकता है; यह उन प्रणालियों में भी काम करता है जिनमें पहुँच रद्द करने का कोई एंडपॉइंट नहीं है।
• न्यूनतम आवश्यक विशेषाधिकार का आंशिक पालन। जहाँ प्रणाली में किसी तरह की भूमिका-व्यवस्था मौजूद है, वहाँ एजेंट उपयोगकर्ता की पहुँच अक्सर केवल उन मॉड्यूल तक सीमित की जा सकती है जिनकी उसे वास्तव में ज़रूरत है।

इसकी वास्तविक लागत है। ऑनबोर्डिंग के दौरान किसी को हाथ से उपयोगकर्ता बनाना होगा, जिससे ठीक उसी समय अतिरिक्त झंझट बढ़ता है जब इसकी सबसे कम ज़रूरत होती है। लगभग आधी प्रणालियाँ हर अतिरिक्त उपयोगकर्ता के लिए शुल्क लेती हैं—छोटे व्यवसायों के टूल में हर महीने कुछ यूरो से लेकर पूर्ण ERP में सौ यूरो से भी अधिक तक। कई अन्य प्रणालियाँ योजना के अनुसार उपयोगकर्ताओं की संख्या सीमित करती हैं, इसलिए एक और उपयोगकर्ता जोड़ने पर पूरी कंपनी को महँगी योजना लेनी पड़ सकती है। और जिस सेवा उपयोगकर्ता की ज़िम्मेदारी किसी के पास न हो, वह अपने आप में एक जोखिम बन जाता है—यह उस गैर-मानवीय पहचान के अनियंत्रित विस्तार का हिस्सा है, जिसके बारे में Unite.AI पहले भी लिख चुका है। किसी भी अन्य खाते की तरह, इसका भी एक ज़िम्मेदार व्यक्ति और समीक्षा की तारीख तय होनी चाहिए।

इससे उन प्रणालियों में स्कोप की समस्या भी हल नहीं होती जिनमें स्कोप हैं ही नहीं। लेकिन इससे कार्रवाई का स्रोत पता लगाने और पहुँच रद्द करने की ज़िम्मेदारी वापस उसी प्रणाली में आ जाती है जहाँ ऑडिटर वास्तव में देखते हैं।

संरचनात्मक उपाय: प्रत्यायोजित पहचान

सैद्धांतिक रूप से इसका सही उपाय पहले से मौजूद है। OAuth 2.0 टोकन विनिमय (RFC 8693) प्रतिरूपण और प्रत्यायोजन के बीच अंतर स्पष्ट करता है। प्रत्यायोजन में एजेंट अपनी पहचान बनाए रखता है और टोकन में “act” दावे के ज़रिए दर्ज होता है कि वह किसी व्यक्ति की ओर से कार्रवाई कर रहा है।

लेखा प्रणालियों पर लागू करने पर इसका अर्थ होगा:

• लेजर में दर्ज हो कि इस एजेंट ने इस व्यक्ति की ओर से प्रविष्टि की
• स्कोप प्रति उपयोगकर्ता के बजाय हर प्रत्यायोजन के लिए दिए जाएँ
• व्यक्ति के खाते को छुए बिना किसी एक प्रत्यायोजन को रद्द किया जा सके

जहाँ तक मैं पता लगा सका, इन 32 प्रणालियों में से कोई भी ऐसी सुविधा का समर्थन नहीं करती। इसलिए फिलहाल यह एक दिशा है, उपलब्ध विकल्प नहीं। इस कारण यह इंटीग्रेटरों का काम नहीं, बल्कि लेखा सॉफ़्टवेयर और ERP सॉफ़्टवेयर प्रदाताओं से एक अनुरोध है: एजेंट पहले से ही आपके लेजर में प्रविष्टियाँ कर रहे हैं, और आपके API को यह बताने में सक्षम होना चाहिए।

एजेंट को लेजर तक पहुँच देने से पहले क्या करें

अगर आप एजेंटों को लेखा प्रणालियों या ERP प्रणालियों से जोड़ रहे हैं, तो यह छोटी-सी जाँच-सूची अपनाएँ:

1. हर लक्ष्य प्रणाली के क्रेडेंशियल मॉडल की जाँच करें। क्या यह OAuth है या स्थिर कुंजी? क्रेडेंशियल कितने समय तक मान्य रहता है? क्या उसके स्कोप हैं, और क्या उसकी पहुँच रद्द की जा सकती है?
2. अपनी पहुँच-परत फिर भी बनाएँ। हर एजेंट की अलग पहचान, स्कोप, इडेम्पोटेंसी और अनुमोदन आपकी ओर से होने चाहिए—चाहे लक्ष्य प्रणाली में जो भी सुविधाएँ उपलब्ध हों।
3. जहाँ भी प्रणाली अनुमति दे, एजेंट के लिए अलग उपयोगकर्ता बनाएँ। कार्रवाई का स्रोत पता लगाने की कीमत के रूप में ऑनबोर्डिंग की मेहनत और लाइसेंस की लागत स्वीकार करें।
4. अपने ऑडिट रिकॉर्ड को छेड़छाड़ का पता लगाने योग्य बनाएँ। कई प्रणालियों के लिए यही एकमात्र रिकॉर्ड होगा जो साबित करेगा कि एजेंट शामिल था।
5. अवशिष्ट जोखिम को लिखित रूप में दर्ज करें। जहाँ किसी प्रणाली में स्कोप और निरस्तीकरण की सुविधा नहीं है, वहाँ अपने ग्राहक को और अपने जोखिम रजिस्टर में भी यह स्पष्ट रूप से बताएं।

सीमा ही असली मुद्दा है

अपने MCP सर्वर को सुरक्षित करना ज़रूरी है, लेकिन इतना काफ़ी नहीं। लेज़र में लिखने वाले एजेंट की सुरक्षा का निर्धारण आपकी परत और अभिलेख की प्रणाली के बीच की सीमा पर होता है। आज यह सीमा आपके बजाय प्रणालियाँ तय करती हैं।

अच्छी बात यह है कि इस कमी को स्पष्ट रूप से परिभाषित किया जा सकता है। मानक मौजूद हैं। जो चीज़ नहीं है, वह है बहीखाते रखने वाली प्रणालियों में उनके लिए समर्थन।