AWS MCP Server di Claude Code: OAuth, SigV4 dan Scope IAM

Saya membuka AWS MCP Server dengan satu anggapan tetap: Claude Code hanya bicara OAuth 2.1, AWS memakai SigV4, jadi setiap setup butuh proxy lokal di tengah. Itu persis isi post pengumuman general availability. Tetapi itu bukan lagi cerita lengkapnya, dan panduan setup yang berhenti di sana menyuruh Anda memasang software yang mungkin tidak perlu.

Post ini adalah pembacaan dekat halaman AWS per 17 Oktober 2026: pengumuman GA, user guide untuk setup, OAuth, akses multi-profile dan CloudTrail, halaman IAM, serta repository proxy. Saya tidak menjalankannya di akun AWS, jadi setiap command dan policy di bawah diambil dari halaman tersebut atau diberi label sebagai ilustrasi saya sendiri. Pertanyaan yang saya pedulikan adalah yang dilewati halaman setup: bagaimana mencegah agent yang bisa membaca menjadi master key?

Apa itu AWS MCP Server, dan apa yang berubah sejak GA

AWS News Blog mengumumkan general availability pada 6 Mei 2026. Saat peluncuran, server di-host di US East (N. Virginia) dan Europe (Frankfurt), dan bisa memanggil API di Region mana pun. Post tersebut menyatakan tidak ada biaya tambahan untuk server itu sendiri, hanya untuk resource AWS yang Anda buat dan data transfer. Halaman setup saat ini mencantumkan delapan Region endpoint, antara lain Singapura, Sydney, Tokyo, London, dan Irlandia, masing-masing dengan URL berbentuk https://aws-mcp.REGION.api.aws/mcp.

Post GA menggambarkan tool call_aws yang bisa menjalankan lebih dari 15.000 operasi API AWS dengan kredensial IAM Anda, dan Security Blog masih menyebut aws___call_aws. Halaman tools di user guide yang saya baca hari ini mencantumkan hal lain: aws___run_script, aws___get_presigned_url, dan aws___get_tasks sebagai API tools, plus aws___retrieve_skill, aws___search_documentation, aws___read_documentation, aws___list_regions, dan aws___get_regional_availability sebagai knowledge tools. call_aws tidak disebut sama sekali. Dari halaman-halaman itu saya tidak bisa memastikan apakah tool tersebut di-rename, digabung ke run_script, atau sekadar tidak ditulis di guide, jadi cek daftar tool yang tampil di client Anda sebelum menulis policy yang mengandalkan nama tool.

Dua detail dari post GA penting untuk keamanan. Tool run_script menjalankan Python pendek di sandbox sisi server yang mewarisi permission IAM Anda dan tidak punya akses jaringan. Lalu skills, panduan terkurasi dari tim layanan AWS yang menggantikan Agent SOPs, hanyalah panduan, bukan permission tambahan. Tidak ada toolset yang memberi akses yang belum Anda miliki, dan itu sekaligus inti manfaat dan inti risikonya: agent bisa melakukan apa pun yang bisa dilakukan identitas di belakangnya.

Premis yang kedaluwarsa: OAuth saja, jadi butuh proxy

Post GA menjelaskan proxy begini: spesifikasi MCP hanya mendukung OAuth 2.1, AWS mengautentikasi dengan IAM SigV4, sehingga MCP Proxy for AWS yang open source berjalan di mesin Anda dan menjembatani keduanya. Contohnya memasang proxy dengan uvx, di-pin ke mcp-proxy-for-aws versi 1.6.0, dan catatannya menyuruh mengecek versi terbaru di repository. Bagi developer yang mulai dari post itu di bulan Mei, proxy adalah satu-satunya jalan menuju Claude Code.

User guide sekarang mendokumentasikan jalan kedua. AWS Sign-in bertindak sebagai OAuth authorization server, dan client yang kompatibel OAuth, termasuk Claude Code, terhubung langsung ke URL server tanpa proxy lokal. Command untuk Claude Code hanya satu baris. IAM principal membutuhkan dua action sign-in, signin:AuthorizeOAuth2Access dan signin:CreateOAuth2Token, yang dibundel oleh managed policy AWSMCPSignInOAuthAccessPolicy. Access token interaktif berlaku satu jam, dan refresh token, yang sekali pakai dan dirotasi, berlaku hingga 12 jam.

Jadi framing yang akurat adalah sebuah pilihan, bukan workaround. Proxy belum usang: halaman setup mengarahkan agent terminal dan IDE seperti Claude Code, Kiro, dan Codex ke opsi SigV4, dan decision guide-nya mempertahankan proxy sebagai pilihan di lima situasi. Saya membuang anggapan bahwa Claude Code mewajibkan proxy, karena halaman yang saya baca membantahnya.

OAuth atau SigV4 proxy: memilih satu untuk Claude Code

AWS menerbitkan decision guide di halaman setup. Saya mengubahnya menjadi tabel dan menambahkan apa harga tiap pilihan, hanya dengan fakta dari halaman yang sama.

Di bawah ini kedua setup persis seperti di user guide. Satu trade-off perlu disebut terus terang. Command proxy yang didokumentasikan memakai mcp-proxy-for-aws-cli di versi latest, sehingga setiap start menjalankan rilis terbaru, sedangkan post GA mem-pin versi. Repository proxy menyarankan paket -cli karena mem-pin seluruh dependency tree. Saya akan mem-pin rilis tertentu setelah Anda mengujinya, karena proxy yang menandatangani setiap request dengan kredensial Anda adalah hal terakhir yang boleh berubah sendiri.

# Option A: direct OAuth. One IAM role needs the two signin actions,
# which the AWS managed policy bundles.
aws iam attach-role-policy \
  --role-name MyRole \
  --policy-arn arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy

claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http
# The first tool call opens a browser at AWS Sign-in. The access token lasts
# 1 hour and is refreshed for up to 12 hours before you sign in again.

# Option B: SigV4 through the MCP Proxy for AWS. Needs the AWS CLI 2.32.0+
# and uv. The endpoint Region picks the server; AWS_REGION in --metadata picks
# the default Region for operations (without it, operations default to us-east-1).
aws login
aws sts get-caller-identity          # prove the credentials work first
claude mcp add-json aws-mcp '{"type":"stdio","command":"uvx","args":["mcp-proxy-for-aws-cli@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"],"env":{}}'

IAM: tidak ada permission MCP untuk diberikan, hanya key untuk di-deny

Halaman IAM menyatakannya lugas: server tidak mendefinisikan action, resource, atau condition key khusus layanan miliknya sendiri. Ia mengautentikasi request Anda dengan SigV4, menambahkan dua condition context key standar, lalu meneruskan panggilan; layanan tujuan kemudian mengotorisasinya dengan policy IAM Anda yang sudah ada. Jadi memakai server ini tidak butuh permission khusus MCP, hanya permission yang Anda butuhkan untuk panggilan API langsung.

Kedua key itu adalah aws:ViaAWSMCPService, Boolean yang bernilai true untuk request lewat AWS managed MCP server mana pun, dan aws:CalledViaAWSMCP, string berisi service principal server tersebut. Contoh nilai yang terdokumentasi adalah aws-mcp.amazonaws.com untuk server ini, eks-mcp.amazonaws.com untuk server EKS, dan ecs-mcp.amazonaws.com untuk server ECS. Key pertama mematikan semua managed MCP server sekaligus; yang kedua menarget satu server.

// Wrong: written for the preview. These aws-mcp actions are deprecated and
// have no effect, so this Deny matches nothing and nothing tells you.
{
  "Effect": "Deny",
  "Action": ["aws-mcp:CallReadWriteTool"],
  "Resource": "*"
}

// Right: key the Deny on the context keys the server adds to every
// forwarded request. aws:ViaAWSMCPService is true for any AWS managed MCP
// server; aws:CalledViaAWSMCP names the one server by its service principal.
{
  "Sid": "DenyDeleteWhenAccessedViaMCP",
  "Effect": "Deny",
  "Action": ["s3:DeleteObject", "s3:DeleteBucket"],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com" }
  }
}

Snippet pertama di atas adalah jebakannya, dan ini hal terpenting di post ini. Selama preview, server mewajibkan action aws-mcp:InvokeMcp, aws-mcp:CallReadOnlyTool, dan aws-mcp:CallReadWriteTool. AWS kini menyatakan action itu tidak lagi diperlukan dan tidak berefek, baik di statement Allow maupun Deny. Snippet kedua adalah pengganti yang didokumentasikan AWS.

Membatasi scope agar agent bukan master key

Sebuah condition key membuat satu identitas berperilaku berbeda tergantung apakah manusia atau agent yang memanggil. AWS menunjukkan polanya dengan policy yang mengizinkan baca S3 dan menolak s3:DeleteObject serta s3:DeleteBucket ketika request datang lewat server. Itu adalah Deny list, dan Deny list hanya mencakup apa yang terpikirkan oleh Anda. Pendapat saya sendiri, yang tidak dinyatakan halaman AWS, adalah menumpuk kontrol berlapis agar tidak ada satu daftar yang menentukan eksposur Anda. Tabel di bawah adalah susunan saya atas kontrol yang dijelaskan halaman-halaman itu.

Policy pertama di bawah adalah ilustrasi saya untuk lapisan 1, sisanya dari AWS. Halaman multi-profile menambahkan saran yang akan saya ikuti untuk banyak akun: jadikan profile read-only sebagai default, karena profile pertama dalam daftar adalah yang ditandatangani proxy saat agent tidak menyebut apa pun, dan jadikan profile yang bisa menulis sebagai pilihan eksplisit. Hanya profile yang dideklarasikan saat startup yang bisa dijangkau, sehingga agent tidak bisa menjelajah ke sisa file config AWS Anda.

// Layer 1 (my own illustration, not an AWS sample): the role the agent
// assumes allows reads only. Anything not listed is denied by default.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AgentReadOnly",
      "Effect": "Allow",
      "Action": ["ec2:Describe*", "s3:ListBucket", "s3:GetObject", "logs:FilterLogEvents"],
      "Resource": "*"
    }
  ]
}

// Layer 3: an SCP (or identity policy) that shuts every AWS managed MCP
// server out of an OU. This one is copied from the AWS user guide.
{
  "Sid": "DenyAllActionsViaMCP",
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": { "Bool": { "aws:ViaAWSMCPService": "true" } }
}

# Layer 4: hide write-capable tools at the proxy. Sign with a read-only
# profile first, and name any extra profiles you want the agent to reach.
uvx mcp-proxy-for-aws-cli@latest https://aws-mcp.us-east-1.api.aws/mcp \
  --read-only --profile prod-readonly dev

Di mana ia gagal: kegagalan dan trade-off

Sebagian besar risiko di sini datang dari aturan yang tampak benar tetapi tidak melakukan apa-apa, bukan dari server itu sendiri.

Jebakan lain yang saya temukan di halaman-halaman itu, urut dari yang paling saya khawatirkan:

• Mencabut akses tidak instan. Mencabut refresh token menghentikan access token baru, tetapi yang sudah ada berlaku hingga satu jam. Untuk containment segera, AWS menyuruh menolak request lewat condition key aws:SignInSessionArn.
• Mengubah IAM policy pada principal otomatis mencabut refresh token OAuth-nya, berguna saat mengetatkan role, tetapi artinya sesi berakhir tanpa peringatan.
• Daftar OAuth client tertutup. Hanya agent yang disetujui yang bisa mendaftar lewat Dynamic Client Registration, dan hanya redirect URI publik yang berfungsi, sehingga tool internal buatan Anda tidak bisa langsung mendaftar.
• Dokumentasi sudah bergeser: nama tool di post GA tidak ada di halaman tool saat ini. Policy yang ditulis berdasarkan nama tool, bukan action API, akan lapuk.

Trade-off di balik semuanya adalah kenyamanan melawan containment. OAuth adalah rute tercepat menuju agent yang berfungsi, sedangkan proxy SigV4 membeli mode read-only, kontrol profile, dan Region default tetap dengan harga proses yang harus Anda jaga tetap terbaru. Saya akan memilih proxy untuk apa pun yang dekat production dan OAuth untuk akun sandbox, tetapi itu penilaian, bukan sesuatu yang ditetapkan AWS.

Apa yang bisa Anda lihat sesudahnya: CloudTrail dan metrik

User guide menyatakan CloudTrail menangkap semua panggilan untuk authenticated tools. Panggilan ke tool read-write muncul sebagai event dengan eventSource aws-mcp.amazonaws.com, eventName CallReadWriteTool, dan eventType AwsMcpEvent, dengan parameter request persis tersalin. Perhatikan bahwa guide mengklasifikasikan entri itu sebagai data event, jadi trail default mungkin tidak menyimpannya sampai Anda mengonfigurasinya; saya tidak memverifikasi apa yang ditampilkan Event history. Dengan OAuth, Sign-in juga mencatat AuthorizeOAuth2Access dan CreateOAuth2Token, dan panggilan API berikutnya membawa konteks aws:SignInSessionArn sehingga aktivitas bisa dikaitkan ke sign-in.

// Fields from the AWS CloudTrail user guide for an MCP tool call. The entry
// is a data event, so check your trail records them rather than assuming.
{
  "eventCategory": "Data",
  "eventType": "AwsMcpEvent",
  "eventSource": "aws-mcp.amazonaws.com",
  "eventName": "CallReadWriteTool",
  "requestParameters": { "method": "tools/call", "params": { } },
  "mcpEventDetails": { "mcpServerName": "aws-mcp.us-east-1.api.aws" }
}
// The tool name is logged without the client prefix: your client shows
// aws___retrieve_skill, CloudTrail logs retrieve_skill.

Post GA menambahkan metrik CloudWatch di namespace AWS-MCP yang memisahkan panggilan agent dari panggilan langsung manusia. Saya tidak menemukan nama metriknya di halaman yang saya baca, jadi tidak saya cantumkan. Security Blog menyarankan memakai CloudTrail untuk melihat apa yang sebenarnya dilakukan agent, lalu mengetatkan policy dari bukti itu, dan memulai dengan restriktif sebelum melonggarkan.

Yang dikerjakan hari Senin

Urutan singkat yang mengikuti halaman-halaman di atas. Kerjakan dulu di akun sandbox.

1. Cari prefix aws-mcp: di setiap SCP, boundary, dan role policy, lalu ganti setiap Deny dengan condition key aws:ViaAWSMCPService atau aws:CalledViaAWSMCP.
2. Buat role read-only yang sempit untuk agent, dan jadikan itu identitas yang dipakai Claude Code, bukan profile administrator Anda.
3. Hubungkan dengan OAuth untuk satu akun sandbox, atau dengan proxy yang di-pin ke versi teruji jika Anda butuh profile, mode read-only, atau Region default.
4. Daftar tool yang benar-benar tampil di client Anda dan baca namanya. Jangan berasumsi call_aws ada.
5. Panggil satu action yang terdaftar lewat server dan satu lewat CLI. Pastikan hanya yang pertama ditolak, lalu temukan keduanya di CloudTrail.

Hanya ketika kelimanya terpenuhi, server yang sama boleh diarahkan ke role dengan akses tulis, dan itu pun hanya lewat Deny list yang pernah Anda lihat benar-benar menolak sesuatu.

AWS MCP Server tidak menambah permission, ia membuka permission yang sudah Anda miliki kepada agent, jadi pekerjaannya adalah mengecilkan identitas dan membuktikan Deny-nya bekerja. Perlakukan proxy sebagai pilihan, bukan keharusan, jangan percaya action aws-mcp di policy, dan baca daftar tool yang tampil di client Anda, bukan yang ada di sebuah blog, termasuk yang ini.