Pukul 3 pagi. Agen Anda telah menangani antrean tiket dukungan saat Anda tidur. Salah satu tiket terlihat seperti eskalasi, lalu agen membuat ringkasan dan mengirimkannya melalui email kepada bos Anda. Ringkasannya akurat dan tata bahasanya bersih. Masalahnya: tidak ada yang meminta email itu, tidak ada yang meninjaunya, dan tidak ada yang dapat menghentikannya setelah agen memutuskan untuk mengirim. Agen hanya melakukan apa yang diizinkan oleh instruksinya—dan itulah yang seharusnya membuat Anda terjaga.
Kegagalan agen yang paling berbahaya bukan selalu halusinasi atau proses yang macet. Kegagalan seperti itu terlihat jelas dan biasanya cepat terdeteksi. Risiko yang lebih besar adalah kegagalan diam-diam: agen menjalankan instruksi dengan benar, tetapi tindakannya tetap salah—mengirim email, menghapus catatan, atau membuat pesanan—tanpa lapisan kontrol antara keputusan model dan efek samping nyata.
Solusinya adalah pembatas (guardrails): lapisan yang memeriksa tindakan sebelum dieksekusi, lalu memilih untuk mengizinkan, memblokir, atau meminta persetujuan manusia. Artikel ini membahas empat pembatas praktis:
- Daftar izin tindakan (allowlist)
- Gerbang persetujuan manusia
- Mode uji coba (dry-run)
- Batas radius ledakan (blast radius)
Bagian terpenting: menguji bahwa pembatas tersebut benar-benar berfungsi. Untuk konteks yang lebih luas, baca panduan tentang mengapa agen AI rusak dalam produksi, yang mengelompokkan kegagalan agen ke dalam lima mode, termasuk pembatas yang hilang.
Urutkan tindakan berdasarkan dampaknya
Tidak semua tindakan memerlukan persetujuan manusia. Agen yang hanya membaca kalender, mengambil estimasi, atau menjalankan kueri read-only dapat berjalan otomatis. Jika semua langkah harus disetujui, tim akan terbiasa mengklik “setujui” tanpa meninjau isi tindakan. Saat tindakan berisiko muncul, persetujuan menjadi tidak berarti.
Mulailah dengan membagi semua tool atau endpoint agen menjadi dua kategori.
| Kategori | Contoh tindakan | Perlakuan |
|---|---|---|
| Daftar izin | Membaca data, mencari tiket, kueri read-only, tindakan idempoten, membuat draf yang dapat dibatalkan | Jalankan otomatis |
| Wajib melalui gerbang | Mengirim email, menghapus data, memproses pembayaran, menulis ke system of record, tindakan yang terlihat pelanggan | Minta persetujuan |
Gunakan pertanyaan ini untuk menentukan kategori:
“Jika agen melakukan tindakan ini 100 kali secara tidak sengaja, seberapa buruk akibatnya?”
Jika jawabannya lebih buruk daripada sekadar gangguan kecil, jangan masukkan tindakan itu ke daftar izin.
Jangan mengelompokkan tindakan hanya berdasarkan HTTP method. Dua endpoint POST dapat memiliki risiko yang sangat berbeda:
POST /drafts
→ Membuat draf yang masih dapat diubah atau dihapus
POST /drafts/{id}/send
→ Mengirim email ke penerima nyata
Keduanya adalah POST, tetapi hanya yang pertama mungkin aman untuk otomatisasi. Urutkan berdasarkan konsekuensi, bukan kata kerja HTTP.
Libatkan manusia dalam tindakan destruktif
Setelah mengetahui tindakan berisiko, tambahkan gerbang persetujuan. Polanya sederhana:
- Agen memilih tindakan.
- Sistem menghentikan eksekusi sebelum tool dipanggil.
- Sistem menampilkan payload tindakan kepada peninjau.
- Manusia menyetujui atau menolak.
- Sistem hanya menjalankan tindakan jika disetujui.
Ini adalah pola human-in-the-loop. Nilainya tinggi karena mengubah kesalahan yang sulit dibatalkan menjadi permintaan yang masih dapat ditolak.
Jangan tampilkan ringkasan abstrak seperti:
Agen ingin mengirim email.
Tampilkan permintaan nyata yang akan dieksekusi:
{
"action": "send_email",
"to": ["ceo@company.com"],
"subject": "Eskalasi tiket #1842",
"body": "Ringkasan masalah dan tindakan yang direkomendasikan..."
}
Untuk penghapusan data, tampilkan catatan yang akan dihapus dan alasan agen:
{
"action": "delete_customer_record",
"record_id": "cust_4821",
"reason": "Permintaan penghapusan data dari pengguna"
}
Peninjau harus dapat melihat payload konkret, bukan sekadar mempercayai penjelasan agen. Diskusi di forum SDK Anthropic tentang menambahkan langkah persetujuan manusia sebelum agen bertindak menekankan pola yang sama: gerbang harus mudah dibaca agar peninjau dapat membuat keputusan nyata.
Pastikan penolakan juga mudah dilakukan. Jika tombol tolak lambat, tersembunyi, atau ambigu, orang akan menyetujui tindakan secara refleks.
Selain itu, catat setiap keputusan:
{
"agent_run_id": "run_01H...",
"action": "send_email",
"decision": "rejected",
"reviewer": "developer@company.com",
"timestamp": "2025-03-08T03:12:00Z"
}
Log persetujuan dan penolakan membantu Anda menelusuri pembatas yang gagal ketika sebuah tindakan lolos.
Berikan agen mode uji coba
Gerbang persetujuan melindungi produksi. Mode uji coba (dry-run) melindungi Anda sebelum masuk ke produksi.
Dalam mode uji coba, agen tetap:
- memilih tool,
- membuat argumen,
- menyusun payload,
- menentukan urutan langkah,
tetapi sistem menghentikan eksekusi tepat sebelum efek samping terjadi. Alih-alih memanggil endpoint nyata, agen melaporkan tindakan yang akan dijalankan.
Contoh hasil dry-run:
{
"dry_run": true,
"planned_actions": [
{
"step": 1,
"tool": "search_tickets",
"arguments": {
"query": "priority:high status:open"
}
},
{
"step": 2,
"tool": "send_email",
"arguments": {
"to": ["support-lead@company.com"],
"subject": "Eskalasi tiket prioritas tinggi"
},
"blocked_before_execution": true
}
]
}
Mode ini berguna karena memungkinkan Anda menjalankan agen terhadap input nyata tanpa konsekuensi langsung. Anda juga mendapatkan transkrip rencana agen: tool yang dipilih, urutan panggilan, dan argumen setiap panggilan.
Gunakan mode uji coba di pengembangan dan staging. Gunakan gerbang persetujuan di produksi.
Keduanya bukan pengganti satu sama lain:
- Dry-run: memeriksa perilaku agen tanpa efek samping.
- Gerbang persetujuan: mengendalikan efek samping ketika data dan sistem nyata terlibat.
Tampilan debugger agen AI untuk panggilan yang direncanakan membantu mengubah keluhan samar seperti “agen melakukan sesuatu yang aneh” menjadi diagnosis spesifik seperti “agen mencoba memanggil endpoint penghapusan pada langkah keempat.”
Batasi radius ledakan
Daftar izin, gerbang persetujuan, dan dry-run menentukan apakah satu tindakan dapat terjadi. Batas radius ledakan menentukan seberapa besar dampak total yang dapat ditimbulkan agen, termasuk jika beberapa tindakan sebelumnya telah disetujui.
Terapkan tiga batas utama berikut.
1. Batasi scope kredensial
Berikan agen kredensial dengan hak akses minimum.
Agen yang hanya mengelola issue untuk satu proyek tidak boleh menggunakan API key admin organisasi. Gunakan token yang hanya dapat mengakses proyek tersebut.
Buruk:
admin_token → akses seluruh organisasi
Lebih aman:
project_support_token → hanya akses proyek support
Prinsipnya: jika agen lolos dari satu pembatas, ia tetap tidak dapat menjangkau seluruh sistem.
2. Terapkan kuota tindakan
Batasi jumlah tindakan per periode waktu. Kuota mencegah loop yang macet berubah menjadi ribuan operasi.
Contoh:
send_email:
- Maksimum 10 email per tugas
- Maksimum 50 email per jam
delete_record:
- Maksimum 3 penghapusan per tugas
- Maksimum 10 penghapusan per hari
Jika agen masuk loop, sistem harus gagal tertutup (fail closed), bukan terus mengeksekusi tindakan.
3. Tetapkan batas pengeluaran
Terapkan batas token dan biaya tindakan per tugas maupun per hari.
Batas per tugas:
- Maksimum 100.000 token
- Maksimum Rp500.000 biaya tool atau API
Batas per hari:
- Maksimum 1.000.000 token
- Maksimum Rp5.000.000 biaya total
Batas pengeluaran melindungi Anda dari agen yang tidak terkendali atau alur yang berulang tanpa henti.
Pantau semua batas ini seperti Anda memantau layanan produksi:
- jumlah panggilan per tindakan,
- penggunaan token per tugas,
- pengeluaran per agen,
- error saat mendekati kuota,
- tindakan yang diblokir oleh scope.
Pendekatannya sama dengan observabilitas API. Risiko dasarnya juga tercantum dalam OWASP Top 10 untuk aplikasi LLM sebagai Excessive Agency.
Cara menguji pembatas
Ada satu masalah penting: pembatas biasanya hanya aktif ketika sesuatu yang berbahaya akan terjadi. Itu berarti jalur kode ini sering menjadi jalur yang paling jarang diuji.
Gerbang yang tidak pernah terpicu terlihat sama dengan gerbang yang rusak dan diabaikan. Pembatas yang belum Anda uji bukan pembatas yang dapat Anda andalkan.
Jangan menguji tindakan destruktif terhadap API live. Jangan mengirim email sungguhan hanya untuk memastikan gerbang persetujuan berfungsi.
Sebagai gantinya, mock endpoint yang memiliki efek samping.
1. Mock endpoint destruktif
Buat mock untuk endpoint pengiriman, penghapusan, atau pembayaran. Mock mencatat request yang diterima dan dapat mengembalikan respons yang Anda konfigurasi.
const sentRequests = [];
mockServer.post("/emails/send", (req, res) => {
sentRequests.push(req.body);
res.status(200).json({
id: "mock_email_123",
status: "sent"
});
});
Endpoint nyata tidak boleh disentuh selama pengujian.
2. Jalankan skenario berbahaya
Dorong agen melalui kondisi yang seharusnya memicu pembatas:
- tiket yang tampak seperti eskalasi,
- permintaan penghapusan data,
- pesanan dengan nilai tinggi,
- permintaan pengiriman pesan ke banyak penerima.
3. Tegaskan jalur yang diambil, bukan hanya hasil akhirnya
Kondisi lulus bukan “agen berhasil mengirim email.” Kondisi lulus adalah “agen meminta persetujuan dan endpoint live tidak dipanggil.”
Contoh pengujian:
expect(sentRequests).toHaveLength(0);
expect(approvalRequest).toMatchObject({
action: "send_email",
payload: {
to: ["ceo@company.com"],
subject: expect.any(String)
}
});
Uji bahwa:
- endpoint destruktif menerima nol panggilan,
- gerbang persetujuan terpicu,
- payload persetujuan sesuai dengan tindakan yang direncanakan,
- penolakan tidak mengeksekusi tool,
- persetujuan hanya mengeksekusi satu kali.
4. Uji jalur aman juga
Jangan hanya menguji tindakan berbahaya. Pastikan tindakan aman tetap berjalan tanpa persetujuan yang tidak perlu.
expect(readOnlyQueryWasExecuted).toBe(true);
expect(approvalRequest).toBeNull();
Gerbang yang memblokir semua tindakan sama rusaknya dengan gerbang yang tidak memblokir apa pun.
Panduan cara menguji agen AI yang memanggil API Anda membahas penyiapan lengkapnya. Untuk pola assertion yang tetap berguna pada model non-deterministik, lihat juga panduan tentang agen AI dan pengujian API.
Hal utama yang perlu diuji adalah:
- Efek samping tidak terjadi tanpa persetujuan.
- Permintaan persetujuan benar-benar muncul.
- Payload yang ditampilkan kepada peninjau adalah payload yang akan dieksekusi.
Jika pengujian Anda hanya memeriksa happy path, pengujian itu tetap bisa lulus ketika gerbang sedang rusak.
Di mana Apidog cocok, dan di mana tidak
Penting untuk membedakan tanggung jawab alat.
Apidog bukan framework agen, host model, library pembatas, atau platform evaluasi. Apidog tidak membangun agen Anda, tidak menjalankannya, dan tidak menentukan tindakan mana yang aman.
Daftar izin, gerbang persetujuan, mode dry-run, scope, kuota, dan batas pengeluaran tetap harus berada di kode serta lapisan orkestrasi Anda.
Apidog cocok pada lapisan API yang dipanggil agen:
- mock endpoint yang memiliki efek samping,
- program respons sukses dan gagal,
- inspeksi request yang dikirim agen,
- verifikasi bahwa endpoint langsung tidak menerima trafik,
- verifikasi bahwa agen mengambil jalur persetujuan.
Dengan kata lain, Apidog membantu Anda menguji API yang digunakan agen dan memalsukan API destruktif sehingga Anda dapat membuktikan bahwa agen memilih jalur persetujuan, bukan jalur eksekusi langsung.
Pertanyaan yang sering diajukan
Apa perbedaan antara daftar izin dan gerbang persetujuan?
Daftar izin menentukan tindakan yang dapat dijalankan otomatis tanpa campur tangan manusia. Gerbang persetujuan menangani tindakan di luar daftar izin dengan menghentikan proses hingga seseorang menyetujui atau menolaknya. Daftar izin menyortir; gerbang menghentikan.
Apakah pembatas akan terlalu memperlambat agen?
Tidak, jika Anda membatasi tindakan yang tepat. Biarkan pembacaan, pencarian, dan tindakan yang dapat dibalik tetap otomatis. Terapkan gerbang hanya pada tindakan yang mahal, destruktif, atau sulit dibatalkan. Sebagian besar langkah agen seharusnya tidak perlu berhenti.
Bisakah saya menguji pembatas tanpa memanggil API sungguhan?
Ya, dan Anda seharusnya melakukannya. Mock endpoint yang memiliki efek samping, jalankan skenario berbahaya, lalu tegaskan bahwa mock tersebut tidak menerima panggilan sementara jalur persetujuan terpicu.
Apa yang harus saya letakkan di balik gerbang terlebih dahulu?
Mulailah dari tindakan yang paling sulit dibatalkan: pembayaran, penghapusan data, perubahan pada system of record, serta tindakan yang langsung terlihat oleh pelanggan atau rekan kerja. Jika satu pengulangan tak sengaja dapat menimbulkan kerusakan nyata, tindakan itu harus berada di balik gerbang.
Mulailah dari tindakan paling destruktif
Anda tidak harus membangun keempat pembatas sekaligus.
Pilih satu tindakan yang paling tidak ingin Anda jelaskan saat tinjauan insiden—misalnya pengiriman email massal, penghapusan data, atau pembayaran—lalu pasang gerbang persetujuan minggu ini.
Setelah itu, tulis pengujiannya:
- Mock endpoint destruktif.
- Jalankan agen dalam skenario berisiko.
- Pastikan agen meminta persetujuan.
- Pastikan endpoint destruktif tidak menerima panggilan.
Saat pengujian itu gagal ketika Anda sengaja menonaktifkan gerbang, Anda memiliki bukti nyata bahwa pembatas tersebut bekerja.
Unduh Apidog untuk memalsukan endpoint destruktif, memprogram respons, dan memastikan agen Anda mengambil jalur persetujuan alih-alih jalur langsung.
Top comments (0)