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
Buat atau pilih role atau user IAM khusus. Jangan gunakan akun Root Anda. Lampirkan managed policy bernama AWSMCPSignInOAuthAccessPolicy ke dalamnya. Kebijakan ini hanya memberikan izin yang diperlukan untuk memulai alur sign-in OAuth untuk akses MCP. Kebijakan ini tidak memberikan hak administratif yang luas secara mandiri. Kemampuan aktual yang akan dimiliki agen Anda ditentukan oleh kebijakan IAM lainnya yang Anda lampirkan ke identitas tersebut. Jika Anda ingin agen membaca log CloudWatch tetapi tidak pernah menyentuh IAM atau penagihan, buatlah kebijakan kustom yang mengizinkan logs:DescribeLogGroups dan logs:FilterLogEvents dan tidak ada yang lain.
Langkah 2: Konfigurasi client Anda
Tambahkan URL server AWS MCP resmi ke konfigurasi client Anda. Ini berfungsi dengan Claude Desktop, Claude Code, dan Kiro. Dalam file pengaturan MCP Anda, daftarkan endpoint server agar client tahu ke mana harus mengarahkan panggilan tool terkait AWS.
Langkah 3: Autentikasi melalui browser Anda
Saat pertama kali agen mencoba memanggil tool AWS, sistem operasi Anda akan membuka jendela browser. Masuklah dengan identitas IAM yang sama yang telah Anda siapkan di Langkah 1. Alur OAuth akan mengembalikan token berdurasi singkat ke server MCP. Anda tidak akan melihat secret key. Anda tidak perlu menempelkan apa pun ke dalam file konfigurasi. Token akan diperbarui secara otomatis dan kedaluwarsa dengan cepat.
Langkah 4: Verifikasi batas kepercayaan (trust boundary)
Setelah terautentikasi, buka CloudTrail dan konfirmasikan bahwa tindakan muncul di bawah identitas yang Anda buat. Anda akan melihat event seperti ListBuckets atau DescribeInstances yang terhubung ke user atau role IAM spesifik tersebut. Jika Anda melihat aktivitas akun Root, Anda melakukan kesalahan dan harus segera mencabut (revoke) sesi tersebut.
Jika OAuth tidak sesuai dengan alur kerja Anda, Managed server juga mendukung autentikasi SigV4 melalui kredensial AWS CLI Anda yang sudah ada. Jalur tersebut melewati pop-up browser, tetapi Anda tetap mendapatkan manfaat dari server MCP yang menangani penandatanganan (signing) dan manajemen sesi, alih-alih mengekspos kredensial mentah ke agen.
Kebiasaan Keamanan yang Benar-benar Penting
Server MCP hanya seaman identitas IAM di belakangnya.
Mulailah dengan hak akses minimum (least privilege). Agen Anda tidak memerlukan AdministratorAccess untuk memperbaiki integrasi API Gateway yang salah rute. Berikan izin baca atau tulis yang tepat sesuai yang diperlukan untuk tugas saat ini, dan putar (rotate) atau cabut izin tersebut setelah pekerjaan selesai. Jika Anda menggunakan role, atur durasi sesi yang singkat. Jika Anda menggunakan user, aktifkan MFA di mana pun alat Anda mengizinkannya.
Jangan pernah melakukan otorisasi sebagai user Root. Root melewati service control policies dan memiliki akses tanpa batas ke seluruh akun. Jika agen salah menafsirkan prompt dan mencoba menghapus sumber daya, Anda ingin permintaan tersebut diblokir oleh kebijakan batas (boundary policy). Root tidak memiliki guardrails seperti itu.
Terakhir, perlakukan agen seperti anak magang baru yang mengikuti instruksi dengan sempurna tetapi kurang memiliki akal sehat. Ia akan mengeksekusi apa yang Anda minta, secara harfiah dan segera. Jika Anda menyuruhnya untuk "membersihkan security groups yang tidak digunakan," ia mungkin akan menghentikan yang terhubung ke database produksi Anda karena cocok dengan kriteria luas yang Anda berikan. Tinjau setiap perintah destruktif sebelum mengonfirmasinya, terutama saat agen memiliki akses tulis.
Kesimpulan Utama
Anda tidak perlu mengorbankan keamanan demi kegunaan. Managed AWS MCP Server memungkinkan asisten AI Anda melihat infrastruktur nyata Anda, memperbaiki halusinasi sendiri, dan beroperasi dalam kerangka kerja IAM yang sama yang mengatur anggota tim Anda lainnya. Anda mendapatkan konteks langsung tanpa harus memasukkan rahasia (secrets) ke dalam file environment. Atur alur OAuth, kunci izinnya, dan biarkan agen bekerja dengan mata terbuka dan tangan yang terikat pada kebijakan Anda.