OpenRouter'ın Armor koruma bariyeri agent tool call'larını denetliyor, ancak Claude Code modunda yalnızca işaretliyor

OpenRouter, beta aşamasında bir tool-call koruma bariyeri başlattı

15 Ekim'de OpenRouter, Armor'u beta aşamasına taşıdı: bir model ile onu yöneten uygulama arasında aracı görevi üstlenen, her tool call'u herhangi bir şey çalıştırılmadan önce düz İngilizceyle yazılmış kurallara göre değerlendiren bir güvenlik sınıflandırıcısı. Bir kurala uyan çağrı işaretlenir, modele hangi kurala takıldığı bildirilir ve çağrı çoğu yapılandırmada hiç çalışmaz. Gabriel Anhaia'nın dev.to'daki yazısı mekanizmayı adım adım anlatıyor; GIGAZINE lansmanı 16 Ekim'de ele aldı.

Bu garantiyi bozan bir mod var ve agent pipeline'ları kuran herkesin dikkat etmesi gereken ayrıntı tam olarak bu.

Bir karar nasıl üretilir

dev.to'da özetlenen Armor dokümantasyonuna göre her tool call, yapılandırılmış kurallarla ve konuşma bağlamıyla birlikte bir karar modeline gönderiliyor. Model, çağrının her kurala uyma olasılığını döndürüyor ve Armor bu skorları tek bir karara indiriyor: flagged veya not_flagged.

Lansman yazısı sınıflandırıcıyı, üretilmiş metin yerine tipli sonuçlar ve olasılıklarla yanıt veren yapılandırılmış bir karar modeli olan TypeSafe'in Jev'i olarak adlandırıyor; güncel sürüm olarak typesafe/jev-1.14 listeleniyor. Öne sürülen fikir şu: istenmeyen tool call'ları yakalamak için desen ve regex eşleştirmesi çoğu zaman yetersiz kalıyor ve OpenRouter, Armor'ın hem performans hem maliyet açısından Claude Code'un yerleşik otomatik mod sınıflandırıcısından daha iyi olduğunu iddia ediyor. explainx.ai'deki bir inceleme, bu karşılaştırmayı destekleyecek hiçbir test seti veya kıyaslama sayısı yayımlanmadığını belirtiyor; dev.to yazarı da Armor'ı kendisi test etmemiş.

Üç kural kademesi

Kurallar üç kademeye ayrılıyor:

• hard_deny, kullanıcı ne isterse istesin asla ilerlememesi gereken eylemleri kapsıyor.
• soft_deny, genellikle yanlış olan ama zaman zaman bilinçli olarak istenen eylemleri kapsıyor; bir eşleşme, bir allow kuralı da devreye girmediği veya kullanıcı o konuşmada tam olarak o hedef üzerinde tam olarak o işlemi açıkça istemediği sürece engelleniyor.
• allow hiçbir şeyi engellemiyor; soft-deny kurallarına istisnalar açıyor.

Armor ayrıca, kullanıcının konuşmada belirttiği ve henüz kaldırmadığı sınırlar için (örneğin inceleme yapılana kadar push atılmaması talebi) yerleşik bir soft-deny zorunlu kılıyor. Kurallar bir id, isteğe bağlı bir ad, talimatlar ve isteğe bağlı bir eşik taşıyor; deny kuralları için varsayılan eşik 0.6, allow kuralları için 0.7. Bir denetim modu her şeyi puanlıyor ama hiçbir şeyi zorunlu kılmıyor; bu sayede ekipler zorunlu kılmayı açmadan önce kuralları gerçek trafiğe göre ayarlayabiliyor. Bu mod Claude Code uyumluluk moduyla birleştirilemiyor.

Engellenen bir çağrı nereye düşüyor

Üç çıktı modu bir engellemenin nasıl görüneceğini belirliyor. Metinle, yani Chat Completions ve Responses üzerindeki varsayılan modda, engellenen çağrı asistan metnindeki bir işaretçiyle değiştiriliyor; Responses API'de custom_item ile ise openrouter:armor_blocked çıktı öğesine dönüşüyor. Her iki durumda da çağrı uygulama koduna hiç ulaşmıyor ve modele çağrının engellendiği ve aynı argümanlarla yeniden denenmemesi gerektiği bildiriliyor.

claude_code_compatibility adlı üçüncü mod Messages API için geçerli ve bir plugins girdisi yerine dangerous_tool_use türünde bir safeguards girdisiyle seçiliyor. Bu modda işaretlenen tool_use yanıtta kalıyor, safeguard_results dizisinde işaretleniyor ve zorunlu kılmaya istemciye geçiyor. Dokümanlar sonucu açık söylüyor: safeguard_results'u yok sayan bir Messages istemcisi işaretlenmiş bir çağrıyı çalıştırır. Bir istemcinin kontrol etmeyebileceği düşünülüyorsa dokümanlar bunun yerine output_mode text öneriyor. Claude Code'un kendisi bunu doğru şekilde ele alıyor: çağrıyı reddediyor ve is_error bir tool sonucu döndürüyor; asıl açık, kararı hiç okumayan elle yazılmış bir Messages istemcisidir.

Hata modları ve sınırlar

Karar modeli zaman aşımına uğradığında, hata verdiğinde veya karar verilemeyecek kadar büyük bir istek aldığında karar elde edilemiyor. Plugin isteklerinde on_error, varsayılan olan block ile log arasında seçim yapıyor. Claude Code modunda bu ayar geçerli değil: kararı elde edilemeyen çağrılar her zaman karar görünür şekilde serbest bırakılıyor ve karar istemciye kalıyor.

Dokümante edilmiş diğer sınırlar: Armor henüz HIPAA, Zero Data Retention veya veri bölgesi kısıtlamalı isteklerde kullanılamıyor. Bu isteklerde plugin istekleri 403 ile reddedilirken, Claude Code istekleri elde edilemeyen bir kararla serbest bırakılıyor ve Claude Code'un yerel otomatik mod denetimine düşüyor; yani Armor bugün o çağrıları taramıyor. Karar modeli yanlış pozitifler ve kaçırılmalar üretebiliyor; ayar düğmesi olarak kural başına eşik kullanılıyor. Claude Code uyumlu kural seti yüklüyken medyan gecikme tool call başına 279 ms, 90. yüzdelikte 334 ms arttı; bir agent turunun tetiklediği her çağrıda ödediği bir maliyet bu. Değerlendirme beta süresince ücretsiz, fiyatlandırma genel kullanıma açılmadan önce açıklanacak; yapılandırma alanları, safeguard_results nesnesi ve openrouter:armor_blocked öğe türü de hâlâ değişebilir.

Neden önemli

Agent pipeline'ları modellere giderek daha çok shell ve dosya sistemi erişimi veriyor ve tool call'ları sunucu tarafında yakalayan bir koruma bariyeri, istemci tarafı denetimlerin bir hata veya özel bir istemci bunları atladığında açık bıraktığı boşluğu kapatıyor. Armor'ın varsayılan tasarımı zorunlu kılmayı uygulamanın yukarısında tutuyor; Claude Code uyumluluk modu ise bilinen bir şekilde kararlara uyan bir istemci olduğu için bu sorumluluğu bilinçli olarak geri devrediyor. O uç noktaya kendi yaptığı bir Messages istemcisini yönlendiren herkes, safeguard_results'u okuma işini, çağrı başına gecikmeyle ve OpenRouter'ın hâlâ değişebileceğini söylediği beta dönemi API yüzeyiyle birlikte devralıyor.