तुमच्या .env फाईल्समध्ये AWS access keys पेस्ट करणे थांबवा.
आपण सर्वजण या परिस्थितीतून गेलो आहोत. रात्रीची वेळ आहे, तुम्ही Lambda permission error debug करत आहात, आणि तुमचा AI assistant सतत काल्पनिक account IDs सह काल्पनिक service names किंवा ARNs तयार करत आहे. तुम्हाला मॉडेलला तुमचे प्रत्यक्ष रिसोर्सेस (resources) दाखवायचे आहेत जेणेकरून ते चुकीची माहिती (hallucinating) देणे थांबवेल आणि प्रत्यक्ष काम सुरू करेल. हताश होऊन, तुम्ही एक access key घेता, ती environment फाईलमध्ये टाकता आणि एजंटला देता. ते काम करते. तुम्हाला दिलासा मिळतो. मग सकाळ होते आणि तुम्हाला लक्षात येते की तो सीक्रेट (secret) तुमच्या shell history, terminal scrollback मध्ये किंवा त्याहून वाईट, नुकत्याच शेअर केलेल्या रिपॉझिटरीमध्ये (repository) पुश केलेल्या commit मध्ये आहे.
Model Context Protocol नेमकी हीच गोंधळाची स्थिती टाळण्यासाठी बनवण्यात आला आहे.
MCP तुमच्या AI agent आणि बाह्य सिस्टिम्समध्ये एक मानक पूल (standard bridge) तयार करतो. कच्च्या क्रेडेंशियल्स (raw credentials) एजंटला देऊन ते लीक होणार नाहीत अशी आशा करण्याऐवजी, तुम्ही एका नियंत्रित सर्व्हरद्वारे कनेक्ट होता जो authentication हाताळतो, permissions मर्यादित करतो आणि तुमच्या keys पूर्णपणे चॅट विंडोच्या बाहेर ठेवतो.
AWS साठी, तुमच्याकडे सध्या निवडण्यासाठी दोन अधिकृत MCP servers आहेत. चुकीचा पर्याय निवडल्यास तुमचा agent अंध असू शकतो किंवा त्याला खूप कमी देखरेखीसह खूप जास्त ॲक्सेस मिळू शकतो.
फरक जाणून घ्या: Knowledge विरुद्ध Hands
पहिला पर्याय म्हणजे AWS Knowledge MCP Server. याला असा एक सिनियर इंजिनिअर समजा ज्याने संपूर्ण AWS documentation लायब्ररी पाठ केली आहे, परंतु तुमच्या अकाउंटसाठी त्याच्याकडे कोणतेही लॉगिन क्रेडेंशियल्स नाहीत. हे डिझाइननुसार 'read-only' आहे, जे एजंटला वास्तविक API syntax, योग्य service names आणि सध्याच्या सर्वोत्तम पद्धती (best practices) समजण्यासाठी अधिकृत AWS docs चा संदर्भ देते.
ते वापरण्यासाठी तुम्हाला AWS अकाउंटची गरज नाही. तुम्ही ते तुमच्या इन्फ्रास्ट्रक्चरला (infrastructure) कनेक्ट करत नाही. जेव्हा तुम्ही आर्किटेक्चर डायग्राम काढत असता, ECS किंवा EventBridge सारखी नवीन service शिकत असता, किंवा एखादे विशिष्ट API call दोन वर्षांपूर्वी तुम्ही ज्याप्रमाणे वापरले होते तसाच वागतो की नाही हे तपासत असता, तेव्हा तुम्ही ते वापरू शकता. हे एजंटला अंदाज लावण्यापासून थांबवते. जर तुम्ही त्याला S3 bucket policy साठी Terraform लिहिण्यास सांगितले, तर त्याला वास्तविक fields आणि वैध values माहित असतात कारण ते गेल्या वर्षी संपलेल्या ट्रेनिंग डेटावरून नाही, तर थेट मूळ स्त्रोतावरून (source) माहिती घेत आहे.
दुसरा पर्याय म्हणजे AWS MCP Server (Managed). हे तुमच्या एजंटला केवळ स्मृती (memory) नाही, तर 'हात' (hands) देते. योग्य authentication सह, ते तुमचे CloudWatch logs तपासू शकते, तुमचे S3 buckets सूचीबद्ध करू शकते, तुमचे DynamoDB table schemas वाचू शकते, एखाद्या रोलला (role) जोडलेल्या IAM policies तपासू शकते किंवा कोणते security groups इंटरनेटसाठी खुले आहेत याची पडताळणी करू शकते. हे तुमच्या वास्तविक अकाउंटवर काम करते, ज्यामुळे प्रोडक्शनच्या समस्या सोडवण्यासाठी किंवा लाइव्ह इन्फ्रास्ट्रक्चर रिफॅक्टरिंग करण्यासाठी ते शक्तिशाली ठरते.
Managed server दीर्घकाळ टिकणाऱ्या (long-lived) keys नाकारते. ते ब्राउझर साइन-इनद्वारे OAuth द्वारे, किंवा SigV4 signing वापरून AWS CLI द्वारे authenticate होते. प्रत्येक tool call अल्पायुषी (short-lived) tokens सह होतो, प्रत्येक कृती CloudTrail मध्ये एक ट्रेल सोडते आणि एजंट तुम्ही परिभाषित केलेल्या IAM मर्यादांच्या (boundaries) आतच काम करतो. तो त्याच्या permissions च्या बाहेर जाऊ शकत नाही कारण तो तुमच्या संस्थेतील इतर प्रत्येक AWS यूजर किंवा रोलला नियंत्रित करणाऱ्या त्याच पॉलिसी इंजिनद्वारे बांधलेला असतो.
लक्षात ठेवण्यासाठी हा सुवर्ण नियम आहे: एक सर्व्हर तुमच्या एजंटला ज्ञान (knowledge) देतो, तर दुसरा त्याला कृती करण्यासाठी हात (hands) देतो. जेव्हा तुम्ही अभ्यास किंवा डिझाइन करत असता तेव्हा Knowledge server वापरा. जेव्हा तुम्ही ऑपरेशन किंवा दुरुस्ती करत असता तेव्हा Managed server वापरा.
बहुतेक कामांसाठी AWS Managed Server ची शिफारस का करते
AWS आता दोन्ही समांतर चालवण्याऐवजी बहुतेक वापरकर्त्यांना सिंगल Managed MCP Server कडे वळवत आहे. Managed server ने Knowledge server ने दिलेला documentation context स्वतःमध्ये सामावून घेतला आहे, त्यामुळे ते एकाच endpoint अंतर्गत संदर्भ साहित्य (reference material) आणि लाइव्ह अकाउंट ॲक्शन्स दोन्ही हाताळते.
दोन्ही सर्व्हर एकाच वेळी चालवल्याने अनुभव खराब होऊ शकतो. एजंटला ओव्हरलॅपिंग tool definitions मिळतात आणि त्याला 'read-only documentation lookup' करायचे की तुमच्या अकाउंटविरुद्ध 'live API' कॉल करायचे याबद्दल गोंधळ होऊ शकतो. या संभमामुळे प्रतिसाद मिळण्यास उशीर होतो आणि अधूनमधून tool-selection मध्ये चुका होतात. Managed server वर लक्ष केंद्रित केल्याने तुमचे कॉन्फिगरेशन सोपे होते आणि एजंट अधिक केंद्रित राहतो.
OAuth सह Managed Server सेट करणे
Managed server सुरू करण्यासाठी साधारण पाच मिनिटे लागतात, परंतु हे टप्पे महत्त्वाचे आहेत कारण हे तुमच्या अकाउंटशी थेट कनेक्शन आहे.
Step 1: तुमची IAM identity तयार करा
एक समर्पित IAM role किंवा user तयार करा किंवा निवडा. तुमच्या Root account चा वापर करू नका. त्याला AWSMCPSignInOAuthAccessPolicy नावाचे managed policy जोडा. हे policy केवळ MCP access साठी OAuth sign-in flow सुरू करण्यासाठी आवश्यक असलेल्या permissions प्रदान करते. हे स्वतःहून व्यापक administrative अधिकार देत नाही. तुमच्या 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 आपोआप refresh होते आणि लवकर expire होते.
Step 4: trust boundary तपासा
एकदा authenticate झाल्यावर, CloudTrail उघडा आणि तुम्ही तयार केलेल्या identity अंतर्गत actions दिसत आहेत की नाही याची खात्री करा. तुम्हाला त्या विशिष्ट IAM user किंवा role शी संबंधित ListBuckets किंवा DescribeInstances सारखे events दिसले पाहिजेत. जर तुम्हाला Root account activity दिसली, तर तुमच्याकडून काहीतरी चूक झाली आहे आणि तुम्ही त्वरित session revoke केला पाहिजे.
जर OAuth तुमच्या workflow ला साजेसा नसेल, तर Managed server तुमच्या सध्याच्या AWS CLI credentials द्वारे SigV4 authentication ला देखील सपोर्ट करते. या मार्गामुळे browser pop-up येत नाही, परंतु agent ला raw credentials देण्याऐवजी MCP server द्वारे signing आणि session management हाताळले जाण्याचे फायदे तुम्हाला मिळतातच.
खरोखर महत्त्वाच्या असलेल्या सुरक्षा सवयी (Security Habits)
MCP server हे त्याच्या मागे असलेल्या IAM identity इतकेच सुरक्षित असते.
'Least privilege' (किमान विशेषाधिकार) पासून सुरुवात करा. चुकीच्या पद्धतीने routed API Gateway integration दुरुस्त करण्यासाठी तुमच्या agent ला AdministratorAccess ची गरज नसते. सध्याच्या कामासाठी आवश्यक असलेले नेमके read किंवा write permissions द्या, आणि काम पूर्ण झाल्यावर ते rotate किंवा revoke करा. जर तुम्ही role वापरत असाल, तर session duration कमी ठेवा. जर तुम्ही user वापरत असाल, तर तुमचे tooling जिथे शक्य असेल तिथे MFA सक्षम करा.
Root user म्हणून कधीही authorize करू नका. Root हे service control policies बायपास करते आणि संपूर्ण account मध्ये विनाअट प्रवेश (unrestricted access) मिळवते. जर agent ने prompt चा चुकीचा अर्थ लावला आणि resources delete करण्याचा प्रयत्न केला, तर तुम्हाला ती request एका boundary policy द्वारे ब्लॉक करायची असेल. Root कडे असे कोणतेही guardrails नसतात.
शेवटी, agent ला एका नवीन intern सारखे वागवा जो सूचनांचे तंतोतंत पालन करतो पण ज्याकडे सामान्य ज्ञान (common sense) नसते. तुम्ही जे सांगाल ते तो शब्दशः आणि त्वरित कार्यान्वित करेल. जर तुम्ही त्याला "unused security groups clean up करा" असे सांगितले, तर तो तुमच्या production database ला जोडलेला security group देखील terminate करू शकतो कारण तो तुम्ही दिलेल्या व्यापक निकषांशी जुळत असेल. कोणतेही destructive commands confirm करण्यापूर्वी त्यांची पुनरावलोकन (review) करा, विशेषतः जेव्हा agent कडे write access असतो.
मुख्य निष्कर्ष (The Real Takeaway)
तुम्हाला उपयुक्ततेसाठी सुरक्षेचा त्याग करण्याची गरज नाही. Managed AWS MCP Server तुमच्या AI assistant ला तुमचे वास्तविक infrastructure पाहू देते, स्वतःच्या hallucinations मध्ये सुधारणा करण्यास मदत करते आणि तुमच्या टीमच्या इतर सदस्यांना नियंत्रित करणाऱ्या त्याच IAM framework मध्ये काम करण्यास अनुमती देते. environment files मध्ये secrets टाकल्याशिवाय तुम्हाला live context मिळतो. OAuth flow सेट करा, permissions लॉक करा आणि agent ला त्याच्या डोळ्यांत डोळे घालून आणि तुमच्या policies च्या मर्यादेत राहून काम करू द्या.