10 Pola Prompt Berbahaya di Claude Code | Yang Harus Dihindari dan Alternatif Aman

Apakah Anda menulis prompt dengan pikiran “pasti dia mengerti maksudku”? Claude Code menjalankan instruksi secara harfiah. Instruksi yang samar atau berbahaya menghasilkan hasil yang tidak diinginkan.

Artikel ini membahas 10 pola prompt berbahaya yang telah menyebabkan insiden nyata, beserta alternatif aman untuk masing-masing. Jika Anda mengenali salah satu pola ini setelah membaca, ubah segera.

---

Pola 1: “Baca semua dan pahami seluruh proyek”

Mengapa berbahaya

❌ "Baca seluruh repository ini dan pahami sebelum mengimplementasikan"

Menjalankan ini pada repository dengan ratusan file menyebabkan konteks meledak. Puluhan ribu token dikonsumsi dan pemrosesan berhenti dengan error Prompt is too long. Jika berhenti di tengah pembacaan, implementasi dilakukan berdasarkan pemahaman yang tidak lengkap.

Selain itu, jika ada file yang mengandung .env atau kunci rahasia, semuanya dimuat ke dalam konteks.

Alternatif aman

✅ "Periksa struktur direktori src/api/ dan baca hanya file yang berkaitan dengan auth"
✅ "Baca hanya package.json dan README terlebih dahulu untuk mendapatkan gambaran umum proyek"
✅ "Gunakan Grep untuk menemukan file terkait autentikasi sebelum membacanya"

Poin kunci: Batasi secara eksplisit cakupan apa yang harus dibaca. Claude Code akan mencoba membaca secara luas jika tidak ditentukan.

---

Pola 2: “Jika ada error, retry otomatis”

Mengapa berbahaya

❌ "Jika ada error saat memanggil API eksternal, retry otomatis sampai berhasil"

Jika layanan eksternal sedang down, ia akan terus menghantam API dalam loop tak terbatas. Ada insiden nyata dengan puluhan ribu panggilan dalam satu jam, dengan tagihan membengkak hingga jutaan rupiah. Ini terutama umum terjadi pada batch job malam yang berjalan tanpa diketahui hingga pagi.

Alternatif aman

✅ "Jika ada error, retry maksimal 3 kali.
   Tunggu 1 detik sebelum percobaan ke-1, 4 detik sebelum ke-2, 16 detik sebelum ke-3.
   Jika ketiganya gagal, catat error dan hentikan pemrosesan"

✅ "Gunakan kode berikut untuk retry:
   withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 })"

---

Pola 3: “Sambungkan langsung ke DB produksi dan periksa”

Mengapa berbahaya

❌ "Sambungkan ke DB produksi di DATABASE_URL, periksa jumlah pengguna, lalu lakukan perbaikan"

Yang dimulai sebagai “hanya memeriksa” membawa risiko bahwa query perbaikan selanjutnya dieksekusi terhadap DB produksi. Jika setelah SELECT secara tidak sengaja ada DELETE atau UPDATE, data produksi hilang. Menghubungkan ke produksi dengan mudah memicu operasi di luar cakupan yang dimaksud.

Alternatif aman

✅ "Sambungkan ke DB pengembangan (DATABASE_URL_DEV) dan periksa jumlah pengguna.
   Jangan terhubung ke produksi"

✅ "Generate query-nya tapi jangan dieksekusi.
   Saya akan meninjaunya dan menjalankannya sendiri"

✅ Di CLAUDE.md:
"Mengeksekusi query terhadap DATABASE_URL produksi dilarang.
 Verifikasi dulu di staging, eksekusi hanya setelah persetujuan pengguna"

---

Pola 4: Menempel kunci API langsung di prompt

Mengapa berbahaya

❌ "Gunakan QIITA_TOKEN=abc123def456 untuk posting ke Qiita"
❌ "Gunakan sk-ant-api03-xxxxx untuk memanggil Anthropic API"

Konten yang ditulis dalam prompt disimpan sebagai riwayat percakapan. Diteruskan apa adanya saat mendelegasikan ke sub-agent. Tetap ada di log di bawah direktori lokal .claude/ dan dapat secara tidak sengaja bocor ke luar melalui alat backup atau berbagi kode.

Alternatif aman

✅ "Gunakan QIITA_TOKEN dari .env untuk menjalankan scripts/qiita-publish.mjs"
   ← Nilai token hanya ada di .env; hanya nama variabel yang masuk ke prompt

✅ Baca dari variabel lingkungan di script Anda:
   const token = process.env.QIITA_TOKEN;
   if (!token) throw new Error("QIITA_TOKEN belum diset");

---

Pola 5: “Selesaikan konflik dan push ke produksi”

Mengapa berbahaya

❌ "Ada konflik dengan branch main. Selesaikan dan push ke produksi"

git push --force mungkin dipilih sebagai cara untuk “menyelesaikan konflik.” Ini berisiko menghapus commit rekan tim. Selain itu, “push ke produksi” dapat mengakibatkan push langsung yang melewati CI/CD.

Alternatif aman

✅ "Periksa konflik dengan main dan usulkan strategi merge.
   Tunggu persetujuan saya sebelum benar-benar merge dan push"

✅ Di CLAUDE.md:
"git push --force dilarang.
 Jika force diperlukan, gunakan --force-with-lease dan konfirmasi dengan pengguna"

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ]
  }
}

---

Pola 6: “Hapus semua file lama dan bersihkan”

Mengapa berbahaya

❌ "Hapus semua file di dist/, .cache/, dan file log lama untuk membersihkan"

Karena “lama” bersifat ambigu, file yang diperlukan mungkin terhapus. Khususnya, direktori .cache/ dapat berisi data kritis yang spesifik untuk OS atau alat tertentu. Menentukan beberapa direktori sekaligus menghasilkan rm -rf dist .cache logs/, yang dapat menjalar ke jalur yang tidak diinginkan.

Alternatif aman

✅ "Hapus hanya isi direktori site/dist/.
   Biarkan direktorinya sendiri tetap ada. Jangan sentuh direktori lain"

✅ "Tunjukkan daftar file yang akan dihapus sebelum menghapusnya agar saya bisa konfirmasi.
   Hapus setelah saya setujui"

---

Pola 7: “Setujui semua secara otomatis dan jalankan sekaligus”

Mengapa berbahaya

❌ "Lewati semua konfirmasi di tengah dan jalankan sampai akhir"
❌ "Jalankan dengan opsi --dangerously-skip-permissions"

Alur persetujuan adalah mekanisme keamanan. Melewatinya membiarkan Claude Code melanjutkan dengan apa yang dinilai sebagai “paling efisien.” Itu bisa berarti rm -rf, force push, atau penulisan ke DB produksi—semua tanpa konfirmasi.

Alternatif aman

✅ "Daftar langkah-langkah untuk tugas ini terlebih dahulu.
   Setelah saya setujui, jalankan satu langkah sekaligus dan konfirmasi hasilnya di setiap langkah"

✅ Untuk otomasi, hanya izinkan operasi yang terpercaya:
   "allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]

---

Pola 8: “Update migrasi dan bersihkan DB”

Mengapa berbahaya

❌ "File migrasi berantakan. Rapikan dan bawa ke keadaan terbaru"

“Merapikan” dapat ditafsirkan sebagai menghapus file migrasi lama. Jika riwayat migrasi hilang, menyiapkan lingkungan baru atau rollback menjadi tidak mungkin. Jika perintah seperti migrate reset dieksekusi, data produksi bisa terhapus.

Alternatif aman

✅ "Tampilkan daftar file migrasi dan hanya tunjukkan duplikat atau masalah yang ada.
   Jangan buat perubahan apapun"

✅ "Periksa migrasi yang belum diterapkan dan tampilkan SQL yang akan dijalankan.
   Eksekusi setelah saya setujui"

✅ Di CLAUDE.md:
"Jangan hapus file migrasi.
 Selalu minta konfirmasi pengguna sebelum menjalankan migrasi yang mengandung ALTER/DROP"

---

Pola 9: “Update semua package ke versi terbaru”

Mengapa berbahaya

❌ "Package npm sudah usang. Update semuanya ke versi terbaru"

npm update atau npm install package@latest dapat menaikkan versi major. Jika ada breaking changes, build lokal mungkin berhasil tetapi layanan bisa mati setelah deployment ke produksi. Kerusakan dependensi secara cascading juga umum terjadi.

Alternatif aman

✅ "Jalankan npm outdated dan tampilkan daftar package yang bisa diupdate.
   Saya akan tinjau secara terpisah apapun yang menaikkan versi major"

✅ "Update hanya package dengan kerentanan keamanan (terdeteksi oleh npm audit)"

✅ "Update hanya react dan next.js ke versi minor terbaru.
   Jangan naikkan versi major"

---

Pola 10: “Deploy dulu, test belakangan”

Mengapa berbahaya

❌ "Saya akan tulis test nanti, deploy dulu sekarang"
❌ "CI lambat, lewati dengan --no-verify dan push"

Test dan CI bukan “lambat”—mereka “melindungi Anda.” Pola terburuk adalah menemukan bug di produksi untuk pertama kalinya setelah melewatinya. --no-verify menonaktifkan segalanya termasuk git hooks, sehingga secret scanning dan lint juga dilewati.

Alternatif aman

✅ "Tulis test dulu, dan deploy setelah lulus.
   Meskipun coverage tidak cukup, jalur utama sudah OK"

✅ "Selidiki mengapa CI lambat dan percepat dengan memanfaatkan cache.
   Jangan dilewati"

✅ Di CLAUDE.md:
"--no-verify dilarang.
 Jangan pernah gunakan cara apapun untuk melewati CI"

---

Ringkasan: 3 Prinsip Menulis Prompt yang Aman

Prinsip 1: Tentukan cakupan secara eksplisit “Semua”, “seluruh”, dan “semuanya” adalah kata-kata berbahaya. Tentukan dengan tepat apa yang harus dibaca, diubah, dan dihapus.

Prinsip 2: Pertahankan langkah konfirmasi Sisipkan “periksa”, “usulkan”, atau “tampilkan daftar” sebelum “jalankan”. Terutama untuk operasi yang mempengaruhi produksi.

Prinsip 3: Jangan pernah memasukkan rahasia ke dalam prompt Kunci API, kata sandi, dan string koneksi masuk ke .env. Hanya nama variabel yang masuk ke prompt.

Frasa berbahaya	Alternatif aman
”Baca semua"	"Baca hanya direktori [X]"
"Retry otomatis"	"Retry maksimal 3 kali, lalu berhenti"
"Sambungkan ke DB produksi"	"Verifikasi di DB dev, saya yang jalankan di produksi"
"Hapus semua dan bersihkan"	"Hapus hanya [X], tampilkan daftarnya dulu"
"Jalankan semuanya sekaligus"	"Biarkan saya konfirmasi langkah-langkahnya dulu, lalu lanjutkan”

Claude Code hanya mengikuti instruksi—tidak ada niat jahat. Bahayanya ada pada orang yang memberikan instruksi samar. Membangun kebiasaan menulis instruksi yang spesifik dan jelas cakupannya adalah jalan tercepat untuk mencegah insiden.

Artikel Terkait

• 7 Insiden Produksi Nyata dengan Claude Code dan Prosedur Pemulihan Lengkap
• Panduan Lengkap Praktik Keamanan Terbaik Claude Code
• Panduan Lengkap Izin Claude Code

Referensi

• Panduan Keamanan Resmi Claude Code
• OWASP LLM Application Security