Stop pasting AWS access keys into your .env files.
We have all been there. It is late, you are debugging a Lambda permission error, and your AI assistant keeps inventing service names or ARNs with imaginary account IDs. You want the model to see your actual resources so it stops hallucinating and starts fixing. Out of desperation, you grab an access key, drop it into an environment file, and feed it to the agent. It works. Relief floods in. Then morning arrives, and you realize that secret is sitting in your shell history, terminal scrollback, or worse, a commit that just pushed to a shared repository.
This is the exact mess the Model Context Protocol was built to prevent.
MCP creates a standard bridge between your AI agent and external systems. Instead of handing over raw credentials and hoping the agent does not leak them, you connect through a controlled server that handles authentication, scopes permissions, and keeps your keys out of the chat window entirely.
For AWS, you currently have two official MCP servers to pick from. Choosing the wrong one either leaves your agent blind or gives it too much access with too little oversight.
Know the Difference: Knowledge vs. Hands
The first option is the AWS Knowledge MCP Server. Think of it as a senior engineer who has memorized the entire AWS documentation library but has no login credentials for your account. It is read-only by design, referencing official AWS docs to ground the agent in real API syntax, correct service names, and current best practices.
You do not need an AWS account to use it. You do not connect it to your infrastructure. You spin it up when you are sketching an architecture diagram, learning a new service like ECS or EventBridge, or validating whether a particular API call still behaves the way you remember from two years ago. It stops the agent from guessing. If you ask it to write Terraform for an S3 bucket policy, it knows the real fields and valid values because it is pulling from the source, not from training data that cut off last year.
The second option is the AWS MCP Server (Managed). This one gives your agent hands, not just memory. With proper authentication, it can inspect your CloudWatch logs, list your S3 buckets, read your DynamoDB table schemas, check IAM policies attached to a role, or verify which security groups are open to the internet. It operates on your real account, which makes it powerful for troubleshooting production issues or refactoring live infrastructure.
The Managed server refuses long-lived keys. It authenticates through OAuth via a browser sign-in, or through AWS CLI using SigV4 signing. Every tool call happens with short-lived tokens, every action leaves a trail in CloudTrail, and the agent operates strictly within the IAM boundaries you define. It cannot wander outside its permissions because it is bound by the same policy engine that governs every other AWS user or role in your organization.
Here is the golden rule to remember: one server gives your agent knowledge, the other gives it hands. Use the Knowledge server when you are studying or designing. Use the Managed server when you are operating or repairing.
Why AWS Recommends the Managed Server for Most Tasks
AWS now pushes most users toward the single Managed MCP Server rather than running both in parallel. The Managed server has absorbed the documentation context that the Knowledge server provided, so it handles both reference material and live account actions under one endpoint.
Running both servers simultaneously can actually degrade the experience. The agent receives overlapping tool definitions and can get confused about whether to call a read-only documentation lookup or a live API against your account. That hesitation produces slower responses and occasional tool-selection errors. Consolidating down to the Managed server simplifies your configuration and keeps the agent focused.
Setting Up the Managed Server with OAuth
Getting the Managed server running takes about five minutes, but the steps matter because this is a live connection to your account.
Step 1: Prepare your IAM identity
Cipta atau pilih peranan (role) atau pengguna IAM yang khusus. Jangan gunakan akaun Root anda. Lampirkan polisi terurus (managed policy) bernama AWSMCPSignInOAuthAccessPolicy kepadanya. Polisi ini hanya memberikan kebenaran yang diperlukan untuk memulakan aliran log masuk OAuth bagi akses MCP. Ia tidak memberikan hak pentadbiran yang luas secara sendirinya. Keupayaan sebenar ejen anda akan ditentukan oleh polisi IAM lain yang anda lampirkan pada identiti tersebut. Jika anda mahu ejen membaca log CloudWatch tetapi tidak menyentuh IAM atau pengebilan, bina polisi tersuai yang membenarkan logs:DescribeLogGroups dan logs:FilterLogEvents dan tiada yang lain.
Langkah 2: Konfigurasikan klien anda
Tambahkan URL pelayan AWS MCP rasmi ke dalam konfigurasi klien anda. Ini berfungsi dengan Claude Desktop, Claude Code, dan Kiro. Dalam fail tetapan MCP anda, daftarkan titik akhir (endpoint) pelayan supaya klien tahu ke mana hendak menghalakan panggilan alat (tool calls) berkaitan AWS.
Langkah 3: Sahkan melalui pelayar anda
Kali pertama ejen cuba memanggil alat AWS, sistem operasi anda akan membuka tetingkap pelayar. Log masuk dengan identiti IAM yang sama yang anda sediakan dalam Langkah 1. Aliran OAuth mengembalikan token jangka pendek kepada pelayan MCP. Anda tidak akan melihat kunci rahsia (secret key). Anda tidak perlu menampal apa-apa ke dalam fail konfigurasi. Token tersebut diperbaharui secara automatik dan tamat tempoh dengan cepat.
Langkah 4: Sahkan sempadan kepercayaan (trust boundary)
Setelah disahkan, buka CloudTrail dan sahkan bahawa tindakan muncul di bawah identiti yang anda cipta. Anda sepatutnya melihat peristiwa seperti ListBuckets atau DescribeInstances yang dikaitkan dengan pengguna atau peranan IAM khusus tersebut. Jika anda melihat aktiviti akaun Root, anda telah melakukan kesilapan dan harus membatalkan sesi tersebut dengan segera.
Jika OAuth tidak sesuai dengan aliran kerja anda, pelayan Terurus (Managed server) juga menyokong pengesahan SigV4 melalui kredential AWS CLI sedia ada anda. Laluan tersebut melangkau tetingkap timbul (pop-up) pelayar, tetapi anda masih mendapat manfaat daripada pelayan MCP yang mengendalikan penandatanganan dan pengurusan sesi berbanding mendedahkan kredential mentah kepada ejen.
Tabiat Keselamatan yang Benar-benar Penting
Pelayan MCP hanya seaman identiti IAM di sebaliknya.
Mulakan dengan prinsip keistimewaan paling rendah (least privilege). Ejen anda tidak memerlukan AdministratorAccess untuk membaiki integrasi API Gateway yang salah haluan. Berikan kebenaran baca atau tulis yang diperlukan tepat untuk tugasan semasa, dan putar (rotate) atau batalkan kebenaran tersebut apabila kerja selesai. Jika anda menggunakan peranan, tetapkan tempoh sesi yang singkat. Jika anda menggunakan pengguna, aktifkan MFA di mana-mana sahaja alatan anda membenarkannya.
Jangan sesekali memberi kebenaran sebagai pengguna Root. Root memintas polisi kawalan perkhidmatan (service control policies) dan mempunyai akses tanpa sekatan ke seluruh akaun. Jika ejen tersalah tafsir arahan (prompt) dan cuba memadam sumber, anda mahu permintaan tersebut disekat oleh polisi sempadan (boundary policy). Root tidak mempunyai pagar keselamatan (guardrails) sedemikian.
Akhir sekali, layan ejen seperti pelatih baharu yang mengikut arahan dengan sempurna tetapi kurang akal budi (common sense). Ia akan melaksanakan apa yang anda minta, secara literal dan serta-merta. Jika anda menyuruhnya untuk "membersihkan kumpulan keselamatan (security groups) yang tidak digunakan," ia mungkin menamatkan kumpulan yang disambungkan ke pangkalan data pengeluaran (production database) anda kerana ia sepadan dengan kriteria luas yang anda berikan. Semak sebarang arahan pemusnah sebelum mengesahkannya, terutamanya apabila ejen mempunyai akses tulis.
Kesimpulan Sebenar
Anda tidak perlu mengorbankan keselamatan demi kegunaan. Pelayan AWS MCP Terurus membolehkan pembantu AI anda melihat infrastruktur sebenar anda, membetulkan halusinasi sendiri, dan beroperasi dalam rangka kerja IAM yang sama yang mengawal ahli pasukan anda yang lain. Anda mendapat konteks langsung tanpa perlu memasukkan rahsia ke dalam fail persekitaran (environment files). Tetapkan aliran OAuth, kunci kebenaran, dan biarkan ejen bekerja dengan mata yang terbuka dan tangan yang terikat pada polisi anda.