Checklist Keamanan AI Agent: Apa yang Perlu Dicek Sebelum Mendelegasikan Kerja
Checklist praktis untuk meninjau tool, prompt, batas data, permission, log, dan approval sebelum AI agent mengambil tindakan.
Terakhir diperbarui pada
AI agent bergerak dari chat menjadi sistem kerja. Ia bisa membaca file, membuka halaman, memanggil tool, membuat pull request, mengubah record, dan mengambil keputusan dalam beberapa langkah. Itu mengubah pertanyaan keamanan: bukan hanya “apakah model menjawab salah?”, tetapi “apa yang bisa dilakukan sistem jika ia salah memahami tugas atau percaya input yang salah?”
Checklist keamanan AI agent adalah review praktis sebelum tim mendelegasikan pekerjaan nyata. Ia melihat prompt, tool, sumber data, permission, memori, log, dan titik approval manusia.
Apa yang berubah
Risiko awal produk AI berpusat pada teks yang dihasilkan. Model bisa halusinasi, membocorkan konteks, atau mengikuti instruksi jahat. Agent menambah permukaan karena reasoning model digabungkan dengan sistem eksternal.
Workflow agent modern dapat mencakup file lokal, repository, ticket, database, tool API atau MCP, browser action, memori sesi, permission pengguna, dan perencanaan multi-langkah.
Karena itu, “prompt yang lebih baik” tidak cukup. Agent yang andal butuh batas tentang data mana yang dipercaya, tool mana yang boleh dipakai, aksi mana yang perlu konfirmasi, dan bagaimana manusia bisa mengaudit hasilnya.
Tiga layer risiko
| Layer | Risiko | Pertanyaan review |
|---|---|---|
| Instructions | Halaman, email, ticket, atau dokumen mencoba menimpa aturan tugas | Bisakah agent membedakan instruksi user dan konten tidak terpercaya? |
| Tools | Tool terlalu luas, dipalsukan, diracuni, atau dikombinasikan secara berbahaya | Apakah agent hanya melihat tool yang dibutuhkan tugas ini? |
| Data | Data tidak terpercaya dianggap sebagai metadata, asal file, output tool, atau konteks eksekusi | Bisakah sistem memisahkan data terpercaya dari data yang dikontrol pihak luar? |
Masalah barunya adalah agent tidak hanya membaca teks berbahaya. Ia bisa memakai teks itu untuk memilih tool, klik tombol, menulis kode, atau mengubah data bisnis.
Prompt injection, tool poisoning, dan data injection
| Risiko | Arti sederhana | Contoh |
|---|---|---|
| Prompt injection | Konten tidak terpercaya mencoba mengganti instruksi agent | Halaman web meminta agent membocorkan instruksi tersembunyi |
| Tool poisoning | Deskripsi atau metadata tool memengaruhi cara model memilih tool | Tool palsu mengklaim harus dipakai untuk semua data finansial |
| Agent data injection | Data jahat menyamar sebagai konteks terpercaya | Repository atau respons tool memanipulasi path file, asal data, atau konteks eksekusi |
Konten berbahaya tidak selalu terlihat seperti perintah. Ia bisa berupa link, label, nama tool, asal file, patch, atau respons terstruktur.
Checklist sebelum mendelegasikan kerja
| Cek | Default yang baik | Sinyal risiko |
|---|---|---|
| Scope tugas | Satu pekerjaan jelas dan satu kondisi sukses | Agent diminta menangani apa pun yang muncul |
| Batas data | Input terpercaya dipisah dari konten tidak terpercaya | Web, email, ticket, dan output tool dicampur |
| Inventory tool | Setiap tool punya owner, tujuan, dan permission | Agent melihat toolbox besar dan kabur |
| Permission | Read-only default; write action perlu approval | Agent bisa edit, delete, deploy, pay, atau email sendiri |
| Kredensial | Token scoped, bisa dirotasi, dan spesifik layanan | Token diteruskan terlalu luas |
| Approval manusia | Aksi eksternal atau destruktif berhenti untuk review | Agent bisa menjalankan aksi irreversible |
| Logging | Prompt, tool call, output, approval, dan aksi final disimpan | Hanya jawaban akhir yang terlihat |
| Test set | Ada contoh normal, berantakan, dan adversarial | Hanya demo happy path |
Aturan sederhana: jika aksi sulit dibatalkan, agent tidak boleh melakukannya tanpa approval manusia.
Review khusus MCP
Sebelum memakai MCP server dalam workflow agent, tanyakan:
- Siapa pemilik server, dan apakah implementasinya bisa dipercaya?
- Data dan aksi apa yang dibuka?
- Apakah nama dan deskripsi tool cukup jelas untuk dipilih model?
- Bisakah scope dipersempit per task atau user?
- Apakah authorization memakai consent per client dan redirect URI yang tepat?
- Apakah token diterbitkan untuk MCP server, bukan diteruskan membabi buta?
- Apakah client bisa memblokir request ke endpoint internal atau metadata?
- Apakah tool call tercatat cukup detail?
Setup MCP yang aman bukan yang punya tool paling banyak, tetapi yang hanya membuka tool yang dibutuhkan.
Checklist coding agent
Coding agent perlu review tambahan karena menyentuh repository, terminal, dependency, build script, dan CI.
| Sebelum mengizinkan | Cek |
|---|---|
| Edit file | Batasi working directory dan review patch |
| Command | Pisahkan command read-only dari install, delete, deploy, atau mutasi state |
| Dependency | Cek package name, registry, lockfile, dan postinstall script |
| Secrets | Jangan biarkan token masuk prompt, log, file, atau shell history |
| Pull request | Wajib test, diff review, dan provenance yang jelas |
| Input eksternal | Anggap issue, README, komentar, dan snippet web sebagai data tidak terpercaya |
Coding agent bisa produktif, tetapi review path harus tetap terlihat.
Apa yang bisa dilakukan tim kecil minggu ini
- Pilih satu workflow berulang, misalnya meringkas ticket atau draft PR.
- Jalankan dengan akses read-only dulu.
- Tulis semua tool yang bisa dipanggil agent.
- Hapus tool yang tidak dibutuhkan.
- Tambahkan approval untuk write action, pesan eksternal, pembelian, deployment, dan delete.
- Simpan raw prompt, tool call, output, dan aksi final.
- Uji satu contoh adversarial, misalnya ticket yang meminta agent mengabaikan aturan.
Jika agent tidak bisa menjelaskan data mana yang dipercaya dan tool mana yang dipakai, workflow belum siap otonom.
Update log
Jul 09 2026: Menerbitkan versi Indonesia dengan checklist keamanan agent, review MCP, risiko coding agent, FAQ, dan referensi.