Checklist Keamanan Aplikasi AI: 15 Poin Cek Sebelum Rilis

Tim kecil jarang melewatkan peluncuran karena malas. Mereka melewatkannya karena tidak tahu apa yang harus diperiksa — dan tidak ada yang mengingatkan. Halaman ini adalah checklist ringkas untuk dipakai sehari sebelum aplikasi berbasis AI Anda dibuka ke publik.

Setiap poin ditandai: [otomatis] bila bisa diperiksa alat, [manual] bila butuh keputusan manusia. Semua poin manual tetap harus dikerjakan — tidak ada alat yang bisa menggantikannya.

Kelompok 1 — Kode & Rahasia

1. [otomatis] Tidak ada kunci API di kode atau riwayat Git. Termasuk kunci model AI, layanan pembayaran, dan database. Rahasia yang pernah ter-commit harus dianggap bocor — rotasi, bukan sekadar dihapus dari file terbaru.
2. [otomatis] File .env tidak ikut terkirim ke repositori publik. Periksa riwayat, bukan hanya kondisi sekarang.
3. [manual] Rahasia produksi berbeda dari yang dipakai saat pengembangan. Kunci yang muncul di dokumentasi internal atau catatan tim sebaiknya dianggap perlu diganti.

Kelompok 2 — Dependensi & Konfigurasi

4. [otomatis] Dependensi tidak punya kerentanan yang sudah diketahui publik. Perlu file lock (package-lock/pnpm-lock/requirements) — tanpa itu pemeriksaan tidak bisa dipertanggungjawabkan.
5. [otomatis] Mode debug mati, dan alamat CORS tidak dibuka untuk semua domain. Pola ini muncul saat penyalinan konfigurasi dari tahap pengembangan.
6. [otomatis] Header keamanan dasar dan sertifikat TLS aktif pada domain produksi. Termasuk pengalihan dari HTTP ke HTTPS.

Kelompok 3 — Lapisan LLM (paling sering terlewat)

7. [otomatis] Diuji dengan skenario prompt injection dan jailbreak. Bukan sekadar mencoba satu-dua prompt, tetapi pola serangan yang lazim dipakai. Ini pemeriksaan yang tidak tersedia di pemindai kode biasa.
8. [otomatis] System prompt tidak bisa diambil keluar oleh pengguna. Kebocoran instruksi internal memudahkan serangan lanjutan.
9. [manual] Tool/aksi yang dipegang agen hanya sebatas yang diperlukan. Jika tool tidak memiliki izin menghapus, perintah "hapus semua data" akan gagal — bukan karena model menolak, tetapi karena haknya memang tidak ada. Ini pertahanan paling efektif dengan biaya paling murah.
10. [manual] Output model divalidasi sebelum dipakai. Balasan model jangan langsung dijadikan perintah, tautan, atau kueri tanpa pemeriksaan.
11. [manual] Ada batas biaya dan laju permintaan. Tanpa itu, satu penyalahgunaan bisa berbiaya besar dan membuat layanan tumbang.

Kelompok 4 — Akses & Data

12. [manual] Kebijakan akses data diperiksa dari dalam platform Anda. Jika Anda memakai layanan database terkelola, jalankan pemeriksa bawaannya (misalnya advisor keamanan) untuk memastikan tidak ada tabel yang dapat dibaca tanpa batasan. Pemeriksaan ini hanya valid dari sisi platform — alat luar tidak bisa membuktikannya.
13. [manual] Setiap data milik pengguna hanya bisa diakses pemiliknya. Uji minimal dua hal: ambil satu ID data milik orang lain dan pastikan permintaan gagal; lalu pastikan endpoint internal tidak bisa dipanggil dari luar.
14. [manual] Percobaan gagal tercatat. Tanpa catatan, Anda tidak akan tahu ada yang sedang mencoba menembus — dan tidak bisa menjawab klien saat mereka bertanya.

Yang Tidak Bisa Diperiksa Alat Mana Pun

Dua hal ini sebaiknya Anda tuliskan secara jujur di catatan rilis internal, agar tidak berubah menjadi klaim berlebih:

• Kebenaran rancangan logika bisnis. Alat bisa melihat pola berisiko, tetapi tidak bisa menilai apakah aturan diskon, kuota, atau alur persetujuan Anda dapat disalahgunakan.
• Bukti bahwa sebuah celah benar-benar bisa dieksploitasi. Membuktikannya memerlukan pengujian aktif dengan izin pemilik sistem. Hasil pemindaian bersifat indikatif dan tetap butuh penilaian manusia.

Cara Memakainya dalam Satu Hari

1. Jalankan pemeriksaan otomatis lebih dulu (poin 1-8) — cepat dan hasilnya langsung terlihat.
2. Perbaiki temuan berisiko tinggi sebelum menyentuh yang lain. Jangan mulai dari yang mudah.
3. Kerjakan poin manual (9-15) bersama orang yang menulis kode atau yang mengelola data.
4. Simpan hasilnya sebagai satu berkas: tanggal, versi yang diuji, temuan, status, dan area yang belum diuji.

Kesimpulan

Keamanan sebelum peluncuran tidak menuntut tim besar atau anggaran besar. Yang dibutuhkan hanya urutan yang jelas: rahasia, dependensi, perilaku model, lalu kontrol akses — dijalankan sebelum rilis, bukan sesudah ada masalah.

AISG membantu bagian yang paling teknis dan paling sering terlewat: memeriksa rahasia dan dependensi pada kode, menguji perilaku LLM terhadap serangan prompt, lalu merangkumnya menjadi laporan yang bisa dibaca tim non-teknis. Pemindaian kode berjalan lokal — kode Anda tidak diunggah.