আপনার .env ফাইলে AWS access key পেস্ট করা বন্ধ করুন।
আমরা সবাই এই পরিস্থিতির মধ্য দিয়ে গিয়েছি। রাত অনেক হয়েছে, আপনি একটি Lambda permission error ডিবাগ করছেন, আর আপনার AI অ্যাসিস্ট্যান্ট ক্রমাগত কাল্পনিক অ্যাকাউন্ট আইডি সহ সার্ভিস নাম বা ARN তৈরি করে চলেছে। আপনি চান মডেলটি আপনার আসল রিসোর্সগুলো দেখুক যাতে এটি ভুল তথ্য (hallucinating) দেওয়া বন্ধ করে এবং সমস্যা সমাধান শুরু করে। মরিয়া হয়ে আপনি একটি access key সংগ্রহ করেন, সেটি একটি এনভায়রনমেন্ট ফাইলে ফেলে দেন এবং এজেন্টকে দিয়ে দেন। এটি কাজ করে। আপনি স্বস্তি পান। তারপর সকাল হলো, এবং আপনি বুঝতে পারলেন যে সেই সিক্রেটটি আপনার শেল হিস্ট্রি (shell history), টার্মিনাল স্ক্রলব্যাক (terminal scrollback), অথবা আরও খারাপভাবে, একটি কমিট (commit) হিসেবে শেয়ারড রিপোজিটরিতে পুশ হয়ে গেছে।
Model Context Protocol ঠিক এই বিশৃঙ্খলাটি প্রতিরোধ করার জন্যই তৈরি করা হয়েছে।
MCP আপনার AI এজেন্ট এবং এক্সটার্নাল সিস্টেমের মধ্যে একটি স্ট্যান্ডার্ড ব্রিজ তৈরি করে। এজেন্ট যাতে আপনার ক্রেডেনশিয়াল (credentials) ফাঁস না করে সেই আশায় সরাসরি সেগুলো না দিয়ে, বরং আপনি একটি নিয়ন্ত্রিত সার্ভারের মাধ্যমে সংযোগ স্থাপন করেন যা অথেন্টিকেশন (authentication) পরিচালনা করে, পারমিশন স্কোপ করে এবং আপনার কী (key) গুলোকে চ্যাট উইন্ডো থেকে সম্পূর্ণ দূরে রাখে।
AWS-এর জন্য, বর্তমানে আপনার কাছে বেছে নেওয়ার জন্য দুটি অফিসিয়াল MCP সার্ভার রয়েছে। ভুলটি বেছে নিলে আপনার এজেন্ট হয় অন্ধ হয়ে থাকবে অথবা খুব সামান্য তদারকি ছাড়াই অতিরিক্ত অ্যাক্সেস পেয়ে যাবে।
পার্থক্য বুঝুন: জ্ঞান বনাম হাত (Knowledge vs. Hands)
প্রথম বিকল্পটি হলো AWS Knowledge MCP Server। এটিকে একজন সিনিয়র ইঞ্জিনিয়ার হিসেবে ভাবুন যার পুরো AWS ডকুমেন্টেশন লাইব্রেরি মুখস্থ কিন্তু আপনার অ্যাকাউন্টের কোনো লগইন ক্রেডেনশিয়াল নেই। এটি ডিজাইন অনুযায়ী শুধুমাত্র রিড-অনলি (read-only), যা এজেন্টকে আসল API সিনট্যাক্স, সঠিক সার্ভিস নাম এবং বর্তমান বেস্ট প্র্যাকটিস সম্পর্কে ধারণা দিতে অফিসিয়াল AWS docs ব্যবহার করে।
এটি ব্যবহার করার জন্য আপনার কোনো AWS অ্যাকাউন্ট প্রয়োজন নেই। আপনি এটিকে আপনার ইনফ্রাস্ট্রাকচারের সাথে কানেক্ট করবেন না। আপনি যখন একটি আর্কিটেকচার ডায়াগ্রাম আঁকছেন, ECS বা EventBridge-এর মতো নতুন কোনো সার্ভিস শিখছেন, অথবা কোনো নির্দিষ্ট API কল এখনও দুই বছর আগের মতো কাজ করছে কি না তা যাচাই করছেন, তখন এটি ব্যবহার করবেন। এটি এজেন্টকে আন্দাজে ভুল তথ্য দেওয়া থেকে বিরত রাখে। আপনি যদি তাকে একটি S3 bucket policy-র জন্য Terraform লিখতে বলেন, সে আসল ফিল্ড এবং ভ্যালিড ভ্যালুগুলো জানবে কারণ সে গত বছরের ট্রেনিং ডেটা থেকে নয়, বরং সরাসরি সোর্স থেকে তথ্য সংগ্রহ করছে।
দ্বিতীয় বিকল্পটি হলো AWS MCP Server (Managed)। এটি আপনার এজেন্টকে শুধু স্মৃতি নয়, বরং কাজ করার ক্ষমতা (hands) দেয়। সঠিক অথেন্টিকেশনের মাধ্যমে, এটি আপনার CloudWatch লগ পরিদর্শন করতে পারে, আপনার S3 bucket-গুলোর তালিকা করতে পারে, আপনার DynamoDB টেবিল স্কিমা পড়তে পারে, কোনো রোলে (role) যুক্ত IAM পলিসি চেক করতে পারে, অথবা কোন সিকিউরিটি গ্রুপগুলো ইন্টারনেটের জন্য উন্মুক্ত তা যাচাই করতে পারে। এটি আপনার আসল অ্যাকাউন্টে কাজ করে, যা প্রোডাকশন সমস্যা সমাধান বা লাইভ ইনফ্রাস্ট্রাকচার রিফ্যাক্টরিং করার জন্য অত্যন্ত শক্তিশালী।
Managed সার্ভার দীর্ঘস্থায়ী (long-lived) কী গ্রহণ করে না। এটি ব্রাউজার সাইন-ইন-এর মাধ্যমে OAuth অথবা SigV4 সাইনিং ব্যবহার করে AWS CLI-এর মাধ্যমে অথেন্টিকেট করে। প্রতিটি টুল কল (tool call) শর্ট-লিভড টোকেনের (short-lived tokens) মাধ্যমে ঘটে, প্রতিটি অ্যাকশন CloudTrail-এ একটি ট্রেইল রেখে যায় এবং এজেন্টটি আপনার নির্ধারিত IAM বাউন্ডারির মধ্যেই কাজ করে। এটি তার পারমিশনের বাইরে যেতে পারে না কারণ এটি সেই একই পলিসি ইঞ্জিন দ্বারা নিয়ন্ত্রিত যা আপনার অর্গানাইজেশনের অন্য প্রতিটি AWS ইউজার বা রোলকে নিয়ন্ত্রণ করে।
মনে রাখার মতো গোল্ডেন রুল হলো: একটি সার্ভার আপনার এজেন্টকে জ্ঞান দেয়, অন্যটি তাকে কাজ করার ক্ষমতা দেয়। যখন আপনি পড়াশোনা বা ডিজাইন করছেন তখন Knowledge সার্ভার ব্যবহার করুন। যখন আপনি অপারেশন বা মেরামত করছেন তখন Managed সার্ভার ব্যবহার করুন।
কেন AWS বেশিরভাগ কাজের জন্য Managed Server ব্যবহারের পরামর্শ দেয়
AWS এখন উভয় সার্ভার সমান্তরালভাবে চালানোর পরিবর্তে বেশিরভাগ ব্যবহারকারীকে একক Managed MCP Server-এর দিকে ঠেলে দিচ্ছে। Knowledge সার্ভার যে ডকুমেন্টেশন কনটেক্সট প্রদান করত, তা Managed সার্ভার গ্রহণ করেছে, তাই এটি একটি মাত্র এন্ডপয়েন্টের অধীনে রেফারেন্স ম্যাটেরিয়াল এবং লাইভ অ্যাকাউন্ট অ্যাকশন—উভয়ই পরিচালনা করতে পারে।
উভয় সার্ভার একসাথে চালালে আসলে অভিজ্ঞতা খারাপ হতে পারে। এজেন্ট ওভারল্যাপিং টুল ডেফিনিশন পায় এবং রিড-অনলি ডকুমেন্টেশন লুকআপ নাকি আপনার অ্যাকাউন্টের বিপরীতে একটি লাইভ API কল করতে হবে তা নিয়ে বিভ্রান্ত হতে পারে। এই দ্বিধা ধীরগতির রেসপন্স এবং মাঝে মাঝে ভুল টুল সিলেকশন এরর তৈরি করে। Managed সার্ভারে কনসোলিডেট করা আপনার কনফিগারেশন সহজ করে এবং এজেন্টকে ফোকাসড রাখে।
OAuth-এর মাধ্যমে Managed Server সেটআপ করা
Managed সার্ভার চালু করতে প্রায় পাঁচ মিনিট সময় লাগে, তবে ধাপগুলো গুরুত্বপূর্ণ কারণ এটি আপনার অ্যাকাউন্টের সাথে একটি লাইভ কানেকশন।
ধাপ ১: আপনার IAM identity প্রস্তুত করুন
একটি ডেডিকেটেড IAM role বা user তৈরি করুন অথবা নির্বাচন করুন। আপনার Root account ব্যবহার করবেন না। এতে AWSMCPSignInOAuthAccessPolicy নামক managed policy-টি যুক্ত করুন। এই policy-টি শুধুমাত্র MCP access-এর জন্য OAuth sign-in flow শুরু করার প্রয়োজনীয় permission প্রদান করে। এটি নিজে থেকে কোনো ব্যাপক administrative rights প্রদান করে না। আপনার agent-এর প্রকৃত ক্ষমতা নির্ভর করবে আপনি সেই identity-র সাথে আরও কোন IAM policies যুক্ত করছেন তার ওপর। আপনি যদি চান agent-টি CloudWatch logs পড়তে পারুক কিন্তু IAM বা billing-এ কোনো পরিবর্তন না করুক, তবে একটি custom policy তৈরি করুন যা শুধুমাত্র logs:DescribeLogGroups এবং logs:FilterLogEvents অনুমতি দেয় এবং অন্য কিছু নয়।
Step 2: আপনার client কনফিগার করুন
আপনার client configuration-এ অফিসিয়াল AWS MCP server URL যোগ করুন। এটি Claude Desktop, Claude Code, এবং Kiro-এর সাথে কাজ করে। আপনার MCP settings file-এ server endpoint-টি রেজিস্টার করুন যাতে client বুঝতে পারে AWS-সংক্রান্ত tool calls কোথায় পাঠাতে হবে।
Step 3: আপনার browser-এর মাধ্যমে authenticate করুন
প্রথমবার যখন agent একটি AWS tool কল করার চেষ্টা করবে, আপনার operating system একটি browser window খুলবে। Step 1-এ আপনি যে IAM identity প্রস্তুত করেছিলেন, সেটি দিয়ে sign in করুন। OAuth flow-টি MCP server-কে একটি short-lived token প্রদান করে। আপনি কোনো secret key দেখতে পাবেন না। আপনাকে কোনো configuration file-এ কিছু paste করতে হবে না। Token-টি স্বয়ংক্রিয়ভাবে রিফ্রেশ হয় এবং দ্রুতের মধ্যেই expire হয়ে যায়।
Step 4: trust boundary যাচাই করুন
authenticate করার পর, CloudTrail খুলুন এবং নিশ্চিত করুন যে আপনার তৈরি করা identity-র অধীনে কাজগুলো (actions) দেখা যাচ্ছে। আপনি সেই নির্দিষ্ট IAM user বা role-এর সাথে যুক্ত ListBuckets বা DescribeInstances-এর মতো event দেখতে পাবেন। যদি আপনি Root account-এর অ্যাক্টিভিটি দেখতে পান, তবে বুঝতে হবে আপনি কিছু ভুল করেছেন এবং অবিলম্বে session-টি revoke করা উচিত।
যদি OAuth আপনার workflow-এর সাথে সামঞ্জস্যপূর্ণ না হয়, তবে Managed server আপনার বিদ্যমান AWS CLI credentials-এর মাধ্যমে SigV4 authentication-ও সমর্থন করে। এই পদ্ধতিতে browser pop-up এড়িয়ে যাওয়া যায়, তবে agent-এর কাছে raw credentials প্রকাশ না করে MCP server-এর মাধ্যমে signing এবং session management করার সুবিধা আপনি তখনও পাবেন।
যে নিরাপত্তা অভ্যাসগুলো আসলে গুরুত্বপূর্ণ
একটি MCP server ততটাই নিরাপদ যতটা নিরাপদ এর পেছনের IAM identity।
'Least privilege' নীতি দিয়ে শুরু করুন। একটি ভুলভাবে routed API Gateway integration ঠিক করার জন্য আপনার agent-এর AdministratorAccess-এর প্রয়োজন নেই। বর্তমান কাজের জন্য ঠিক যতটুকু read বা write permission প্রয়োজন তা-ই প্রদান করুন, এবং কাজ শেষ হয়ে গেলে সেগুলো rotate বা revoke করে দিন। আপনি যদি একটি role ব্যবহার করেন, তবে session duration স্বল্প রাখুন। আপনি যদি একটি user ব্যবহার করেন, তবে আপনার tooling যেখানে অনুমতি দেয় সেখানে MFA সক্রিয় করুন।
কখনোই Root user হিসেবে authorize করবেন না। Root service control policies বাইপাস করে এবং পুরো account-এ অবাধ অ্যাক্সেস পায়। যদি agent কোনো prompt ভুলভাবে ব্যাখ্যা করে এবং resource ডিলিট করার চেষ্টা করে, তবে আপনি চাইবেন যেন একটি boundary policy সেই request-টি ব্লক করে দেয়। Root-এর ক্ষেত্রে এমন কোনো guardrails নেই।
পরিশেষে, agent-টিকে একজন নতুন ইন্টার্ন হিসেবে বিবেচনা করুন যে নির্দেশগুলো নিখুঁতভাবে অনুসরণ করে কিন্তু সাধারণ জ্ঞান (common sense) নেই। আপনি যা বলবেন এটি তা-ই আক্ষরিকভাবে এবং তাৎক্ষণিকভাবে কার্যকর করবে। আপনি যদি একে "unused security groups পরিষ্কার করতে" বলেন, তবে এটি আপনার production database-এর সাথে যুক্ত security group-টিও বন্ধ করে দিতে পারে কারণ এটি আপনার দেওয়া বিস্তৃত শর্তের সাথে মিলে গেছে। যেকোনো destructive command কনফার্ম করার আগে তা পর্যালোচনা করুন, বিশেষ করে যখন agent-এর write access থাকে।
মূল সারসংক্ষেপ
উপযোগিতার জন্য আপনাকে নিরাপত্তাকে বিসর্জন দিতে হবে না। Managed AWS MCP Server আপনার AI assistant-কে আপনার আসল infrastructure দেখতে দেয়, তার নিজের hallucination সংশোধন করতে সাহায্য করে এবং আপনার টিমের বাকি সদস্যদের মতো একই IAM framework-এর মধ্যে কাজ করতে দেয়। environment file-এ secret না রেখেও আপনি live context পাবেন। OAuth flow সেট আপ করুন, permission-গুলো কঠোরভাবে নিয়ন্ত্রণ করুন এবং agent-টিকে আপনার policy-র সীমাবদ্ধতার মধ্যে থেকে কাজ করতে দিন।