Checklist Keamanan MCP Server untuk Developer

Model Context Protocol memungkinkan sebuah AI client memanggil tool Anda dan membaca data Anda melalui sebuah server kecil. Kenyamanan itu juga sebuah beban risiko: setiap primitif yang Anda ekspos adalah sesuatu yang bisa dicoba diraih penyerang lewat model. Sebuah MCP server adalah perangkat lunak produksi, dan ia layak mendapat threat modeling yang sama seperti API publik mana pun.

Checklist ini menyatukan panduan dalam spesifikasi MCP dengan temuan terbaru dari Cloud Security Alliance dan OWASP. Kerjakan sebelum Anda menghubungkan server ke kredensial sungguhan atau merilisnya ke sebuah marketplace. Butir-butirnya berurutan dari kontrol berdampak tertinggi hingga kebersihan operasional.

Checklist inti

Jika Anda tidak melakukan apa pun yang lain, lakukan ini. Setiap butir menutup lubang yang telah dieksploitasi pada deployment MCP sungguhan, dan tidak satu pun membutuhkan tooling yang eksotis.

Perlakukan ini sebagai daftar pra-terbang dan konfirmasi setiap baris sebelum server Anda menyentuh token sungguhan atau data pengguna sungguhan:

• Validasi audience setiap token yang masuk dan tolak token apa pun yang tidak diterbitkan untuk server Anda. Spesifikasi MCP melarang token passthrough justru karena alasan ini.
• Wajibkan persetujuan pengguna yang eksplisit sebelum client yang terdaftar secara dinamis bisa bertindak atas nama seseorang, sehingga server Anda tidak pernah menjadi confused deputy.
• Hasilkan session ID yang non-deterministik dan tidak bisa ditebak, lalu ikat setiap session ke identitas pengguna yang terverifikasi, bukan sekadar ke string session-nya.
• Pada transport HTTP, validasi header Origin dan Host serta blokir permintaan keluar ke alamat internal seperti endpoint metadata cloud di 169.254.169.254 untuk menghentikan SSRF.
• Jangan pernah menyusun perintah shell dari input model yang tidak disanitasi pada server stdio, yang merupakan jalur command injection klasik.
• Pin dan tinjau definisi tool agar sebuah server tidak bisa diam-diam menukar deskripsi yang tidak berbahaya dengan yang jahat setelah Anda menyetujuinya.

Autentikasi dan confused deputy

Kebanyakan insiden MCP yang serius bermula di batas autentikasi. Server yang menerima bearer token apa pun, atau yang meneruskan token yang diterimanya ke API di hilir, memberi penyerang cara meminjam otoritas orang lain. Spesifikasinya tegas soal ini: server hanya boleh menerima token yang diterbitkan untuk dirinya sendiri, dan tidak boleh meneruskan token ke layanan lain.

Ketika server Anda berada di depan sebuah penyedia OAuth, ia bisa menjadi confused deputy yang bertindak dengan hak lebih besar daripada yang seharusnya dimiliki pemanggil. Perbaikannya adalah pemeriksaan persetujuan dan audience yang ditegakkan di tepi. Sebuah profil pengerasan minimal untuk server Streamable HTTP terlihat seperti ini:

# Streamable HTTP MCP server hardening (env)
BIND_ADDRESS=127.0.0.1            # never 0.0.0.0 on a shared host
ALLOWED_ORIGINS=https://app.example.com
REQUIRE_AUTH=true                 # close the optional-auth gap
TOKEN_AUDIENCE=mcp.example.com    # reject tokens minted for anything else
BLOCK_INTERNAL_IPS=169.254.169.254,127.0.0.1,::1  # stop SSRF to metadata

Risiko spesifik per transport

Dua transport yang umum gagal dengan cara berbeda, sehingga kontrolnya pun berbeda. Ketahui yang mana yang Anda jalankan dan pertahankan sesuai itu.

• Server stdio berjalan sebagai subprocess lokal, sehingga risiko utamanya adalah command injection: setiap tempat Anda menyisipkan keluaran model ke string shell atau SQL adalah target.
• Menurut Cloud Security Alliance, command injection melalui server stdio adalah salah satu cacat MCP yang paling umum ditemukan di lapangan.
• Server HTTP dapat dijangkau lewat jaringan, sehingga mewarisi risiko web: SSRF, pemeriksaan origin yang hilang, dan session hijacking melalui identifier yang mudah ditebak.
• Jalankan setiap server dengan hak paling kecil. Sebuah tool yang hanya perlu membaca satu direktori tidak seharusnya punya akses tulis ke seluruh disk atau ke jaringan.

Supply chain: tool poisoning dan rug-pull

Tool yang diiklankan sebuah MCP server adalah instruksi yang akan dipercaya model, dan kepercayaan itulah permukaan serangannya. Dalam serangan tool poisoning sebuah deskripsi membawa instruksi tersembunyi; dalam rug-pull sebuah server berperilaku baik saat ditinjau lalu menukar perilaku jahat kemudian.

Menurut round-up eksploit Q1 2026 dari OWASP GenAI, teknik prompt injection dan tool poisoning terhadap tooling agen sedang dikatalogkan secara aktif, bukan dianggap teoretis. Tangani setiap MCP server pihak ketiga seperti dependensi yang belum diperiksa: pin versinya, tinjau definisi tool-nya, dan tinjau ulang saat ada pembaruan.

Kebersihan operasional

Lapisan terakhir adalah yang membosankan yang menyelamatkan Anda pada jam 3 dini hari. Kontrol ini tidak menghentikan sebuah eksploit tertentu; ia membatasi radius ledakan dan membuat insiden terlihat.

• Catat setiap pemanggilan tool beserta argumen dan hasilnya, dan simpan log itu di tempat yang tidak bisa disunting model.
• Simpan secret di luar kode dalam environment variable atau secret manager, jangan pernah di dalam definisi tool yang bisa dibaca model.
• Terapkan rate-limit dan atur timeout pada setiap tool agar agen yang lepas kendali tidak bisa menghabiskan layanan di hilir atau anggaran Anda.
• Jaga dependensi tetap ter-patch dan pantau advisory, karena satu library transport yang rentan membatalkan setiap kontrol di atasnya.

Keamanan MCP tidak eksotis; ia adalah keamanan aplikasi biasa yang diterapkan pada jenis pemanggil baru. Validasi token, ikat session, jaga transport Anda, jangan percaya tool pihak ketiga, dan catat semuanya. Jalankan checklist ini sekali sebelum peluncuran dan sekali lagi pada setiap kenaikan dependensi, dan sebagian besar berita krisis MCP berhenti membicarakan Anda.