LiteLLM 1.101.4: AI Güvenlik Katmanında Straiker v3 ve Sürüm Ayarı Düzeltmeleri

Bir yapay zekâ uygulamasının yanıt vermesi, güvenlik kontrolünün gerçekten çalıştığını göstermez. LiteLLM’in 1 Ekim 2026’da yayımlanan 1.101.4 sürümü, bu ayrımı somutlaştıran bir bakım güncellemesi. Straiker v3 güvenlik servisine geçişte oluşan kimlik doğrulama sorunlarını, paylaşılan API sürümü varsayılanlarını ve hatalı ayar yüzünden güvenlik katmanının devre dışı kalabildiği bir geçiş sorununu ele alıyor. Haber, yeni bir modelin daha iyi cevap üretmesi değil; mevcut modellerin önündeki denetim zincirinin doğru kurulması.

Buradaki değişiklikler özellikle LiteLLM’in 1.101.x kararlı dalını kullanan, model çağrılarını merkezi bir ağ geçidinden yöneten ekipleri ilgilendiriyor. Aşağıdaki değerlendirme resmî sürüm kaydı ve geliştiricilerin değişiklik belgelerine dayanıyor. Bu yazı için bağımsız bir Straiker kiracısında performans veya saldırı testi yapılmadı; kaynaklardaki test sonuçları ürünün her kurulumda aynı sonucu vereceği anlamına gelmiyor.

Ne değişti, neden önemli?

Sürümü hazırlayan değişiklik kaydı, üç düzeltmenin 1.101.x dalına geri taşındığını açıklıyor. Bunlar Straiker v3 platform bağlantısı, ortak ayarlardaki API sürümü varsayılanının düzeltilmesi ve Straiker için tanınmayan sürüm değerlerinin güvenli biçimde ele alınması. Aynı kayıtta bağımlılık kilidinde pyjwt sürümünün 2.14.0’a yükseltildiği de belirtiliyor. Bu son değişiklikten hareketle belgelenmemiş bir açık veya bütün güvenlik sorunlarının giderildiği sonucu çıkarılamaz.

Pratikte ilk sorun, yeni Straiker anahtarının eski servis yoluna gönderilmesiydi. Geliştiricilerin anlattığı önceki davranışta, yönetici anahtarı yenilediğinde güvenlik kontrolünden geçen model istekleri 401 hatasıyla sonuçlanabiliyordu. Düzeltme, uygun koşullarda v3 anahtarını v3 yoluna yönlendiriyor. Kullanıcı açısından bunun karşılığı, sohbet uygulamasının modelden bağımsız bir bağlantı hatası yüzünden kullanılamaz hâle gelmesini önlemek. Ancak bu, her 401 hatasının aynı nedenle oluştuğu anlamına gelmez.

Straiker v3: Anahtar, rota ve kayıtlı ayar birlikte düşünülmeli

Straiker v3 bağlantısının birincil kaydı, yeni anahtarların sk_agt_ önekiyle tanındığını ve sürüm açıkça seçilmemişse /api/v3/detect yolunun kullanıldığını anlatıyor. Eski anahtarlar için v1 yolu korunuyor. Böylece aynı güvenlik sağlayıcısının farklı API nesilleri arasında geçiş yapılabiliyor; uygulamanın model seçimini değiştirmek gerekmiyor.

Önemli istisna, daha eski sürümde oluşturulup veritabanına api_version: v1 olarak kaydedilmiş Straiker ayarı. Geri taşıma kaydına göre bu değer yeni anahtarla bile v1 rotasını seçmeye devam ediyor. Belgelenen çözüm, ilgili güvenlik katmanında sürümü açıkça v3 olarak ayarlamak. Dolayısıyla yalnız kapsayıcı imajını güncellemek yeterli olmayabilir: yapılandırma dosyası ile yönetim arayüzünden kaydedilmiş ayarın aynı şeyi söylediğini kontrol etmek gerekiyor.

Bir kurum içi destek asistanını düşünelim. Yönetici Straiker anahtarını döndürüyor, ama veritabanındaki eski sürüm alanı yerinde kalıyor. Kullanıcı ekranda yalnız “istek başarısız” görüyor; geliştirici model sağlayıcısını inceleyerek zaman kaybedebiliyor. Bu güncellemenin uygulanmasında asıl değer, hatayı doğru katmanda aramakta: anahtarın geçerliliği, seçilen API yolu ve güvenlik servisinin yanıtı ayrı ayrı izlenmeli.

Sağlıklı görünen sunucu, çalışan güvenlik kontrolü demek değil

Tanınmayan API sürümü düzeltmesi daha kritik bir operasyonel ayrıntıyı belgeliyor. Straiker v3 değişikliğinin getirdiği önceki doğrulama davranışında, örneğin başka bir sağlayıcıdan kopyalanmış tarih biçimindeki sürüm değeri Straiker yapılandırmasının yüklenmemesine yol açabiliyordu. Başlatma kaydında uyarı bulunmasına rağmen ağ geçidi çalışmaya devam ediyordu. Bu, 1.101.3’ün bütün kurulumlarında bulunan bir kusur olarak sunulmamalı; geri taşıma paketi, v3 geçişinin beraberinde getireceği bu sorunu da önlüyor.

Yeni davranışta yapılandırmadan gelen tanınmayan değer uyarıyla yok sayılıyor ve rota anahtarın önekine göre seçiliyor. Açıkça belirtilen v1 ve v3 değerlerinin davranışı korunuyor. Bunun sonucu “uygulama açıldı” kontrolünün neden yetersiz olduğunu gösteriyor: izleme sistemi, güvenlik servisinin gerçekten çağrıldığını da kanıtlamalı. Başarılı HTTP yanıtı tek başına koruma kanıtı değildir.

Burada ayrıntılı bir sınır da var. Kaynak, esnek davranışın yapılandırma girdisi için geçerli olduğunu; sınıfı doğrudan Python içinde oluşturan kodun tanınmayan değerleri hâlâ reddettiğini söylüyor. Hazır ağ geçidini çalıştıran ekip ile aynı bileşeni kendi uygulamasına gömen geliştirici bu nedenle aynı yükseltme testini kullanmamalı.

Azure Content Safety düzeltmesi aynı pakette ne arıyor?

Ortak API sürümü düzeltmesi, Javelin için kullanılan v1 varsayılanının Azure Content Safety ayarlarına sızmasını ele alıyor. Azure bu değeri kabul etmediğinde güvenlik çağrısı 404 dönebiliyor, sonuçta model isteği de başarısız olabiliyordu. Paylaşılan alanın varsayılanı boş bırakılıyor; sağlayıcı kendi uygun varsayılanını seçiyor. Belgede Azure için bu değer 2024-09-01, Javelin için v1 olarak açıklanıyor.

Bu düzeltme Straiker geri taşımasının önkoşulu: ortak alan kendiliğinden v1 ile dolarsa, “sürüm belirtilmediğinde anahtara bak” mantığı devreye girmiyor. Küçük görünen bir varsayılanın birden fazla sağlayıcıyı etkilemesi, çoklu model ağ geçitlerinin bakım zorluğunu gösteriyor. Kullanıcıya sunulan tek sohbet kutusunun arkasında model, ağ geçidi ve güvenlik servisi farklı sürüm kurallarıyla çalışabiliyor.

Gerçek kullanım için küçük ama anlamlı bir geçiş testi

Üretime geçmeden önce önerimiz, aynı yapılandırmanın bir kopyasında üç yolu sınamak: izin verilmesi gereken sıradan bir istek, kurum politikasının engellemesi gereken sentetik bir örnek ve güvenlik servisine ulaşılamayan kontrollü bir durum. İlkinde yanıtın gelmesi, ikincisinde beklenen engellemenin gerçekleşmesi, üçüncüsünde kurumun seçtiği hata politikasının uygulanması kontrol edilmeli. Bunlar bu yazıda çalıştırılmış testler değil, değişikliklerin kapsamından çıkan uygulama önerileri.

Test verisi gerçek müşteri kaydı olmamalı. İstek kimliği üzerinden model çağrısı, Straiker çağrısı ve uygulama yanıtı eşleştirilebilir; sırf hata ayıklamak için bütün konuşmayı kalıcı günlüklere yazmak gerekmez. Kaynaktaki örnekte izin verilen istekte 200 ve uygulanan güvenlik katmanını belirten başlık, engellenen istekte ise kurum mesajıyla 400 görülüyor. Kendi istemcinizin bu hatayı kullanıcıya anlaşılır biçimde göstermesi ayrıca kontrol edilmeli.

Geri taşıma kaydı, canlı akış kanıtının gerçek Straiker kiracısı yerine Straiker davranışını taklit eden yerel bir servisle üretildiğini açıkça belirtiyor. Bu, yönlendirme ve hata aktarımı için yararlı kanıt; gerçek kurum politikalarının doğruluğunu veya saldırı yakalama oranını ölçmüyor. Kurulumunuzu değerlendirirken bu iki kanıt türünü birbirine karıştırmamak önemli.

Maliyet, lisans ve gizlilik hesabı

1.101.4 etiketindeki lisans metni, belirtilen istisnalar dışındaki içeriği MIT lisansıyla sunuyor; enterprise dizinindeki içerik kendi lisansına tabi. Dolayısıyla açık kaynak bileşeni kullanabilmek, bütün kurumsal özelliklerin veya bağlı servislerin ücretsiz olduğu anlamına gelmiyor. Bu sürüm kayıtlarında Straiker için doğrulanmış bir fiyat tarifesi bulunmadığından burada birim maliyet verilmiyor.

Toplam gideri model tüketimi, ağ geçidinin barındırılması, güvenlik servisi ve işletim emeği birlikte belirler. Güvenlik kontrolü ek bir ağ çağrısı da oluşturabilir; gecikme ve maliyet etkisi kullanılan modlara ve trafik hacmine göre ölçülmeli. Güncellemenin herkese belirli oranda tasarruf sağlayacağına ilişkin kaynaklarda bir ölçüm yok.

Gizlilik tarafında önemli nokta, güvenlik servisine aktarılan içeriğin ayrı bir veri akışı olması. Straiker v3 değişiklik kaydı, belirli istek alanlarının aktarımını ve araç/MCP kimlik bilgilerinin maskelenmesini açıklıyor. Kimlik bilgilerinin maskelenmesi, mesajlardaki kişisel verilerin otomatik anonimleştirildiği anlamına gelmez. Hangi içeriklerin gönderildiği, saklama süresi, erişim yetkileri ve kurum sözleşmesi ayrıca değerlendirilmelidir.

Sonuç: Yükseltmenin hedefi daha akıllı model değil, doğrulanabilir denetim

LiteLLM 1.101.4, özellikle 1.101.x dalında Straiker v3’e geçen veya Azure Content Safety kullanan ekipler için incelenmeye değer. Eski kayıtlı ayarlar, açık API sürümü seçimi ve başlatma uyarıları yükseltme kontrolünün parçası olmalı. Sürüm sayfası Docker imzalarının doğrulanması için de talimat veriyor; imza doğrulaması kaynağa güveni destekler, yazılımın hatasız olduğunu kanıtlamaz.

En yararlı kabul ölçütü basit: uygulama yanıt verirken güvenlik katmanı gerçekten çalışıyor mu ve beklenen durumda isteği durduruyor mu? Bu sorunun yanıtı ancak kendi akışınızdan toplanan kanıtla verilebilir. Güncellemenin somut kazanımı, bu zincirde belgelenmiş uyumsuzlukları azaltması; model kalitesini artırdığı veya her riski ortadan kaldırdığı iddiası değil.