MCP ஒரு நிலையான “Enterprise-Managed Authorization” விபரக்குறிப்பை (spec) வெளியிட்டுள்ளது; OAuth client-credentials வரைவு மற்றும் இரண்டு திறந்த முன்மொழிவுகள் உட்பட மற்ற machine-to-machine அடையாள வரைவுகள் இன்னும் முழுமையடையவில்லை. Model Context Protocol மூலம் தன்னாட்சி முகவர்களை (autonomous agents) இயக்க முயற்சிப்பவர்களுக்கு, இன்றைய புரோட்டோகால் ஒரு மனித பயனரைச் சரிபார்க்க முடியும், ஆனால் ஒரு தானியங்கி செயல்முறை (unattended process) தான் அது என்று நிரூபிப்பதற்கான தயார் நிலையில் உள்ள வழிமுறையை வழங்கவில்லை.
இந்தத் திட்டவரைவு (roadmap) ஏன் முக்கியமானது
Model Context Protocol (MCP) திட்டவரைவு, முகவர் அடையாளம் (agent identity) மற்றும் பாதுகாப்பை அதன் முக்கிய முன்னுரிமைகளில் ஒன்றாகப் பட்டியலிடுகிறது. நான்கு அம்சங்கள் வெளியிடத் திட்டமிடப்பட்டிருந்தன: மனிதர்களை மையமாகக் கொண்ட பிரவுசர் ஓட்டம் (human-centric browser flow), சேவைகளுக்கான OAuth client-credentials ஓட்டம், DPoP-அடிப்படையிலான டோக்கன் பிணைப்பு (token binding), மற்றும் workload-identity federation நுட்பம். இதில் முதலாவதான—Enterprise-Managed Authorization—மட்டும் நிலையான நிலையை எட்டியுள்ளது.
இந்த நிலையான விபரக்குறிப்பு (spec) உண்மையில் என்ன செய்கிறது
Enterprise-Managed Authorization மூலம், ஒவ்வொரு ஊழியரும் ஒவ்வொரு இணைப்பையும் அங்கீகரிக்க வேண்டிய அவசியமின்றி, IT நிர்வாகிகள் ஒரே ஒரு கன்சோலில் (console) இருந்து சர்வர் அணுகலை வழங்க முடியும். இந்த ஓட்டம் ஒரு பிரவுசர் ரீடைரக்ட் (browser redirect) மற்றும் பயனர் லாகின் முறையைப் பயன்படுத்துகிறது, இதனால் லேப்டாப் பயன்படுத்துபவர் அங்கீகாரம் பெற்றவுடன், சர்வர் அந்த பயனரின் அமர்வை (session) நம்புகிறது.
இதன் வரம்பு வெளிப்படையானது: இந்தச் செயல்முறைக்கு விசைப்பலகையில் (keyboard) ஒரு மனிதர் தேவை. இரவு முழுவதும் இயங்கும், தரவைச் செயலாக்கும் அல்லது எச்சரிக்கைகளுக்குப் பதிலளிக்கும் ஒரு முகவருக்கு (agent), லாகின் பட்டனை அழுத்த யாரும் இருக்க மாட்டார்கள். இதன் விளைவாக, தானியங்கி முகவர்களைச் சார்ந்திருக்கும் எந்தவொரு பயன்பாடும் (deployment), தற்போது MCP உறுதி அளிக்கும் ஒரே விபரக்குறிப்பைப் பயன்படுத்த முடியாது.
வரைவு விருப்பங்கள் மற்றும் அவற்றின் குறைபாடுகள்
முகவர்களுக்குத் தனிப்பட்ட அடையாளத்தை வழங்குவதை இரண்டு வரைவு விரிவாக்கங்கள் (draft extensions) நோக்கமாகக் கொண்டுள்ளன:
- SEP-1932 (DPoP) – டோக்கன்களை ஒரு public-private key ஜோடியுடன் இணைக்கிறது, இதனால் திருடப்பட்ட டோக்கன்கள் பயனற்றதாகிவிடும்.
- SEP-1933 (Workload Identity Federation) – கிளவுட் தளங்களில் ஏற்கனவே வழங்கப்பட்டுள்ள அடையாளங்களை முகவர்கள் பெற அனுமதிக்கிறது.
இவை இரண்டும் திறந்த நிலையில் உள்ள pull requests ஆக உள்ளன; இவை எதுவும் அதிகாரப்பூர்வ விபரக்குறிப்பில் இணைக்கப்படவில்லை. இதற்கிடையில், ஆவணப்படுத்தப்பட்ட மற்றொரு ஒரே விருப்பம், முன்கூட்டியே பதிவு செய்யப்பட்ட ரகசியங்களை (secrets) கோரும் OAuth client-credentials ஓட்டம் மட்டுமே. ஒரு முகவரால் படிக்கக்கூடிய இடத்தில் அந்த ரகசியங்களைச் சேமிப்பது ஒரு பொதுவான தாக்குதல் வாய்ப்பை (attack surface) உருவாக்குகிறது: ரகசியம் கசிந்தால், எந்தவொரு தாக்குதல்தாரரும் முகவர் போலத் தங்களை அடையாளப்படுத்திக் கொள்ள முடியும்.
இன்றைய உற்பத்திச் சூழலுக்கான (production) நடைமுறைப் படிகள்
இந்த புரோட்டோகால் இன்னும் ஒரு இயல்பான முகவர் அடையாளத்தை (native agent identity) வழங்காததால், அடையாள மேலாண்மையை (identity management) MCP-க்கு வெளியே கொண்டு செல்வதன் மூலம் குழுக்கள் முகவர்களைப் பாதுகாப்பாக வைத்திருக்க முடியும்:
- Workload அடுக்கில் சரிபார்க்கக்கூடிய அடையாளங்களை வழங்குங்கள். SPIRE போன்ற அமைப்புகள் ஹோஸ்டின் trust root உடன் இணைக்கப்பட்ட குறுகிய காலச் சான்றிதழ்களை உருவாக்குகின்றன, இது நிலையான ரகசியங்களை (static secrets) தவிர்க்கிறது.
- Gateway-இல் சான்றுகளை (credentials) முடிவுக்குக் கொண்டு வாருங்கள். ஒரு front-end சேவை API key அல்லது டோக்கனைத் தன்னிடம் வைத்துக்கொண்டு, முகவர் சார்பாக கோரிக்கைகளை (requests) முன்னோக்கி அனுப்புகிறது, இதன் மூலம் ரகசியம் runtime சூழலுக்கு வெளியே வைக்கப்படுகிறது.
- டோக்கன் உள்ளடக்கத்தை வைத்து அல்லாமல், சரிபார்க்கப்பட்ட அடையாளத்தின் அடிப்படையில் அங்கீகாரம் செய்யுங்கள். அங்கீகாரம் (authentication - யார் அழைக்கிறார்கள்) மற்றும் அனுமதி (authorization - அவர்கள் என்ன செய்யலாம்) ஆகியவற்றைத் தனித்தனியாகப் பிரியுங்கள், இதனால் அங்கீகார முறை மாறினாலும் கொள்கைகளை (policy) அமல்படுத்த முடியும்.
அடுத்து கவனிக்க வேண்டியவை
திறந்த நிலையில் உள்ள அந்த இரண்டு pull requests – DPoP binding மற்றும் workload-identity federation – ஆகியவையே MCP-க்குள் உண்மையான machine-to-machine அடையாளத் தரநிலையை நோக்கிய ஒரே பாதைகள். சமூகம் அவற்றை இணைத்தால், முகவர்கள் ரகசியங்களை வெளிப்படுத்தாமல் ஒரு private key-ஐ வைத்திருப்பதை நிரூபிக்கவோ அல்லது கிளவுட் மூலம் வழங்கப்பட்ட அடையாளங்களைப் பெறவோ முடியும். அதுவரை, எந்தவொரு உற்பத்திச் சூழலும் (production deployment) வெளிப்புற அடையாளக் கட்டமைப்புகளைச் சார்ந்திருக்க வேண்டும் அல்லது நிலையான சான்றுகளின் (static credentials) அபாயத்தை ஏற்க வேண்டும்.
இதிலிருந்து நாம் அறிவது தெளிவானது: MCP தற்போது ஒரு கோரிக்கைக்குப் பின்னால் இருக்கும் நபரை அங்கீகரிக்க முடியும், ஆனால் கோரிக்கையைச் செய்யும் மென்பொருளை இன்னும் அங்கீகரிக்கவில்லை. பாதுகாப்பான தன்னாட்சி முகவர்கள் தேவைப்படும் குழுக்கள், விபரக்குறிப்பு வரும் வரை காத்திருக்கக் கூடாது; அவர்கள் இன்றே workload அடுக்கில் அடையாளத்தை உருவாக்க வேண்டும் மற்றும் நிலுவையில் உள்ள DPoP மற்றும் federation முன்மொழிவுகளைக் கவனித்து வர வேண்டும்.