Skip to content

Kapan Agent AI Harus Dicabut dari Workflow

Adityo Guni Waluyo

Kerangka evaluasi pencabutan agent AI dari produksi: audit excessive agency OWASP dan tanda operasional pematangan arsitektur.

Pada pembaruan dokumentasi di sebuah project portal berita daerah, satu agen AI dihentikan operasinya secara permanen. Modul yang sebelumnya menangani validasi data dan penjadwalan tugas rutin dikembalikan ke alur kerja semi-manual. Skrip otomatis kini hanya menyiapkan draf, dan titik pemeriksaan manusia tetap wajib sebelum eksekusi akhir. Reaksi awal terhadap penghentian semacam ini biasanya menganggapnya sebagai kegagalan teknologi atau ketidakmampuan model menangani beban produksi.

Faktanya, penghentian semacam ini sering merupakan keputusan cakupan yang disengaja. Mengurangi otonomi agen bukan langkah mundur, melainkan bagian dari pematangan arsitektur sistem. OWASP GenAI Top-10 2025 mengklasifikasikan agensi berlebihan sebagai risiko utama LLM bernomor LLM06 [1]. Menarik agen dari lingkungan produksi adalah mekanisme mitigasi risiko yang sah ketika biaya kompleksitas melebihi nilai otomatisasi yang dihasilkan [4].

Menentukan kapan agent AI harus dicabut dari workflow memerlukan kerangka evaluasi yang objektif, bukan intuisi atau reaksi terhadap satu insiden. Kerangka keamanan modern menyediakan parameter terukur untuk menilai batas operasional agen.

Tiga Akar Penyebab Agensi Berlebihan

OWASP GenAI Top-10 2025 mengidentifikasi Excessive Agency sebagai LLM06, dengan tiga akar penyebab yang dapat diaudit satu per satu: excessive functionality, excessive permissions, dan excessive autonomy [4].

Pertama, fungsionalitas berlebihan. Kondisi ini terjadi ketika agen diberi akses ke alat yang tidak diperlukan untuk tugas intinya. Sebuah project e-commerce tidak memerlukan agen penjadwalan untuk memiliki akses tulis ke basis data inventaris utama.

Kedua, izin berlebihan. Hal ini terjadi ketika token otorisasi mencakup cakupan lebih luas dari yang dibutuhkan. Contohnya memberikan hak akses administratif global hanya agar agen dapat membaca satu tabel log.

Ketiga, otonomi berlebihan. Ini merujuk pada kemampuan agen melakukan tindakan berantai tanpa persetujuan manusia atau batas waktu eksekusi yang ketat. Kombinasi ketiganya memperluas permukaan serangan secara drastis.

Audit Otorisasi dan Tanda Penarikan

Spesifikasi otorisasi Model Context Protocol memberikan batasan teknis yang jelas. Spesifikasi ini menegaskan token harus terikat pada audience tertentu melalui resource indicator, dan praktik penerusan token (token passthrough) dilarang secara eksplisit [2]. Langkah ini mencegah agen memakai kredensial yang dimaksudkan untuk satu layanan agar dapat membuka layanan lain.

Server otorisasi MCP juga sebaiknya menerbitkan token akses berumur pendek [2]. Jika kredensial agen bocor, jendela penyalahgunaan menjadi sempit. Dokumen tutorial resmi menambahkan aturan cakupan least-privilege: jangan pakai scope catch-all, pisahkan akses per alat atau kemampuan [3].

Auditnya bisa dijalankan sebagai daftar pertanyaan singkat. Alat apa saja yang dimiliki agen, dan apakah semuanya dipakai untuk tugas intinya. Token yang dipakai menerbitkan izin apa, dan apakah ia terikat pada satu layanan tujuan. Tindakan mana yang berjalan tanpa persetujuan manusia. Tiga jawaban yang menggatal biasanya cukup untuk membuka diskusi pencabutan.

Sistem yang memaksa pengembang memberikan token statis berumur panjang dengan cakupan admin global agar agen dapat berfungsi menunjukkan arsitektur yang bermasalah. Dalam kondisi seperti itu, pencabutan agen dari produksi adalah keputusan yang tepat.

Selain audit keamanan, metrik operasional memberi sinyal kelayakan. Penarikan menjadi langkah yang tepat ketika intervensi manusia diperlukan lebih dari separuh waktu untuk mengoreksi output atau menyetujui tindakan. Kondisi ini menandakan model tidak memiliki konteks yang memadai untuk domain tugasnya.

Pemicu lain adalah ketika pemeliharaan konteks agen memakan waktu lebih lama daripada waktu yang dihemat otomatisasi. Agen berhenti menjadi pengganda produktivitas dan berubah menjadi beban pemeliharaan yang menghambat kecepatan tim.

Ada juga sinyal berbentuk biaya kesalahan. Tugas yang diserahkan ke agen perlu digolongkan menurut dampaknya bila salah: bisa dibalik dengan satu tombol, butuh prosedur pemulihan, atau permanen. Semakin sering agen menyentuh dua golongan terakhir tanpa pengawasan, semakin kuat alasan menariknya keluar, sebab kerugian satu insiden bisa menghapus penghematan berbulan-bulan.

Pertanyaan yang lebih berguna bukan bagaimana membangun agen yang lebih pintar, melainkan kapan sebuah agen layak dipertahankan. Mencabut agen AI dari alur kerja bukan pengakuan kekalahan, melainkan penegasan batas sistem yang sehat.

Sumber

Artikel terkait