Hizalama, uygulama güvenliğinin yerine geçmez

Tez#

Model sağlayıcıları davranış sınırlarını belirgin biçimde iyileştirdi: zararlı istekler daha tutarlı reddediliyor, sistem talimatlarına uyum arttı, hassas alanlarda daha dikkatli davranılıyor. Bu ilerleme gerçek ve ölçülebilir. Sorun, bu ilerlemenin bir güvenlik mimarisi yerine konması.

Fark, garantinin türünde. Bir yetki denetimi kodda çalıştığında sonucu belirli: kullanıcının izni yoksa işlem yapılmıyor ve bu, girdinin ne olduğuna bağlı değil. Bir model reddi ise bir olasılık dağılımının sonucu: aynı istek farklı biçimde ifade edildiğinde, farklı bir dille sorulduğunda ya da bir bağlam içine gömüldüğünde sonuç değişebiliyor. Güvenlik mühendisliğinde bu ayrım temel: kontrol ya vardır ya yoktur. "Çoğu zaman engelliyor" bir kontrol tanımı değil, bir risk azaltımı — ve ikisi aynı yerde kullanılamıyor.

Bağlam: hangi koruma nereye ait#

Tablo, tipik koruma ihtiyaçlarını ve her birinin hangi katmanda çözülmesi gerektiğini gösteriyor. Model tarafına bırakılan her satır bir açık bırakıyor.

İkinci satır ajan sistemlerinde en sık yapılan hatanın tam hâli. Bir ajana silme yetkisi veren bir araç bağlanıyor ve güvenlik, sistem istemine yazılan "onay almadan silme yapma" cümlesine bırakılıyor. Oysa doğru kurulum aracın kendisine yalnızca okuma yetkisi vermek; silme gerekiyorsa ayrı bir araç ve ayrı bir onay akışı kurmak. Birinci yaklaşımda tek bir etkili istem yeterli, ikincisinde istem hiçbir şey değiştirmiyor.

Kanıt: model tarafına bırakılmaması gerekenler#

Aşağıdaki kontroller model davranışına bırakıldığında sistematik olarak açık kalıyor. Hepsinin kod karşılığı var ve hepsinin maliyeti düşük.

• Yetki: hangi kullanıcı hangi kaynağa erişebilir? Model talimatı bunu sağlayamıyor; sorgu düzeyinde filtre gerekiyor.
• İşlem kapsamı: araç yetkileri en az ayrıcalık ilkesine göre verilmeli. Geniş yetkili bir araca "dikkatli ol" demek kontrol değil.
• Bütçe: tur sayısı, token miktarı ve harcama sert sınırla kesilmeli. Modelin kendini durdurmasına güvenilmiyor.
• Çıktı temizliği: kişisel veri ve sır maskeleme çıktı yolunda yapılmalı; modele bırakıldığında kaçak oluyor.
• Girdi kaynağı ayrımı: kullanıcı mesajı ile araç çıktısı ayrı işaretlenmeli. Model bu ayrımı kendiliğinden korumuyor.
• İdempotanlık: aynı işlemin iki kez yapılmasını engelleyen anahtar kodda olmalı; model tekrar etmeyeceğine dair garanti vermiyor.
• Kayıt: denetim izi modelden bağımsız tutulmalı; model kendi eylemini rapor etmeyi atlayabiliyor.

Altıncı madde ajan akışlarında sessizce hasar üreten kontrol. Bir ajan bir ödeme işlemini başlatıyor, yanıt gecikiyor, ajan işlemin başarısız olduğunu düşünüp tekrar deniyor. İkinci deneme kodda bir idempotanlık anahtarıyla engellenmiyorsa işlem iki kez gerçekleşiyor. Bu, kötü niyet gerektirmeyen ve yalnızca kodda çözülebilen bir hata sınıfı.

Mekanizma: hizalamanın neden kontrol olmadığı#

Hizalamanın bir kontrol olarak sayılamamasının üç yapısal nedeni var ve üçü de eğitimle tümden giderilebilir değil.

Birincisi olasılıksal olması: model davranışı bir dağılımdan örnekleniyor ve dağılımın kuyruğunda istenmeyen davranışlar bulunuyor. İkincisi girdiye duyarlılığı: modelin sınırları, girdi metniyle etkileşime giriyor ve girdinin bir bölümü saldırganın kontrolünde olabiliyor — dolaylı istem enjeksiyonunda modelin okuduğu belge tam olarak bu. Üçüncüsü sürüme duyarlılığı: bir sürümde reddedilen bir istek, sonraki sürümde kabul edilebiliyor ve sağlayıcı bunu bir kırılma olarak duyurmuyor. Bu üç özellik bir arada, model davranışını izlenmesi gereken bir değişken kılıyor — sabit bir kontrol değil. Dolayısıyla doğru kullanım biçimi hizalamayı savunmanın son katmanı saymak değil, ilk katmanı saymak: yanlış istekleri azaltıyor, ama arkasında deterministik kontroller olmadan bir güvenlik duruşu oluşturmuyor.

Karşı görüş#

Üç itiraz var. Birincisi: bazı kontroller kodla ifade edilemiyor — "zararlı içerik üretme" bir yetki denetimine çevrilemez. İkincisi: her şeyi kodda kısıtlamak ajanın yararını yok ediyor; aşırı kısıtlı bir ajan iş yapmıyor. Üçüncüsü: hizalama yeterince iyileşti; pratikte atlatma denemeleri artık büyük ölçüde başarısız.

Ajanın yetkisini okumaya indirdik ve yazma işlemlerini ayrı bir onay akışına aldık. Atlatma denemeleri devam ediyor ama artık başarılı olsalar bile yapabilecekleri bir şey yok.

Birinci itiraz doğru ve tezin sınırını çiziyor: içerik kalitesi ve ton gibi kontroller model tarafına ait, çünkü kodla ifade edilebilir bir kural değil. Tez bunları kodda aramıyor; kodda çözülebilen kontrollerin modele bırakılmamasını söylüyor. İkinci itiraz gerçek bir denge sorunu ve alıntı pratik çözümü gösteriyor: kısıtlama yetkiyi kaldırmak değil, yetkiyi ayrı bir onay akışına bağlamak. Üçüncü itiraz ise ölçüyü yanlış yere koyuyor: atlatma denemelerinin başarısızlık oranı yükselse bile, bir kontrolün değeri başarı oranıyla değil garantinin türüyle ölçülüyor. Yüzde doksan dokuz engelleme, yüz binlerce istekte binlerce geçiş demek.

Sınırlar ve belirsizlik#

Bu analiz hizalama araştırmasının değerini azaltmıyor; onu bir mimari katman olarak konumlandırıyor.

• İçerik kontrolleri kodla ifade edilemiyor: bu alanda model tarafı tek seçenek ve bu bir eksiklik değil.
• Kod kontrollerinin maliyeti var: her kontrol bir geliştirme ve bakım yükü; önceliklendirme gerekiyor.
• Atlatma başarı oranı ölçülmedi: kendi sisteminizde bu oranı bilmeden önceliklendirme yapılamıyor.
• Aşırı kısıtlamanın ürün maliyeti ölçülmüyor: kaç meşru isteğin engellendiği genellikle izlenmiyor.

Sonuç#

Hizalama bir güvenlik özelliği ama bir güvenlik kontrolü değil. Olasılıksal, girdiye duyarlı ve sürüme bağlı olduğu için izlenmesi gereken bir değişken; sabit bir kapı değil. Bu üç özellik eğitimle tümden giderilebilir değil, dolayısıyla ayrım kalıcı.

Pratik kural basit: kodda çözülebilen hiçbir kontrol modele bırakılmaz. Yetki, işlem kapsamı, bütçe, çıktı temizliği, girdi kaynağı ayrımı, idempotanlık ve kayıt — yedisi de kodda çözülüyor. Model tarafına kalan şey ton, üslup ve içerik kalitesi; bunlar zaten kodla ifade edilemeyen kontroller. Doğru kurulumda hizalama savunmanın son katmanı değil ilk katmanı oluyor.

Ne yapmalı?#

1. 1Sistem istemindeki güvenlik cümlelerini listeleyin

   Her biri için sorun: bu kodda çözülebilir mi? Çözülebiliyorsa istemden kaldırıp koda taşıyın.

2. 2Araç yetkilerini en aza indirin

   Geniş yetkili bir araca "dikkatli ol" demek kontrol değil. Yazma işlemleri ayrı araç ve ayrı onay.

3. 3Bütçeyi sert sınırla kesin

   Tur, token ve harcama sınırı kodda olmalı; modelin kendini durdurmasına güvenilmiyor.

4. 4Çıktı maskelemeyi yola koyun

   Kişisel veri ve sır temizliği modele bırakıldığında kaçak oluyor.

5. 5İdempotanlık anahtarı ekleyin

   Ajan bir işlemi tekrar deneyebiliyor; tekrarı engelleyen anahtar kodda olmalı.

6. 6Denetim izini modelden bağımsız tutun

   Model kendi eylemini rapor etmeyi atlayabiliyor; kayıt çağrı yolunda tutulmalı.