MCP ഒരു സ്റ്റേബിൾ “Enterprise-Managed Authorization” സ്പെസിഫിക്കേഷൻ പ്രസിദ്ധീകരിച്ചിട്ടുണ്ട്; OAuth ക്ലയന്റ്-ക്രെഡൻഷ്യൽസ് ഡ്രാഫ്റ്റും മറ്റ് രണ്ട് ഓപ്പൺ പ്രൊപ്പോസലുകളും ഉൾപ്പെടെയുള്ള മറ്റ് മെഷീൻ-ടു-മെഷീൻ ഐഡന്റിറ്റി ഡ്രാഫ്റ്റുകൾ ഇനിയും പൂർത്തിയായിട്ടില്ല. Model Context Protocol ഉപയോഗിച്ച് ഓട്ടോണമസ് ഏജന്റുകളെ (autonomous agents) പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കുന്നവർക്ക്, ഇന്നത്തെ പ്രോട്ടോക്കോളിന് ഒരു മനുഷ്യ ഉപയോക്താവിനെ (human user) വെരിഫൈ ചെയ്യാൻ കഴിയുമെങ്കിലും, ഒരു അറ്റൻഡഡ് പ്രോസസ്സ് (unattended process) അത് അവകാശപ്പെടുന്ന വ്യക്തി തന്നെയാണെന്ന് തെളിയിക്കാൻ നിലവിൽ ഒരു മാർഗ്ഗവുമില്ല.
റോഡ്മാപ്പ് പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്
ഏജന്റ് ഐഡന്റിറ്റിയും സുരക്ഷയും (agent identity and security) അതിന്റെ പ്രധാന മുൻഗണനകളിൽ ഒന്നായി MCP റോഡ്മാപ്പ് പട്ടികപ്പെടുത്തുന്നു. നാല് കാര്യങ്ങളാണ് റിലീസ് ചെയ്യാൻ നിശ്ചയിച്ചിരുന്നത്: ഹ്യൂമൻ-സെൻട്രിക് ബ്രൗസർ ഫ്ലോ (human-centric browser flow), സർവീസുകൾക്കായുള്ള ഒരു OAuth ക്ലയന്റ്-ക്രെഡൻഷ്യൽസ് ഫ്ലോ, DPoP അടിസ്ഥാനമാക്കിയുള്ള ടോക്കൺ ബൈൻഡിംഗ്, ഒരു വർക്ക്ലോഡ്-ഐഡന്റിറ്റി ഫെഡറേഷൻ മെക്കാനിസം എന്നിവയാണവ. ഇതിൽ ആദ്യത്തേത്—Enterprise-Managed Authorization—മാത്രം സ്റ്റേബിൾ പദവിയിൽ എത്തിയിട്ടുണ്ട്.
സ്റ്റേബിൾ സ്പെസിഫിക്കേഷൻ യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നത്
ഓരോ ജീവനക്കാരനും ഓരോ കണക്ഷനും പ്രത്യേകം അംഗീകരിക്കുന്നതിന് പകരം, ഒരു സിംഗിൾ കൺസോൾ വഴി സെർവർ ആക്സസ് അനുവദിക്കാൻ Enterprise-Managed Authorization ഐടി അഡ്മിൻമാരെ അനുവദിക്കുന്നു. ഈ പ്രക്രിയയിൽ ഒരു ബ്രൗസർ റീഡയറക്റ്റും യൂസർ ലോഗിനും ഉപയോഗിക്കുന്നു, അതിനാൽ ഒരു ലാപ്ടോപ്പിലുള്ള വ്യക്തിക്ക് ഓതന്റിക്കേറ്റ് ചെയ്യാൻ കഴിയും, തുടർന്ന് സെർവർ ആ യൂസറുടെ സെഷനെ വിശ്വസിക്കുകയും ചെയ്യുന്നു.
ഇതിന്റെ പരിമിതി വ്യക്തമാണ്: ഈ പ്രക്രിയയ്ക്ക് കീബോർഡിൽ ഇരിക്കുന്ന ഒരു മനുഷ്യൻ ആവശ്യമാണ്. രാത്രികാലങ്ങളിൽ പ്രവർത്തിക്കുന്നതോ, ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നതോ, അല്ലെങ്കിൽ അലേർട്ടുകൾക്ക് പ്രതികരിക്കുന്നതോ ആയ ഒരു ഏജന്റിന് ലോഗിൻ ബട്ടൺ ക്ലിക്ക് ചെയ്യാൻ ആരുമില്ല. തൽഫലമായി, അറ്റൻഡഡ് ഏജന്റുകളെ (unattended agents) ആശ്രയിക്കുന്ന ഏത് വിന്യാസത്തിനും (deployment) നിലവിൽ MCP ഉറപ്പുനൽകുന്ന ഏക സ്പെസിഫിക്കേഷൻ ഉപയോഗിക്കാൻ കഴിയില്ല.
ഡ്രാഫ്റ്റ് ഓപ്ഷനുകളും അവയുടെ പോരായ്മകളും
ഏജന്റുകൾക്ക് സ്വന്തമായി ഐഡന്റിറ്റി നൽകുന്നതിനായി രണ്ട് ഡ്രാഫ്റ്റ് എക്സ്റ്റൻഷനുകൾ ലക്ഷ്യമിടുന്നു:
- SEP-1932 (DPoP) – ടോക്കണുകളെ ഒരു പബ്ലിക്-പ്രൈവറ്റ് കീ പെയറുമായി ബന്ധിപ്പിക്കുന്നു, ഇത് മോഷ്ടിക്കപ്പെട്ട ടോക്കണുകൾ ഉപയോഗശൂന്യമാക്കുന്നു.
- SEP-1933 (Workload Identity Federation) – ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമുകളിൽ നേരത്തെ തന്നെ നൽകിയിട്ടുള്ള ഐഡന്റിറ്റികൾ ഏജന്റുകൾക്ക് സ്വീകരിക്കാൻ അനുവദിക്കുന്നു.
ഇവ രണ്ടും ഓപ്പൺ പുൾ റിക്വസ്റ്റുകളായി (open pull requests) നിലനിൽക്കുന്നു; ഇവയൊന്നും ഔദ്യോഗിക സ്പെസിഫിക്കേഷനിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല. ഇതിനിടയിൽ, മുൻകൂട്ടി രജിസ്റ്റർ ചെയ്ത സീക്രട്ടുകൾ (secrets) ആവശ്യമായ ഒരു OAuth ക്ലയന്റ്-ക്രെഡൻഷ്യൽസ് ഫ്ലോ മാത്രമാണ് രേഖപ്പെടുത്തപ്പെട്ട മറ്റൊരു ഓപ്ഷൻ. ഏജന്റിന് വായിക്കാൻ കഴിയുന്ന രീതിയിൽ ഈ സീക്രട്ടുകൾ സൂക്ഷിക്കുന്നത് ഒരു വലിയ സുരക്ഷാ ഭീഷണി (attack surface) സൃഷ്ടിക്കുന്നു: സീക്രട്ട് ചോർന്നാൽ, ഏതൊരു ആക്രമണകാരിക്കും ഏജന്റായി ചമയാൻ കഴിയും.
ഇന്നത്തെ പ്രൊഡക്ഷൻ സാഹചര്യങ്ങളിൽ സ്വീകരിക്കാവുന്ന പ്രായോഗിക നടപടികൾ
പ്രോട്ടോക്കോൾ ഇതുവരെ ഒരു നേറ്റീവ് ഏജന്റ് ഐഡന്റിറ്റി നൽകുന്നില്ലാത്തതിനാൽ, ഐഡന്റിറ്റി മാനേജ്‌മെന്റ് MCP-ക്ക് പുറത്തേക്ക് മാറ്റുന്നതിലൂടെ ടീമുകൾക്ക് ഏജന്റുകളെ സുരക്ഷിതമാക്കാം:
- വർക്ക്ലോഡ് ലെയറിൽ വെരിഫയബിൾ ഐഡന്റിറ്റികൾ നൽകുക. SPIRE പോലുള്ള സിസ്റ്റങ്ങൾ ഹോസ്റ്റിന്റെ ട്രസ്റ്റ് റൂട്ടുമായി ബന്ധിപ്പിച്ചുള്ള ഹ്രസ്വകാല സർട്ടിഫിക്കറ്റുകൾ നിർമ്മിക്കുന്നു, ഇത് സ്റ്റാറ്റിക് സീക്രട്ടുകളുടെ ആവശ്യം ഇല്ലാതാക്കുന്നു.
- ഗേറ്റ്‌വേയിൽ വെച്ച് ക്രെഡൻഷ്യലുകൾ അവസാനിപ്പിക്കുക (Terminate credentials). ഒരു ഫ്രണ്ട്-എൻഡ് സർവീസ് API കീ അല്ലെങ്കിൽ ടോക്കൺ കൈവശം വയ്ക്കുകയും ഏജന്റിന് വേണ്ടി റിക്വസ്റ്റുകൾ ഫോർവേഡ് ചെയ്യുകയും ചെയ്യുന്നു, ഇത് റൺടൈം എൻവയോൺമെന്റിൽ നിന്ന് സീക്രട്ടുകളെ അകറ്റി നിർത്തുന്നു.
- ടോക്കൺ ഉള്ളടക്കത്തിന് പകരം വെരിഫൈ ചെയ്ത ഐഡന്റിറ്റിയുടെ അടിസ്ഥാനത്തിൽ ഓതറൈസ് ചെയ്യുക. ഓതന്റിക്കേഷൻ (ആരാണ് വിളിക്കുന്നത്) എന്നത് ഓതറൈസേഷനിൽ (അവർക്ക് എന്ത് ചെയ്യാൻ കഴിയും) നിന്ന് വേർതിരിക്കുക, അതുവഴി ഓതന്റിക്കേഷൻ രീതി മാറിയാലും പോളിസി നടപ്പിലാക്കാൻ കഴിയും.
ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
DPoP ബൈൻഡിംഗ്, വർക്ക്ലോഡ്-ഐഡന്റിറ്റി ഫെഡറേഷൻ എന്നീ രണ്ട് ഓപ്പൺ പുൾ റിക്വസ്റ്റുകൾ മാത്രമാണ് MCP-ക്കുള്ളിൽ യഥാർത്ഥ മെഷീൻ-ടു-മെഷീൻ ഐഡന്റിറ്റി സ്റ്റാൻഡേർഡിലേക്കുള്ള ഏക വഴികൾ. കമ്മ്യൂണിറ്റി ഇവ സംയോജിപ്പിക്കുകയാണെങ്കിൽ, സീക്രട്ടുകൾ വെളിപ്പെടുത്താതെ തന്നെ ഒരു പ്രൈവറ്റ് കീ കൈവശമുണ്ടെന്ന് തെളിയിക്കാനോ ക്ലൗഡ് നൽകിയ ഐഡന്റിറ്റികൾ സ്വീകരിക്കാനോ ഏജന്റുകൾക്ക് സാധിക്കും. അതുവരെ, ഏതൊരു പ്രൊഡക്ഷൻ വിന്യാസവും ബാഹ്യ ഐഡന്റിറ്റി ഫ്രെയിംവർക്കുകളെ ആശ്രയിക്കേണ്ടി വരും അല്ലെങ്കിൽ സ്റ്റാറ്റിക് ക്രെഡൻഷ്യലുകളുടെ റിസ്ക് സ്വീകരിക്കേണ്ടി വരും.
ഇതിലെ പാഠം വ്യക്തമാണ്: ഒരു റിക്വസ്റ്റിന് പിന്നിലുള്ള വ്യക്തിയെ ഓതന്റിക്കേറ്റ് ചെയ്യാൻ നിലവിൽ MCP-ക്ക് കഴിയും, എന്നാൽ റിക്വസ്റ്റ് നടത്തുന്ന സോഫ്റ്റ്‌വെയറിനെ അത് ഓതന്റിക്കേറ്റ് ചെയ്യുന്നില്ല. സുരക്ഷിതമായ ഓട്ടോണമസ് ഏജന്റുകൾ ആവശ്യമുള്ള ടീമുകൾ സ്പെസിഫിക്കേഷൻ വരുന്നത് വരെ കാത്തിരിക്കരുത്; അവർ ഇന്ന് തന്നെ വർക്ക്ലോഡ് ലെയറിൽ ഐഡന്റിറ്റി നിർമ്മിക്കുകയും നിലവിൽ വരാനിരിക്കുന്ന DPoP, ഫെഡറേഷൻ പ്രൊപ്പോസലുകൾ എന്നിവ ശ്രദ്ധിക്കുകയും വേണം.