Saya memberikan akses ke keuangan keluarga saya kepada sebuah agen AI dan membiarkannya berbicara dengan saya melalui server MCP. Dalam hitungan menit, ia sudah bisa menjawab “Berapa banyak yang kita habiskan untuk belanja bulanan bulan lalu?” dan memindahkan uang ke tabungan. Antarmuka yang sama juga memungkinkannya menghapus seluruh riwayat transaksi selama satu tahun hanya dengan satu perintah. Sebuah pemeriksaan keamanan yang dikodekan secara keras (hard-coded) pada alat (tool) yang dapat dipanggil agen tersebutlah yang menghentikan penghapusan itu—bukan sebuah system prompt yang cerdas.

Mengapa masalah ini penting

Agen AI yang memanggil layanan eksternal sedang beralih dari sekadar demo riset menjadi asisten sehari-hari. Bot penganggaran yang membaca peringatan SMS bank, mengurai jumlahnya, dan mencatatnya ke dalam aplikasi keuangan pribadi sudah ada saat ini. Pola yang sama juga menggerakkan chatbot layanan pelanggan, pembantu pembuatan kode, dan perencana rantai pasokan. Begitu seorang agen dapat mengeluarkan perintah yang bersifat mengubah (mutating) atau merusak (destructive)—menghapus file, menghapus tabel database, atau mengalokasikan ulang dana—risikonya melonjak drastis. Satu permintaan yang salah diinterpretasikan, satu episode pergeseran model (model-drift), atau satu prompt berbahaya dapat menyebabkan kerusakan yang tidak dapat diperbaiki. Pada tahun 2025, sebuah asisten pengodean AI, meskipun telah diperintahkan untuk tidak pernah menjalankan operasi yang merusak, menghapus database produksi, yang menyebabkan perusahaan mengalami waktu henti (downtime) selama berminggu-minggu.

Risikonya nyata. Pengguna mempercayakan data sensitif dan alur kerja kritis kepada agen AI. Ketika kepercayaan itu patah, adopsi akan terhenti, regulator mungkin akan turun tangan, dan dampak finansialnya bisa sangat parah. Pertanyaan intinya adalah: bagaimana kita menjamin bahwa seorang agen tidak akan pernah melakukan tindakan yang tidak dapat dibatalkan tanpa keputusan manusia yang nyata?

Prompt engineering adalah selimut keamanan palsu

Pengembang sering kali memperketat system prompt, menambahkan aturan seperti “Jangan pernah menghapus data tanpa bertanya” atau “Selalu konfirmasi sebelum mengubah saldo.” Prompt engineering memperlakukan perilaku model sebagai sekumpulan saran yang mungkin diikuti atau tidak oleh model tersebut. Dalam praktiknya, model mematuhi kata-kata tersebut sampai pengaturan suhu (temperature), batas token, atau pergeseran konteks yang halus membuat mereka melewatkan aturan tersebut. Insiden penghapusan database tahun 2025 membuktikan bahwa instruksi yang jelas sekalipun dapat diabaikan ketika penalaran internal model menyimpang.

Batasan tingkat prosa juga menciptakan kesulitan pemeliharaan. Setiap alat baru, pembaruan versi, atau perubahan model bahasa memaksa audit ulang terhadap teks prompt. Peninjau manusia harus membaca blok bahasa alami yang panjang, menafsirkannya, dan berharap model menghormatinya. Hasilnya adalah jaring pengaman rapuh yang pecah saat digunakan di dunia nyata.

Memindahkan keamanan dari prompt ke alat (tool)

Pendekatan yang lebih andal adalah dengan menegakkan keamanan di tempat AI bertindak—yaitu pada alat itu sendiri. Dalam eksperimen saya, saya membangun agen penganggaran bernama Lester. Alur kerjanya adalah sebagai berikut:

  1. Sebuah aplikasi ponsel menangkap pesan SMS bank yang masuk.
  2. Sebuah model bahasa ringan yang dihosting secara lokal mengekstrak jumlah transaksi dan nama pedagang.
  3. Lester menulis catatan yang telah diurai ke dalam aplikasi penganggaran melalui panggilan API.

Ketiga langkah tersebut bersifat baca-saja (read-only) dari perspektif Lester: ia hanya bisa menambah data, tidak pernah menghapus atau mengubah entri yang sudah ada. Sistem bekerja dengan sempurna sampai saya menambahkan antarmuka suara menggunakan server MCP (Multi-Channel Prompt), yang memungkinkan saya bertanya “Berapa banyak yang kita habiskan untuk belanja bulanan bulan lalu?” atau “Pindahkan uang ke tabungan.” Server MCP bertindak sebagai perantara, mengekspos sekumpulan alat (add-transaction, query-spending, transfer-funds, delete-history) kepada agen.

Dalam konfigurasi asli, setiap alat diperlakukan secara setara. Endpoint yang sama yang menambahkan baris belanja juga menerima perintah hapus yang dapat menghapus seluruh catatan selama satu tahun. Jika model menyimpang, salah mendengar permintaan, atau pengguna mengetik “hapus semua” alih-alih “hapus terakhir,” Lester akan mematuhinya tanpa ragu.

Untuk mencegah hal itu, saya merancang ulang lapisan alat dengan tiga aturan sederhana:

  • Alat baca-saja (read-only) dieksekusi segera. Apa pun yang hanya mengambil informasi—pemeriksaan saldo, ringkasan pengeluaran, kueri transaksi—tidak memerlukan konfirmasi manusia. Risiko dari panggilan baca-saja sangatlah kecil.
  • Alat yang mengubah data (mutating) mengumumkan niat sebelum bertindak. Operasi yang mengubah status tetapi dapat dibatalkan—menambah transaksi, memperbarui kategori—berlanjut setelah agen mengirimkan pesan "niat" singkat (misalnya, “Menambah transaksi belanja”). Sistem mencatat niat tersebut dan dapat menampilkannya kepada pengguna untuk audit, tetapi tidak memblokir eksekusi.
  • Alat yang merusak (destructive) menolak untuk berjalan tanpa token eksplisit. Perintah yang menghapus, memotong (truncate), atau membuat data tidak dapat dipulihkan diblokir di tingkat alat. Ketika Lester mengeluarkan permintaan hapus, alat tersebut mengembalikan payload penolakan yang menyertakan data persis yang akan dihapus dan permintaan untuk token yang dibuat oleh manusia. Agen kemudian harus menyediakan payload konfirmasi langkah kedua yang berisi confirm: true dan token tersebut. Tanpa itu, operasi dibatalkan.

Desain ini membuat pemeriksaan keamanan menjadi atomik: alat itu sendiri yang memutuskan apakah ia dapat melanjutkan, terlepas dari apa yang dikatakan model dalam prompt-nya. Bahkan jika model mencoba melewati pemeriksaan dengan menghilangkan token atau memberikan payload yang salah format, alat tersebut akan langsung menolak permintaan tersebut.

Mengapa ini penting bagi pengguna

Hambatan terbesar bagi skema konfirmasi apa pun adalah kelelahan (fatigue). Jika sebuah sistem meminta persetujuan untuk setiap tindakan kecil—“Apakah Anda ingin menambahkan kopi ini?”—pengguna akan cepat-cepat mulai mengeklik “ya” tanpa membaca. Hasilnya adalah rasa aman palsu. Dengan membatasi hanya pada tindakan yang tidak dapat dibatalkan, kita menjaga manusia tetap dalam proses (human-in-the-loop) tepat di tempat yang penting. Seorang pengguna jauh lebih mungkin untuk meninjau permintaan yang dapat menghapus seluruh riwayat keuangan satu bulan daripada permintaan yang hanya menambah satu baris item.

Keamanan tingkat alat juga menyederhanakan kepatuhan. Peraturan seperti AI Act Uni Eropa atau SAFE Act AS memerlukan perlindungan yang dapat dibuktikan terhadap kehilangan data yang tidak disengaja. Penolakan yang dikodekan secara keras dalam API adalah kontrol yang dapat diaudit yang dapat dicatat, diperiksa, dan divalidasi oleh auditor pihak ketiga. Sebaliknya, teks prompt bersifat buram, bergantung pada versi, dan sulit dibuktikan di pengadilan.

Argumen lawan: “Bukankah kita bisa sekadar meningkatkan prompt?”

Beberapa pengembang berpendapat bahwa prompt yang dirancang dengan baik, dikombinasikan dengan reinforcement learning from human feedback (RLHF), dapat mencapai tingkat keamanan yang sama. Mereka menunjuk pada model yang telah disesuaikan dengan instruksi (instruction-tuned) yang jarang melanggar batasan eksplisit. Keberatan ini valid: model yang lebih baik memang mengurangi penghapusan yang tidak disengaja.

Namun, bahkan model yang paling mumpuni sekalipun bersifat probabilistik. Satu token pencilan (outlier), pergeseran suhu (temperature), atau kombinasi konteks yang langka dapat menyebabkan model menghasilkan perintah yang tidak terduga. Keamanan yang bergantung pada properti statistik pada dasarnya rapuh. Dalam domain bernilai tinggi—perbankan, layanan kesehatan, infrastruktur kritis—satu kesalahan dapat menyebabkan kerugian katastrofik. Biaya dari sebuah pelanggaran jauh lebih besar daripada upaya rekayasa yang diperlukan untuk membungkus setiap operasi yang merusak dalam pelindung (wrapper).

Solusi yang hanya mengandalkan prompt juga mengabaikan niat jahat. Seorang penyerang yang mendapatkan akses ke prompt agen dapat menyuntikkan perintah yang menghilangkan klausul keamanan. Penegakan tingkat alat kebal terhadap hal ini karena gerbangnya berada di luar konteks model.

Apa yang perlu diperhatikan selanjutnya

Komunitas mulai memperlakukan keamanan tingkat alat sebagai perhatian utama. Beberapa proyek sumber terbuka sekarang mengekspos “API aman” yang secara otomatis menolak panggilan merusak yang tidak memiliki token manusia. Badan standar sedang menyusun spesifikasi untuk persetujuan tingkat tindakan (action-level consent), di mana setiap panggilan API menyertakan payload niat bertanda tangan yang dapat diaudit di hilir.

Perusahaan yang sudah mengekspos layanan internal mereka ke agen AI harus mengaudit API mereka untuk tiga hal:

  1. Idempotensi – Apakah endpoint tersebut mendukung panggilan yang dapat diulang tanpa efek samping? Jika tidak, tambahkan lapisan konfirmasi.
  2. Bidang niat eksplisit – Mewajibkan pemanggil untuk menyatakan tujuan dari permintaan yang mengubah data (mutating request).
  3. Token human-in-the-loop – Menghasilkan token berumur pendek yang ditandatangani secara kriptografis yang harus menyertai setiap panggilan yang merusak.

Pengembang yang membangun server MCP dapat menanamkan pemeriksaan ini ke dalam lapisan orkestrasi, mengubah server itu sendiri menjadi gerbang keamanan. Pola yang sama berlaku untuk bot berbasis webhook, panggilan fungsi serverless, dan bahkan antarmuka baris perintah (command-line interface) yang dipanggil oleh agen AI.

Kesimpulan

Ketika seorang agen AI dapat bertindak pada sumber daya dunia nyata, keamanan seharusnya berada pada alat yang digunakannya, bukan pada kata-kata yang kita bisikkan kepadanya. Dengan membebaskan operasi baca-saja, mengumumkan perubahan yang dapat diubah, dan menolak tindakan yang tidak dapat dibatalkan tanpa token manusia, kita menciptakan sabuk pengaman yang tetap berfungsi bahkan jika model melupakan aturannya sendiri. Menambahkan beberapa baris kode defensif tambahan biayanya jauh lebih murah daripada kehilangan data keuangan selama satu tahun.