Anda memberi agen coding tugas kecil: perbaiki satu test yang gagal. Dua puluh menit kemudian, ia sudah menulis ulang tiga file yang tidak berhubungan, menjalankan migrasi database ke DATABASE_URL apa pun yang ditemukannya di shell Anda, dan melakukan force push ke branch yang sedang dipakai orang lain. Tidak ada satu pun hal itu yang diminta dalam prompt. Agen itu punya akses bebas ke mesin, jadi ia memanfaatkannya sepenuhnya.
Izin adalah cara Anda menentukan sejak awal apa yang boleh disentuh agen. Izin agen coding adalah aturan yang menetapkan file, perintah, kredensial, dan repositori mana yang bisa dijangkau agen tertentu selama satu run, serta di titik mana manusia harus turun tangan. Kalau benar, agen yang keluar dari skenario akan gagal dengan aman di dalam kotak yang Anda buat. Kalau salah, satu run buruk bisa sampai ke production.
Artikel ini membahas model izin lapisan demi lapisan, menyebut mode kegagalan di setiap langkah, dan ditutup dengan daftar periksa yang bisa Anda jalankan hari ini. Artikel ini menggunakan Sharkly untuk membuat setiap lapisan jadi konkret, karena tugas Sharkly adalah berada di atas agen coding Anda dan menampung cakupan ini di satu tempat. Anda sudah punya agen coding. Sharkly mengubahnya menjadi tim, dan tim butuh aturan tentang siapa yang boleh melakukan apa.
Tiga lapisan tempat izin agen berada
Izin untuk agen coding bukan satu setelan tunggal. Izin itu ada di tiga tempat, dan celah di salah satunya akan meniadakan dua lapisan lainnya.
- Runtime menentukan tool mana yang bisa dipanggil agen: membaca file, mengedit file, menjalankan perintah shell, mengakses jaringan. Ini adalah Claude Code, Codex, Gemini CLI, atau agen mana pun yang mengeksekusi pekerjaan.
- Mesin menentukan apa yang bisa dijangkau tool tersebut: direktori mana, kredensial mana, variabel lingkungan mana, jaringan mana. Sebuah Computer di Sharkly “menyediakan sistem operasi, file, kredensial, akses jaringan, dan tool yang dibutuhkan sebuah Agent,” jadi mesin adalah radius dampak yang sebenarnya.
- Task menentukan batas niat: repositori mana yang menjadi cakupan run ini, status apa saja yang boleh ditetapkan agen, dan titik di mana manusia menerima hasilnya.
Satu batas yang perlu ditegaskan: izin bukan gerbang persetujuan. Izin adalah apa yang bisa dilakukan agen. Gerbang persetujuan adalah tempat manusia memutuskan. Anda butuh keduanya. Izin ketat tanpa gerbang berarti tidak ada yang memeriksa hasilnya. Gerbang dengan izin longgar berarti kerusakan sudah terjadi sebelum ada yang sempat melihat.
Langkah 1: Batasi cakupan tool di runtime
Mulai dari tempat agen beraksi. Sebagian besar agen coding menyertakan sistem izin: daftar allow dan daftar deny untuk tool, plus prompt sebelum tindakan destruktif dijalankan. Claude Code, misalnya, memungkinkan Anda mengizinkan atau menolak tool tertentu dan akan bertanya sebelum menjalankan perintah shell; nama setelannya berbeda-beda di tiap runtime dan sering berubah, jadi bacalah dokumentasi agen Anda yang terbaru, bukan snippet yang Anda temukan tahun lalu.
Setelan default yang aman: longgar untuk baca, ketat untuk tulis. Biarkan agen membaca repo, menjalankan test, typecheck, dan build tanpa perlu bertanya. Pasang gerbang untuk edit file dan perintah shell, entah lewat prompt atau daftar allow yang eksplisit.
Mode kegagalan ini punya nama, dan inilah yang selalu dipakai orang saat dikejar tenggat: mode skip menyeluruh. Setiap runtime punya flag yang mematikan semua prompt, dan itu praktis untuk sesi yang diawasi. Bahayanya adalah membiarkannya menyala untuk run tanpa pengawasan. Agen yang tidak pernah perlu bertanya, sambil menjalankan rencana yang ternyata keliru, akan dengan senang hati menghapus hal yang salah ia pahami. Gunakan auto-accept saat Anda mengawasi. Matikan saat Anda pergi.
Langkah 2: Batasi cakupan mesin dan kredensialnya
Daftar tool di runtime tidak ada gunanya kalau mesin menyerahkan semuanya ke agen. Agen yang diizinkan menjalankan perintah shell di komputer harian Anda bisa membaca setiap SSH key, setiap .env, dan setiap kredensial yang bisa dijangkau akun login Anda. Mode kegagalannya senyap: tidak ada yang tampak salah sampai agen memakai kunci production yang seharusnya tidak pernah dilihatnya.
Ada dua langkah untuk memperkecil radius dampak. Pertama, jalankan agen di lingkungan yang cakupannya terbatas, bukan di laptop tempat Anda menyimpan rahasia sungguhan. Sharkly mendaftarkan sebuah Computer dengan token instalasi sekali pakai yang berumur pendek dan hanya bisa digunakan sekali, dan dokumentasinya tegas: jangan menaruh token itu di image, script, Task, atau komentar yang bisa dipakai ulang. Entah Computer itu berupa container, server, atau mesin cadangan, jangkauan agen adalah jangkauan lingkungan itu, bukan jangkauan Anda. Kalau Anda ingin agen tetap bekerja saat Anda offline, jalankan di Computer remote alih-alih di laptop Anda yang menyala.
Kedua, serahkan hanya apa yang dibutuhkan satu run. Lingkungan run di Sharkly disusun dari konfigurasi eksplisit: repositori yang dilampirkan, variabel lingkungan, binding secret, dan direktori kerja. Lampirkan repositori ke sebuah Agent ketika ia butuh cakupan kode yang lebih sempit daripada default Space, supaya Agent frontend tidak pernah melakukan checkout ke layanan billing. Jaga setiap run di worktree terisolasi miliknya sendiri; inilah bedanya antara edit buruk yang tetap terkurung di satu checkout dan dua agen yang merusak working tree yang sama. Aturan internal berlaku untuk setiap kolom: isi hanya konfigurasi yang diminta produk, dan jangan pernah menempelkan password atau token ke kolom atau perintah startup yang tidak berkaitan.
Langkah 3: Batasi cakupan task dan serahkan merge ke manusia
Lapisan terakhir adalah niat. Bahkan agen yang sudah di-sandbox dengan benar dan punya kredensial terbatas bisa mengerjakan pekerjaan yang salah: menandai task-nya sendiri selesai, mendorong perubahan setengah jadi ke branch bersama, atau memutuskan sebuah PR siap di-merge.
Di sinilah kontrak manusia–agen berlaku. Agen meneliti, mengeksekusi, menguji, dan melaporkan. Manusia menentukan arah, memberi wewenang, dan menerima hasil. Otomasi berhenti di titik yang membutuhkan pertimbangan tim. Agen boleh membuka PR draft dan melampirkan hasil test-nya; agen tidak boleh menyetujui PR itu atau mem-merge-nya ke branch yang dilindungi. Proteksi branch di host dan review manusia pada task adalah dua kunci yang menjaga garis itu tetap utuh.
Di Sharkly, batas ini melekat pada task itu sendiri. Workflow bertipe Task membatasi status mana yang bisa dipilih seorang Agent, sehingga Agent tidak bisa diam-diam memindahkan pekerjaan ke status “Done” atau “Released” yang menjadi milik manusia. Ketika Agent butuh keputusan, ia membiarkan Task menunggu review manusia atau balasan manusia, dan itu muncul di Inbox agar orang yang bertanggung jawab bisa menerima, meminta perubahan, atau mengalihkan tugas. Eksekusi, hambatan, hasil, dan review semuanya kembali ke satu Task yang sama, bukan berserakan di lima terminal.
Di sinilah juga setup buat sendiri berhenti bisa diskalakan. Satu agen, satu repo, satu engineer yang teliti: Anda masih bisa menyimpan seluruh model izin di kepala. Tambahkan agen kedua dan ketiga, lebih banyak repositori, dan seorang rekan setim, maka “apa yang boleh dilakukan masing-masing agen di sini” jadi pertanyaan yang tak bisa dijawab siapa pun dari ingatan. Papan task mengubah aturan-aturan itu menjadi konfigurasi bersama yang bisa diperiksa: siapa yang menugaskan pekerjaan, cakupan apa yang dimiliki run tersebut, bukti apa yang kembali, dan siapa yang menerimanya. Itulah lapisan manajemen di atas agen coding Anda. Anda bisa membangunnya sendiri dengan worktree, kredensial terbatas, dan proteksi branch, atau menjalankan agen coding Anda yang sudah ada lewat Sharkly dan mengelola izin, task, serta review di satu tempat.
Daftar periksa izin yang bisa Anda jalankan hari ini
Telusuri daftar ini untuk setiap agen yang Anda izinkan menyentuh repositori sungguhan:
- Runtime: baca dan test diizinkan tanpa prompt; edit dan perintah shell diberi gerbang; mode skip menyeluruh dimatikan untuk run tanpa pengawasan.
- Mesin: agen berjalan di Computer dengan cakupan terbatas, bukan di komputer harian Anda; token instalasi dan akses bersifat sekali pakai dan tidak pernah di-commit.
- Kredensial: hanya variabel lingkungan dan binding secret yang dibutuhkan run ini, tidak ada yang ditempel ke kolom yang tidak berkaitan.
- Cakupan repositori: agen dilampirkan hanya ke repo yang dibutuhkan pekerjaannya, bukan semua repo di Space.
- Isolasi: setiap run mendapat worktree-nya sendiri supaya perubahan buruk tidak merusak checkout bersama.
- Cakupan task: agen boleh menetapkan status pengerjaan, tapi tidak boleh memindahkan task ke status accepted atau released yang menjadi milik manusia.
- Merge: proteksi branch plus review manusia dengan bukti tingkat task berdiri di antara PR agen dan branch main.
Kalau ada satu butir yang longgar, perketat sebelum run berikutnya, bukan setelah insiden yang mengajarkan mengapa hal itu penting.
FAQ
Apa bedanya izin agen coding dengan gerbang persetujuan? Izin mendefinisikan apa yang secara teknis bisa dilakukan agen: file, perintah, dan kredensial mana yang bisa dijangkaunya. Gerbang persetujuan adalah titik di mana manusia memutuskan apakah menerima apa yang sudah dilakukan agen. Anda butuh keduanya, karena izin yang ketat tetap menyisakan pekerjaan yang sebaiknya disetujui manusia, dan gerbang persetujuan tidak banyak menolong jika agen sudah punya izin untuk menimbulkan kerusakan.
Haruskah agen coding diizinkan mem-merge PR-nya sendiri? Tidak, jangan sebagai default. Biarkan agen membuka PR draft dan melampirkan hasil verifikasinya, lalu serahkan merge ke manusia atau review yang diwajibkan. Alasannya adalah kontrak manusia–agen: agen mengeksekusi dan melaporkan, manusia menerima dan merilis. Ini tetap berlaku bahkan untuk alur kerja human-in-the-loop di mana agen mengerjakan sebagian besar pekerjaan.
Apakah aman menjalankan agen dengan semua prompt izin dimatikan? Hanya selama Anda mengawasinya. Mode auto-accept berguna untuk sesi yang diawasi, di mana Anda bisa menghentikan langkah yang salah. Untuk run tanpa pengawasan atau sepanjang malam, biarkan prompt atau daftar allow tetap aktif, dan tempatkan agen di mesin dengan cakupan terbatas agar kesalahan tetap terkendali.
