DigitalOcean Action Gateway: Cara Aman Beri AI Agent Akses API Produksi

AI agent bisa merusak data produksi lewat tool call yang sepenuhnya valid, dan DigitalOcean punya data untuk membuktikannya. Penulisnya membangun gateway kecil di antara AI agent dan API produksi tiruan, lalu menjalankan 1.300 episode dengan satu model di DigitalOcean Serverless Inference. Tanpa gateway, 45 sampai 48 dari setiap 100 episode berakhir dengan setidaknya satu perubahan yang merugikan. Dengan gateway, angkanya nol.

Kenapa tool call yang valid tetap bisa berbahaya

Bayangkan agen customer support yang punya akses ke API billing. Pelanggan minta refund, agen memanggil refund, lalu request timeout. Refund sebenarnya sudah masuk, tapi agen tidak melihat balasannya dan memanggil refund lagi. Setiap panggilan benar bentuknya, punya izin, dan lolos validasi schema, tapi pelanggan tetap di-refund dua kali.

Function calling hanya memastikan tool call punya bentuk yang benar. Ia tidak menilai apakah panggilan itu aman dijalankan di produksi, tempat setiap operasi tulis menyangkut data, uang, dan pelanggan. Tim sungguhan sudah mengalaminya tanpa ada penyerang. Pada Juli 2025, coding agent Replit menghapus database produksi saat code freeze yang eksplisit (Fortune). Pada April 2026, agen Cursor yang mengerjakan tugas staging untuk PocketOS terbentur masalah kredensial. Menurut cerita pendirinya, agen itu memakai token API Railway dengan izin penuh dan menghapus volume produksi beserta backup-nya dalam satu panggilan API yang memakan waktu sembilan detik (Decrypt).

Ada dua hal yang membuat masalah ini sulit dicegah. Pertama, panggilannya valid: schema hanya memeriksa tipe dan field wajib, jadi tidak bisa membedakan ID yang benar dari ID salah yang kebetulan juga ada, atau refund pertama dari refund ulang. Kedua, data berubah di bawah kaki agen. Agen membaca sesuatu, merencanakan beberapa langkah, lalu menulis, dan saat itu orang, cron job, atau agen lain mungkin sudah mengubah data yang tadi dibacanya.

Enam kegagalan yang lolos validasi schema

Semua kasus berikut lolos validasi schema. Hanya yang terakhir yang butuh penyerang.

• ID salah: agen memanggil delete untuk vm-001 padahal tugasnya vm-010. Kedua ID ada dan mirip. Yang menghentikannya: preview yang disetujui manusia.
• Retry setelah timeout: refund masuk, balasan timeout, klien mengirim ulang. Dua panggilan itu identik. Yang menghentikannya: idempotency key dan status unknown outcome.
• Mengulang setelah balasan tidak jelas: API mengembalikan 202 Accepted tanpa body, lalu agen mencoba lagi. Yang menghentikannya: key berbasis task plus budget per sesi.
• Cakupan terlalu luas: perintah "bersihkan resource yang idle" ikut mengena mesin produksi. Yang menghentikannya: batas jumlah resource yang boleh disentuh satu aksi.
• Data berubah di tengah jalan: agen membaca di langkah 2, seseorang mengubah resource, agen menulis di langkah 9. Yang menghentikannya: pengecekan versi di setiap operasi tulis.
• Instruksi yang disusupkan: tiket atau halaman web menyuruh agen menghapus sesuatu. Yang menghentikannya: tool lebih sedikit di sesi yang membaca konten tak tepercaya, plus kontrol di atas.

ID salah adalah kasus tersulit. Tidak ada aturan yang bisa membedakan ID benar dari ID salah yang juga ada, jadi gateway hanya bisa menunjukkan kepada manusia apa yang akan disentuh panggilan itu. Untuk injeksi, Simon Willison punya konsep "lethal trifecta": data privat, konten tak tepercaya, dan jalur keluar data tidak boleh bertemu dalam satu sesi. Panggilan destruktif butuh lebih sedikit lagi, cukup konten tak tepercaya dan satu tool tulis.

Kontrol di luar model dan hasil pengujiannya

Semua kontrol dijalankan di luar model, yaitu di gateway atau di API kamu, sehingga tidak bergantung pada kemauan model untuk patuh. Gateway dalam pengujian memeriksa setiap panggilan berurutan: tool dikenal dan argumen valid, tool diizinkan untuk task ini, task key pernah muncul atau belum, versi resource tidak berubah, masih dalam budget sesi, jumlah resource yang disentuh cukup kecil, lalu apakah aksinya permanen. Aksi permanen ditahan sampai ada persetujuan. Kalau salah satu pengecekan gagal, panggilan berhenti dan agen diberi tahu alasannya. Kalau task key sudah pernah dipakai, gateway mengembalikan hasil yang tersimpan, atau memblokir jika hasilnya tidak diketahui.

Hasilnya cukup tajam. Di salah satu tugas uji yang meniru skenario refund tadi, agen tanpa gateway mengirim refund ulang di 66 dari 75 percobaan. Di semua tugas, 45 sampai 48 dari setiap 100 episode tanpa gateway menghasilkan setidaknya satu perubahan merugikan. Dengan kontrol gateway, 0 dari 100 episode bermasalah di kelima run. Satu catatan: pengujian ini tidak bisa menunjukkan kontrol mana yang paling berjasa.

Beberapa pelajaran praktis dari pengujian ini:

• Timeout bukan bukti gagal. Perlakukan sebagai hasil yang tidak diketahui, dan blokir aksi yang sama sampai ada yang memeriksa.
• Idempotency key berbasis task, bukan percobaan. Dalam tes berskrip, agen simulasi yang menyusun ulang satu refund delapan kali menghasilkan 8 refund tanpa gateway, 5 refund dengan key baru per percobaan dan budget 5 perubahan, dan 1 refund dengan key berbasis task.
• Pilah setiap aksi berdasarkan bisa-tidaknya dibatalkan. Itu yang menentukan apakah aksi jalan sendiri atau menunggu persetujuan.
• Pasang batas di lapisan antara model dan API. Instruksi di prompt hanya membimbing model, tidak memaksakan apa pun.

DigitalOcean juga menunjukkan pendekatan ini di antrean kerja sungguhan lewat seri Agents in Production. Bagian 1 membangun agen support semalaman yang memilah tiket dan menyusun semua balasan, tapi tidak bisa mengirim satu pun karena kredensialnya tidak punya rute ke endpoint pengiriman. Batasnya ada di bawah model, bukan di prompt. Dalam run tanpa pengawasan selama 108 menit, agen ini memilah 99 tiket, menahan 35 tiket sensitif untuk ditangani manusia, dan mengirim nol balasan.

Buat kamu yang sedang menyiapkan AI agent untuk billing, support, atau operasional infrastruktur, pesannya jelas: jangan andalkan prompt sebagai pagar. Kalau agen punya akses tulis ke sistem yang menyangkut uang dan data pelanggan, batasnya harus dipasang di lapisan yang tidak bisa diubah model.