ನಿಮ್ಮ .env ಫೈಲ್‌ಗಳಿಗೆ AWS access keys ಗಳನ್ನು ಪೇಸ್ಟ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ.

ನಾವೆಲ್ಲರೂ ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ. ತಡವಾಗಿದೆ, ನೀವು Lambda permission error ಅನ್ನು ಡೀಬಗ್ ಮಾಡುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ನಿಮ್ಮ AI ಅಸಿಸ್ಟೆಂಟ್ ಕಲ್ಪಿತ ಅಕೌಂಟ್ ID ಗಳೊಂದಿಗೆ ಕಾಲ್ಪನಿಕ ಸರ್ವಿಸ್ ಹೆಸರುಗಳು ಅಥವಾ ARNs ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತಲೇ ಇರುತ್ತದೆ. ನಿಮ್ಮ ಏಜೆಂಟ್ ಕಲ್ಪನೆಗಳನ್ನು ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ನಿಜವಾದ ರಿಸೋರ್ಸ್‌ಗಳನ್ನು ನೋಡಿ ಸಮಸ್ಯೆಗಳನ್ನು ಸರಿಪಡಿಸಲು ನೀವು ಬಯಸುತ್ತೀರಿ. ನಿರಾಶೆಯಿಂದಾಗಿ, ನೀವು ಒಂದು access key ಅನ್ನು ಪಡೆದು, ಅದನ್ನು ಎನ್ವಿರಾನ್ಮೆಂಟ್ ಫೈಲ್‌ಗೆ ಹಾಕಿ, ಏಜೆಂಟ್‌ಗೆ ನೀಡುತ್ತೀರಿ. ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಿಮಗೆ ನೆಮ್ಮದಿ ಸಿಗುತ್ತದೆ. ನಂತರ ಬೆಳಿಗ್ಗೆಯಾಗಿದಾಗ, ಆ ರಹಸ್ಯ ಕೀ (secret) ನಿಮ್ಮ ಶೆಲ್ ಇತಿಹಾಸ (shell history), ಟರ್ಮಿನಲ್ ಸ್ಕ್ರೋಲ್‌ಬ್ಯಾಕ್ ಅಥವಾ ಅದಕ್ಕಿಂತ最 ಕೆಟ್ಟದಾಗಿ, ಹಂಚಿಕೆಯ ರೆಪೊಸಿಟರಿಗೆ (shared repository) ಪುಶ್ ಮಾಡಲಾದ ಕಮಿಟ್‌ನಲ್ಲಿ ಇರುವುದು ನಿಮಗೆ ಅರಿವಾಗುತ್ತದೆ.

Model Context Protocol ಅನ್ನು ಇದೇ ರೀತಿಯ ಗೊಂದಲವನ್ನು ತಡೆಗಟ್ಟಲು ನಿರ್ಮಿಸಲಾಗಿದೆ.

MCP ನಿಮ್ಮ AI ಏಜೆಂಟ್ ಮತ್ತು ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗಳ ನಡುವೆ ಒಂದು ಪ್ರಮಾಣಿತ ಸೇತುವೆಯನ್ನು (standard bridge) ನಿರ್ಮಿಸುತ್ತದೆ. ಕಚ್ಚಾ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು (raw credentials) ಏಜೆಂಟ್‌ಗೆ ನೀಡಿ ಅವು ಸೋರಿಕೆಯಾಗಬಹುದು ಎಂದು ಆತಂಕಪಡುವ ಬದಲು, ನೀವು ದೃಢೀಕರಣವನ್ನು (authentication) ನಿರ್ವಹಿಸುವ, ಅನುಮತಿಗಳನ್ನು (permissions) ನಿಯಂತ್ರಿಸುವ ಮತ್ತು ನಿಮ್ಮ ಕೀಗಳನ್ನು ಚಾಟ್ ವಿಂಡೋದಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ದೂರವಿಡುವ ನಿಯಂತ್ರಿತ ಸರ್ವರ್ ಮೂಲಕ ಸಂಪರ್ಕಿಸುತ್ತೀರಿ.

AWS ಗಾಗಿ, ನೀವು ಆಯ್ಕೆ ಮಾಡಲು ಪ್ರಸ್ತುತ ಎರಡು ಅಧಿಕೃತ MCP ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ. ತಪ್ಪು ಸರ್ವರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ನಿಮ್ಮ ಏಜೆಂಟ್‌ಗೆ ಸರಿಯಾದ ಮಾಹಿತಿ ನೀಡದೆ ಇಡಬಹುದು ಅಥವಾ ಸರಿಯಾದ ಮೇಲ್ವಿಚಾರಣೆ ಇಲ್ಲದೆ ಅದಕ್ಕೆ ಅತಿಯಾದ ಪ್ರವೇಶವನ್ನು ನೀಡಬಹುದು.

ವ್ಯತ್ಯಾಸವನ್ನು ತಿಳಿಯಿರಿ: ಜ್ಞಾನ (Knowledge) vs. ಕೈಗಳು (Hands)

ಮೊದಲ ಆಯ್ಕೆಯೆಂದರೆ AWS Knowledge MCP Server. ಇದನ್ನು ಇಡೀ AWS ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಲೈಬ್ರರಿಯನ್ನು ನೆನಪಿಟ್ಟುಕೊಂಡಿರುವ ಆದರೆ ನಿಮ್ಮ ಅಕೌಂಟ್‌ಗೆ ಲಾಗಿನ್ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಸ್ ಇಲ್ಲದ ಹಿರಿಯ ಎಂಜಿನಿಯರ್ ಎಂದು ಭಾವಿಸಿ. ಇದು ವಿನ್ಯಾಸದ ಮೂಲಕ 'ರೀಡ್-ಓನ್ಲಿ' (read-only) ಆಗಿದ್ದು, ಏಜೆಂಟ್‌ಗೆ ನೈಜ API ಸಿಂಟ್ಯಾಕ್ಸ್, ಸರಿಯಾದ ಸರ್ವಿಸ್ ಹೆಸರುಗಳು ಮತ್ತು ಪ್ರಸ್ತುತ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು (best practices) ನೀಡಲು ಅಧಿಕೃತ AWS ಡಾಕ್ಸ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ.

ಇದನ್ನು ಬಳಸಲು ನಿಮಗೆ AWS ಅಕೌಂಟ್ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಇದನ್ನು ನಿಮ್ಮ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್‌ಗೆ ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ. ನೀವು ಆರ್ಕಿಟೆಕ್ಚರ್ ಡಯಾಗ್ರಾಮ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವಾಗ, ECS ಅಥವಾ EventBridge ನಂತಹ ಹೊಸ ಸೇವೆಯನ್ನು ಕಲಿಯುವಾಗ ಅಥವಾ ಒಂದು ನಿರ್ದಿಷ್ಟ API ಕಾಲ್ ಇಂದಿನಲ್ಲೂ ಹಳೆಯದರಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವಾಗ ಇದನ್ನು ಬಳಸಬಹುದು. ಇದು ಏಜೆಂಟ್ ಅಂದಾಜು ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ನೀವು S3 ಬಕೆಟ್ ಪಾಲಿಸಿಗಾಗಿ Terraform ಬರೆಯಲು ಕೇಳಿದರೆ, ಅದು ಕಳೆದ ವರ್ಷದ ತರಬೇತಿ ಡೇಟಾದಿಂದಲ್ಲದೆ, ನೇರವಾಗಿ ಮೂಲ ದಾಖಲೆಗಳಿಂದ (source) ಮಾಹಿತಿಯನ್ನು ಪಡೆಯುವುದರಿಂದ ನೈಜ ಫೀಲ್ಡ್‌ಗಳು ಮತ್ತು ಮಾನ್ಯವಾದ ಮೌಲ್ಯಗಳನ್ನು ತಿಳಿಯುತ್ತದೆ.

ಎರಡನೇ ಆಯ್ಕೆಯೆಂದರೆ AWS MCP Server (Managed). ಇದು ನಿಮ್ಮ ಏಜೆಂಟ್‌ಗೆ ಕೇವಲ ನೆನಪನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಕೆಲಸ ಮಾಡುವ ಕೈಗಳನ್ನು (hands) ನೀಡುತ್ತದೆ. ಸರಿಯಾದ ದೃಢೀಕರಣದೊಂದಿಗೆ, ಇದು ನಿಮ್ಮ CloudWatch ಲಾಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು, ನಿಮ್ಮ S3 ಬಕೆಟ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ನೀಡಬಹುದು, ನಿಮ್ಮ DynamoDB ಟೇಬಲ್ ಸ್ಕೀಮಾಗಳನ್ನು ಓದಬಹುದು, ರೋಲ್‌ಗೆ ಅಂಟಿಸಲಾದ IAM ಪಾಲಿಸಿಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು ಅಥವಾ ಯಾವ ಸೆಕ್ಯುರಿಟಿ ಗ್ರೂಪ್‌ಗಳು ಇಂಟರ್ನೆಟ್‌ಗೆ ತೆರೆದಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು. ಇದು ನಿಮ್ಮ ನೈಜ ಅಕೌಂಟ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಪ್ರೊಡಕ್ಷನ್ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಅಥವಾ ಲೈವ್ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಅನ್ನು ಸುಧಾರಿಸಲು (refactoring) ಅತ್ಯಂತ ಶಕ್ತಿಯುತವಾಗಿದೆ.

Managed ಸರ್ವರ್ ದೀರ್ಘಕಾಲದ (long-lived) ಕೀಗಳನ್ನು ಬಳಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಇದು ಬ್ರೌಸರ್ ಸೈನ್-ಇನ್ ಮೂಲಕ OAuth ಅಥವಾ SigV4 ಸೈನಿಂಗ್ ಬಳಸುವ AWS CLI ಮೂಲಕ ದೃಢೀಕರಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಟೂಲ್ ಕಾಲ್ ಕೂಡ ಅಲ್ಪಾವಧಿಯ ಟೋಕನ್‌ಗಳೊಂದಿಗೆ (short-lived tokens) ನಡೆಯುತ್ತದೆ, ಪ್ರತಿಯೊಂದು ಕ್ರಮವು CloudTrail ನಲ್ಲಿ ದಾಖಲಾಗುತ್ತದೆ ಮತ್ತು ಏಜೆಂಟ್ ನೀವು ವ್ಯಾಖ್ಯಾನಿಸಿದ IAM ಮಿತಿಗಳ ಒಳಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಿಮ್ಮ ಸಂಸ್ಥೆಯಲ್ಲಿನ ಇತರ ಎಲ್ಲಾ AWS ಬಳಕೆದಾರರು ಅಥವಾ ರೋಲ್‌ಗಳನ್ನು ನಿಯಂತ್ರಿಸುವ ಅದೇ ಪಾಲಿಸಿ ಇಂಜಿನ್‌ನಿಂದಾಗಿ, ಇದು ತನ್ನ ಅನುಮತಿಗಳ ಹೊರಗೆ ಹೋಗಲು ಸಾಧ್ಯವಿಲ್ಲ.

ನೆನಪಿಡಬೇಕಾದ ಸುವರ್ಣ ನಿಯಮ ಇಲ್ಲಿದೆ: ಒಂದು ಸರ್ವರ್ ನಿಮ್ಮ ಏಜೆಂಟ್‌ಗೆ ಜ್ಞಾನವನ್ನು ನೀಡುತ್ತದೆ, ಇನ್ನೊಂದು ಅದಕ್ಕೆ ಕೈಗಳನ್ನು ನೀಡುತ್ತದೆ. ನೀವು ಅಧ್ಯಯನ ಅಥವಾ ವಿನ್ಯಾಸ ಮಾಡುತ್ತಿರುವಾಗ Knowledge ಸರ್ವರ್ ಬಳಸಿ. ನೀವು ಕಾರ್ಯಾಚರಣೆ ಅಥವಾ ದುರಸ್ತಿ ಮಾಡುತ್ತಿರುವಾಗ Managed ಸರ್ವರ್ ಬಳಸಿ.

ಹೆಚ್ಚಿನ ಕಾರ್ಯಗಳಿಗಾಗಿ AWS ಏಕೆ Managed ಸರ್ವರ್ ಅನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ

AWS ಈಗ ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರನ್ನು ಎರಡನ್ನೂ ಸಮಾನಾಂತರವಾಗಿ ಚಲಾಯಿಸುವ ಬದಲು ಒಂದೇ Managed MCP Server ಕಡೆಗೆ ಪ್ರೇರೇಪಿಸುತ್ತಿದೆ. Knowledge ಸರ್ವರ್ ಒದಗಿಸುತ್ತಿದ್ದ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಸಂದರ್ಭವನ್ನು (context) Managed ಸರ್ವರ್ ತನ್ನೊಳಗೆ ಅಳವಡಿಸಿಕೊಂಡಿದೆ, ಆದ್ದರಿಂದ ಇದು ಒಂದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅಡಿಯಲ್ಲಿ ರೆಫರೆನ್ಸ್ ಮೆಟೀರಿಯಲ್ ಮತ್ತು ಲೈವ್ ಅಕೌಂಟ್ ಕ್ರಮಗಳೆರಡನ್ನೂ ನಿರ್ವಹಿಸುತ್ತದೆ.

ಎರಡೂ ಸರ್ವರ್‌ಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಚಲಾಯಿಸುವುದು ಅನುಭವವನ್ನು ಕುಗ್ಗಿಸಬಹುದು. ಏಜೆಂಟ್ ಒಂದೇ ರೀತಿಯ ಟೂಲ್ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಪಡೆಯಬಹುದು ಮತ್ತು ಅದು ರೀಡ್-ಓನ್ಲಿ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ನೋಡುವುದೋ ಅಥವಾ ನಿಮ್ಮ ಅಕೌಂಟ್‌ಗೆ ಲೈವ್ API ಕಾಲ್ ಮಾಡುವುದೋ ಎಂಬ ಗೊಂದಲಕ್ಕೆ ಒಳಗಾಗಬಹುದು. ಈ ಹಿಂಜರಿಕೆ ನಿಧಾನಗತಿಯ ಪ್ರತಿಕ್ರಿಯೆಗಳಿಗೆ ಮತ್ತು ಸಾಂದರ್ಭಿಕ ಟೂಲ್-ಸೆಲೆಕ್ಷನ್ ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. Managed ಸರ್ವರ್‌ಗೆ ಮಿತಿ ಮಾಡಿಕೊಳ್ಳುವುದು ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಏಜೆಂಟ್ ಅನ್ನು ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ.

OAuth ಮೂಲಕ Managed ಸರ್ವರ್ ಅನ್ನು ಸೆಟಪ್ ಮಾಡುವುದು

Managed ಸರ್ವರ್ ಅನ್ನು ಚಾಲನೆಯಲ್ಲಿ ತರಲು ಸುಮಾರು ಐದು ನಿಮಿಷಗಳು ಬೇಕಾಗುತ್ತವೆ, ಆದರೆ ಈ ಹಂತಗಳು ಬಹಳ ಮುಖ್ಯ ಏಕೆಂದರೆ ಇದು ನಿಮ್ಮ ಅಕೌಂಟ್‌ಗೆ ನೇರವಾದ ಸಂಪರ್ಕವಾಗಿದೆ.

ಹಂತ 1: ನಿಮ್ಮ IAM identity ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿ

ಒಂದು ಮೀಸಲಾದ IAM role ಅಥವಾ user ಅನ್ನು ರಚಿಸಿ ಅಥವಾ ಆಯ್ಕೆ ಮಾಡಿ. ನಿಮ್ಮ Root account ಅನ್ನು ಬಳಸಬೇಡಿ. ಅದಕ್ಕೆ AWSMCPSignInOAuthAccessPolicy ಎಂಬ managed policy ಅನ್ನು ಅಟ್ಯಾಚ್ ಮಾಡಿ. ಈ policy ಕೇವಲ MCP ಪ್ರವೇಶಕ್ಕಾಗಿ OAuth sign-in flow ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಅಗತ್ಯವಿರುವ ಅನುಮತಿಗಳನ್ನು ಮಾತ್ರ ನೀಡುತ್ತದೆ. ಇದು ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ವ್ಯಾಪಕವಾದ administrative rightsಗಳನ್ನು ನೀಡುವುದಿಲ್ಲ. ನಿಮ್ಮ agent ಗೆ ಇರುವ ನಿಜವಾದ ಸಾಮರ್ಥ್ಯಗಳು ನೀವು ಆ identity ಗೆ ಅಟ್ಯಾಚ್ ಮಾಡುವ ಉಳಿದ IAM policies ನಿಂದ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತವೆ. ನೀವು agent ಗೆ CloudWatch logs ಓದಲು ಅನುಮತಿಸಬೇಕೆಂದಿದ್ದರೆ ಆದರೆ IAM ಅಥವಾ billing ಅನ್ನು ಎಂದಿಗೂ ಮುಟ್ಟಬಾರದು ಎಂದಿದ್ದರೆ, ಕೇವಲ logs:DescribeLogGroups ಮತ್ತು logs:FilterLogEvents ಅನ್ನು ಮಾತ್ರ ಅನುಮತಿಸುವ ಒಂದು custom policy ಅನ್ನು ರಚಿಸಿ.

ಹಂತ 2: ನಿಮ್ಮ client ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ

ನಿಮ್ಮ client configuration ಗೆ ಅಧಿಕೃತ AWS MCP server URL ಅನ್ನು ಸೇರಿಸಿ. ಇದು Claude Desktop, Claude Code, ಮತ್ತು Kiro ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ MCP settings file ನಲ್ಲಿ, server endpoint ಅನ್ನು ರಿಜಿಸ್ಟರ್ ಮಾಡಿ, ಇದರಿಂದ client ಗೆ AWS ಸಂಬಂಧಿತ tool calls ಅನ್ನು ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಬೇಕೆಂದು ತಿಳಿಯುತ್ತದೆ.

ಹಂತ 3: ನಿಮ್ಮ browser ಮೂಲಕ Authenticate ಮಾಡಿ

ಮೊದಲ ಬಾರಿಗೆ agent ಒಂದು AWS tool ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ನಿಮ್ಮ operating system ಒಂದು browser window ಅನ್ನು ತೆರೆಯುತ್ತದೆ. ಹಂತ 1 ರಲ್ಲಿ ನೀವು ಸಿದ್ಧಪಡಿಸಿದ ಅದೇ IAM identity ಮೂಲಕ sign in ಮಾಡಿ. OAuth flow એ MCP server ಗೆ ಅಲ್ಪಾವಧಿಯ (short-lived) token ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ನೀವು ಯಾವುದೇ secret key ಅನ್ನು ನೋಡಲಾಗುವುದಿಲ್ಲ. ನೀವು configuration file ಗೆ ಏನನ್ನೂ ಪೇಸ್ಟ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ. Token ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಿಫ್ರೆಶ್ ಆಗುತ್ತದೆ ಮತ್ತು ಶೀಘ್ರವಾಗಿ ಅವಧಿ ಮುಗಿಯುತ್ತದೆ.

ಹಂತ 4: trust boundary ಅನ್ನು ಪರಿಶೀಲಿಸಿ

Authenticate ಆದ ನಂತರ, CloudTrail ತೆರೆಯಿರಿ ಮತ್ತು ನೀವು ರಚಿಸಿದ identity ಅಡಿಯಲ್ಲಿ ಕ್ರಮಗಳು (actions) ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿವೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಆ ನಿರ್ದಿಷ್ಟ IAM user ಅಥವಾ role ಗೆ ಸಂಬಂಧಿಸಿದ ListBuckets ಅಥವಾ DescribeInstances ನಂತಹ events ಗಳನ್ನು ನೀವು ನೋಡಬೇಕು. ನೀವು 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' (ಕನಿಷ್ಠ ಅನುಮತಿ) ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. ತಪ್ಪಾದ ಹಾದಿಯಲ್ಲಿರುವ API Gateway integration ಅನ್ನು ಸರಿಪಡಿಸಲು ನಿಮ್ಮ agent ಗೆ AdministratorAccess ಅಗತ್ಯವಿಲ್ಲ. ಪ್ರಸ್ತುತ ಕಾರ್ಯಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಓದುವ ಅಥವಾ ಬರೆಯುವ (read or write) ಅನುಮತಿಗಳನ್ನು ಮಾತ್ರ ನೀಡಿ, ಮತ್ತು ಕೆಲಸ ಮುಗಿದ ನಂತರ ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಿ (rotate) ಅಥವಾ ರದ್ದುಗೊಳಿಸಿ (revoke). ನೀವು role ಬಳಸುತ್ತಿದ್ದರೆ, ಅಲ್ಪಾವಧಿಯ session duration ಅನ್ನು ನಿಗದಿಪಡಿಸಿ. ನೀವು user ಬಳಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ tooling ಅನುಮತಿಸುವಲ್ಲಿ MFA ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ.

ಎಂದಿಗೂ Root user ಆಗಿ ಅಧಿಕಾರ ನೀಡಬೇಡಿ. Root એ service control policies ಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಇಡೀ ಖಾತೆಯಾದ್ಯಂತ ಅನಿಯಮಿತ ಪ್ರವೇಶವನ್ನು (unrestricted access) ಹೊಂದಿರುತ್ತದೆ. ಒಂದು ವೇಳೆ agent ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಂಡು ಸಂಪನ್ಮೂಲಗಳನ್ನು (resources) ಅಳಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಆ ವಿನಂತಿಯನ್ನು boundary policy ಮೂಲಕ ತಡೆಯಲು ನೀವು ಬಯಸುತ್ತೀರಿ. Root ಗೆ ಅಂತಹ ಯಾವುದೇ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳು (guardrails) ಇರುವುದಿಲ್ಲ.

ಕೊನೆಯದಾಗಿ, agent ಅನ್ನು ಸೂಚನೆಗಳನ್ನು ಪರಿಪೂರ್ಣವಾಗಿ ಪಾಲಿಸುವ ಆದರೆ ಸಾಮಾನ್ಯ ಜ್ಞಾನದ ಕೊರತೆಯಿರುವ ಹೊಸ ಇಂಟರ್ನ್‌ನಂತೆ ಪರಿಗಣಿಸಿ. ನೀವು ಕೇಳಿದ್ದನ್ನು ಅದು ಅಕ್ಷರಶಃ ಮತ್ತು ತಕ್ಷಣವೇ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ನೀವು ಅದಕ್ಕೆ "ಬಳಕೆಯಲ್ಲಿಲ್ಲದ security groups ಗಳನ್ನು ಕ್ಲೀನ್ ಮಾಡಿ" ಎಂದು ಹೇಳಿದರೆ, ನೀವು ನೀಡಿದ ವಿಶಾಲವಾದ ಮಾನದಂಡಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಅದು ನಿಮ್ಮ production database ಗೆ ಅಂಟಿಸಲಾದ group ಅನ್ನು ಕೊನೆಗೊಳಿಸಬಹುದು (terminate). ಯಾವುದೇ ವಿನಾಶಕಾರಿ ಕಮಾಂಡ್‌ಗಳನ್ನು (destructive commands) ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ಪರಿಶೀಲಿಸಿ, ವಿಶೇಷವಾಗಿ agent ಗೆ write access ಇದ್ದಾಗ.

ನಿಜವಾದ ಸಾರಾಂಶ

ನೀವು ಉಪಯುಕ್ತತೆಗಾಗಿ ಭದ್ರತೆಯನ್ನು ಬಲಿಕೊಡಬೇಕಾಗಿಲ್ಲ. Managed AWS MCP Server ನಿಮ್ಮ AI assistant ಗೆ ನಿಮ್ಮ ನೈಜ ಮೂಲಸೌಕರ್ಯವನ್ನು (infrastructure) ನೋಡಲು, ತನ್ನದೇ ಆದ ಭ್ರಮೆಗಳನ್ನು (hallucinations) ತಿದ್ದಿಕೊಳ್ಳಲು ಮತ್ತು ನಿಮ್ಮ ತಂಡದ ಉಳಿದವರನ್ನು ನಿಯಂತ್ರಿಸುವ ಅದೇ IAM framework ಒಳಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ನೀವು environment files ಗೆ secrets ಗಳನ್ನು ಹಾಕದೆ ನೇರವಾದ ಸಂದರ್ಭವನ್ನು (live context) ಪಡೆಯುತ್ತೀರಿ. OAuth flow ಅನ್ನು ಹೊಂದಿಸಿ, ಅನುಮತಿಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿಯಂತ್ರಿಸಿ, ಮತ್ತು agent ನಿಮ್ಮ policies ಗೆ ಬದ್ಧವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಬಿಡಿ.