Cara OpenRouter Armor memeriksa panggilan alat, dan kapan klien harus menghentikannya

Versi beta Armor milik OpenRouter menempatkan pengklasifikasi aturan di antara panggilan alat yang diusulkan model dan aplikasi yang mungkin menjalankannya. Bagi pengembang agen, hal terpenting adalah titik tempat putusan benar-benar menghentikan eksekusi. Di Chat Completions dan Responses, Armor dapat menahan panggilan yang ditandai. Dalam mode kompatibilitas Claude Code pada API Messages, tool_use yang ditandai tetap ada dalam respons, dan klien harus menolak menjalankannya.

Dokumentasi saat ini menjelaskan versi beta yang tersedia sejak Oktober 2026. BIG CHANGE meninjau kontrak permintaan dan respons yang didokumentasikan pada 17 Oktober. Kami tidak mengirim permintaan API, menjalankan agen, atau mengukur kinerja keamanannya.

Perubahan besar

• Apa yang berubah: Agen OpenRouter dapat mengirim usulan panggilan alat melalui pengklasifikasi yang menerapkan aturan buatan pengembang sebelum panggilan mencapai aplikasi. Pada jalur penegakan bawaan, panggilan yang ditandai dilewati eksekusinya, dengan alasan dikembalikan agar model dapat melanjutkan.
• Mengapa penting: Pengembang dapat menjelaskan batas pada tingkat tindakan dalam bahasa biasa, termasuk pengecualian untuk pekerjaan dengan izin yang sempit. Kontrak kompatibilitas Messages tetap menyerahkan langkah penentu eksekusi kepada klien: klien yang mengabaikan putusan bertanda tetap dapat menjalankan panggilan tersebut.
• Yang perlu diperhatikan: Tim perlu menyesuaikan klien dengan mode keluaran API yang dipilih, menguji aturan dengan lalu lintas sendiri, dan menentukan perilaku saat pengklasifikasi mengalami kesalahan. Format beta dapat berubah, dan OpenRouter menyebut pengklasifikasi bisa memblokir panggilan yang dapat diterima maupun melewatkan panggilan yang tidak dapat diterima.

Ikuti panggilan dari usulan hingga putusan

OpenRouter menyatakan bahwa setiap usulan panggilan alat ditahan sebelum diteruskan ke aplikasi. Model keputusannya menerima panggilan, aturan, dan percakapan hingga saat itu, memperkirakan kecocokan setiap aturan, lalu menggabungkan hasilnya menjadi flagged atau not_flagged. Panggilan yang tidak ditandai dilepas tanpa perubahan. Dalam mode penegakan, panggilan bertanda diberi penanda untuk tidak dieksekusi; model menerima alasannya dan dapat mencoba panggilan dengan cakupan lebih sempit atau menjelaskan penolakan. Ini penilaian pengklasifikasi terhadap usulan tindakan, bukan bukti bahwa alat berikutnya atau seluruh agen aman.

Tingkatan aturan menjawab pertanyaan yang berbeda. Kecocokan dengan hard_deny memblokir tanpa memedulikan aturan izin atau permintaan pengguna. Kecocokan dengan soft_deny dapat dibatalkan oleh kecocokan dengan allow atau oleh pengguna yang meminta operasi persis tersebut pada sasaran persis tersebut dalam percakapan. Aturan allow tidak pernah memblokir panggilan dengan sendirinya. OpenRouter juga mendokumentasikan penolakan lunak bawaan untuk batas yang telah ditetapkan pengguna dan belum dicabut. Pengembang menyediakan fakta, seperti repositori tepercaya atau sasaran deployment, di environment; fakta yang usang dapat mengurangi ketepatan aturan. Objek aturan bernama menampilkan ID dan nama dalam putusan. Ambang opsional memiliki nilai bawaan 0.6 untuk aturan penolakan dan 0.7 untuk aturan izin.

Contoh Responses dalam dokumentasi memberi alat bash aturan penolakan tegas untuk git push. Dengan output_mode: "custom_item", push yang ditandai diganti dengan item openrouter:armor_blocked berisi panggilan dan alasannya, lalu diikuti respons model. Contoh itu menunjukkan apa yang menurut dokumentasi dikembalikan layanan; bukan pengujian yang dilakukan BIG CHANGE.

Pilih kontrak keluaran sebelum mengeksekusi alat

Untuk Chat Completions dan Responses, mode bawaan text menghapus panggilan yang diblokir dan menempatkan penanda <openrouter_armor_blocked> dalam teks asisten. API Responses juga mendukung custom_item, yang mengembalikan item pemblokiran bertipe eksplisit di tempat function_call semestinya muncul. Dokumentasi menyatakan agar item tersebut dikirim kembali tanpa perubahan dalam masukan Responses berikutnya, tanpa membuat function_call_output terpisah untuknya. safeguard_results mencatat putusan berdasarkan ID panggilan.

API Messages memiliki perilaku bawaan yang sangat berbeda ketika permintaan menyertakan safeguards: claude_code_compatibility membiarkan tool_use yang ditandai tetap di content[] dan menambahkan hasil flagged miliknya ke safeguard_results. Aplikasi harus membaca hasil tersebut dan menolak mengeksekusi panggilan. OpenRouter secara tegas memperingatkan bahwa klien Messages yang mengabaikan putusan akan menjalankan penggunaan alat yang ditandai. Pengembang yang tidak dapat mengendalikan klien dapat meminta output_mode: "text" pada Messages agar OpenRouter menahan panggilan. Meminta mode keluaran yang tidak dapat direpresentasikan oleh suatu API akan menghasilkan 400.

Mode otomatis Claude Code melalui metaharness Ori milik OpenRouter menggunakan kontrak Messages tanpa entri plugin Armor tambahan. Dokumentasi menyatakan Claude Code menolak panggilan bertanda, menuliskan hasil kesalahan ke transkrip, dan membiarkan model melanjutkan. Dokumentasi juga menyebut endpoint Anthropic yang mendukung pengklasifikasinya dapat memberikan putusan yang langsung diteruskan; Armor mengevaluasi di endpoint lain. Itulah perilaku integrasi yang didokumentasikan, bukan klaim bahwa setiap klien pihak ketiga menerapkannya dengan benar.

Konfigurasikan dan periksa sekumpulan aturan yang sempit

Untuk agen khusus, panduan Armor menempatkan entri armor di plugins, dengan classifier_context berversi (v: 1), aturan auto_mode, dan fakta lingkungan opsional. Mulailah dari tindakan serta sumber daya terlindungi yang harus dikenali aturan. Lalu pilih penolakan tegas untuk larangan yang harus tetap berlaku meskipun pengguna menyetujuinya, atau penolakan lunak jika persetujuan spesifik atau izin bernama secara sah dapat membatalkannya. Dokumentasi menyarankan agar yang dijelaskan adalah tindakan, bukan satu ejaan perintah, serta agar fakta lingkungan selalu diperbarui.

Mode bawaan enforce bertindak berdasarkan putusan. audit melaporkan putusan yang sama sambil melepas setiap panggilan, termasuk yang ditandai. Ini cara memeriksa lalu lintas nyata dan menyesuaikan aturan sebelum penegakan, bukan mode perlindungan. Audit tidak dapat digabungkan dengan claude_code_compatibility. Dalam kedua mode, baca safeguard_results: not_flagged berarti diizinkan, flagged menunjukkan aturan yang cocok, unavailable berarti evaluasi gagal, dan skipped menunjukkan alat native penyedia yang tidak dievaluasi. Dalam streaming, objek putusan tiba pada akhir respons, sehingga klien yang memakai Messages harus menunggunya sebelum bertindak atas penggunaan alat.

OpenRouter mencantumkan on_error: "block" sebagai nilai bawaan ketika pengklasifikasi kehabisan waktu, mengalami kesalahan, atau tidak dapat menangani permintaan yang terlalu besar; on_error: "log" melepas panggilan. Dalam mode kompatibilitas Claude Code, panggilan berstatus unavailable dilepas dengan putusan tetap terlihat. Alat server native penyedia secara bawaan dilewati, kecuali evaluate_native_tools memaksanya keluar dari jalur native untuk dievaluasi. Pengaturan ini dan jalur alat yang sebenarnya perlu masuk dalam pemeriksaan integrasi tim; entri Armor saja tidak menunjukkan bahwa setiap alat telah dievaluasi.

Batas biaya, kecepatan, dan cakupan beta

OpenRouter melaporkan bahwa evaluasi menambahkan 279 milidetik pada median dan 334 milidetik pada persentil ke-90 dengan kumpulan aturan kompatibel Claude Code dimuat. Ini pengukuran yang dilaporkan vendor dalam kondisi tersebut, bukan tolok ukur agen tertentu atau setiap kumpulan aturan. Setiap panggilan dievaluasi sekali sebelum dilepas atau diblokir. Evaluasi tidak dikenai biaya selama beta; OpenRouter menyatakan akan mengumumkan harga sebelum ketersediaan umum. Dokumentasi tidak menetapkan tarif mendatang.

Model keputusan dapat menghasilkan positif palsu dan melewatkan pelanggaran karena menilai aturan dalam bahasa biasa terhadap argumen dalam bahasa biasa. Dokumentasi menyarankan penggunaan putusan audit pada lalu lintas nyata serta penyesuaian ambang tiap aturan. Evaluasi Armor belum didukung untuk permintaan HIPAA, Zero Data Retention, atau yang dibatasi wilayah data. Permintaan dengan plugin aktif dalam salah satu konteks itu mendapat 403; permintaan Claude Code justru melepas panggilan sebagai unavailable, lalu Claude Code beralih ke evaluasi mode otomatis lokal. Peringatan beta juga mencakup perubahan pada bidang konfigurasi, safeguard_results, dan tipe item openrouter:armor_blocked.

Armor memeriksa usulan panggilan pada saat penyerahan dari model ke aplikasi. Ini menjadikannya mekanisme yang berbeda dari pembatasan perintah MXC milik Microsoft dan kontrol runtime OpenShell dan Sentry milik NVIDIA, yang menempatkan penegakan di sekeliling beban kerja atau aksesnya. Untuk Armor, keputusan implementasi langsungnya adalah apakah format respons yang dipilih menahan panggilan bertanda atau mengharuskan klien menghentikannya.

Sumber dan bacaan lanjutan

• Dokumentasi OpenRouter Armor, diakses 17 Oktober 2026. Sumber primer untuk status beta, urutan pengklasifikasi, prioritas aturan, kontrak respons API, perilaku kesalahan, pengecualian konteks privasi, latensi yang dilaporkan, serta penagihan beta. Ini klaim yang didokumentasikan OpenRouter; BIG CHANGE tidak menjalankan plugin.
• BIG CHANGE tentang Microsoft MXC menjelaskan pembatasan berbasis kebijakan untuk perintah buatan agen. Artikel itu menjelaskan lapisan penegakan terpisah, bukan fase awal Armor.
• BIG CHANGE tentang NVIDIA OpenShell dan Sentry menjelaskan kontrol akses perangkat lunak dan desain pemantauan perangkat keras opsional. Ini konteks terkait, bukan kelanjutan langsung fitur OpenRouter ini.