ਆਪਣੀਆਂ .env ਫਾਈਲਾਂ ਵਿੱਚ AWS access keys ਪੇਸਟ ਕਰਨਾ ਬੰਦ ਕਰੋ।
ਅਸੀਂ ਸਾਰੇ ਕਦੇ ਨਾ ਕਦੇ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਰਹੇ ਹਾਂ। ਦੇਰ ਹੋ ਚੁੱਕੀ ਹੈ, ਤੁਸੀਂ ਇੱਕ Lambda permission error ਨੂੰ debug ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਤੁਹਾਡਾ AI assistant ਲਗਾਤਾਰ ਕਾਲਪਨਿਕ account IDs ਦੇ ਨਾਲ ਸੇਵਾ ਦੇ ਨਾਮ ਜਾਂ ARNs ਬਣਾ ਰਿਹਾ ਹੈ। ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਮਾਡਲ ਤੁਹਾਡੇ ਅਸਲ resources ਨੂੰ ਦੇਖੇ ਤਾਂ ਜੋ ਇਹ ਗਲਤ ਜਾਣਕਾਰੀ (hallucinating) ਦੇਣਾ ਬੰਦ ਕਰੇ ਅਤੇ ਸੁਧਾਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੇ। ਨਿਰਾਸ਼ਾ ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ 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 (raw credentials) ਦੇਣ ਅਤੇ ਇਸ ਉਮੀਦ ਵਿੱਚ ਰਹਿਣ ਦੀ ਬਜਾਏ ਕਿ agent ਉਹਨਾਂ ਨੂੰ ਲੀਕ ਨਾ ਕਰੇ, ਤੁਸੀਂ ਇੱਕ controlled server ਰਾਹੀਂ ਜੁੜਦੇ ਹੋ ਜੋ authentication ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ, permissions ਨੂੰ scope ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀਆਂ keys ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਚੈਟ ਵਿੰਡੋ ਤੋਂ ਦੂਰ ਰੱਖਦਾ ਹੈ।
AWS ਲਈ, ਤੁਹਾਡੇ ਕੋਲ ਚੁਣਨ ਲਈ ਵਰਤਮਾਨ ਵਿੱਚ ਦੋ ਅਧਿਕਾਰਤ MCP servers ਹਨ। ਗਲਤ ਚੋਣ ਕਰਨ ਨਾਲ ਜਾਂ ਤਾਂ ਤੁਹਾਡਾ agent ਅੰਨ੍ਹਾ ਰਹਿ ਜਾਵੇਗਾ ਜਾਂ ਇਸਨੂੰ ਬਹੁਤ ਘੱਟ ਨਿਗਰਾਨੀ ਦੇ ਨਾਲ ਬਹੁਤ ਜ਼ਿਆਦਾ access ਮਿਲ ਜਾਵੇਗਾ।
ਅੰਤਰ ਨੂੰ ਸਮਝੋ: Knowledge ਬਨਾਮ Hands
ਪਹਿਲਾ ਵਿਕਲਪ AWS Knowledge MCP Server ਹੈ। ਇਸਨੂੰ ਇੱਕ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਵਾਂਗ ਸਮਝੋ ਜਿਸਨੇ ਪੂਰੀ AWS documentation library ਯਾਦ ਕੀਤੀ ਹੋਈ ਹੈ ਪਰ ਤੁਹਾਡੇ account ਲਈ ਕੋਈ login credentials ਨਹੀਂ ਹਨ। ਇਹ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ read-only ਹੈ, ਜੋ agent ਨੂੰ ਅਸਲ API syntax, ਸਹੀ ਸੇਵਾ ਦੇ ਨਾਮ, ਅਤੇ ਮੌਜੂਦਾ best practices ਨਾਲ ਜੋੜਨ ਲਈ ਅਧਿਕਾਰਤ AWS docs ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।
ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ AWS account ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਆਪਣੇ infrastructure ਨਾਲ ਨਹੀਂ ਜੋੜਦੇ। ਤੁਸੀਂ ਇਸਨੂੰ ਉਦੋਂ ਚਲਾਉਂਦੇ ਹੋ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ architecture diagram ਤਿਆਰ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ, ਕੋਈ ਨਵੀਂ ਸੇਵਾ ਜਿਵੇਂ ਕਿ ECS ਜਾਂ EventBridge ਸਿੱਖ ਰਹੇ ਹੁੰਦੇ ਹੋ, ਜਾਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ ਕਿ ਕੀ ਕੋਈ ਖਾਸ API call ਅਜੇ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਜਿਵੇਂ ਤੁਹਾਨੂੰ ਦੋ ਸਾਲ ਪਹਿਲਾਂ ਯਾਦ ਸੀ। ਇਹ agent ਨੂੰ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ S3 bucket policy ਲਈ Terraform ਲਿਖਣ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਅਸਲ fields ਅਤੇ ਵੈਧ (valid) values ਜਾਣਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸੋਮੇ (source) ਤੋਂ ਡਾਟਾ ਲੈ ਰਿਹਾ ਹੈ, ਨਾ ਕਿ ਪਿਛਲੇ ਸਾਲ ਖਤਮ ਹੋਏ training data ਤੋਂ।
ਦੂਜਾ ਵਿਕਲਪ AWS MCP Server (Managed) ਹੈ। ਇਹ ਤੁਹਾਡੇ agent ਨੂੰ ਸਿਰਫ਼ ਯਾਦਦਾਸ਼ਤ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਹੱਥ (hands) ਵੀ ਦਿੰਦਾ ਹੈ। ਸਹੀ authentication ਦੇ ਨਾਲ, ਇਹ ਤੁਹਾਡੇ CloudWatch logs ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ, ਤੁਹਾਡੇ S3 buckets ਦੀ ਸੂਚੀ ਬਣਾ ਸਕਦਾ ਹੈ, ਤੁਹਾਡੇ DynamoDB table schemas ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਕਿਸੇ role ਨਾਲ ਜੁੜੀਆਂ IAM policies ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕਿਹੜੇ security groups internet ਲਈ ਖੁੱਲ੍ਹੇ ਹਨ। ਇਹ ਤੁਹਾਡੇ ਅਸਲ account 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਜੋ ਇਸਨੂੰ production ਦੇ ਮੁੱਦਿਆਂ ਨੂੰ ਸੁਲਝਾਉਣ ਜਾਂ live infrastructure ਨੂੰ refactor ਕਰਨ ਲਈ ਸ਼ਕਤੀਸ਼ਾਲੀ ਬਣਾਉਂਦਾ ਹੈ।
Managed server ਲੰਬੇ ਸਮੇਂ ਵਾਲੀਆਂ (long-lived) keys ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ browser sign-in ਰਾਹੀਂ OAuth ਰਾਹੀਂ, ਜਾਂ SigV4 signing ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ AWS CLI ਰਾਹੀਂ authenticate ਹੁੰਦਾ ਹੈ। ਹਰ tool call short-lived tokens ਦੇ ਨਾਲ ਹੁੰਦੀ ਹੈ, ਹਰ ਕਾਰਵਾਈ CloudTrail ਵਿੱਚ ਇੱਕ ਨਿਸ਼ਾਨ ਛੱਡਦੀ ਹੈ, ਅਤੇ agent ਸਖਤੀ ਨਾਲ ਉਹਨਾਂ IAM boundaries ਦੇ ਅੰਦਰ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ। ਇਹ ਆਪਣੀਆਂ permissions ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਜਾ ਸਕਦਾ ਕਿਉਂਕਿ ਇਹ ਉਸੇ policy engine ਦੁਆਰਾ ਬੱਝਿਆ ਹੋਇਆ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸੰਗਠਨ (organization) ਵਿੱਚ ਹਰ ਹੋਰ AWS user ਜਾਂ role ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ।
ਇੱਥੇ ਯਾਦ ਰੱਖਣ ਲਈ ਇੱਕ ਸੁਨਹਿਰੀ ਨਿਯਮ ਹੈ: ਇੱਕ server ਤੁਹਾਡੇ agent ਨੂੰ knowledge ਦਿੰਦਾ ਹੈ, ਦੂਜਾ ਉਸਨੂੰ hands ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਪੜ੍ਹਾਈ ਜਾਂ ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ ਤਾਂ Knowledge server ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ operation ਜਾਂ ਮੁਰੰਮਤ (repairing) ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ ਤਾਂ Managed server ਦੀ ਵਰਤੋਂ ਕਰੋ।
AWS ਜ਼ਿਆਦਾਤਰ ਕੰਮਾਂ ਲਈ Managed Server ਦੀ ਸਿਫਾਰਸ਼ ਕਿਉਂ ਕਰਦਾ ਹੈ
AWS ਹੁਣ ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਨਾਲ ਚਲਾਉਣ ਦੀ ਬਜਾਏ ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇੱਕੋ 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 ਨਾਲ ਇੱਕ live connection ਹੈ।
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 ਨੂੰ ਕਿੱਥੇ ਰੂਟ (route) ਕਰਨਾ ਹੈ।
Step 3: ਆਪਣੇ browser ਰਾਹੀਂ authenticate ਕਰੋ
ਜਦੋਂ ਪਹਿਲੀ ਵਾਰ agent ਕਿਸੇ AWS tool ਨੂੰ ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ 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 (ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ) ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ। ਇੱਕ ਗਲਤ ਰੂਟ ਕੀਤੇ API Gateway integration ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਤੁਹਾਡੇ agent ਨੂੰ AdministratorAccess ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਸਿਰਫ਼ ਉਹੀ read ਜਾਂ write permissions ਦਿਓ ਜੋ ਮੌਜੂਦਾ ਕੰਮ ਲਈ ਲੋੜੀਂਦੀਆਂ ਹਨ, ਅਤੇ ਕੰਮ ਖਤਮ ਹੋਣ 'ਤੇ ਉਹਨਾਂ ਨੂੰ rotate ਜਾਂ revoke ਕਰ ਦਿਓ। ਜੇਕਰ ਤੁਸੀਂ role ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ session ਦੀ ਮਿਆਦ (duration) ਘੱਟ ਰੱਖੋ। ਜੇਕਰ ਤੁਸੀਂ user ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਜਿੱਥੇ ਵੀ ਤੁਹਾਡੇ tooling ਦੀ ਇਜਾਜ਼ਤ ਹੋਵੇ ਉੱਥੇ MFA enable ਕਰੋ।
ਕਦੇ ਵੀ Root user ਵਜੋਂ authorize ਨਾ ਕਰੋ। Root service control policies ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪੂਰੇ account ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਰੋਕ-ਟੋਕ ਦੇ access ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਜੇਕਰ agent ਕਿਸੇ prompt ਦਾ ਗਲਤ ਅਰਥ ਕੱਢਦਾ ਹੈ ਅਤੇ resources ਨੂੰ ਡਿਲੀਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਚਾਹੋਗੇ ਕਿ ਉਹ request ਇੱਕ boundary policy ਦੁਆਰਾ ਰੋਕ ਦਿੱਤੀ ਜਾਵੇ। Root ਕੋਲ ਅਜਿਹੀ ਕੋਈ guardrails ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਅੰਤ ਵਿੱਚ, agent ਨਾਲ ਇੱਕ ਨਵੇਂ intern ਵਾਂਗ ਵਿਵਹਾਰ ਕਰੋ ਜੋ ਹਦਾਇਤਾਂ ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਪਰ ਉਸ ਵਿੱਚ common sense ਦੀ ਕਮੀ ਹੈ। ਇਹ ਉਹ ਕੁਝ ਵੀ ਕਰੇਗਾ ਜੋ ਤੁਸੀਂ ਕਹੋਗੇ, ਸ਼ਾਬਦਿਕ (literally) ਅਤੇ ਤੁਰੰਤ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ "unused security groups ਨੂੰ clean up ਕਰੋ" ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਤੁਹਾਡੇ production database ਨਾਲ ਜੁੜੇ group ਨੂੰ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੇ ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ ਵਿਆਪਕ ਮਾਪਦੰਡਾਂ (criteria) ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਵਿਨਾਸ਼ਕਾਰੀ (destructive) command ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ agent ਕੋਲ write access ਹੋਵੇ।
ਅਸਲ ਸਿੱਖਿਆ
ਤੁਹਾਨੂੰ ਉਪਯੋਗਤਾ (usefulness) ਲਈ ਸੁਰੱਖਿਆ ਨਾਲ ਸਮਝੌਤਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। Managed AWS MCP Server ਤੁਹਾਡੇ AI assistant ਨੂੰ ਤੁਹਾਡੇ ਅਸਲ infrastructure ਨੂੰ ਦੇਖਣ, ਆਪਣੀਆਂ hallucinations ਨੂੰ ਸੁਧਾਰਨ, ਅਤੇ ਉਸੇ IAM framework ਦੇ ਅੰਦਰ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਬਾਕੀ ਟੀਮ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਤੁਹਾਨੂੰ environment files ਵਿੱਚ secrets ਪਾਏ ਬਿਨਾਂ live context ਮਿਲਦਾ ਹੈ। OAuth flow ਸੈੱਟਅੱਪ ਕਰੋ, permissions ਨੂੰ ਲਾਕ ਕਰੋ, ਅਤੇ agent ਨੂੰ ਆਪਣੀਆਂ ਅੱਖਾਂ ਖੋਲ੍ਹ ਕੇ ਅਤੇ ਤੁਹਾਡੀਆਂ policies ਨਾਲ ਬੱਝ ਕੇ ਕੰਮ ਕਰਨ ਦਿਓ।