MCP ने एक स्थिर “Enterprise-Managed Authorization” spec प्रकाशित केला आहे; इतर मशीन-टू-मशीन ओळख (identity) मसुदे—ज्यामध्ये OAuth client-credentials मसुदा आणि दोन खुले प्रस्ताव समाविष्ट आहेत—अजून अपूर्ण आहेत. Model Context Protocol सह स्वायत्त एजंट्स (autonomous agents) चालवण्याचा प्रयत्न करणाऱ्या कोणासाठीही, याचा अर्थ असा आहे की आजचा प्रोटोकॉल मानवी वापरकर्त्याची पडताळणी करू शकतो, परंतु एखादी अनअटेंडेड प्रक्रिया (unattended process) तीच आहे असा दावा सिद्ध करण्यासाठी कोणतीही तयार पद्धत प्रदान करत नाही.
रोडमॅप का महत्त्वाचा आहे
Model Context Protocol (MCP) रोडमॅपमध्ये एजंट ओळख (agent identity) आणि सुरक्षा यांना सर्वोच्च प्राधान्य दिले आहे. चार गोष्टी रिलीज होण्यासाठी नियोजित होत्या: मानवी-केंद्रित ब्राउझर फ्लो, सेवांसाठी OAuth client-credentials फ्लो, DPoP-आधारित टोकन बाइंडिंग आणि वर्कलोड-आयडेंटिटी फेडरेशन मेकॅनिझम. केवळ पहिली गोष्ट—Enterprise-Managed Authorization—स्थिर स्थितीत पोहोचली आहे.
स्थिर spec प्रत्यक्षात काय करते
Enterprise-Managed Authorization मुळे आयटी ॲडमिनना प्रत्येक कर्मचाऱ्याने प्रत्येक कनेक्शन मंजूर करण्याऐवजी एकाच कन्सोलमधून सर्व्हर ॲक्सेस मंजूर करता येतो. हा फ्लो ब्राउझर रिडायरेक्ट आणि युजर लॉगिन वापरतो, ज्यामुळे लॅपटॉपवरील व्यक्ती प्रमाणीकरण (authenticate) करू शकते आणि त्यानंतर सर्व्हर त्या वापरकर्त्याच्या सेशनवर विश्वास ठेवतो.
याची मर्यादा स्पष्ट आहे: या प्रक्रियेसाठी कीबोर्डवर एखादी व्यक्ती असणे आवश्यक आहे. रात्रभर चालणारा, डेटा प्रोसेस करणारा किंवा अलर्टला प्रतिसाद देणारा एजंट, लॉगिन बटण क्लिक करण्यासाठी कोणाही उपलब्ध नसतो. परिणामी, अनअटेंडेड एजंट्सवर अवलंबून असलेले कोणतेही डिप्लॉयमेंट सध्या MCP ने हमी दिलेल्या एकमेव spec चा वापर करू शकत नाही.
मसुदा पर्याय आणि त्यांचे तोटे
दोन मसुदा विस्तार (draft extensions) एजंट्सना त्यांची स्वतःची ओळख देण्यासाठी प्रयत्नशील आहेत:
- SEP-1932 (DPoP) – टोकन्सना पब्लिक-प्रायव्हेट की पेअरशी बांधते, ज्यामुळे चोरीला गेलेले टोकन्स निरुपयोगी ठरतात.
- SEP-1933 (Workload Identity Federation) – एजंट्सना क्लाउड प्लॅटफॉर्मवर आधीच उपलब्ध असलेल्या ओळखी वारसाहक्काने (inherit) मिळवू देते.
हे दोन्ही सध्या ओपन पुल रिक्वेस्ट (pull requests) म्हणून आहेत; यापैकी कोणताही अधिकृत spec मध्ये विलीन (merge) झालेला नाही. दरम्यान, एकमेव दुसरा दस्तऐवजीकृत पर्याय म्हणजे OAuth client-credentials फ्लो आहे ज्यासाठी प्री-रजिस्टर्ड सीक्रेट्सची आवश्यकता असते. एजंट वाचू शकेल अशा ठिकाणी ही सीक्रेट्स साठवणे एक क्लासिक अटॅक सरफेस (attack surface) तयार करते: जर सीक्रेट लीक झाले, तर कोणताही अटॅकर एजंटचे रूप धारण करू शकतो.
आजच्या प्रोडक्शनसाठी व्यावहारिक पावले
प्रोटोकॉल अद्याप नेटिव्ह एजंट आयडेंटिटी प्रदान करत नसल्यामुळे, टीम्स आयडेंटिटी मॅनेजमेंट MCP च्या बाहेर नेऊन एजंट्स सुरक्षित करू शकतात:
- वर्कलोड लेयरवर पडताळण्यायोग्य ओळख जारी करा. SPIRE सारखी सिस्टम्स होस्टच्या ट्रस्ट रूटशी जोडलेली अल्पकाळ टिकणारी प्रमाणपत्रे (short-lived certificates) तयार करतात, ज्यामुळे स्टॅटिक सीक्रेट्सची गरज उरत नाही.
- गेटवेवर क्रेडेंशियल्स समाप्त करा. एक फ्रंट-एंड सर्व्हिस API की किंवा टोकन धारण करते आणि एजंटच्या वतीने विनंत्या (requests) पुढे पाठवते, ज्यामुळे सीक्रेट रनटाइम एन्व्हायरमेंटच्या बाहेर राहते.
- टोकन कंटेंटवर नाही, तर पडताळलेल्या ओळखीवर आधारित अधिकार (authorize) द्या. ऑथेंटिकेशन (कोण कॉल करत आहे) आणि ऑथोरायझेशन (ते काय करू शकतात) वेगळे करा, जेणेकरून ऑथेंटिकेशन पद्धत बदलली तरी पॉलिसी लागू केली जाऊ शकते.
पुढे काय पाहावे
दोन ओपन पुल रिक्वेस्ट – DPoP बाइंडिंग आणि वर्कलोड-आयडेंटिटी फेडरेशन – हे MCP मध्ये खऱ्या मशीन-टू-मशीन आयडेंटिटी स्टँडर्डकडे जाण्याचे एकमेव मार्ग आहेत. जर कम्युनिटीने त्यांना विलीन केले, तर एजंट्स सीक्रेट्स उघड न करता प्रायव्हेट कीची मालकी सिद्ध करू शकतील किंवा क्लाउड-इश्यू केलेल्या ओळखी वारसाहक्काने मिळवू शकतील. तोपर्यंत, कोणतेही प्रोडक्शन डिप्लॉयमेंट बाह्य आयडेंटिटी फ्रेमवर्कवर अवलंबून राहावे लागेल किंवा स्टॅटिक क्रेडेंशियल्सचा धोका स्वीकारून घ्यावा लागेल.
निष्कर्ष स्पष्ट आहे: MCP सध्या विनंतीमागील व्यक्तीचे प्रमाणीकरण (authenticate) करू शकते, परंतु विनंती करणाऱ्या सॉफ्टवेअरचे प्रमाणीकरण अद्याप करू शकत नाही. ज्या टीम्सना सुरक्षित स्वायत्त एजंट्सची गरज आहे त्यांनी spec येण्याची वाट पाहू नये; त्यांनी आजच वर्कलोड लेयरवर आयडेंटिटी तयार केली पाहिजे आणि प्रलंबित DPoP आणि फेडरेशन प्रस्तावांवर लक्ष ठेवले पाहिजे.