MCP একটি স্থিতিশীল “Enterprise-Managed Authorization” spec প্রকাশ করেছে; অন্যান্য machine-to-machine identity ড্রাফটগুলো—যার মধ্যে একটি OAuth client-credentials ড্রাফট এবং দুটি ওপেন প্রপোজাল অন্তর্ভুক্ত—এখনও অসম্পূর্ণ রয়েছে। যারা Model Context Protocol দিয়ে autonomous agents চালাতে চাইছেন, তাদের জন্য এর অর্থ হলো বর্তমান প্রোটোকল একজন মানুষের পরিচয় যাচাই করতে পারলেও, একটি unattended process বা স্বয়ংক্রিয় প্রক্রিয়া যে সে আসলে কে, তা প্রমাণ করার জন্য কোনো প্রস্তুতকৃত উপায় প্রদান করে না।
রোডম্যাপ কেন গুরুত্বপূর্ণ
Model Context Protocol (MCP) রোডম্যাপে agent identity এবং security-কে শীর্ষ অগ্রাধিকারের তালিকায় রাখা হয়েছে। চারটি বিষয় প্রকাশের জন্য নির্ধারিত ছিল: একটি human-centric browser flow, সার্ভিসের জন্য একটি OAuth client-credentials flow, একটি DPoP-ভিত্তিক token binding, এবং একটি workload-identity federation mechanism। শুধুমাত্র প্রথমটি—Enterprise-Managed Authorization—স্থিতিশীল অবস্থায় পৌঁছেছে।
স্থিতিশীল specটি আসলে কী করে
Enterprise-Managed Authorization আইটি অ্যাডমিনদের প্রতিটি সংযোগের জন্য প্রতিটি কর্মচারীর অনুমোদনের প্রয়োজন ছাড়াই একটি একক কনসোল থেকে সার্ভার অ্যাক্সেস দেওয়ার সুবিধা দেয়। এই ফ্লোতে একটি browser redirect এবং ইউজার লগইন ব্যবহার করা হয়, ফলে ল্যাপটপে থাকা একজন ব্যক্তি authenticate করতে পারেন এবং এরপর সার্ভার সেই ইউজারের সেশনকে বিশ্বাস করে।
এর সীমাবদ্ধতাটি স্পষ্ট: এই প্রক্রিয়ার জন্য কিবোর্ডে একজন মানুষের প্রয়োজন। একটি এজেন্ট যা সারারাত চলে, ডেটা প্রসেস করে বা অ্যালার্টের প্রতিক্রিয়া জানায়, তার কাছে লগইন বাটনে ক্লিক করার মতো কেউ নেই। ফলস্বরূপ, যে কোনো deployment যা unattended agents-এর ওপর নির্ভরশীল, তা বর্তমানে MCP-এর একমাত্র নিশ্চিত specটি ব্যবহার করতে পারে না।
ড্রাফট অপশন এবং তাদের অসুবিধাগুলো
দুটি ড্রাফট এক্সটেনশন এজেন্টদের নিজস্ব পরিচয় দেওয়ার লক্ষ্য রাখে:
- SEP-1932 (DPoP) – টোকেনগুলোকে একটি public-private key pair-এর সাথে যুক্ত করে, ফলে চুরি হওয়া টোকেনগুলো অকেজো হয়ে পড়ে।
- SEP-1933 (Workload Identity Federation) – এজেন্টদের ক্লাউড প্ল্যাটফর্মে ইতিমধ্যে provision করা পরিচয়গুলো উত্তরাধিকারসূত্রে গ্রহণ করতে দেয়।
উভয়ই বর্তমানে ওপেন pull request হিসেবে রয়েছে; কোনোটিই অফিসিয়াল spec-এ merge করা হয়নি। ইতিমধ্যে, একমাত্র অন্য নথিভুক্ত বিকল্পটি হলো একটি OAuth client-credentials flow যার জন্য pre-registered secrets প্রয়োজন। সেই secretগুলো এমন জায়গায় সংরক্ষণ করা যেখানে একটি এজেন্ট সেগুলো পড়তে পারে, তা একটি ক্লাসিক attack surface তৈরি করে: যদি secretটি ফাঁস হয়ে যায়, তবে যেকোনো আক্রমণকারী এজেন্টের ছদ্মবেশ ধারণ করতে পারে।
বর্তমানে প্রোডাকশনের জন্য ব্যবহারিক পদক্ষেপসমূহ
যেহেতু প্রোটোকলটি এখনও একটি native agent identity প্রদান করে না, তাই টিমগুলো identity management MCP-এর বাইরে নিয়ে গিয়ে এজেন্টগুলোকে সুরক্ষিত করতে পারে:
- Workload লেয়ারে যাচাইযোগ্য পরিচয় প্রদান করুন। SPIRE-এর মতো সিস্টেমগুলো হোস্টের trust root-এর সাথে যুক্ত short-lived certificates তৈরি করে, যা static secrets ব্যবহারের প্রয়োজনীয়তা দূর করে।
- একটি gateway-তে credentials শেষ করুন। একটি front-end service API key বা token ধারণ করে এবং এজেন্টের পক্ষ থেকে requests গুলো forward করে, ফলে secretটি runtime environment-এর বাইরে থাকে।
- Token কন্টেন্টের পরিবর্তে যাচাইকৃত পরিচয়ের ভিত্তিতে authorize করুন। Authentication (কে কল করছে) এবং authorization (তারা কী করতে পারে)-কে আলাদা রাখুন যাতে authentication পদ্ধতি পরিবর্তন হলেও policy কার্যকর করা যায়।
পরবর্তীতে যা খেয়াল রাখতে হবে
দুটি ওপেন pull request – DPoP binding এবং workload-identity federation – হলো MCP-এর মধ্যে একটি প্রকৃত machine-to-machine identity standard-এ পৌঁছানোর একমাত্র পথ। কমিউনিটি যদি এগুলো merge করে, তবে এজেন্টরা secret প্রকাশ না করেই একটি private key-এর মালিকানা প্রমাণ করতে পারবে বা cloud-issued পরিচয়গুলো গ্রহণ করতে পারবে। ততক্ষণ পর্যন্ত, যেকোনো production deployment-কে অবশ্যই বাহ্যিক identity framework-এর ওপর নির্ভর করতে হবে অথবা static credentials-এর ঝুঁকি মেনে নিতে হবে।
মূল কথাটি পরিষ্কার: MCP বর্তমানে একটি request-এর পেছনের ব্যক্তিকে authenticate করতে পারে, কিন্তু এটি request করা software-টিকে এখনও authenticate করতে পারে না। যে টিমগুলোর নিরাপদ autonomous agents প্রয়োজন, তাদের specটি আসার জন্য অপেক্ষা করা উচিত নয়; তাদের আজই workload লেয়ারে identity তৈরি করতে হবে এবং পেন্ডিং DPoP ও federation প্রপোজালগুলোর দিকে নজর রাখতে হবে।