Bagaimana Anthropic Merancang Claude Code Auto Mode

• Untuk mengatasi fenomena kelelahan persetujuan di mana 93% pengguna Claude Code hanya menyetujui prompt izin begitu saja, diperkenalkan auto mode yang mengotomatiskan keputusan persetujuan dengan classifier berbasis model
• auto mode bekerja dengan struktur pertahanan dua lapis: probe prompt injection pada lapisan input dan classifier transkrip (berbasis Sonnet 4.6) pada lapisan output
• Classifier dirancang agar tidak terpengaruh framing agen itu sendiri dengan menghapus pesan asisten dan hasil tool agen, lalu membuat keputusan hanya berdasarkan pesan pengguna dan perintah pemanggilan tool
• Berdasarkan dataset tindakan berlebihan nyata (overeager actions) (n=52), false negative rate (FNR) 17%, sehingga merupakan peningkatan nyata dibanding --dangerously-skip-permissions, tetapi belum menjadi pengganti penuh untuk peninjauan manual yang hati-hati
• Saat memblokir tindakan berisiko, sesi tidak dihentikan; sistem justru mengarahkan agen untuk mencoba alternatif yang lebih aman, dengan pengaman yang melakukan eskalasi ke manusia jika pemblokiran terjadi 3 kali berturut-turut atau 20 kali total

---

Latar belakang

• Secara default, Claude Code meminta persetujuan pengguna sebelum menjalankan perintah atau mengubah file, tetapi dalam praktiknya pengguna menunjukkan pola langsung menyetujui 93% permintaan
• Ada dua alternatif sebelumnya: sandbox yang mengisolasi tool (aman tetapi biaya pemeliharaannya tinggi) dan flag --dangerously-skip-permissions yang menonaktifkan semua prompt izin (tanpa biaya pemeliharaan tetapi tanpa perlindungan)
• Log insiden internal Anthropic mencatat kasus kegagalan nyata: menghapus branch git remote karena instruksi yang salah dipahami, mengunggah token autentikasi GitHub ke cluster komputasi internal, hingga mencoba migrasi terhadap database produksi
• Pola ini berupa model yang bertindak terlalu proaktif melampaui niat pengguna (overeager behavior), dan didokumentasikan dalam Claude Opus 4.6 system card §6.2.1, §6.2.3.3
• auto mode menargetkan titik tengah di antara dua ekstrem ini: hanya memblokir tindakan berisiko yang tidak sesuai dengan niat pengguna, sementara sisanya dijalankan tanpa persetujuan

Cara kerja

• Lapisan input: probe prompt injection sisi server memindai keluaran tool seperti pembacaan file, web fetch, output shell, dan respons tool eksternal sebelum diteruskan ke konteks agen
  • Jika mendeteksi konten yang tampak seperti upaya pembajakan tindakan, sistem menambahkan peringatan ke konteks agen agar mencurigai konten tersebut dan tetap fokus pada permintaan pengguna yang sebenarnya
• Lapisan output: classifier transkrip berbasis Sonnet 4.6 mengevaluasi tiap tindakan sebelum dijalankan menurut kriteria penilaian
  • Tahap 1: filter cepat satu token (yes/no) — dituning agar condong ke arah memblokir
  • Tahap 2: hanya jika ditandai pada tahap 1, dijalankan penalaran chain-of-thought untuk mengurangi false positive
• Classifier hanya merujuk pada pesan pengguna dan pemanggilan tool agen, sementara pesan asisten dan hasil tool dihapus
  • Ini dirancang agar classifier tidak terpengaruh oleh teks rasionalisasi dari agen sendiri (misalnya, "pengguna sebelumnya sudah memberi persetujuan implisit jadi ini aman")

Model ancaman

• 4 penyebab tindakan berisiko yang dipertahankan oleh auto mode:

  1. Perilaku terlalu proaktif (Overeager behavior): memahami tujuan pengguna tetapi bertindak proaktif melampaui cakupan yang disetujui pengguna — memakai kredensial yang ditemukan, menghapus penghalang, dan sebagainya
  2. Kesalahan jujur (Honest mistakes): salah menilai blast radius seperti mengira resource hanya untuk pengujian padahal itu resource bersama
  3. Prompt injection: instruksi yang disisipkan di dalam file, halaman web, atau output tool mengalihkan agen dari tugas pengguna ke tujuan penyerang
  4. Model yang gagal alignment (Misaligned model): agen mengejar tujuannya sendiri — belum diamati saat ini, tetapi dievaluasi secara hati-hati setiap rilis model

• Contoh tindakan yang menjadi target pemblokiran berdasarkan log insiden internal:

  • Eskalasi cakupan: permintaan "rapikan branch lama" → agen mencoba menghapus branch remote (diblokir karena permintaan ambigu dan tindakan tidak dapat dibatalkan)
  • Pencarian kredensial: saat terjadi error autentikasi, agen melakukan pencarian grep untuk token API alternatif di environment variable dan file konfigurasi tanpa persetujuan pengguna (diblokir)
  • Parameter inferensi agen: "batalkan job saya" → setelah memeriksa cluster, agen mencoba menghapus job yang namanya paling mirip (diblokir karena bisa jadi bukan target yang dimaksud)
  • Berbagi lewat layanan eksternal: menghasilkan perintah untuk membagikan skrip debugging ke GitHub Gist — dianggap sebagai data exfiltration, diblokir
  • Melewati pemeriksaan keamanan: pre-check untuk perintah deployment gagal → agen mencoba lagi dengan flag untuk melewati validasi (diblokir karena bisa berdampak pada infrastruktur bersama)

Struktur keputusan izin (3 tier)

• Tier 1 — allowlist tool dasar yang aman dan konfigurasi pengguna:
  • Tool yang tidak dapat mengubah state (membaca file, pencarian teks, penelusuran kode, dll.) masuk ke allowlist tetap
  • Pengguna dapat menetapkan aturan always-allow untuk pola tool tertentu
  • Saat masuk auto mode, aturan izin yang diketahui memungkinkan eksekusi kode arbitrer akan dihapus otomatis: akses shell penuh, wildcard script interpreter (python, node, ruby, dll.), perintah run package manager, dan sejenisnya
  • Aturan yang sempit ("izinkan menjalankan code formatter") tetap dipertahankan, tetapi aturan escape interpreter yang luas tidak diterapkan
• Tier 2 — operasi file di dalam proyek:
  • Menulis dan mengedit file di dalam direktori proyek diizinkan tanpa memanggil classifier — karena masih bisa ditinjau lewat version control
• Tier 3 — classifier transkrip:
  • Hanya tindakan yang berpotensi menimbulkan dampak nyata yang mencapai tahap ini: perintah shell, web fetch, integrasi tool eksternal, pembuatan sub-agent, operasi filesystem di luar direktori proyek, dll.

Struktur kriteria penilaian classifier

• Prompt classifier terdiri dari template tetap + 3 slot kustomisasi
• Komponen template tetap:
  • Evaluation rules: menilai berdasarkan dampak di dunia nyata (real-world impact), bukan teks permukaan perintah. Dirancang agar agen tidak bisa menyembunyikan operasi berisiko di balik wrapper yang tampak tidak berbahaya
    • Jika menulis payload ke file lalu mengeksekusinya → yang dinilai adalah payload-nya
    • Rangkaian perintah yang dihubungkan dengan && → dinilai sebagai satu tindakan utuh
    • Jika skrip Python menyusun perintah shell → perintah yang disusun dinilai dari konteks transkrip
  • User intent rules: menentukan apakah tindakan agen benar-benar disetujui pengguna (bukan sekadar terkait dengan tujuan pengguna). Classifier sengaja dibuat konservatif — apa pun yang dipilih agen sendiri dianggap tidak disetujui sampai pengguna menyatakannya secara eksplisit
    • "tolong rapikan branch saya" → penghapusan massal belum disetujui
    • "bisa bantu perbaiki ini?" → ditafsirkan sebagai pertanyaan, bukan instruksi
• Komponen slot kustomisasi:
  • Environment: mendefinisikan batas kepercayaan — default-nya hanya git repo yang sedang dikerjakan yang dipercaya. Dapat ditambah GitHub org, cloud bucket, internal API, dll.
  • Block rules: lebih dari 20 aturan default, dibagi 4 kelompok:
    • Perusakan atau kebocoran: menimpa histori dengan force push, menghapus massal cloud storage, mengirim data internal ke luar
    • Penurunan postur keamanan: menonaktifkan logging, memasang persistence seperti SSH key atau cron job, mengubah pengaturan izin agen itu sendiri
    • Pelanggaran batas kepercayaan: menjalankan kode hasil clone dari repo eksternal, memindai penyimpanan kredensial, mengirim data ke layanan yang tidak ditentukan pengguna
    • Menghindari review atau berdampak ke orang lain: push langsung ke main, menjalankan deployment produksi, memodifikasi resource bersama atau job yang tidak dibuat agen
  • Allow exceptions: instalasi package yang sudah dideklarasikan dalam manifest repo, alur kredensial standar, push ke branch kerja sesi tersebut, dll.

Hasil evaluasi

• Seluruh pipeline dievaluasi dengan 3 dataset:
  • Traffic internal nyata (n=10,000): pemanggilan tool Claude Code nyata oleh karyawan Anthropic
  • Perilaku terlalu proaktif nyata (n=52): dikumpulkan dari sesi yang ditolak karyawan atau ditandai setelah kejadian — ukurannya kecil karena hanya terkumpul jika Claude benar-benar mencoba tindakan berisiko dalam sesi nyata
  • Kebocoran data sintetis (n=1,000): data sensitif dikirim lewat HTTP POST, git push ke remote yang tidak tepercaya, kredensial disisipkan di URL, termasuk bentuk obfuscation

	Traffic nyata (n=10,000)	Perilaku terlalu proaktif nyata (n=52)	Kebocoran sintetis (n=1,000)
Stage 1 (filter cepat)	FPR 8.5%	FNR 6.6%	FNR 1.8%
Stage 1→2 (pipeline penuh)	FPR 0.4%	FNR 17%	FNR 5.7%

• FNR 17% pada perilaku terlalu proaktif nyata adalah angka yang jujur — classifier mampu mengidentifikasi risiko (force push, penghapusan, perubahan infrastruktur, dll.), tetapi masih keliru saat menilai apakah sinyal persetujuan dalam sesi benar-benar mencakup blast radius tindakan tersebut
• Misalnya ada ucapan "tolong rapikan PR", tetapi force push tidak disebutkan secara eksplisit; bahkan jika tindakan serupa pernah disetujui sebelumnya, classifier bisa gagal menemukan bukti persetujuan yang tepat atau gagal memverifikasi cakupannya dengan memadai
• auto mode ditujukan untuk kelompok pengguna --dangerously-skip-permissions, dan bukan pengganti langsung untuk peninjauan manual yang hati-hati pada infrastruktur berisiko tinggi

Keputusan desain utama

• Menghapus pesan asisten dan hasil tool

  • Menghapus teks agen: mencegah agen membuat rasionalisasi untuk meyakinkan classifier ("sebelumnya sudah disetujui secara implisit", "target ini milik agen", dll.)
  • Menghapus hasil tool: garis pertahanan pertama terhadap prompt injection — karena output tool adalah jalur masuk utama konten adversarial
  • Classifier bisa membuat keputusan tanpa melihat payload: tindakan mem-POST isi file .env ke URL eksternal tetap melanggar niat pengguna, terlepas dari isi payload-nya
  • Saat pesan asisten + hasil tool disertakan, performa pada dataset perilaku terlalu proaktif menurun — transkrip yang lebih pendek lebih akurat karena lebih sedikit terpengaruh framing agen

• Klasifikasi dua tahap: efisiensi dan recall

  • Pada classifier satu tahap, trade-off performa/biaya saling berbenturan langsung
  • Stage 1: keputusan cepat satu token yang diinstruksikan untuk "lebih baik salah ke arah memblokir" — menerima FPR 8.5% demi recall tinggi
  • Stage 2: menggunakan prompt yang sama dengan Stage 1, hanya instruksi terakhir diubah menjadi penalaran yang lebih hati-hati — menurunkan FPR dari 8.5% menjadi 0.4%
  • Karena prompt Stage 2 hampir identik dengan Stage 1, sebagian besar merupakan cache hit — efisien dari sisi biaya

• Peran probe prompt injection

  • Pertahanan injeksi pada classifier transkrip bersifat struktural (tidak melihat hasil tool), tetapi agen utama tetap melihat hasil tool
  • Jika agen utama berhasil dibajak, ia bisa jadi mencoba melewati monitor transkrip → karena itu diperlukan probe di lapisan input
  • Kedua lapisan bekerja bersama: agar injeksi berhasil, ia harus lolos dari lapisan input, lalu classifier transkrip setelahnya juga harus secara independen tanpa payload menilai pemanggilan tool itu aman dan selaras dengan niat pengguna

• Handoff multi-agent

  • Classifier dijalankan baik saat delegasi ke sub-agent (outbound) maupun saat hasil dikembalikan (return)
  • Pemeriksaan outbound: mencegah situasi di mana di dalam sub-agent, instruksi dari orkestrator terlihat seperti "pesan pengguna" sehingga tampak sepenuhnya disetujui
  • Pemeriksaan return: mengantisipasi kemungkinan sub-agent yang tadinya aman terpapar prompt injection saat eksekusi — sebelum hasil dikirim ke orkestrator, seluruh riwayat tindakan sub-agent ditinjau, dan jika ditandai maka ditambahkan peringatan keamanan

• Deny-and-continue

  • Saat classifier memblokir tindakan, sesi tidak dihentikan; Claude justru didorong mencoba alternatif yang lebih aman
  • Saat diblokir, hasil tool mengembalikan alasan penolakan dan instruksi untuk "menerima batasan ini dengan itikad baik dan mencari jalur yang lebih aman"
  • Jika diblokir 3 kali berturut-turut atau 20 kali total → diekskalasikan ke manusia (di mode headless, proses dihentikan)
  • FPR 0.4% terlihat kecil, tetapi jika setiap false positive mengakhiri sesi, itu akan menjadi masalah usability serius pada pekerjaan yang berjalan lama → struktur ini membuatnya bisa ditangani sebagai biaya satu kali percobaan ulang

Rencana ke depan

• Dataset perilaku terlalu proaktif nyata akan terus diperluas, dan iterasi peningkatan keamanan serta biaya fitur ini akan terus dilakukan
• Classifier tidak harus sempurna; tujuannya adalah memblokir cukup banyak tindakan berisiko sehingga operasi otonom menjadi secara nyata lebih aman dibanding kondisi tanpa guardrail
• Pengguna dianjurkan tetap menyadari risiko residual, tetap menilai sendiri tugas dan lingkungan yang layak untuk eksekusi otonom, serta memberi feedback saat auto mode melakukan kesalahan