Conduct: Guardrails Open-Source untuk LLM dan MCP Tool Calls di Tim AI

Salah satu masalah terbesar saat tim mulai membangun AI agent yang bisa memanggil tool adalah kontrol: bagaimana memastikan agent hanya melakukan apa yang diizinkan, dan bagaimana membuktikannya? Sebuah proyek baru bernama Conduct mencoba menjawab pertanyaan ini dengan pendekatan guardrails open-source yang serius.

Artikel ini membahas apa itu Conduct, bagaimana cara kerjanya, kenapa guardrails penting untuk AI agent, dan apa yang bisa dipelajari tim yang sedang membangun sistem AI dengan tool calls.

Apa itu Conduct

Conduct adalah proyek open-source yang menyediakan governance untuk AI agent di lingkungan tim. Fokus utamanya adalah tool calls — saat agent AI memanggil fungsi atau tool eksternal. Conduct menyediakan firewall runtime yang mencatat apa yang terjadi, dan lapisan kontrol yang menentukan apa yang boleh terjadi.

Konsep utamanya: runtime firewall memberitahu lo apa yang sudah terjadi (logging dan observability), sementara Conduct Guard mengontrol apa yang bisa terjadi (enforcement). Kedua aspek ini penting untuk AI agent yang beroperasi di lingkungan produksi.

Proyek ini menggunakan kebijakan yang ditandatangani (signed policy) — aturan kontrol dibuat dan ditandatangani secara kriptografis, sehingga bisa diverifikasi siapa yang menyetujui dan tidak bisa diubah diam-diam. Ada juga verifikasi chain untuk memastikan rantai tindakan agent bisa diaudit.

Mode defaultnya fail-closed: jika tidak ada aturan yang mengizinkan suatu tindakan, tindakan itu ditolak. Pendekatan ini lebih aman dibandingkan mode default yang mengizinkan segalanya dan baru memblokir yang dilarang.

Kenapa Guardrails Diperlukan

AI agent modern tidak hanya menjawab pertanyaan — mereka memanggil API, mengakses database, mengirim email, atau mengeksekusi perintah. Setiap kemampuan ini adalah permukaan risiko. Tanpa kontrol yang jelas, sebuah agent yang diarahkan dengan prompt yang salah bisa melakukan tindakan yang merugikan.

Masalah klasik: prompt injection. Jika agent membaca konten dari web, email, atau dokumen yang mengandung instruksi tersembunyi, agent bisa dimanipulasi untuk melakukan hal di luar tujuan semula. Guardrails yang membatasi tool calls adalah pertahanan terhadap manipulasi semacam ini.

Selain itu, ada masalah operasional: bagaimana tim tahu agent melakukan apa? Logging saja tidak cukup jika tidak ada kontrol. Guardrails memberikan lapisan kepastian: tindakan tertentu tidak mungkin terjadi karena dicegah di level kebijakan, bukan hanya dicatat setelah terjadi.

Untuk tim yang beroperasi di lingkungan perusahaan — dengan kepatuhan, audit, dan akuntabilitas — kemampuan membuktikan bahwa agent dibatasi adalah nilai yang nyata.

MCP dan Ekosistem Tool Calls

Salah satu perkembangan penting di ekosistem AI agent adalah Model Context Protocol (MCP), protokol standar untuk menghubungkan model AI dengan tool dan sumber data. MCP membuat integrasi tool lebih mudah, tapi juga memperluas permukaan yang perlu dikontrol.

Conduct mendukung MCP sebagai bagian dari arsitekturnya. Dengan router yang bertindak sebagai proxy LLM, Conduct bisa mengawasi dan mengontrol lalu lintas antara agent dan tool — termasuk tool yang terhubung lewat MCP. Ini memberikan titik kontrol terpusat yang penting untuk keamanan.

Kombinasi antara agent yang bisa memanggil banyak tool dan protokol standar seperti MCP membuat kebutuhan akan lapisan kontrol semakin jelas. Tanpa guardrails, setiap tool baru yang dihubungkan adalah risiko baru.

Cara Kerja Conduct

Arsitektur Conduct terdiri dari beberapa komponen. Ada router yang bertindak sebagai proxy untuk panggilan LLM — semua permintaan agent melewati router, sehingga bisa diinspeksi dan dikontrol. Ada kebijakan yang mendefinisikan aturan: tool apa yang boleh dipanggil, dengan argumen apa, dan dalam kondisi apa.

Kebijakan ini ditandatangani dengan kunci kriptografis. Ini berarti kebijakan memiliki asal yang jelas — tim tahu siapa yang menyetujui aturan tersebut. Perubahan kebijakan bisa diverifikasi, dan kebijakan yang tidak sah bisa ditolak.

Ada juga verifikasi chain, yang memungkinkan audit rantai tindakan agent. Jika sesuatu terjadi, tim bisa menelusuri bagaimana agent sampai pada tindakan tersebut — input apa yang diterima, keputusan apa yang dibuat, dan tool apa yang dipanggil.

Mode fail-closed memastikan default yang aman: tindakan tanpa izin eksplisit ditolak. Ini mungkin membutuhkan lebih banyak konfigurasi di awal, tapi memberikan jaminan keamanan yang lebih kuat di produksi.

Kasus Penggunaan di Tim Nyata

Bayangkan sebuah tim yang membangun agent customer support yang bisa membaca tiket, menulis balasan, dan mengirim email. Tanpa guardrails, agent bisa saja mengirim email ke alamat yang salah atau mengakses data pelanggan di luar wewenangnya. Dengan Conduct, kebijakan bisa membatasi: agent hanya bisa membaca tiket yang ditugaskan padanya, dan hanya bisa mengirim email setelah disetujui manusia.

Contoh lain: agent analisis data yang bisa mengakses database. Kebijakan bisa membatasi query hanya pada tabel tertentu, melarang operasi destruktif seperti DELETE atau DROP, dan mewajibkan persetujuan untuk ekspor data. Dengan begitu, kerusakan dari prompt injection atau kesalahan logika bisa dicegah.

Contoh ketiga: agent DevOps yang bisa menjalankan perintah. Ini adalah kasus berisiko tinggi — agent yang dikompromikan bisa mengubah konfigurasi produksi. Guardrails yang membatasi perintah yang diizinkan, membatasi target host, dan mewajibkan persetujuan untuk tindakan sensitif menjadi pertahanan yang penting.

Hal yang Perlu Dipertimbangkan

Mengadopsi guardrails seperti Conduct bukan tanpa biaya. Pertama, ada kompleksitas konfigurasi: tim perlu mendefinisikan kebijakan dengan jelas, dan kebijakan yang terlalu ketat bisa menghambat produktivitas agent. Menyeimbangkan keamanan dan kegunaan adalah pekerjaan yang berkelanjutan.

Kedua, mode fail-closed bisa mengecewakan di awal — agent akan menolak banyak tindakan sampai kebijakan lengkap. Tim perlu merencanakan proses iterasi: mulai dari kebijakan yang longgar untuk eksperimen, lalu memperketat saat pola penggunaan menjadi jelas.

Ketiga, proyek ini masih muda. Sebagai proyek open-source baru, ekosistem, dokumentasi, dan dukungannya masih berkembang. Tim yang mengadopsi harus siap untuk membaca kode, mengatasi masalah sendiri, dan berkontribusi balik.

Keempat, guardrails bukan pengganti desain yang baik. Lapisan kontrol membantu, tapi desain sistem yang membatasi dampak kegagalan — prinsip least privilege, isolasi, dan human-in-the-loop untuk tindakan sensitif — tetap yang terpenting.

Kebijakan yang Efektif: Apa yang Perlu Diatur

Menyusun kebijakan guardrails yang baik adalah keterampilan yang perlu dipelajari. Kebijakan yang terlalu longgar tidak memberikan perlindungan; kebijakan yang terlalu ketat membuat agent tidak berguna. Kuncinya adalah memahami risiko setiap tool dan mengatur kontrol secara proporsional.

Mulai dari inventarisasi tool: apa saja tool yang bisa dipanggil agent, data apa yang bisa diakses, dan tindakan apa yang bisa dilakukan. Setiap tool harus punya profil risiko — read-only jelas lebih aman daripada yang bisa menulis atau menghapus. Tools dengan dampak tinggi perlu kontrol lebih ketat.

Lalu, definisikan siapa atau apa yang boleh memanggil tool apa. Prinsip least privilege berlaku: agent hanya diberi akses ke tool yang dibutuhkan untuk tugasnya, bukan semua tool yang tersedia. Agent customer support tidak perlu akses ke tool administrasi sistem.

Terakhir, tentukan tindakan yang butuh persetujuan manusia. Operasi yang berdampak besar atau sulit dibatalkan — mengirim email ke banyak penerima, menghapus data, mengubah konfigurasi produksi — sebaiknya melewati human-in-the-loop. Ini bukan penghalang produktivitas, melainkan jaring pengaman.

Audit dan Observability

Guardrails tidak lengkap tanpa observability. Kemampuan mencatat setiap keputusan — tool apa yang dipanggil, dengan argumen apa, oleh agent mana, atas dasar apa — adalah fondasi audit yang baik. Jika terjadi insiden, tim bisa menelusuri rantai penyebab dengan percaya diri.

Log yang baik mencatat tidak hanya tindakan yang berhasil, tapi juga tindakan yang diblokir. Pola blokir yang sering muncul bisa menjadi sinyal: mungkin kebijakan terlalu ketat, mungkin ada agent yang mencoba melakukan hal di luar wewenang, atau mungkin ada prompt injection yang mencoba memanipulasi agent.

Dashboard untuk memantau penggunaan tool juga berguna. Berapa banyak panggilan per tool, dari agent mana, pada jam berapa? Anomali — lonjakan panggilan tool tertentu, panggilan di luar jam kerja — bisa menjadi indikator awal masalah. Monitoring yang baik mengubah guardrails dari alat pencegahan pasif menjadi alat deteksi aktif.

Terakhir, lakukan review berkala terhadap kebijakan dan log. Kebijakan harus dievaluasi seiring perubahan sistem: tool baru ditambahkan, pola penggunaan berubah, risiko baru muncul. Guardrails adalah sistem yang hidup, bukan konfigurasi sekali jadi.

Memulai dengan Conduct: Langkah Praktis

Bagi tim yang ingin mencoba Conduct, ada beberapa langkah praktis. Pertama, mulai di lingkungan non-produksi — gunakan sandbox atau staging yang aman untuk bereksperimen. Ini memberi ruang untuk mempelajari arsitektur dan kebijakan tanpa risiko.

Kedua, mulai dengan satu use case kecil. Pilih satu agent atau satu tool yang paling berisiko, dan bangun kebijakan untuk itu. Contoh nyata memberikan pembelajaran yang jauh lebih baik daripada teori: bagaimana kebijakan ditulis, bagaimana fail-closed bekerja, bagaimana proses approval mengalir.

Ketiga, libatkan tim keamanan dan operasi sejak awal. Guardrails bukan hanya tanggung jawab developer AI — tim keamanan punya perspektif risiko, tim operasi paham dampak di produksi. Kolaborasi sejak awal menghasilkan kebijakan yang lebih realistis.

Keempat, dokumentasikan keputusan kebijakan. Kenapa tool ini diizinkan, kenapa tindakan itu butuh persetujuan, siapa yang menyetujui? Dokumentasi yang baik membantu audit dan onboarding anggota tim baru. Kebijakan tanpa konteks sulit dipelihara.

Terakhir, rencanakan proses iterasi. Kebijakan awal hampir pasti perlu penyesuaian setelah dipakai di dunia nyata. Bangun loop umpan balik: pantau blokir, dengarkan keluhan developer, sesuaikan kebijakan, dan evaluasi dampaknya.

Kesimpulan

Conduct mewakili arah yang benar untuk keamanan AI agent: kontrol eksplisit, kebijakan yang bisa diverifikasi, dan mode fail-closed. Saat tim semakin banyak membangun agent yang memanggil tool, pertanyaan "bagaimana kita membuktikan agent tidak melakukan hal yang tidak diizinkan?" menjadi semakin penting. Alat seperti Conduct membantu menjawabnya dengan memberikan lapisan governance yang terstruktur. Bagi tim yang sedang membangun AI agent dengan MCP atau tool calls — terutama di lingkungan dengan kebutuhan audit — proyek ini layak dipelajari dan dievaluasi. Mulai dari eksperimen di lingkungan non-produksi, pelajari model kebijakannya, dan nilai apakah arsitekturnya cocok dengan kebutuhan tim.