તમારી ફાઇલોમાં AWS એક્સેસ કી પેસ્ટ કરવાનું બંધ કરો.

તમારી .env ફાઇલોમાં AWS access keys પેસ્ટ કરવાનું બંધ કરો.

આપણે બધા આ પરિસ્થિતિમાંથી પસાર થયા છીએ. મોડું થઈ ગયું છે, તમે Lambda permission error ને debug કરી રહ્યા છો, અને તમારો AI assistant કાલ્પનિક account IDs સાથે સર્વિસના નામ અથવા ARNs બનાવવાનું ચાલુ રાખે છે. તમે ઈચ્છો છો કે મોડેલ તમારા વાસ્તવિક રિસોર્સિસ જોઈ શકે જેથી તે ભ્રમિત (hallucinating) થવાનું બંધ કરે અને સુધારવાનું શરૂ કરે. હતાશામાં, તમે એક access key લો છો, તેને environment file માં નાખો છો, અને એજન્ટને આપી દો છો. તે કામ કરે છે. રાહતનો અનુભવ થાય છે. પછી સવાર પડે છે, અને તમને સમજાય છે કે તે secret તમારી shell history, terminal scrollback, અથવા તો વધુ ખરાબ રીતે, એક commit માં છે જે હમણાં જ shared repository માં push કરવામાં આવ્યું છે.

Model Context Protocol આ પ્રકારની અરાજકતા રોકવા માટે જ બનાવવામાં આવ્યો છે.

MCP તમારા AI agent અને બાહ્ય સિસ્ટમ્સ વચ્ચે એક પ્રમાણિત બ્રિજ બનાવે છે. કાચા (raw) credentials આપીને એજન્ટ તેને લીક ન કરે તેવી આશા રાખવાને બદલે, તમે એક નિયંત્રિત (controlled) સર્વર દ્વારા કનેક્ટ કરો છો જે authentication હેન્ડલ કરે છે, permissions સ્કોપ કરે છે, અને તમારી keys ને ચેટ વિન્ડોથી સંપૂર્ણપણે દૂર રાખે છે.

AWS માટે, તમારી પાસે હાલમાં પસંદ કરવા માટે બે સત્તાવાર MCP servers છે. ખોટું પસંદ કરવાથી કાં તો તમારો agent અંધ (blind) રહી જશે અથવા તેને ખૂબ ઓછી દેખરેખ સાથે ખૂબ વધુ એક્સેસ મળી જશે.

તફાવત જાણો: Knowledge vs. Hands

પહેલો વિકલ્પ AWS Knowledge MCP Server છે. તેને એક સિનિયર એન્જિનિયર તરીકે વિચારો જેણે સમગ્ર AWS documentation library મોઢે કરી છે પરંતુ તમારી એકાઉન્ટ માટે કોઈ login credentials નથી. તે ડિઝાઈન મુજબ read-only છે, જે એજન્ટને વાસ્તવિક API syntax, સાચા સર્વિસના નામ અને વર્તમાન શ્રેષ્ઠ પદ્ધતિઓ (best practices) સાથે જોડવા માટે સત્તાવાર AWS docs નો સંદર્ભ આપે છે.

તેનો ઉપયોગ કરવા માટે તમારે AWS account ની જરૂર નથી. તમે તેને તમારા ઇન્ફ્રાસ્ટ્રક્ચર સાથે કનેક્ટ કરતા નથી. જ્યારે તમે આર્કિટેક્ચર ડાયાગ્રામ તૈયાર કરી રહ્યા હોવ, ECS અથવા EventBridge જેવી નવી સર્વિસ શીખી રહ્યા હોવ, અથવા કોઈ ચોક્કસ API call હજુ પણ બે વર્ષ પહેલાં યાદ હોય તેવી રીતે કામ કરે છે કે નહીં તે ચકાસી રહ્યા હોવ ત્યારે તમે તેને ચાલુ કરો છો. તે એજન્ટને અનુમાન લગાવતા અટકાવે છે. જો તમે તેને S3 bucket policy માટે Terraform લખવા માટે કહો છો, તો તે વાસ્તવિક fields અને માન્ય values જાણે છે કારણ કે તે સોર્સમાંથી ડેટા લે છે, ગયા વર્ષે પૂરા થયેલા training data માંથી નહીં.

બીજો વિકલ્પ AWS MCP Server (Managed) છે. આ એક એજન્ટને માત્ર મેમરી જ નહીં, પણ 'હાથ' (hands) પણ આપે છે. યોગ્ય authentication સાથે, તે તમારા CloudWatch logs ને તપાસી શકે છે, તમારા S3 buckets ની યાદી બનાવી શકે છે, તમારા DynamoDB table schemas વાંચી શકે છે, રોલ સાથે જોડાયેલ IAM policies તપાસી શકે છે, અથવા કયા security groups ઇન્ટરનેટ માટે ખુલ્લા છે તે ચકાસી શકે છે. તે તમારા વાસ્તવિક એકાઉન્ટ પર કામ કરે છે, જે તેને production સમસ્યાઓનું troubleshooting કરવા અથવા live ઇન્ફ્રાસ્ટ્રક્ચરને refactor કરવા માટે શક્તિશાળી બનાવે છે.

Managed server લાંબા સમય સુધી ચાલતી (long-lived) keys ને નકારશે. તે બ્રાઉઝર sign-in દ્વારા OAuth અથવા SigV4 signing નો ઉપયોગ કરીને AWS CLI દ્વારા authenticate થાય છે. દરેક tool call ટૂંકા ગાળાના (short-lived) tokens સાથે થાય છે, દરેક એક્શન CloudTrail માં એક ટ્રેલ છોડે છે, અને એજન્ટ તમે વ્યાખ્યાયિત કરેલી IAM boundaries ની અંદર જ કામ કરે છે. તે તેની permissions ની બહાર જઈ શકતું નથી કારણ કે તે તે જ policy engine દ્વારા બંધાયેલું છે જે તમારી સંસ્થામાં અન્ય દરેક AWS user અથવા role ને નિયંત્રિત કરે છે.

યાદ રાખવા માટેનો સુવર્ણ નિયમ અહીં છે: એક સર્વર તમારા એજન્ટને knowledge આપે છે, બીજું તેને hands આપે છે. જ્યારે તમે અભ્યાસ કરી રહ્યા હોવ અથવા ડિઝાઇન કરી રહ્યા હોવ ત્યારે Knowledge server નો ઉપયોગ કરો. જ્યારે તમે ઓપરેટ કરી રહ્યા હોવ અથવા રિપેર કરી રહ્યા હોવ ત્યારે Managed server નો ઉપયોગ કરો.

શા માટે AWS મોટાભાગના કાર્યો માટે Managed Server ની ભલામણ કરે છે

AWS હવે બંનેને સમાંતર ચલાવવાને બદલે મોટાભાગના વપરાશકર્તાઓને સિંગલ Managed MCP Server તરફ પ્રેરે છે. Managed server એ documentation context ને શોષી લીધું છે જે Knowledge server પૂરો પાડતું હતું, તેથી તે એક જ endpoint હેઠળ સંદર્ભ સામગ્રી (reference material) અને live account actions બંનેને હેન્ડલ કરે છે.

બંને સર્વર એકસાથે ચલાવવાથી અનુભવ ખરાબ થઈ શકે છે. એજન્ટને ઓવરલેપિંગ tool definitions મળે છે અને તે મૂંઝવણમાં મુકાઈ શકે છે કે read-only documentation lookup માટે કોલ કરવું કે તમારા એકાઉન્ટ સામે live API માટે. આ ખચકાટને કારણે પ્રતિસાદ ધીમો પડે છે અને ક્યારેક tool-selection માં ભૂલો થાય છે. Managed server પર એકીકૃત કરવાથી તમારું કોન્ફિગરેશન સરળ બને છે અને એજન્ટ કેન્દ્રિત રહે છે.

OAuth સાથે Managed Server સેટઅપ કરવું

Managed server ચલાવવામાં લગભગ પાંચ મિનિટ લાગે છે, પરંતુ સ્ટેપ્સ મહત્વના છે કારણ કે આ તમારા એકાઉન્ટ સાથેનું live connection છે.

Step 1: તમારી IAM identity તૈયાર કરો

એક સમર્પિત IAM રોલ અથવા યુઝર બનાવો અથવા પસંદ કરો. તમારા Root એકાઉન્ટનો ઉપયોગ કરશો નહીં. તેને AWSMCPSignInOAuthAccessPolicy નામની મેનેજ્ડ પોલિસી સાથે જોડો. આ પોલિસી ફક્ત MCP એક્સેસ માટે OAuth સાઇન-ઇન ફ્લો શરૂ કરવા માટે જરૂરી પરવાનગીઓ જ આપે છે. તે પોતે જ વ્યાપક વહીવટી (administrative) અધિકારો આપતી નથી. તમારા એજન્ટ પાસે કઈ વાસ્તવિક ક્ષમતાઓ હશે તે તમે તે ઓળખ (identity) સાથે જોડો છો તે બાકીની IAM પોલિસીઓ દ્વારા નક્કી કરવામાં આવે છે. જો તમે ઈચ્છતા હોવ કે એજન્ટ CloudWatch લોગ્સ વાંચે પરંતુ IAM અથવા બિલિંગને ક્યારેય સ્પર્શ ન કરે, તો એક કસ્ટમ પોલિસી બનાવો જે ફક્ત logs:DescribeLogGroups અને logs:FilterLogEvents ની મંજૂરી આપે અને બીજું કંઈ નહીં.

સ્ટેપ 2: તમારા ક્લાયન્ટને કન્ફિગર કરો

તમારા ક્લાયન્ટ કન્ફિગરેશનમાં સત્તાવાર AWS MCP સર્વર URL ઉમેરો. આ Claude Desktop, Claude Code, અને Kiro સાથે કામ કરે છે. તમારી MCP સેટિંગ્સ ફાઇલમાં, સર્વર એન્ડપોઇન્ટ રજિસ્ટર કરો જેથી ક્લાયન્ટને ખબર પડે કે AWS સંબંધિત ટૂલ કોલ્સ ક્યાં રૂટ કરવા.

સ્ટેપ 3: તમારા બ્રાઉઝર દ્વારા પ્રમાણિત (Authenticate) કરો

જ્યારે એજન્ટ પહેલીવાર AWS ટૂલને ઇનવોક કરવાનો પ્રયાસ કરે છે, ત્યારે તમારું ઓપરેટિંગ સિસ્ટમ બ્રાઉઝર વિન્ડો ખોલે છે. સ્ટેપ 1 માં તમે જે IAM ઓળખ તૈયાર કરી હતી તેનાથી સાઇન-ઇન કરો. OAuth ફ્લો MCP સર્વરને ટૂંકા ગાળાનું ટોકન પરત કરે છે. તમને કોઈ સિક્રેટ કી દેખાશે નહીં. તમારે કન્ફિગરેશન ફાઇલમાં કંઈપણ પેસ્ટ કરવાની જરૂર નથી. ટોકન આપમેળે રિફ્રેશ થાય છે અને ઝડપથી એક્સપાયર થઈ જાય છે.

સ્ટેપ 4: ટ્રસ્ટ બાઉન્ડ્રીની ચકાસણી કરો

એકવાર પ્રમાણિત થયા પછી, CloudTrail ખોલો અને ખાતરી કરો કે તમે બનાવેલી ઓળખ હેઠળ ક્રિયાઓ દેખાય છે. તમારે તે ચોક્કસ IAM યુઝર અથવા રોલ સાથે જોડાયેલી ListBuckets અથવા DescribeInstances જેવી ઇવેન્ટ્સ જોવી જોઈએ. જો તમે Root એકાઉન્ટની પ્રવૃત્તિ જુઓ છો, તો તમે કંઈક ખોટું કર્યું છે અને તમારે તરત જ સેશન રિવોક (revoke) કરી દેવું જોઈએ.

જો OAuth તમારા વર્કફ્લોમાં બંધબેસતું ન હોય, તો મેનેજ્ડ સર્વર તમારા હાલના AWS CLI ક્રેડેન્શિયલ્સ દ્વારા SigV4 પ્રમાણિકરણ (authentication) ને પણ સપોર્ટ કરે છે. તે પદ્ધતિ બ્રાઉઝર પોપ-અપને સ્કીપ કરે છે, પરંતુ એજન્ટને રો (raw) ક્રેડેન્શિયલ્સ આપવાને બદલે MCP સર્વર દ્વારા સાઇનિંગ અને સેશન મેનેજમેન્ટ કરવામાં આવે છે તેનો તમને લાભ મળે છે.

ખરેખર મહત્વની સુરક્ષા આદતો

MCP સર્વર તેની પાછળની IAM ઓળખ જેટલું જ સુરક્ષિત હોય છે.

લઘુત્તમ અધિકાર (least privilege) થી શરૂઆત કરો. ખોટી રીતે રૂટ થયેલ API Gateway ઇન્ટિગ્રેશનને ઠીક કરવા માટે તમારા એજન્ટને AdministratorAccess ની જરૂર નથી. તેને વર્તમાન કાર્ય માટે જરૂરી ચોક્કસ રીડ અથવા રાઈટ પરવાનગીઓ આપો, અને કામ પૂરું થઈ જાય ત્યારે તેને રોટેટ અથવા રિવોક કરો. જો તમે રોલનો ઉપયોગ કરી રહ્યા હોવ, તો સેશનનો સમયગાળો ટૂંકો રાખો. જો તમે યુઝરનો ઉપયોગ કરી રહ્યા હોવ, તો જ્યાં પણ તમારું ટૂલિંગ મંજૂરી આપે ત્યાં MFA સક્ષમ કરો.

ક્યારેય Root યુઝર તરીકે ઓથોરાઈઝ કરશો નહીં. Root સર્વિસ કંટ્રોલ પોલિસીઓને બાયપાસ કરે છે અને સમગ્ર એકાઉન્ટમાં અનિયંત્રિત એક્સેસ મેળવે છે. જો એજન્ટ પ્રોમ્પ્ટનો ખોટો અર્થ કાઢે અને રિસોર્સિસ ડિલીટ કરવાનો પ્રયાસ કરે, તો તમે ઈચ્છો છો કે તે વિનંતી બાઉન્ડ્રી પોલિસી દ્વારા બ્લોક કરી દેવામાં આવે. Root પાસે આવી કોઈ ગાર્ડરેલ્સ (guardrails) હોતી નથી.

અંતે, એજન્ટ સાથે એક નવા ઇન્ટર્નની જેમ વર્ત કરો જે સૂચનાઓનું સંપૂર્ણ પાલન કરે છે પરંતુ કોમન સેન્સનો અભાવ ધરાવે છે. તે તમે જે કહેશો તે શાબ્દિક રીતે અને તરત જ અમલમાં મૂકશે. જો તમે તેને "બિનઉપયોગી સિક્યુરિટી ગ્રુપ્સ ક્લીન અપ કરો" એમ કહો છો, તો તે તમારા પ્રોડક્શન ડેટાબેઝ સાથે જોડાયેલ ગ્રુપને સમાપ્ત કરી શકે છે કારણ કે તે તમે આપેલા વ્યાપક માપદંડો સાથે મેળ ખાતું હતું. કોઈપણ વિનાશક (destructive) કમાન્ડને કન્ફર્મ કરતા પહેલા તેની સમીક્ષા કરો, ખાસ કરીને જ્યારે એજન્ટ પાસે રાઈટ એક્સેસ હોય.

મુખ્ય સારાંશ

તમારે ઉપયોગિતા માટે સુરક્ષા સાથે સમજૂતી કરવાની જરૂર નથી. Managed AWS MCP Server તમારા AI આસિસ્ટન્ટને તમારા વાસ્તવિક ઇન્ફ્રાસ્ટ્રક્ચરને જોવા દે છે, તેના પોતાના હેલ્યુસિનેશન (hallucinations) સુધારવા દે છે, અને તે જ IAM ફ્રેમવર્કની અંદર કામ કરવા દે છે જે તમારી બાકીની ટીમનું સંચાલન કરે છે. તમે એન્વાયરમેન્ટ ફાઇલોમાં સિક્રેટ્સ ડ્રોપ કર્યા વિના લાઈવ કોન્ટેક્સ્ટ મેળવો છો. OAuth ફ્લો સેટ કરો, પરવાનગીઓને લોકડાઉન કરો, અને એજન્ટને તેની આંખો ખુલ્લી રાખીને અને તેના હાથ તમારી પોલિસીઓ સાથે બંધ રાખીને કામ કરવા દો.