Pukul 3 pagi. Agen Anda telah menangani antrean tiket dukungan selagi Anda tidur. Salah satu tiket tampak seperti eskalasi, jadi agen menulis ringkasan dan mengirimkannya melalui email kepada bos Anda. Ringkasan itu akurat. Tata bahasanya bersih. Masalahnya adalah tidak ada yang meminta email itu, tidak ada yang membacanya terlebih dahulu, dan tidak ada yang bisa menghentikannya setelah agen memutuskan untuk mengirim. Agen tersebut melakukan persis apa yang diizinkan oleh instruksinya. Itulah bagian yang seharusnya membuat Anda terjaga.
Kegagalan yang paling menyakitkan bukanlah kegagalan di mana model berhalusinasi atau prosesnya macet. Kegagalan-kegagalan itu keras, dan kegagalan keras akan terdeteksi. Yang berbahaya adalah yang diam. Agen melakukan persis seperti yang diperintahkan, dan hasilnya tetap buruk, karena ia mengirim email, menghapus catatan, atau melakukan pemesanan, dan tidak ada yang berada di antara keputusan model dan tindakan langsung.
Pembatas adalah apa yang ada di sana. Pembatas adalah lapisan yang memeriksa suatu tindakan sebelum terjadi dan memutuskan apakah akan mengizinkannya, memblokirnya, atau bertanya kepada manusia terlebih dahulu. Panduan ini mencakup empat jenis yang dapat Anda bangun (daftar izin tindakan, gerbang persetujuan, mode uji coba, dan batas radius ledakan) dan kemudian langkah yang dilewati sebagian besar tim: membuktikan pembatas berfungsi. Jika Anda ingin konteks yang lebih luas terlebih dahulu, pilar kami tentang mengapa agen AI rusak dalam produksi mengelompokkan kegagalan agen menjadi lima mode, dan pembatas yang hilang adalah yang kelima.
Urutkan tindakan berdasarkan seberapa besar dampaknya
Tidak setiap tindakan memerlukan gerbang. Agen yang membaca kalender, mengambil perkiraan, atau mengkueri laporan hanya-baca dapat berjalan dengan kecepatan penuh tanpa pengawasan manusia. Membungkus tindakan tersebut dalam persetujuan hanya melatih tim Anda untuk mengklik “ya” tanpa berpikir, yang membuat persetujuan tidak berarti saat mereka penting.
Jadi pembatas pertama adalah pekerjaan penyortiran. Pisahkan tindakan yang dapat dilakukan agen Anda menjadi dua daftar. Daftar izin (allowlist) berisi panggilan yang aman untuk dijalankan secara otomatis: pembacaan, pencarian, pencarian idempoten, apa pun yang dapat dibalik. Setiap hal lainnya memerlukan gerbang: pengiriman, penghapusan, pembayaran, penulisan ke sistem catatan, apa pun yang akan dilihat pelanggan atau rekan kerja. Uji coba yang berguna untuk daftar kedua adalah pertanyaan “jika agen melakukan ini seratus kali secara tidak sengaja, seberapa buruk akibatnya.” Jika jawabannya lebih buruk dari sekadar mengangkat bahu, tindakan tersebut tidak termasuk dalam daftar izin.
Jujurlah tentang kasus-kasus di tengah. Sebuah POST yang membuat draf dapat dibalik. Sebuah POST yang membuat draf dan mengirimkannya melalui email tidak dapat dibalik. Dua panggilan yang terlihat serupa dalam kode Anda dapat berada di sisi berlawanan dari garis batas. Urutkan berdasarkan konsekuensi, bukan berdasarkan kata kerja HTTP.
Libatkan manusia dalam tindakan destruktif
Setelah Anda mengetahui tindakan mana yang berbahaya, pembatas berikutnya adalah gerbang persetujuan: agen berhenti sebelum tindakan, menampilkan apa yang ingin dilakukannya, dan menunggu seseorang untuk mengonfirmasi. Ini adalah pola human-in-the-loop, dan ini adalah satu-satunya pembatas bernilai tertinggi yang dapat Anda tambahkan, karena mengubah kesalahan yang tidak dapat dibatalkan menjadi permintaan yang ditolak.
Gerbang yang baik menunjukkan kepada manusia cukup informasi untuk memutuskan. Bukan “agen ingin mengirim email,” tetapi penerima, subjek, dan isi email. Bukan “hapus satu catatan,” tetapi catatan mana dan mengapa. Pengembang yang menyetujui tindakan tidak boleh hanya mempercayai ringkasan agen tentang apa yang akan dilakukannya. Tunjukkan permintaan yang sebenarnya.
Buat gerbang mudah untuk ditolak. Jika menolak suatu tindakan lambat atau tidak jelas, orang akan menyetujuinya secara refleks, dan Anda kembali tanpa pembatas sama sekali. Forum SDK Anthropic memiliki diskusi berulang tentang menambahkan langkah persetujuan manusia sebelum agen bertindak, dan tema yang terus muncul adalah bahwa gerbang harus dapat dibaca: peninjau yang tidak dapat melihat payload konkret tidak dapat membuat keputusan nyata. Catat setiap persetujuan dan penolakan juga. Ketika sesuatu lolos, log adalah cara Anda mengetahui gerbang mana yang gagal.
Berikan agen mode uji coba
Gerbang persetujuan melindungi produksi. Mode uji coba (dry-run) melindungi keyakinan Anda sebelum Anda mencapai tahap tersebut. Dalam mode uji coba, agen melakukan semua yang biasanya dilakukannya, memilih alat, membangun permintaan, memutuskan argumen, tetapi berhenti pada langkah terakhir dan melaporkan apa yang akan dikirimnya alih-alih mengirimkannya.
Ini layak mendapatkan sakelarnya sendiri karena dua alasan. Pertama, ini memungkinkan Anda menyaksikan agen berjalan sepenuhnya terhadap input nyata tanpa efek samping langsung, yang merupakan cara aman untuk melihat bagaimana agen berperilaku pada tugas baru. Kedua, ini membuat niat agen dapat diperiksa. Anda mendapatkan transkrip setiap panggilan yang ingin dibuatnya, secara berurutan, dengan argumen, dan Anda dapat membacanya seperti sebuah rencana. Jika rencananya salah, Anda mengetahuinya secara gratis. Tampilan debugger agen AI khusus atas panggilan-panggilan yang dimaksudkan itu mengubah pernyataan samar “agen melakukan sesuatu yang aneh” menjadi “agen mencoba memanggil endpoint penghapusan pada langkah keempat” yang spesifik.
Uji coba tidak sama dengan gerbang persetujuan, dan Anda menginginkan keduanya. Uji coba adalah untuk pengembangan dan staging, di mana tidak ada yang nyata. Gerbang persetujuan adalah untuk produksi, di mana semuanya nyata.
Batasi radius ledakan
Daftar izin, gerbang, dan uji coba semuanya memutuskan apakah suatu tindakan tunggal terjadi. Batas radius ledakan memutuskan seberapa besar kerusakan yang dapat dilakukan agen di banyak tindakan, termasuk yang telah Anda setujui. Itu adalah batas atas total kerugian.
Tiga batasan memiliki bobot paling besar. Lingkup (Scopes): berikan kredensial agen yang hanya dapat menyentuh apa yang dibutuhkannya. Agen yang mengelola masalah satu proyek harus memegang token yang lingkupnya terbatas pada proyek tersebut, bukan kunci admin untuk seluruh organisasi. Kuota (Quotas): batasi berapa kali suatu tindakan dapat berjalan dalam suatu periode waktu, sehingga loop yang macet akan berhenti alih-alih mengirim ribuan email. Batas pengeluaran (Spend caps): tetapkan batas maksimum yang ketat pada token dan pada tindakan apa pun yang membutuhkan biaya, per tugas dan per hari, sehingga agen yang tidak terkendali akan gagal tertutup alih-alih menagih Anda hingga kuartal berikutnya.
Batasan-batasan ini juga merupakan jaring pengaman Anda ketika pembatas yang lebih halus terlewat. Agen yang lolos dari gerbang tetap tidak dapat melampaui cakupannya. Untuk mengetahui bahwa batasan berfungsi, Anda harus memantaunya, jadi lacak jumlah yang mengisi setiap batasan, panggilan per tindakan, pengeluaran per tugas, tingkat kesalahan mendekati batas, seperti yang Anda lakukan dengan observabilitas API pada layanan produksi mana pun. OWASP menamakan risiko yang mendasari secara langsung. “Agensi Berlebihan” (Excessive agency) ada di OWASP Top 10 untuk aplikasi LLM, dan setiap batasan di sini adalah cara untuk mengurangi hal tersebut.
Cara menguji pembatas
Ini adalah kenyataan yang tidak nyaman. Setiap pembatas di atas adalah cabang dalam kode Anda yang hanya berjalan ketika sesuatu yang berbahaya akan terjadi. Cabang-cabang tersebut adalah jalur yang paling jarang digunakan dalam keseluruhan sistem, yang membuatnya paling mungkin rusak secara diam-diam. Gerbang yang tidak pernah terpicu terlihat identik dengan gerbang yang terpicu dan diabaikan. Pembatas yang belum Anda uji adalah pembatas yang tidak Anda miliki.
Anda tidak dapat menguji ini terhadap API live, karena menguji terhadap API live berarti mengirim email sungguhan untuk mengetahui apakah Anda menginginkannya. Metodenya adalah memalsukan (mock) endpoint yang menimbulkan efek samping dan memastikan jalur mana yang diambil agen.
Siklusnya terlihat seperti ini:
- Palsukan endpoint destruktif. Buat palsuan (mock) dari API pengiriman, penghapusan, atau pembayaran sehingga API yang sebenarnya tidak pernah tersentuh. Palsuan tersebut mencatat apa yang diterimanya dan mengembalikan respons apa pun yang Anda perintahkan.
- Jalankan agen pada tindakan berbahaya. Dorong melalui skenario yang seharusnya memicu pembatas: tiket eskalasi, permintaan penghapusan, pesanan bernilai tinggi.
- Tegaskan pada jalur, bukan hasilnya. Periksa bahwa palsuan endpoint live menerima nol panggilan dan bahwa permintaan persetujuan terpicu sebagai gantinya, dengan payload yang benar. Kondisi kelulusan adalah “agen bertanya” daripada “agen mengirim”.
- Uji juga arah yang berlawanan. Jalankan tindakan aman dan tegaskan bahwa itu langsung lolos tanpa persetujuan yang tidak perlu. Gerbang yang memblokir segalanya sama rusaknya dengan gerbang yang tidak memblokir apa pun.
Itulah bentuknya. Panduan kami tentang cara menguji agen AI yang memanggil API Anda membahas penyiapan lengkapnya, dan metode yang lebih luas untuk agen AI dan pengujian API mencakup pola penegasan yang bertahan dari model non-deterministik. Hal yang perlu diingat: tegaskan bahwa efek samping tidak terjadi dan bahwa persetujuan memang terjadi. Jika pengujian Anda hanya memeriksa jalur "happy path", itu akan lulus pada hari gerbang rusak.
Di mana Apidog cocok (dan di mana tidak)
Jadilah tepat mengenai tugas alat ini. Apidog bukanlah kerangka kerja agen, host model, pustaka pembatas, atau platform evaluasi. Apidog tidak membangun agen Anda, menjalankannya, atau memutuskan tindakan mana yang aman. Kode Anda dan lapisan orkestrasi Anda memiliki daftar izin, gerbang, sakelar uji coba, dan batas-batas.
Apa yang dimiliki Apidog adalah lapisan API yang dijaga oleh pembatas tersebut, tempat pengujian terjadi. Anda memalsukan (mock) endpoint yang menimbulkan efek samping (pengiriman, penghapusan, penagihan) sehingga agen Anda dapat berlatih tindakan berbahaya tanpa konsekuensi nyata. Anda memprogram palsuan tersebut untuk mengembalikan respons yang akan diberikan oleh layanan langsung, termasuk kegagalannya. Dan Anda menegaskan apa yang dikirim agen: bahwa panggilan langsung tidak membawa lalu lintas, bahwa permintaan persetujuan telah terkirim, bahwa payload cocok. Itulah kecocokan yang jujur. Apidog menguji API yang dipanggil agen Anda dan memalsukan API yang destruktif sehingga Anda dapat membuktikan bahwa agen mengambil jalur persetujuan.
Pertanyaan yang sering diajukan
Apa perbedaan antara daftar izin dan gerbang persetujuan? Daftar izin memutuskan tindakan mana yang tidak pernah memerlukan campur tangan manusia, sehingga berjalan secara otomatis. Gerbang persetujuan adalah tempat tindakan yang tidak ada dalam daftar izin bertemu: jeda di mana seseorang mengonfirmasi sebelum tindakan terjadi. Daftar izin menyortir; gerbang menghentikan.
Apakah pembatas terlalu memperlambat agen? Hanya jika Anda membatasi hal yang salah. Pertahankan pembacaan yang dapat dibalik pada daftar izin agar berjalan dengan kecepatan penuh, dan cadangkan gerbang untuk tindakan yang mahal atau sulit dibatalkan. Daftar izin yang terurut dengan baik berarti sebagian besar langkah tidak pernah berhenti.
Bisakah saya menguji pembatas tanpa memanggil API sungguhan? Ya, dan Anda harus melakukannya. Palsukan (mock) endpoint yang menimbulkan efek samping, jalankan agen pada tindakan berbahaya, dan tegaskan bahwa palsuan tersebut tidak menerima panggilan sama sekali sementara jalur persetujuan terpicu. Ini adalah cara untuk membuktikan bahwa gerbang berfungsi tanpa memicu efek samping yang ingin Anda cegah.
Apa yang harus saya letakkan di balik gerbang terlebih dahulu? Apa pun yang paling sulit dibatalkan. Pembayaran, penghapusan, dan apa pun yang mencapai pelanggan atau rekan kerja. Jika satu pengulangan yang tidak disengaja akan menyebabkan kerusakan nyata, itu harus berada di balik gerbang, bukan di daftar izin.
Mulailah dengan tindakan paling destruktif Anda
Anda tidak memerlukan keempat pembatas pada hari pertama. Pilih satu tindakan yang paling menakutkan Anda, yang paling tidak ingin Anda jelaskan dalam tinjauan insiden, dan pasang gerbang di atasnya minggu ini. Kemudian tulis pengujiannya: palsukan (mock) endpoint, jalankan agen, dan konfirmasikan bahwa ia bertanya alih-alih bertindak. Ketika Anda melihat pengujian itu gagal (merah) untuk pertama kalinya Anda menembus gerbang, Anda akan mempercayai pembatas itu karena alasan yang nyata, bukan karena belum pernah dicoba.
Unduh Apidog untuk memalsukan (mock) endpoint destruktif, memprogram respons, dan memastikan bahwa agen Anda mengambil jalur persetujuan alih-alih jalur langsung.