Banyak bisnis kecil sekarang pakai AI agent: chatbot toko, otomasi email, asisten internal. Semua itu hampir selalu tersambung lewat MCP (Model Context Protocol). Masalahnya, MCP itu pintu. Kalau pintunya longgar, agent-nya bisa lihat data yang seharusnya tidak dia lihat.
Hari ini aku audit tiga tool MCP buatanku sendiri. Bukan audit teori: semua contoh di artikel ini nyata, lengkap dengan PoC yang bisa dijalankan ulang. Ini lima kesalahan yang muncul, dan semuanya bisa terjadi di setup UMKM mana pun.
1. API key nempel di file config
Kesalahan paling umum: key payment gateway atau LLM ditulis langsung di file config atau .env yang ikut ke commit. Di audit sendiri, scanner-ku justru menemukan kelemahan sebaliknya: rule deteksi secrets-nya tidak mengenali format key baru yang mengandung strip di tengah, dan tidak mengenali blok JSON berisi variabel env. Artinya file yang penuh key bisa lolos scan dengan bersih.
Perbaikannya murah: key hidup di environment variable atau secret manager, bukan di file yang ikut git. Kalau pakai scanner, tes dulu dengan key palsu berformat baru. Kalau scanner tidak berteriak, scanner-nya yang rusak, bukan sistemmu yang aman.
2. Percaya penuh hasil scanner pertama
Pass pertama audit-ku menghasilkan 43 temuan. Kalau langsung dipercaya, aku akan buang berapa jam untuk mengejar hantu: hampir semuanya false positive dari file test yang memang sengaja berisi pola rawan. Pass kedua setelah folder test dikecualikan menyisakan 13 temuan, dan semuanya juga false positive, salah satunya scanner menandai docstring-nya sendiri yang menjelaskan pola berbahaya.
Pelajaran untuk bisnis kecil: hasil scan adalah daftar dugaan, bukan daftar kepastian. Siapa pun yang gerak cepat tanpa triage akan salah prioritas. Luangkan 30 menit untuk memilah mana temuan nyata dan mana noise sebelum mengeksekusi perbaikan.
3. Isolasi antar agent dianggap otomatis aman
Temuan paling serius dari audit: di satu server memory, semua klien MCP dianggap satu identitas yang sama. Akibatnya klien mana pun bisa mengubah kebijakan akses sebuah data menjadi bisa dibaca siapa saja, lalu membacanya. PoC-nya sederhana: sebelum perubahan, baca ditolak. Setelah satu request PATCH, baca diterima.
Kalau UMKM kamu menjalankan lebih dari satu agent (satu buat customer service, satu buat keuangan), dan keduanya nyambung ke server data yang sama lewat MCP, cek: apakah masing-masing punya identitas sendiri di sisi server? Kalau semuanya lewat satu identitas generik, isolasimu cuma dekorasi. Perbaikannya: identitas per klien, dan perubahan kebijakan akses hanya boleh lewat jalur admin, bukan lewat endpoint update biasa.
4. Alur hapus data yang bisa dilewati
Di server yang sama, ada aturan: data harus melewati status arsip sebelum dihapus, supaya ada jendela 30 hari untuk audit dan pemulihan. Endpoint resmi menegakkan aturan itu dengan benar. Tapi endpoint PATCH menerima field lifecycle langsung, dan lewat pintu itu data bisa melompat dari aktif ke terhapus tanpa pernah diarsipkan. Jendela 30 hari-nya jadi tidak pernah ada untuk klien yang tahu triknya.
Buat bisnis yang pegang data pelanggan, ini bukan soal teknis doang. Retensi adalah janji: kalau aturan retensimu bisa dilewati lewat satu endpoint, janjimu di kebijakan privacy tidak bernilai. Perbaikannya: field status tidak boleh diubah lewat update bebas, cukup lewat endpoint transisi khusus yang sudah mengecek urutan yang sah.
5. Security scan di CI yang cuma pajangan
Dua repo audit-ku punya langkah security scan di CI. Kedengarannya bagus di README. Masalahnya di salah satunya, langkah itu diset continue-on-error, jadi walau scan menemukan sesuatu, pipeline tetap hijau dan tidak ada yang peduli. Scan dekoratif lebih buruk daripada tidak ada scan, karena memberi rasa aman palsu.
Perbaikan satu baris: hapus continue-on-error, biarkan pipeline merah kalau scanner menemukan temuan. Repo kecil tidak butuh gerbang keamanan berlapis, tapi minimal satu gerbang yang benar-benar berhenti saat ada masalah.
Rangkuman yang bisa kamu jalankan sore ini
- Pindahkan semua API key dari file ke environment variable.
- Jalankan scanner, lalu sisihkan waktu untuk memilah temuan nyata dari noise.
- Cek apakah tiap agent punya identitas berbeda di sisi server MCP.
- Pastikan perubahan status data cuma bisa lewat endpoint transisi yang mengecek urutan sah.
- Buka CI-mu, cari continue-on-error di langkah scan, hapus.
Semua temuan di artikel ini ditemukan, dibuktikan dengan PoC lokal, dan diperbaiki dalam satu hari kerja tanpa tool berbayar. Kamu tidak butuh tim security buat mulai, cukup kebiasaan audit sendiri yang jujur.
Kalau mau lihat tool yang kupakai untuk scan MCP, cek mcpscan. Tulisan berikutnya rencananya tentang cara membangun harness deteksi yang bisa mengukur dirinya sendiri.
Top comments (0)