Açık Uçlu Araç Katmanında Saldırı Yüzeyi

Araç adının bir saldırı yüzeyi olması

Bir bağlanan araç, modele adı ve açıklamasıyla tanıtır. Model, bu metni okur ve hangi araç uygun, buna karar verir. Yani aracın açıklaması, aslında modele yazılmış bir prompttur. Bu, protokolün temel bir özelliğidir ve tam da bu yüzden istismar edilebilir.

Kötü niyetli bir sunucu, açıklamasına “bu aracı her kullanımdan önce çağır” gibi talimatlar yazabilir, ya da zararsız görünen bir adla başka bir aracın işlevini taklit edebilir. Kullanıcı iki aracı yan yana görür; model ise birini diğerine tercih etmesi için yönlendirilmiştir.

Bu “tools poisoning” olarak anılır. En rahatsız edici yanı, tek bir araç eklenmesinin, modelin diğer araçlarla olan davranışını da değiştirebilmesidir. Yani zarar, tek bir bağlantının sınırlarında kalmaz.

Onay yorgunluğu ve sessiz yetki

Güvenlik tavsiyesi nettir: her yazma işleminde kullanıcı onayı iste. Pratikte onaylar o kadar sık çıkar ki, kullanıcı okumadan onaylamaya başlar. Arayüz, bir güvenlik kapısı olmaktan çıkıp bir sürtünme kaynağına dönüşür; kullanıcı onu kapatmak ister.

Saldırgan için bu, en kolay hedeftir: talimatı gizlemek yerine, onayı anlamsız kılmak. Bir ajan zincirinde otuzuncu onay penceresi, ilk pencere kadar koruyucu değildir; çünkü dikkat, kullanıcı tarafında tükenen bir kaynaktır.

Bu yüzden iyi kurulum, onayı seyreltmek yerine önemini artırmaktır: geri döndürülemez işlemlerde onay, geri kalanında otomatik; ve her onayda etkiyi tek cümleyle, somut olarak göstermek. “Bir şeye erişecek” değil, “bu dosyayı silecek”.

Talimat sızıntısı: prompt injection’ın dönüşümü

Bir aracın çıktısı, modele veri olarak girer. Oysa model, girdideki ayrımı biçimden öğrenir: bir web sayfasının metni ile sistem talimatı, aynı dizide yan yana durur. Sayfanın içine yazılmış “bunu yap” satırı, model için emir gibi okunabilir.

Araç bağlandığında bu sızıntı artık zararsız bir yanlış cevaba değil, gerçek bir eyleme dönüşebilir: bir verinin dışarı gönderilmesi, bir dosyanın değiştirilmesi, bir ödeme akımının başlatılması. Bu yüzden “enjektasyon + eylem yetkisi”, saldırı sınıfını tamamen değiştirir.

Teknik olarak çıkış yok gibidir; ama riski ciddi biçimde azaltan pratikler vardır: araç çıktısını veri olarak etiketlemek, zincir içindeki yetkileri daraltmak ve dış verinin tetiklediği yazma işlemlerini zorunlu insan onayına bağlamak.

Kayıt ve kimlik eksikliği

Geleneksel yazılım dünyasında bir paketin nereden geldiği, imzalı olup olmadığı ve kimin bakımı olduğu soruları, onlarca yıllık altyapıyla cevaplanır. Araç sunucularında bu altyapı çoğu yerde yok: herkes sunucu yayımlayabilir, adı kimse denetlemez, güncelleme sessizce davranışı değiştirir.

Bu, tedarik zinciri saldırısının doğrudan karşılığıdır. İlk günde zararsız olan bir araç, üç güncelleme sonra zararlı olabilir; çünkü kullanıcı tarafında bir sürüm kilidi ya da değişiklik bildirimi yoktur. Modelin “güvendiği araç” tanımı, donanmış bir nesne değil.

Kurumsal kullanımda pratik cevap, izin listesidir: yalnızca denetlenmiş, sürümü sabitlenmiş sunucular. Bu, protokolün esneklik vaadini kısmen iptal eder; fakat esneklik ile denetim arasındaki takas, her güvenlik mimarisinin kalbinde durur.

Kullanıcı için kontrol listesi

En yüksek getirili adım, araç sayısını azaltmaktır. Her ek bağlantı, bir yetenek değil bir yüzeydir; kullanılmayan araç, risk olarak kalır. Birçok olayda ihlale giden yol, haftalar önce “belki lazım olur” diye eklenmiş tek bir sunucudur.

İkincisi, yetki kapsamını daraltmaktır: bir araç yalnızca gereken klasörü görmeli, tek bir hesabı kullanmalı, yazma izni yoksa okumayla yetinmeli. Geniş yetkiler, hataları kazanılmaz hale getirir.

Üçüncüsü, kayıttır. Ajanın hangi aracı ne zaman çağırdığı ve hangi veriyi dışarı gönderdiği tutulmalı ve gözden geçirilmelidir. Kaydı olmayan bir ajan, bir denetim aracı değil, bir kör noktadır.

Sık sorulan sorular

Kaynakça

1. Araç bağlama protokolü zafiyetleriThe Register
2. Model güvenlik araştırmalarıAnthropic
3. Yapay zekâ uygulama güvenliğiOWASP