Batas Akses Sebelum Memberi Tools

Setiap tool baru memperluas apa yang bisa dilakukan agent sekaligus memperbesar dampak ketika ia salah bertindak. Kemampuannya mudah didemokan; risikonya sering baru terasa belakangan.

Begitu sebuah tool terhubung, agent tidak cuma mendapat kemampuan baru. Ia juga mendapat jalan untuk membaca data, mengubah catatan, mengirim sesuatu keluar, atau melakukan action yang sulit dibatalkan. Karena itu, pertanyaan pertama seharusnya bukan, “Tools apa saja yang bisa kita connect?” Pertanyaan yang lebih aman adalah, “Outcome apa yang perlu dicapai, dan akses minimum apa yang benar-benar dibutuhkan?”

Urutan ini membuat scope pekerjaan menjadi dasar permission, bukan daftar integrasi yang tersedia.

Mulai dari Outcome yang Sempit

Bayangkan tim sedang mendesain agent untuk memproses hasil meeting. Outcome-nya adalah draft summary yang memisahkan keputusan, action items, PIC, dan deadline yang memang tersedia di notes.

Untuk outcome tersebut, agent mungkin perlu membaca sample meeting notes, melihat daftar peserta yang sudah dikonfirmasi, dan membuat draft terstruktur. Itu belum berarti ia perlu menghapus file, mengubah event lama, membaca seluruh drive perusahaan, atau mengirim hasil ke semua grup.

Kalau daftar tools dibuat lebih dulu, scope mudah melebar mengikuti kemampuan platform. Calendar tersedia, jadi agent diberi akses calendar. Telegram tersedia, jadi agent diberi akses kirim. Drive tersedia, jadi folder yang dibuka terlalu luas. Lama-lama desain workflow menjawab pertanyaan “apa yang bisa dilakukan” dan kehilangan pertanyaan “apa yang seharusnya dilakukan”.

Outcome yang sempit menjaga diskusi tetap grounded. Tulis satu hasil kerja, sumber yang diperlukan, dan siapa yang bertanggung jawab atas hasil final. Setelah itu baru petakan akses.

Pisahkan Read, Write, dan Send/Delete

Tidak semua permission punya konsekuensi yang sama. Untuk audit awal, bedakan akses menjadi tiga kategori.

Read

Read berarti agent bisa melihat file, kalender, database, atau sumber lain. Risiko read kadang dianggap rendah karena agent tidak mengubah apa pun. Padahal data yang terbaca tetap dapat masuk ke context, log, atau output.

Tanyakan sumber mana yang memang relevan. Agent yang merangkum satu meeting tidak otomatis perlu membaca semua transcript. Agent yang memeriksa jadwal satu tim tidak otomatis perlu melihat kalender organisasi. Scope data tetap perlu dibatasi, bahkan ketika aksesnya read-only.

Write

Write berarti agent dapat membuat atau mengubah data. Contohnya membuat draft event, memperbarui status task, atau menulis summary ke dokumen.

Di sini konsekuensinya mulai lebih besar. Perubahan yang keliru dapat mengganggu workflow lain, menimpa informasi yang benar, atau membuat tim mengira sebuah keputusan sudah final. Tentukan objek mana yang boleh dibuat, field mana yang boleh diubah, dan apakah agent menulis langsung ke data utama atau ke area draft.

Kalau read access sudah cukup untuk menghasilkan preview, jangan buru-buru memberi write access. Draft yang direview manusia sering kali sudah mencapai outcome tanpa membuka kewenangan tambahan.

Send/Delete

Send dan delete layak mendapat kontrol paling ketat karena dampaknya keluar dari ruang kerja agent atau sulit dipulihkan.

Mengirim pesan ke Telegram, email, atau pelanggan membuat output menjadi komunikasi resmi. Menghapus file atau event bisa menghilangkan data yang masih dibutuhkan. Walaupun beberapa tindakan bisa dibatalkan, biaya koordinasinya tetap nyata.

Default yang lebih aman adalah preview dulu, approval, baru execute. Agent menyiapkan payload lengkap, manusia melihat tujuan dan isinya, lalu action dijalankan setelah disetujui.

Permission Bukan Checklist Sekali Jadi

Permission sering diperlakukan sebagai setup teknis: beri token, centang scope, selesai. Padahal permission adalah bagian dari desain pekerjaan.

Setidaknya, dokumentasikan enam hal untuk tiap tool:

1. data apa yang boleh dibaca;
2. action apa yang boleh dilakukan;
3. input apa yang wajib tersedia;
4. kondisi apa yang harus menghentikan proses;
5. apakah action dapat dibatalkan;
6. apakah human approval dibutuhkan.

Daftar ini membantu tim membedakan capability dari authority. Agent mungkin technically capable mengirim pesan, tetapi authority untuk mengirim baru muncul setelah preview disetujui. Agent mungkin bisa mengubah kalender, tetapi workflow hanya mengizinkan pembuatan draft event dari informasi yang sudah dikonfirmasi.

Permission juga perlu ditinjau saat scope berubah. Kalau awalnya agent hanya membuat summary lalu kemudian diminta mengirim follow-up, itu bukan tambahan fitur kecil. Ada kategori akses dan tanggung jawab baru yang perlu dievaluasi.

Access Minimum Bukan Berarti Agent Dibuat Lemah

Least privilege kadang terdengar seperti membatasi agent sampai tidak berguna. Yang dibatasi bukan kemampuan berpikirnya, tetapi permukaan tindakannya.

Agent tetap bisa membaca sumber yang disetujui, menyusun struktur, menandai informasi yang hilang, dan membuat rekomendasi. Ia hanya tidak diberi kewenangan yang tidak diperlukan untuk job tersebut.

Pendekatan ini juga memudahkan debugging. Ketika hasil salah, tim punya ruang pencarian yang lebih kecil. Data sumbernya jelas, tool yang dipakai terbatas, dan action yang tersedia dapat ditelusuri. Kalau agent memiliki akses terlalu luas, investigasi ikut menjadi messy karena terlalu banyak kemungkinan.

Contoh praktisnya: sebuah content agent diminta membuat draft post. Ia membutuhkan brief, referensi yang disetujui, dan lokasi untuk menyimpan draft. Ia belum membutuhkan akses publish. Setelah kualitas draft stabil dan approval flow jelas, tim baru dapat mempertimbangkan level otomatisasi berikutnya.

Tambah permission karena ada kebutuhan yang terbukti, bukan karena integrasinya kebetulan tersedia.

Rancang Kondisi Berhenti

Batas akses perlu ditemani batas perilaku. Agent harus tahu kapan data tidak cukup, ketika dua sumber bertentangan, atau saat tool gagal.

Untuk Meeting Operations Agent yang sedang dirancang, informasi yang belum dikonfirmasi tidak boleh diperlakukan sebagai fakta. Kalau deadline tidak ada, agent memberi label bahwa deadline belum ditentukan. Kalau tujuan pengiriman belum jelas, agent tidak memilih channel sendiri. Kalau approval belum diberikan, hasil tetap menjadi preview.

Kondisi berhenti seperti ini membuat permission benar-benar bekerja. Read-only tidak banyak membantu kalau agent bebas mengarang informasi. Approval tidak meaningful kalau preview menyembunyikan field yang tidak pasti. Guardrail perlu menyatu dari input sampai action.

Audit dari Action Paling Berisiko

Kalau lo sudah punya prototype agent, audit-nya bisa dimulai dari ujung workflow.

Lihat semua action yang mengirim, mengubah, atau menghapus sesuatu. Untuk masing-masing action, tanyakan apakah outcome tetap bisa tercapai dengan draft, preview, atau akses yang lebih sempit. Setelah itu periksa sumber yang dibaca: apakah seluruh sumber diperlukan, atau cukup folder, tabel, dan field tertentu?

Hasil audit tidak harus langsung sempurna. Yang penting, tiap akses punya alasan yang terhubung ke pekerjaan. “Biar fleksibel” bukan alasan yang cukup untuk membuka data atau action production.

Di workshop Building AI Employees, prinsip akses minimum ini dipakai saat merancang Meeting Operations Agent. Targetnya bukan agent yang punya semua tombol, melainkan agent yang punya akses cukup untuk bekerja tanpa mengambil tanggung jawab di luar cakupan.

Uji akses dari tindakan paling berisiko: bisakah hasil yang sama dicapai lewat draft atau tampilan pratinjau? Jika bisa, agent belum perlu memegang tombol kirim, ubah, atau hapus. Prinsip ini dibedah dalam kelas Building AI Employees:

https://goakal.com/ai-builders-id/building-ai-employees