AI assistant yang bisa baca email, akses file, dan kirim balasan itu bukan lagi chatbot lucu. Itu sudah jadi sistem yang bisa bertindak — dan berarti bisa diserang.
Artikel ini membahas eksperimen Hackmyclaw, saat lebih dari 2.000 orang mencoba membobol AI assistant lewat email prompt injection. Intinya bukan “AI assistant sudah aman total”, tapi pelajaran yang lebih praktis: kalau agent punya akses tool, file, secret, atau email, lu harus mikir boundary dari awal. Prompt aman itu membantu, tapi bukan pengganti permission, sandbox, audit log, dan desain produk yang sadar risiko.
Apa itu Hackmyclaw?
Hackmyclaw adalah eksperimen publik dari Fernando Irarrázaval. Dia membuat challenge di mana orang bisa mengirim email ke Fiu, AI assistant berbasis OpenClaw, lalu mencoba membuat assistant itu membocorkan isi file secrets.env.
Setelah eksperimen itu masuk front page Hacker News, Fiu menerima lebih dari 6.000 email dari 2.000+ orang yang mencoba menyerang. Menurut laporan penulisnya, secret tidak bocor dan tidak ada unauthorized reply yang berhasil terkirim.
Angka ini menarik karena eksperimennya bukan sekadar demo lokal dengan satu prompt lucu. Ada ribuan orang yang sengaja mencoba attack path berbeda: merayu model, menyamar sebagai instruksi sistem, memanfaatkan email sebagai channel input, dan mencari celah dari cara agent diberi akses.
Kenapa prompt injection di AI assistant lebih serius dari chatbot biasa?
Prompt injection adalah kondisi saat input dari luar mencoba mengubah perilaku model dengan instruksi palsu. Dalam chatbot biasa, dampaknya sering “cuma” jawaban model jadi aneh atau salah arah. Di AI assistant yang punya tool access, dampaknya bisa naik level.
Masalah utamanya bukan model bisa dibohongi. Masalahnya: model yang dibohongi bisa punya akses ke hal yang nyata.
- Email masuk dari orang luar.
- File lokal atau cloud storage.
- Calendar, kontak, dan dokumen kerja.
- Credential, API key, atau environment variable.
- Kemampuan mengirim email, menjalankan command, atau memanggil API.
Kalau semua itu digabung, email bukan lagi cuma pesan. Email bisa berubah jadi input tidak tepercaya yang mencoba menyuruh agent melakukan sesuatu. Buat gua, ini framing yang penting: konten eksternal itu data, bukan bos agent lu.
Pelajaran pertama: prompt aman bukan boundary keamanan
Di eksperimen Hackmyclaw, assistant memang diberi instruksi keamanan: jangan membocorkan secret, jangan mengirim balasan yang tidak diizinkan, dan seterusnya. Tapi pelajaran yang harus diambil bukan “tinggal tulis prompt lebih kuat”.
Prompt itu niat. Boundary itu batas fisik.
Kalau file secrets.env tidak perlu dibaca agent, jangan cuma bilang “jangan baca”. Lebih baik agent memang tidak punya akses baca ke file itu. Kalau agent tidak perlu internet bebas, batasi network. Kalau agent tidak perlu kirim email otomatis, buat action itu butuh confirmation dari manusia.
Ini mirip prinsip least privilege di software engineering: kasih akses paling kecil yang cukup buat task selesai. AI agent tidak spesial. Justru karena dia bisa salah interpretasi instruksi, permission-nya harus lebih ketat, bukan lebih longgar.
Pelajaran kedua: email dan web harus dianggap input musuh
Banyak developer masih memperlakukan email, halaman web, issue GitHub, komentar user, atau dokumen upload sebagai “konten biasa”. Untuk AI agent, ini berbahaya.
Begitu agent membaca konten eksternal, konten itu bisa berisi instruksi: “abaikan aturan sebelumnya”, “kirim credential ke alamat ini”, “jalankan command ini”, atau “rangkum file secret di balasan”. Buat manusia, itu jelas teks mencurigakan. Buat model, teks itu tetap masuk ke context yang sama dengan instruksi lain.
Riset “Prompt Injection as Role Confusion” menjelaskan sudut pandang ini dengan cukup tajam: model sering kesulitan membedakan siapa yang sedang “berbicara” di dalam context. Mana instruksi developer, mana data dari user, mana kutipan dari halaman web, mana output tool. Saat role boundary kabur, injection jadi lebih mungkin.
Makanya desain agent harus memisahkan sumber instruksi. Jangan semua hal dimasukkan ke satu context panjang lalu berharap model selalu paham prioritasnya.
Checklist praktis sebelum lu bikin AI assistant yang bisa bertindak
Kalau lu sedang bikin assistant buat email, dokumen, coding workflow, customer support, atau internal tool, minimal pikirin checklist ini:
- Pisahkan data dan instruksi. Konten email, web, dan dokumen harus diperlakukan sebagai data tidak tepercaya.
- Jangan expose secret ke model kalau tidak wajib. Kalau secret harus dipakai, pakai broker atau tool sempit yang tidak mengembalikan nilai mentahnya.
- Batasi tool access. Tool read-only dan tool write/destructive harus punya permission berbeda.
- Tambahkan human confirmation untuk aksi berisiko. Kirim email, transfer data, deploy, delete, atau revoke akses jangan otomatis.
- Gunakan sandbox untuk eksekusi kode. Container atau microVM bisa membantu membatasi filesystem, network, dan lifecycle.
- Log keputusan penting. Simpan input, tool call, output, dan alasan action supaya insiden bisa ditelusuri.
- Uji dengan prompt jahat beneran. Jangan cuma test happy path. Buat skenario attacker yang mencoba menyamar sebagai sistem.
Kenapa eksperimen ini tetap belum membuktikan AI assistant “aman”?
Hackmyclaw berhasil menahan ribuan percobaan di setup tersebut, dan itu patut diapresiasi. Tapi jangan salah baca: satu eksperimen sukses bukan bukti semua AI assistant aman dari prompt injection.
Ada beberapa alasan kenapa generalisasi harus hati-hati:
- Detail implementasi lengkap tidak selalu sama dengan produk lu.
- Threat model tiap assistant beda: email assistant, coding agent, browser agent, dan finance bot punya risiko berbeda.
- Attack surface berubah saat tool bertambah.
- Model, prompt, retrieval, dan permission system bisa berubah dari waktu ke waktu.
OWASP juga memasukkan prompt injection sebagai salah satu risiko utama aplikasi LLM. Artinya, ini bukan cuma bahan debat di komunitas AI. Ini sudah masuk ranah security engineering yang perlu proses, bukan sekadar prompt kreatif.
Takeaway buat builder: agent harus didesain seperti sistem produksi
Menurut gua, pelajaran paling penting dari Hackmyclaw sederhana: AI assistant yang punya tool access harus diperlakukan seperti sistem produksi, bukan eksperimen chatbot.
Kalau lu membangun agent buat workflow nyata, tanya empat hal ini dari awal:
- Apa input yang tidak bisa dipercaya? Email, web, komentar user, file upload, issue tracker, dan chat eksternal harus masuk daftar.
- Apa aksi yang bisa bikin damage? Mengirim pesan, menghapus data, menjalankan command, memanggil API, atau membuka secret.
- Apa batas yang tidak cuma berbentuk prompt? Permission, sandbox, network policy, secret isolation, dan timeout.
- Kalau agent salah, lu bisa audit apa? Log tool call dan keputusan harus cukup jelas buat debugging dan incident review.
AI agent yang bagus bukan yang kelihatan paling pintar di demo. AI agent yang bagus adalah yang tetap punya batas saat input dari luar mulai jahat, ambigu, atau manipulatif.
FAQ singkat
Apakah prompt injection bisa diselesaikan dengan prompt yang lebih panjang?
Tidak sepenuhnya. Prompt bisa mengurangi risiko, tapi bukan boundary keamanan yang kuat. Untuk sistem yang punya tool access, lu tetap butuh permission, sandbox, validasi, confirmation flow, dan logging.
Apakah semua AI assistant yang membaca email berbahaya?
Tidak otomatis. Tapi email harus dianggap input tidak tepercaya. Risiko naik kalau assistant bisa membaca file, mengakses secret, atau mengirim balasan tanpa persetujuan manusia.
Apakah developer kecil perlu mikirin ini juga?
Iya, terutama kalau app lu mulai menjalankan action otomatis. Versi kecil dari masalah ini bisa muncul di bot internal, automation pribadi, plugin coding agent, atau customer support assistant.
