Transfer sonucu ve tehdit modelini neden değiştirdiği
Bir modele karşı optimize edilen adversarial pertürbasyonlar rutin olarak başka bir modeli bozar. Bu, kardeş checkpoint'lerin bir tuhaflığı değildir. Transfer; mimariler arasında, tokenizer'lar arasında ve söz konusu modelleri üreten farklı eğitim pipeline'ları arasında geçerlidir. Pertürbasyonun hedefin ağırlıklarını bilmesi gerekmez; yalnızca girdiyi, hedefin temsilinin çıktıyı değiştirecek şekilde kaydığı bir bölgeye taşıması yeterlidir.
Tek modelden oluşan bir uygulama için bu bir zahmetten ibarettir. Bir agent yığını için ise yapısaldır. Üretimdeki bir agent çalışması tek bir modelin içinde kalmaz. Yönlendirme yapar: sınıflandırma için ucuz bir model, planlama için daha büyük bir model, çıkarım için özelleşmiş bir model, nihai sentez için bir üçüncüsü. Her atlama yeni bir modeldir ve her atlama, transfer edilen bir pertürbasyonun yeniden girebileceği bir yerdir. Bu zincirdeki tek bir modeli sertleştirmek, saldırganın o segment için maliyetini artırır ve geri kalanı için hiçbir şey yapmaz. Yol açık kalır, çünkü yol zincirin kendisidir.
Sonuç rahatsız edici ama basit: pertürbasyon transfer oluyorsa ve yığın yönlendirme yapıyorsa, model model savunma stratejisi bir savunma değildir. Savunana yüklenen bir maliyettir.
Agent'lar transferi neden güçlendirir
Bir sohbet uygulamasında başarılı bir pertürbasyon kötü bir yanıt üretir. Bir agent'ta ise kötü bir eylem üretir. Fark, döngüdür.
Metin talimata dönüşür
Bir agent adımı, sonraki adımın yalnızca bağlam olarak değil, talimat olarak tükettiği metin üretir. Bir çalışmanın içinde "model çıktısı" ile "model girdisi" arasında katı bir sınır yoktur. Planlayıcının çıktısı, yürütücünün prompt'udur. Planlayıcının temsilini küçük bir miktar kaydıran bir pertürbasyon planı kaydırır ve kaydırılmış plan, downstream'deki her şey tarafından yetkili kabul edilir. Pertürbasyonun bir saldırı string'i olarak yeniden kodlamadan sağ çıkması gerekmez; makul bir talimat olarak sağ çıkar.
Argümanlar ayrıştırılmaz, üretilir
Araç argümanları model tarafından üretilir. Modelin bir değere ilişkin iç temsili kaydığında, yaydığı argüman da onunla birlikte kayar. Araç serbest biçimli string'leri kabul ediyorsa, bu kayma doğrudan çağrıya iner. /data/reports/q3 olan bir yol /data/reports/q3/../../secrets haline gelir, ya da bir alıcı adresi bir karakter kazanır, ya da sayısal bir eşik bir büyüklük mertebesi kayar. Model bunu yapmaya karar vermemiştir; kaydırılmış temsilinin önerdiğini yaymıştır. Aracın bakış açısından çağrı, meşru bir çağrıdan ayırt edilemez.
Devirler, ağ olayı olmadan sınırları aşar
Çok agent'lı sistemler bunu daha da kötüleştirir. Agent A, agent B'ye devrettiğinde, pertürbasyon aynı süreç içinde bir model sınırını aşar; ağ olayı yok, TLS sonlandırması yok ve egress log'u yok. Devri gören bir ağ kontrolü yerleştirilecek bir yer yoktur, çünkü devir bir fonksiyon çağrısıdır. Sürüdeki her model potansiyel bir yeniden giriş noktasıdır ve pertürbasyon her birinde yeniden güçlendirilebilir.
Araç sınırında savunma
Kalıcı kontrol noktası model değildir. Agent ile araçları arasındaki arayüzdür. Bu arayüz, çağrıyı hangi modelin ürettiğinden bağımsız olarak vardır ve kaydırılmış bir temsilin dünyada bir etkiye dönüşmeden önce yakalanabileceği son yerdir.
İlke, modele güvenilmeyen girdi üretimi olarak davranmaktır, çünkü o tam da budur. Model, aday argümanlar üreten bir bileşendir. Sınır, bu adayların kabul edilebilir olup olmadığına karar verir.
Tipli bir şemaya karşı doğrulayın, şekil uymuyorsa reddedin
Her araç çağrısı, yürütmeden önce açık bir şemaya karşı doğrulanır. Doğrulama, niyet üzerine değil şekil üzerinedir. Niyet sınıflandırması bir model problemidir ve modelin güvenlik açıklarını miras alır; şekil doğrulaması ise bir parser problemidir ve almaz. Şema, recipient'ın izin listesindeki bir alan adıyla eşleşen bir string olduğunu söylüyorsa, pertürbe edilmiş bir alıcı eşleşmeyi geçemez. Sınırın argümanın neden yanlış olduğunu bilmesi gerekmez. Doğru şekilde olmadığını bilmesi yeterlidir.
TOOL_SCHEMAS = {
"send_report": {
"type": "object",
"required": ["recipient", "report_id", "format"],
"properties": {
"recipient": {"type": "string", "pattern": r"^[^@]+@reports\\.internal$"},
"report_id": {"type": "string", "pattern": r"^RPT-[0-9]{6}$"},
"format": {"type": "string", "enum": ["pdf", "csv"]},
},
"additionalProperties": False,
}
}
Aralıkları ve numaralandırmaları kısıtlayın
Serbest biçimli string'ler, pertürbasyonların yaşadığı yerdir. Numaralandırma olabilecek her argüman numaralandırma olmalıdır. Her sayısal argüman sınırlı bir aralık taşımalıdır. Pertürbe edilmiş bir argüman böylece kabul edilen kümenin dışına düşer ve kendisi de transfer edilebilir olabilecek bir sınıflandırıcı tarafından değil, tasarım gereği reddedilir.
Her argümanda provenance zorunlu olsun
Her argüman metadata taşır: hangi adım üretti, hangi kaynaktan, hangi model altında. Provenance pertürbasyonu durdurmaz, ama başarısızlığı okunabilir kılar. Bir ret gerçekleştiğinde, provenance kaydı argümanın getirilmiş bir belgeden mi, bir kullanıcı turundan mı yoksa önceki bir model adımından mı geldiğini gösterir. Bu ayrım, düzeltmenin retrieval'da mı, girdi iş
Fail closed yapın ve retry'ı açık hale getirin
Reddedilen bir çağrı, gevşetilmiş bir şemayla sessizce yeniden denenmez. Fail closed yapar ve tipli bir hata yüzeye çıkarır. Agent yeniden deneyebilir, ancak retry kendi log'laması olan kasıtlı bir yoldur; kabul edilen kümeyi sessizce genişleten bir fallback değildir.
Bunun maliyeti
Ödünleşim gerçektir ve açıkça belirtilmelidir.
Şema bakımı, kendi inceleme ritmi olan birinci sınıf bir mühendislik görevi haline gelir. Her aracın bir şeması vardır, her şemanın bir sahibi vardır ve her şema değişikliği bir inceleme olayıdır. Bu bedava değildir. Bu, bu çeyrek yönlendirme tablosunda hangi modelin olduğuna bağlı olmayan bir kontrol noktasına sahip olmanın bedelidir.
Bazı meşru çağrılar fail closed yapar. Geçerli ama biraz sıra dışı bir argüman üretecek olan bir model artık reddedilir. Retry yolu açık, gözlemlenebilir ve sınırlı olmalıdır, yoksa sistem yetenek kaybediyor gibi görünür. Bu adımı atlayan ekipler, ret oranlarının düşük ama tamamlama oranlarının daha da düşük olduğunu keşfeder.
Kapsam, sertleştirilen prompt'larla değil, doğrulanan araç çağrılarıyla ölçülür. Bu, çoğu ekibin izlediğinden farklı bir metriktir ve dashboard'ların ne gösterdiğini değiştirir. Bir prompt sertleştirme dashboard'u, araç sınırı korumasızken sağlıklı görünebilir.
Ölçüm
Sınır, model sertleştirmesinin olmadığı şekillerde ölçülebilir.
- Staging'de bilinen transfer pertürbasyonlarını enjekte edin ve sınırdaki ret oranını kaydedin. Pertürbasyonlar bir modele karşı üretilir ve yönlendirilmiş yığına karşı yeniden oynatılır. Metrik, sınırın yürütmeden önce yakaladığı orandır.
- Aynı çalışmada bir araç zaten çağrıldıktan sonra kaç ret oluştuğunu izleyin. Bir etki yerleştikten sonra gelen ret bir kontrol değildir; bir log kaydıdır. Bu sayı sıfıra sürülmelidir ve sıfır olmayan herhangi bir değer, adımda çok geç konumlanmış bir sınıra işaret eder.
- Reddedilen argümanlarda provenance dağılımını kaydedin. Retler tek bir kaynakta kümeleniyorsa, sorun sınırın upstream'indedir ve şema, onu içererek üzerine düşeni yapıyordur.
Bu metriklerin hiçbiri model ağırlıklarına veya saldırganın optimizasyon prosedürüne erişim gerektirmez. Yalnızca sınırın var olmasını ve log tutmasını gerektirir.
Stratejik nokta şudur: model başına savunmalar, transfer edilebilir bir pertürbasyona karşı hareketli bir hedeftir. Araç sınırı ise aynı pertürbasyona karşı sabit bir hedeftir, çünkü çağrıyı hangi modelin ürettiğini önemsemez. Yalnızca çağrının kabul edilebilir olup olmadığını önemser. Bu, savunanın gerçekten tutabileceği bir özelliktir.