MCP ಒಂದು ಸ್ಥಿರವಾದ “Enterprise-Managed Authorization” ಸ್ಪೆಕ್ (spec) ಅನ್ನು ಪ್ರಕಟಿಸಿದೆ; OAuth client-credentials ಡ್ರಾಫ್ಟ್ ಮತ್ತು ಎರಡು ಮುಕ್ತ ಪ್ರಸ್ತಾವನೆಗಳು ಸೇರಿದಂತೆ ಇತರ machine-to-machine identity ಡ್ರಾಫ್ಟ್‌ಗಳು ಇನ್ನೂ ಅಪೂರ್ಣವಾಗಿವೆ. Model Context Protocol ಬಳಸಿ ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್‌ಗಳನ್ನು (autonomous agents) ನಡೆಸಲು ಪ್ರಯತ್ನಿಸುವವರಿಗೆ, ಇದರರ್ಥ ಇಂದಿನ ಪ್ರೊಟೊಕಾಲ್ ಮಾನವ ಬಳಕೆದಾರರನ್ನು ಪರಿಶೀಲಿಸಬಲ್ಲದು ಆದರೆ ಒಂದು unattended ಪ್ರಕ್ರಿಯೆಯು ಅದು ಹೇಳಿಕೊಂಡಿರುವಂತೆಯೇ ಇರುವುದನ್ನು ಸಾಬೀತುಪಡಿಸಲು ಸಿದ್ಧವಿರುವ ಯಾವುದೇ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ.
ರೋಡ್‌ಮ್ಯಾಪ್ ಏಕೆ ಮುಖ್ಯ
Model Context Protocol (MCP) ರೋಡ್‌ಮ್ಯಾಪ್ ಏಜೆಂಟ್ identity ಮತ್ತು security ಅನ್ನು ತನ್ನ ಪ್ರಮುಖ ಆದ್ಯತೆಗಳಲ್ಲಿ ಒಂದಾಗಿ ಪಟ್ಟಿ ಮಾಡಿದೆ. ಬಿಡುಗಡೆಗಾಗಿ ನಾಲ್ಕು ಅಂಶಗಳನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿತ್ತು: human-centric browser flow, ಸೇವೆಗಳಿಗಾಗಿ OAuth client-credentials flow, DPoP-ಆಧಾರಿತ token binding, ಮತ್ತು workload-identity federation mechanism. ಕೇವಲ ಮೊದಲನೆಯದು—Enterprise-Managed Authorization—ಸ್ಥಿರ ಸ್ಥಿತಿಯನ್ನು ತಲುಪಿದೆ.
ಸ್ಥಿರವಾದ ಸ್ಪೆಕ್ ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ
Enterprise-Managed Authorization ಮೂಲಕ IT ಅಡ್ಮಿನ್‌ಗಳು ಪ್ರತಿಯೊಬ್ಬ ಉದ್ಯೋಗಿಯು ಪ್ರತಿಯೊಂದು ಸಂಪರ್ಕವನ್ನು ಅನುಮೋದಿಸುವ ಬದಲು, ಒಂದೇ ಕನ್ಸೋಲ್‌ನಿಂದ ಸರ್ವರ್ ಪ್ರವೇಶವನ್ನು ನೀಡಬಹುದು. ಈ ಪ್ರಕ್ರಿಯೆಯು browser redirect ಮತ್ತು ಬಳಕೆದಾರರ ಲಾಗಿನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿರುವ ವ್ಯಕ್ತಿಯು પ્રમાݨೀಕರಿಸಬಹುದು (authenticate) ಮತ್ತು ನಂತರ ಸರ್ವರ್ ಆ ಬಳಕೆದಾರರ ಸೆಷನ್ ಅನ್ನು ನಂಬುತ್ತದೆ.
ಇದರ ಮಿತಿ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಈ ಪ್ರಕ್ರಿಯೆಗೆ ಕೀಬೋರ್ಡ್ ಬಳಸಿ ಕೆಲಸ ಮಾಡುವ ಮಾನವನ ಅಗತ್ಯವಿದೆ. ರಾತ್ರಿಯಿಡೀ ಚಾಲನೆಯಲ್ಲಿರುವ, ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಅಥವಾ ಅಲರ್ಟ್‌ಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಏಜೆಂಟ್‌ಗೆ ಲಾಗಿನ್ ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡಲು ಯಾರೂ ಇರುವುದಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, unattended ಏಜೆಂಟ್‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಯಾವುದೇ ನಿಯೋಜನೆಗಳು (deployment) MCP ಪ್ರಸ್ತುತ ಖಾತರಿಪಡಿಸುವ ಏಕೈಕ ಸ್ಪೆಕ್ ಅನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಡ್ರಾಫ್ಟ್ ಆಯ್ಕೆಗಳು ಮತ್ತು ಅವುಗಳ ನ್ಯೂನತೆಗಳು
ಏಜೆಂಟ್‌ಗಳಿಗೆ ತಮ್ಮದೇ ಆದ identity ನೀಡುವ ಗುರಿಯನ್ನು ಹೊಂದಿರುವ ಎರಡು ಡ್ರಾಫ್ಟ್ ಎಕ್ಸ್‌ಟೆನ್ಶನ್‌ಗಳು ಇಲ್ಲಿವೆ:
- SEP-1932 (DPoP) – ಟೋಕನ್‌ಗಳನ್ನು public-private key ಜೋಡಿಗೆ ಬಂಧಿಸುತ್ತದೆ, ಇದರಿಂದ ಕಳುವಾದ ಟೋಕನ್‌ಗಳು ನಿಷ್ಪ್ರಯೋಜಕವಾಗುತ್ತವೆ.
- SEP-1933 (Workload Identity Federation) – ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಈಗಾಗಲೇ ಒದಗಿಸಲಾದ identityಗಳನ್ನು ಏಜೆಂಟ್‌ಗಳು ಪಡೆದುಕೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ.
ಇವೆರಡೂ ಮುಕ್ತ pull requests ಗಳಾಗಿವೆ; ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಅಧಿಕೃತ ಸ್ಪೆಕ್‌ನಲ್ಲಿ ವಿಲೀನಗೊಂಡಿಲ್ಲ. ಈ ಮಧ್ಯೆ, ದಾಖಲಿಸಲಾದ ಏಕೈಕ ಇತರ ಆಯ್ಕೆಯೆಂದರೆ ಮೊದಲೇ ನೋಂದಾಯಿಸಲಾದ secrets ಅಗತ್ಯವಿರುವ OAuth client-credentials flow. ಏಜೆಂಟ್ ಓದಬಲ್ಲ ಸ್ಥಳದಲ್ಲಿ ಆ secrets ಅನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಒಂದು ಸಾಂಪ್ರದಾಯಿಕ attack surface ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ: ಒಂದು ವೇಳೆ secret ಸೋರಿಕೆಯಾದರೆ, ಯಾವುದೇ ದಾಳಿಕಾರನು ಏಜೆಂಟ್‌ನಂತೆ ನಟಿಸಬಹುದು (impersonate).
ಇಂದಿನ ಪ್ರೊಡಕ್ಷನ್‌ಗಾಗಿ ಪ್ರಾಯೋಗಿಕ ಹಂತಗಳು
ಪ್ರೊಟೊಕಾಲ್ ಇನ್ನೂ native agent identity ಅನ್ನು ಒದಗಿಸದ ಕಾರಣ, ತಂಡಗಳು identity management ಅನ್ನು MCP ಹೊರಗೆ ಸ್ಥಳಾಂತರಿಸುವ ಮೂಲಕ ಏಜೆಂಟ್‌ಗಳನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸಬಹುದು:
- Workload layer ನಲ್ಲಿ ಪರಿಶೀಲಿಸಬಹುದಾದ identityಗಳನ್ನು ನೀಡಿ. SPIRE ನಂತಹ ವ್ಯವಸ್ಥೆಗಳು host ನ trust root ಗೆ ಸಂಬಂಧಿಸಿದ ಅಲ್ಪಾವಧಿಯ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು (short-lived certificates) ಸೃಷ್ಟಿಸುತ್ತವೆ, ಇದು static secrets ಅನ್ನು ಇಲ್ಲದಂತೆ ಮಾಡುತ್ತದೆ.
- Gateway ನಲ್ಲಿ credentials ಅನ್ನು ಕೊನೆಗೊಳಿಸಿ (Terminate). ಒಂದು front-end service API key ಅಥವಾ token ಅನ್ನು ಹೊಂದಿದ್ದು, ಏಜೆಂಟ್ ಪರವಾಗಿ ವಿನಂತಿಗಳನ್ನು (requests) ಕಳುಹಿಸುತ್ತದೆ, ಇದರಿಂದ secret ಅನ್ನು runtime environment ನಿಂದ ದೂರವಿಡಬಹುದು.
- Token ವಿಷಯದ ಮೇಲೆ ಅಲ್ಲದೆ, ಪರಿಶೀಲಿಸಿದ identity ಆಧಾರದ ಮೇಲೆ ಅಧಿಕಾರ ನೀಡಿ (Authorize). Authentication (ಯಾರು ಕರೆ ಮಾಡುತ್ತಿದ್ದಾರೆ) ಮತ್ತು authorization (ಅವರು ಏನು ಮಾಡಬಹುದು) ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ, ಇದರಿಂದ authentication ವಿಧಾನವು ಬದಲಾದರೂ policy ಅನ್ನು ಜಾರಿಗೆ ತರಬಹುದು.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
ಎರಡು ಮುಕ್ತ pull requests – DPoP binding ಮತ್ತು workload-identity federation – MCP ಒಳಗೆ ನಿಜವಾದ machine-to-machine identity ಮಾನದಂಡಕ್ಕೆ ಇರುವ ಏಕೈಕ ಮಾರ್ಗಗಳಾಗಿವೆ. ಸಮುದಾಯವು ಅವುಗಳನ್ನು ವಿಲೀನಗೊಳಿಸಿದರೆ, ಏಜೆಂಟ್‌ಗಳು secrets ಅನ್ನು ಬಹಿರಂಗಪಡಿಸದೆ private key ಹೊಂದಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಲು ಅಥವಾ ಕ್ಲೌಡ್ ನೀಡಿದ identityಗಳನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಅಲ್ಲಿಯವರೆಗೆ, ಯಾವುದೇ ಪ್ರೊಡಕ್ಷನ್ ನಿಯೋಜನೆಯು ಬಾಹ್ಯ identity frameworks ಗಳನ್ನು ಅವಲಂಬಿಸಬೇಕಾಗುತ್ತದೆ ಅಥವಾ static credentials ನ ಅಪಾಯವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.
ಇದರ ಸಾರಾಂಶ ಸ್ಪಷ್ಟವಾಗಿದೆ: MCP ಪ್ರಸ್ತುತ ವಿನಂತಿಯ ಹಿಂದಿರುವ ವ್ಯಕ್ತಿಯನ್ನು પ્રમાݨೀಕರಿಸಬಲ್ಲದು, ಆದರೆ ವಿನಂತಿಯನ್ನು ಮಾಡುವ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಇದು ಇನ್ನೂ પ્રમાݨೀಕರಿಸುವುದಿಲ್ಲ. ಸುರಕ್ಷಿತ ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್‌ಗಳು ಬೇಕಾದ ತಂಡಗಳು ಸ್ಪೆಕ್ ಬರಲು ಕಾಯಬಾರದು; ಅವರು ಇಂದೇ workload layer ನಲ್ಲಿ identity ಅನ್ನು ನಿರ್ಮಿಸಬೇಕು ಮತ್ತು ಬಾಕಿ ಇರುವ DPoP ಮತ್ತು federation ಪ್ರಸ್ತಾವನೆಗಳ ಮೇಲೆ ಕಣ್ಣಿಡಬೇಕು.