MCP એ એક સ્થિર “Enterprise-Managed Authorization” સ્પેક પ્રકાશિત કરી છે; અન્ય મશીન-ટુ-મશીન ઓળખના ડ્રાફ્ટ્સ—જેમાં OAuth client-credentials ડ્રાફ્ટ અને બે ખુલ્લા પ્રસ્તાવોનો સમાવેશ થાય છે—અધૂરા છે. Model Context Protocol સાથે સ્વાયત્ત એજન્ટ્સ (autonomous agents) ચલાવવાનો પ્રયાસ કરનાર કોઈપણ વ્યક્તિ માટે, તેનો અર્થ એ છે કે આજનું પ્રોટોકોલ માનવ વપરાશકર્તાને ચકાસી શકે છે પરંતુ અનટેન્ડેડ (unattended) પ્રક્રિયા જે તે હોવાનો દાવો કરે છે તે સાબિત કરવા માટે કોઈ તૈયાર રીત પૂરી પાડતું નથી.
રોડમેપ શા માટે મહત્વનો છે
Model Context Protocol (MCP) રોડમેપ એજન્ટ ઓળખ અને સુરક્ષાને તેની ટોચની પ્રાથમિકતાઓમાં રાખે છે. ચાર વસ્તુઓ રિલીઝ કરવા માટે નિર્ધારિત કરવામાં આવી હતી: હ્યુમન-સેન્ટ્રિક બ્રાઉઝર ફ્લો, સર્વિસીસ માટે OAuth client-credentials ફ્લો, DPoP-આધારિત ટોકન બાઈન્ડિંગ, અને વર્કલોડ-આઈડેન્ટિટી ફેડરેશન મિકેનિઝમ. માત્ર પ્રથમ—Enterprise-Managed Authorization—સ્થિર સ્થિતિમાં પહોંચ્યું છે.
સ્થિર સ્પેક ખરેખર શું કરે છે
Enterprise-Managed Authorization IT એડમિનિસ્ટ્રેટર્સને દરેક કર્મચારીએ દરેક કનેક્શનને મંજૂરી આપવાને બદલે સિંગલ કન્સોલ પરથી સર્વર એક્સેસ આપવાની મંજૂરી આપે છે. આ ફ્લો બ્રાઉઝર રિડાયરેક્ટ અને યુઝર લોગિનનો ઉપયોગ કરે છે, જેથી લેપટોપ પર રહેલી વ્યક્તિ પ્રમાણિત (authenticate) કરી શકે છે અને પછી સર્વર તે યુઝરના સેશન પર વિશ્વાસ કરે છે.
મર્યાદા સ્પષ્ટ છે: આ પ્રક્રિયા માટે કીબોર્ડ પર માનવની જરૂર છે. રાત્રિભર ચાલતું, ડેટા પ્રોસેસ કરતું અથવા એલર્ટ્સનો પ્રતિસાદ આપતું એજન્ટ લોગિન બટન પર ક્લિક કરવા માટે કોઈ વ્યક્તિ ધરાવતું નથી. પરિણામે, કોઈપણ ડિપ્લોયમેન્ટ જે અનટેન્ડેડ એજન્ટ્સ પર આધારિત છે તે હાલમાં MCP દ્વારા ગેરંટી આપવામાં આવેલ એકમાત્ર સ્પેકનો ઉપયોગ કરી શકતું નથી.
ડ્રાફ્ટ વિકલ્પો અને તેમની ખામીઓ
બે ડ્રાફ્ટ એક્સ્ટેન્શનનો હેતુ એજન્ટ્સને તેમની પોતાની ઓળખ આપવાનો છે:
- SEP-1932 (DPoP) – ટોકન્સને પબ્લિક-પ્રાઇવેટ કી પેર સાથે જોડે છે, જેનાથી ચોરાયેલા ટોકન્સ નકામા બની જાય છે.
- SEP-1933 (Workload Identity Federation) – એજન્ટ્સને ક્લાઉડ પ્લેટફોર્મ્સમાં પહેલેથી જ પૂરી પાડવામાં આવેલી ઓળખ વાપરવાની મંજૂરી આપે છે.
બંને ઓપન પુલ રિક્વેસ્ટ (pull requests) તરીકે છે; તેમાંથી એક પણ સત્તાવાર સ્પેકમાં મર્જ કરવામાં આવ્યું નથી. તે દરમિયાન, અન્ય એકમાત્ર દસ્તાવેજીકૃત વિકલ્પ OAuth client-credentials ફ્લો છે જેમાં પ્રી-રજિસ્ટર્ડ સિક્રેટ્સની જરૂર હોય છે. એજન્ટ વાંચી શકે તે રીતે તે સિક્રેટ્સનો સંગ્રહ કરવો એ એક ક્લાસિક એટેક સરફેસ બનાવે છે: જો સિક્રેટ લીક થાય છે, તો કોઈપણ હુમલાખોર એજન્ટનું અનુકરણ (impersonate) કરી શકે છે.
આજે પ્રોડક્શન માટે વ્યવહારુ પગલાં
પ્રોટોકોલ હજુ સુધી નેટિવ એજન્ટ ઓળખ પૂરી પાડતું નથી, તેથી ટીમો ઓળખ વ્યવસ્થાપનને (identity management) MCP ની બહાર ખસેડીને એજન્ટ્સને સુરક્ષિત કરી શકે છે:
- વર્કલોડ લેયર પર વેરિફાઈએબલ ઓળખ ઇશ્યૂ કરો. SPIRE જેવી સિસ્ટમ્સ હોસ્ટના ટ્રસ્ટ રૂટ સાથે જોડાયેલા ટૂંકા ગાળાના પ્રમાણપત્રો જનરેટ કરે છે, જે સ્ટેટિક સિક્રેટ્સને દૂર કરે છે.
- ગેટવે પર ક્રેડેન્શિયલ્સ સમાપ્ત કરો. એક ફ્રન્ટ-એન્ડ સર્વિસ API કી અથવા ટોકન ધરાવે છે અને એજન્ટ વતી વિનંતીઓ આગળ મોકલે છે, જેનાથી સિક્રેટ રનટાઇમ એન્વાયરમેન્ટથી દૂર રહે છે.
- વેરિફાઇડ ઓળખના આધારે અધિકૃત કરો, ટોકન કન્ટેન્ટના આધારે નહીં. ઓથેન્ટિકેશન (કોણ કોલ કરી રહ્યું છે) ને ઓથોરાઈઝેશન (તેઓ શું કરી શકે છે) થી અલગ કરો જેથી ઓથેન્ટિકેશન પદ્ધતિ બદલાય તો પણ પોલિસી લાગુ કરી શકાય.
આગળ શું જોવું
બે ઓપન પુલ રિક્વેસ્ટ – DPoP બાઈન્ડિંગ અને વર્કલોડ-આઈડેન્ટિટી ફેડરેશન – MCP ની અંદર સાચા મશીન-ટુ-મશીન ઓળખના ધોરણ તરફના એકમાત્ર માર્ગો છે. જો સમુદાય તેમને મર્જ કરે છે, તો એજન્ટ્સ સિક્રેટ્સ જાહેર કર્યા વિના પ્રાઇવેટ કીની માલિકી સાબિત કરવા અથવા ક્લાઉડ-ઇશ્યુડ ઓળખ મેળવવા માટે સક્ષમ બનશે. ત્યાં સુધી, કોઈપણ પ્રોડક્શન ડિપ્લોયમેન્ટ એક્સટર્નલ આઈડેન્ટિટી ફ્રેમવર્ક પર આધાર રાખવું પડશે અથવા સ્ટેટિક ક્રેડેન્શિયલ્સનું જોખમ સ્વીકારવું પડશે.
નિષ્કર્ષ સ્પષ્ટ છે: MCP હાલમાં વિનંતી પાછળના વ્યક્તિને પ્રમાણિત કરી શકે છે, પરંતુ તે વિનંતી કરતી સોફ્ટવેરને હજુ સુધી પ્રમાણિત કરતું નથી. જે ટીમોને સુરક્ષિત સ્વાયત્ત એજન્ટ્સની જરૂર છે તેમણે સ્પેક આવવાની રાહ જોવી જોઈએ નહીં; તેમણે આજે જ વર્કલોડ લેયર પર ઓળખ બનાવવી જોઈએ અને પેન્ડિંગ DPoP અને ફેડરેશન પ્રસ્તાવો પર નજર રાખવી જોઈએ.