अपनी .env फाइलों में AWS access keys पेस्ट करना बंद करें।
हम सभी इस स्थिति से गुजर चुके हैं। देर हो रही है, आप एक Lambda permission error को debug कर रहे हैं, और आपका AI assistant काल्पनिक account IDs के साथ service names या ARNs बनाना जारी रखता है। आप चाहते हैं कि मॉडल आपके वास्तविक resources को देखे ताकि वह hallucinate करना बंद करे और सुधारना शुरू करे। हताशा में, आप एक access key लेते हैं, उसे एक environment file में डालते हैं, और उसे agent को दे देते हैं। यह काम कर जाता है। राहत महसूस होती है। फिर सुबह होती है, और आपको एहसास होता है कि वह secret आपकी shell history, terminal scrollback, या इससे भी बदतर, एक commit में है जो अभी-अभी एक shared repository में push किया गया है।
Model Context Protocol इसी तरह की अव्यवस्था को रोकने के लिए बनाया गया है।
MCP आपके AI agent और बाहरी प्रणालियों (external systems) के बीच एक मानक ब्रिज (standard bridge) बनाता है। कच्चे credentials सौंपने और इस उम्मीद में रहने के बजाय कि agent उन्हें लीक नहीं करेगा, आप एक नियंत्रित सर्वर के माध्यम से जुड़ते हैं जो authentication को संभालता है, permissions को scope करता है, और आपकी keys को पूरी तरह से chat window से बाहर रखता है।
AWS के लिए, आपके पास चुनने के लिए वर्तमान में दो आधिकारिक MCP servers हैं। गलत चुनाव करने से या तो आपका agent अंधा रह जाएगा या उसे बहुत कम निगरानी के साथ बहुत अधिक एक्सेस मिल जाएगा।
अंतर जानें: Knowledge बनाम Hands
पहला विकल्प AWS Knowledge MCP Server है। इसे एक ऐसे सीनियर इंजीनियर के रूप में सोचें जिसने पूरी AWS documentation library को याद कर लिया है लेकिन आपके account के लिए उसके पास कोई login credentials नहीं हैं। यह डिज़ाइन के अनुसार read-only है, जो agent को वास्तविक API syntax, सही service names, और वर्तमान best practices से अवगत कराने के लिए आधिकारिक AWS docs का संदर्भ देता है।
इसे उपयोग करने के लिए आपको AWS account की आवश्यकता नहीं है। आप इसे अपने infrastructure से नहीं जोड़ते हैं। आप इसे तब चलाते हैं जब आप एक architecture diagram तैयार कर रहे होते हैं, ECS या EventBridge जैसी नई service सीख रहे होते हैं, या यह सत्यापित कर रहे होते हैं कि क्या कोई विशेष API call अभी भी उसी तरह व्यवहार करता है जैसा आपको दो साल पहले याद था। यह agent को अनुमान लगाने से रोकता है। यदि आप इसे S3 bucket policy के लिए Terraform लिखने के लिए कहते हैं, तो यह वास्तविक fields और मान्य values जानता है क्योंकि यह पिछले साल समाप्त हुए training data से नहीं, बल्कि सीधे source से जानकारी ले रहा है।
दूसरा विकल्प AWS MCP Server (Managed) है। यह आपके agent को केवल याददाश्त नहीं, बल्कि 'हाथ' (hands) भी देता है। उचित authentication के साथ, यह आपके CloudWatch logs का निरीक्षण कर सकता है, आपके S3 buckets की सूची बना सकता है, आपके DynamoDB table schemas को पढ़ सकता है, किसी role से जुड़े IAM policies की जांच कर सकता है, या यह सत्यापित कर सकता है कि कौन से security groups इंटरनेट के लिए खुले हैं। यह आपके वास्तविक account पर काम करता है, जो इसे production issues को troubleshoot करने या live infrastructure को refactor करने के लिए शक्तिशाली बनाता है।
Managed server long-lived keys को अस्वीकार कर देता है। यह browser sign-in के माध्यम से OAuth, या SigV4 signing का उपयोग करके AWS CLI के माध्यम से authenticate करता है। प्रत्येक tool call short-lived tokens के साथ होता है, प्रत्येक action CloudTrail में एक निशान छोड़ता है, और agent पूरी तरह से उन IAM boundaries के भीतर काम करता है जिन्हें आप परिभाषित करते हैं। यह अपनी permissions से बाहर नहीं जा सकता क्योंकि यह उसी policy engine से बंधा हुआ है जो आपके संगठन में प्रत्येक अन्य AWS user या role को नियंत्रित करता है।
याद रखने के लिए सुनहरा नियम यह है: एक server आपके agent को knowledge देता है, दूसरा उसे hands देता है। जब आप अध्ययन या डिज़ाइन कर रहे हों तो Knowledge server का उपयोग करें। जब आप संचालन (operating) या मरम्मत (repairing) कर रहे हों तो Managed server का उपयोग करें।
AWS अधिकांश कार्यों के लिए Managed Server की सिफारिश क्यों करता है
AWS अब दोनों को समानांतर (parallel) में चलाने के बजाय अधिकांश उपयोगकर्ताओं को एकल Managed MCP Server की ओर धकेल रहा है। Managed server ने उस documentation context को समाहित कर लिया है जो Knowledge server प्रदान करता था, इसलिए यह एक ही endpoint के तहत reference material और live account actions दोनों को संभालता है।
दोनों servers को एक साथ चलाने से वास्तव में अनुभव खराब हो सकता है। Agent को ओवरलैपिंग tool definitions प्राप्त होते हैं और वह इस बारे में भ्रमित हो सकता है कि उसे read-only documentation lookup करना चाहिए या आपके account के विरुद्ध एक live API कॉल करना चाहिए। उस हिचकिचाहट से प्रतिक्रियाएँ धीमी हो जाती हैं और कभी-कभी tool-selection में त्रुटियाँ होती हैं। Managed server पर केंद्रित होने से आपका configuration सरल हो जाता है और agent केंद्रित रहता है।
OAuth के साथ Managed Server सेटअप करना
Managed server को चलाने में लगभग पाँच मिनट लगते हैं, लेकिन चरण महत्वपूर्ण हैं क्योंकि यह आपके account के साथ एक लाइव कनेक्शन है।
Step 1: अपनी IAM identity तैयार करें
एक समर्पित IAM role या user बनाएँ या चुनें। अपने Root account का उपयोग न करें। इसके साथ AWSMCPSignInOAuthAccessPolicy नाम की managed policy जोड़ें। यह policy केवल MCP access के लिए OAuth sign-in flow शुरू करने के लिए आवश्यक permissions प्रदान करती है। यह अपने आप में व्यापक administrative अधिकार प्रदान नहीं करती है। आपके agent की वास्तविक क्षमताएं उन अन्य IAM policies द्वारा निर्धारित की जाएंगी जो आप उस identity के साथ जोड़ते हैं। यदि आप चाहते हैं कि 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 को invoke करने का प्रयास करता है, तो आपका operating system एक browser window खोलता है। उसी IAM identity के साथ sign in करें जिसे आपने Step 1 में तैयार किया था। OAuth flow MCP server को एक short-lived token वापस करता है। आपको कोई secret key नहीं दिखेगी। आपको configuration file में कुछ भी paste नहीं करना होगा। Token अपने आप refresh हो जाता है और जल्दी ही expire हो जाता है।
Step 4: trust boundary को सत्यापित करें
Authenticate होने के बाद, CloudTrail खोलें और पुष्टि करें कि actions आपके द्वारा बनाई गई identity के अंतर्गत दिखाई दे रहे हैं। आपको उस विशिष्ट IAM user या role से जुड़े ListBuckets या DescribeInstances जैसे events दिखने चाहिए। यदि आप Root account activity देखते हैं, तो आपने कुछ गलत किया है और आपको तुरंत session को revoke कर देना चाहिए।
यदि OAuth आपके workflow के अनुकूल नहीं है, तो Managed server आपके मौजूदा AWS CLI credentials के माध्यम से SigV4 authentication का भी समर्थन करता है। यह तरीका browser pop-up को छोड़ देता है, लेकिन फिर भी आपको MCP server द्वारा signing और session management को संभालने का लाभ मिलता है, बजाय इसके कि agent को raw credentials दिखाए जाएं।
सुरक्षा की आदतें जो वास्तव में मायने रखती हैं
एक MCP server उतना ही सुरक्षित है जितनी उसके पीछे की IAM identity।
Least privilege (न्यूनतम विशेषाधिकार) से शुरुआत करें। एक misrouted API Gateway integration को ठीक करने के लिए आपके agent को AdministratorAccess की आवश्यकता नहीं है। इसे केवल वही read या write permissions दें जो वर्तमान कार्य के लिए आवश्यक हों, और काम पूरा होने पर उन्हें rotate या revoke कर दें। यदि आप role का उपयोग कर रहे हैं, तो session duration कम रखें। यदि आप user का उपयोग कर रहे हैं, तो जहाँ भी आपका tooling अनुमति दे, वहाँ MFA सक्षम करें।
कभी भी Root user के रूप में authorize न करें। Root, service control policies को बायपास कर देता है और पूरे account में बिना किसी प्रतिबंध के access प्राप्त करता है। यदि agent किसी prompt का गलत अर्थ निकालता है और resources को delete करने का प्रयास करता है, तो आप चाहेंगे कि उस request को एक boundary policy द्वारा ब्लॉक कर दिया जाए। Root के पास ऐसे कोई guardrails नहीं होते हैं।
अंत में, agent के साथ एक नए intern की तरह व्यवहार करें जो निर्देशों का पूरी तरह से पालन करता है लेकिन उसमें common sense की कमी है। यह वही करेगा जो आप कहेंगे, शाब्दिक रूप से और तुरंत। यदि आप इसे "unused security groups को clean up करें" कहते हैं, तो यह आपके production database से जुड़े security group को terminate कर सकता है क्योंकि वह आपके द्वारा दिए गए व्यापक criteria से मेल खाता है। किसी भी destructive command की पुष्टि करने से पहले उसकी समीक्षा करें, विशेष रूप से तब जब agent के पास write access हो।
वास्तविक निष्कर्ष
आपको उपयोगिता के लिए सुरक्षा से समझौता करने की आवश्यकता नहीं है। Managed AWS MCP Server आपके AI assistant को आपके वास्तविक infrastructure को देखने, अपने स्वयं के hallucinations को ठीक करने, और उसी IAM framework के भीतर काम करने की अनुमति देता है जो आपकी टीम के बाकी सदस्यों को नियंत्रित करता है। आपको environment files में secrets डाले बिना live context मिलता है। OAuth flow सेटअप करें, permissions को सुरक्षित करें, और agent को अपनी आँखें खुली रखकर और आपकी policies से बंधे रहकर काम करने दें।