Gizli veride paylaşımlı yapay zeka mı, kendi sunucunuz mu?

Cloudflare'de tam olarak ne oldu

Cloudflare'in yayımladığı olay raporuna göre 27 Ağustos ile 9 Eylül 2026 arasında Workers AI üzerindeki GLM 5.3 modelini kullanan bazı müşteriler, aynı modele kısa süre önce başka müşterilerin gönderdiği isteklerden veri içeren yanıtlar aldı. Etkilenen yanıt sayısı 155. Bunların hepsi 681.280 token'dan uzun istemlere verilmiş yanıtlardı. Cloudflare, kasıtlı bir istismara dair kanıt bulmadığını söylüyor.

Zaman çizelgesi oldukça net. Model 27 Ağustos'ta yayına girdi ve açık ilk günden beri oradaydı. HackerOne üzerinden gelen rapor 8 Eylül saat 23.11'de ulaştı, 9 Eylül 13.22'de güvenlik olayı ilan edildi. Ürün güvenliği ekibi sızıntıyı iki bağımsız hesapla 25 dakika içinde yeniden üretti ve model, olay ilanından sonraki 40 dakika içinde devreden çıkarıldı. Aynı gün düzeltilmiş yapılandırma ve yamalı bir motorla hizmet geri açıldı.

Tepki süresi gerçekten iyi. Beni asıl düşündüren kısım ise açığın iki hafta boyunca kimseye görünmemesi. Hatayı bildiren Knostic'in yazısına göre anormal yanıt HTTP 200 ve success: true ile döndü, üstelik 103.604,64 neuron olarak eksiksiz faturalandı. Yani hiçbir izleme paneli kırmızıya dönmedi. Model başka birinin bağlamıyla cevap verirken kullanıcı bunu sıradan bir halüsinasyon sanabilirdi.

İki küçük karar birleşince açılan kapı

Sızıntının ilk ayağı bir yapılandırma tercihi. Cloudflare, GLM 5.3'ü 1.048.576 token'lık bağlam penceresiyle sundu, ama prefill GPU'larındaki KV önbellek havuzu yalnızca 681.280 token alabiliyordu. Şirket kendi raporunda bu uyumsuzluğu lansmandan önce bildiğini açıkça yazıyor.

İkinci ayak açık kaynaklı SGLang çıkarım motorundaki bir hata. Cloudflare bu modelde prefill ve decode aşamalarını ayrı GPU'larda çalıştırıyor; Unite.AI'ın aktardığına göre prefill GPU'ları KV önbelleğini Mooncake aracılığıyla RDMA üzerinden decode GPU'larına aktarıyor. Önbellek, istekler arasında sıfırlanmayan sabit boyutlu sayfalardan oluşan ortak bir havuz. Hangi sayfanın hangi isteğe ait olduğunu motorun kendisi takip etmek zorunda. Havuza sığmayan bir istem iptal edilmek yerine reddedildi olarak işaretlenip tek token'lık bir yer tutucuyla değiştirildi; decode tarafı 'aktarım tamamlandı' mesajını alınca önceki önbelleğin üzerine yazıldığını varsaydı, oysa önceki kullanıcının durumunun büyük kısmı hâlâ oradaydı.

Hikâyenin en öğretici detayı şu: aynı SGLang hatası 6 Temmuz 2026'da başka bir kullanıcı tarafından #30233 numaralı kayıtla zaten bildirilmişti ve Cloudflare bu kaydı ancak olayı incelerken buldu. Diğer ayrık Workers AI kurulumları etkilenmedi, çünkü onlarda KV havuzu bağlam uzunluğundan büyük. Upstream tarafında PR #36988 (v0.5.20) iptal edilen prefill isteklerini decode'a ulaşmadan emekliye ayırıyor, PR #38935 (v0.5.21) ise bu istekleri kabul aşamasında reddediyor.

Buradan çıkardığım ders basit. Paylaşımlı çıkarımda kiracılar arasındaki izolasyon fiziksel bir duvar değil, yazılımın tuttuğu bir defter kaydı. Defterde tek bir satır yanlış olduğunda komşunuzun verisi sizin ekranınıza düşebiliyor.

Önbellek paylaşımı neden başlı başına bir risk

KV önbelleği, modelin daha önce işlediği token'lara ait ara hesapları saklayarak aynı öneki tekrar hesaplamaktan kurtarır. Bu ciddi bir verim kazancıdır, ama ortak bir havuz demektir. vLLM'in tasarım belgesine göre önek önbellekleme hash tabanlı çalışıyor: KV blokları kendi token'ları ve öncesindeki önekle birlikte hash'leniyor. Paylaşımlı ortamlarda gizliliği artırmak için istek başına isteğe bağlı bir 'salt' desteği de var.

Cloudflare olayı doğrudan içerik sızıntısıydı, fakat önbelleğin daha sessiz bir riski de var. Stanford araştırmacılarının çalışması, önbellekteki istemlerin daha hızlı işlendiğini ve önbellek kullanıcılar arasında paylaşılıyorsa saldırganın yanıt süresine bakarak başkalarının istemleri hakkında bilgi edinebileceğini gösteriyor. Ekip, gerçek LLM API'lerinde önbelleklemeyi tespit eden istatistiksel denetimler geliştirdi.

vLLM'in güvenlik rehberi de önek önbelleğinin yeniden kullanımını bir zamanlama yan kanalı olarak tanımlıyor (CVE-2025-46570) ve cache_salt için 'izolasyon sınırı değildir' diyor; bu ifadeyi aktaran bir ağ geçidi yaması salt'ları kiracı bazında (kuruluş, ekip veya anahtar) ayırarak kiracıların ortak önbelleği paylaşmasını engelliyor. Daha yeni bir makale ise sağlayıcıların çoğunun artık hesap veya kuruluş bazında önbellekleme yaptığını, ancak OpenRouter gibi ağ geçitlerinin araya girdiği ek katmanın bu izolasyonu aşabileceğini ve ilk token süresini ölçen bir saldırganın önbellekteki istemi token token yeniden kurabileceğini belirtiyor.

Kısacası iki ayrı risk sınıfı var. Birincisi Cloudflare'deki gibi bir hatanın doğrudan veri döktüğü durum. İkincisi tasarım gereği paylaşılan bir önbelleğin dolaylı yoldan bilgi sızdırması. Altyapı seçerken ikisini de hesaba katmak gerekiyor.

Büyük sağlayıcılar yazılı olarak ne vaat ediyor

Kurumsal API sağlayıcılarının belgeleri önbellek kapsamı konusunda artık oldukça açık. Okurken bakmanız gereken şey izolasyonun birimi: kuruluş mu, çalışma alanı mı, API anahtarı mı?

Burada bir uyarı yapmam lazım. Bu belgeler tasarım niyetini anlatıyor, hatasızlık garantisi vermiyor. Cloudflare'in de müşteri verilerini birbirine karıştırmak gibi bir niyeti yoktu; sızıntı bir yapılandırma tercihi ile bir motor hatasının üst üste binmesinden çıktı. Yine de önbelleği kuruluş düzeyinde ayıran bir sağlayıcıda, bir hatanın etki alanı tasarım gereği daha dardır.

• OpenAI belgelerine göre önbelleğe alınmış durumlar tekil makinelerde tutuluyor, kuruluşlar arasında paylaşılmıyor ve bölgesel işleme sınırlarının ötesinde yeniden kullanılmıyor.
• Anthropic belgelerine göre farklı kuruluşlar, aynı istemi gönderseler bile önbellek paylaşmıyor.
• Anthropic, Claude API, AWS üzerindeki Claude Platform ve Microsoft Foundry'de önbelleği çalışma alanı düzeyinde de ayırıyor; Bedrock ve Google Cloud üzerinden yönetilen Claude'da ise ayrım yalnızca kuruluş düzeyinde.
• Araya bir ağ geçidi koyuyorsanız, sağlayıcının izolasyonunun ağ geçidi katmanında korunup korunmadığını ayrıca sorgulamanız gerekiyor.

Üç seçenek yan yana

Gizli iş yükleri için pratikte üç yol var. Maliyet için rakam vermeyeceğim, çünkü elimde güvenilir kaynaklı karşılaştırmalı fiyat verisi yok ve bu rakamlar model boyutuna, kullanım yoğunluğuna ve donanım seçimine göre çok değişiyor. Ama maliyetin yapısı ve operasyon yükünün kime düştüğü oldukça net.

Benim gözlemim şu: çoğu şirket bu kararı tek seferlik bir altyapı seçimi gibi ele alıyor. Oysa doğru soru 'hangi veri hangi katmana gidecek' sorusu. Aynı şirket pazarlama metinlerini paylaşımlı bir API'ye, yönetim kurulu tutanaklarını kendi sunucusuna gönderebilir ve gönderirse daha iyi eder.

• Paylaşımlı sunucusuz çıkarım: Token veya istek başına ödersiniz, boşta maliyet yoktur, operasyon yükü neredeyse sıfırdır. Buna karşılık donanımı ve çoğu zaman önbellek havuzunu başka müşterilerle paylaşırsınız; izolasyon tamamen sağlayıcının yazılımına ve yapılandırmasına bağlıdır. Cloudflare olayı tam olarak bu kategoride yaşandı.
• Ayrılmış bulut örneği: GPU'lar ve çıkarım süreci yalnızca sizin için çalışır, başka müşteriyle KV havuzu paylaşmazsınız. Boşta kalan kapasite için de ödersiniz, kapasite planlaması ve model sürüm takibi kısmen size geçer. Veri yine sağlayıcının veri merkezinden geçer, bu yüzden sözleşme ve veri işleme koşulları önemini korur.
• Yerel (on-premise) model: Veri binanızdan çıkmaz, kiracılar arası risk tanım gereği ortadan kalkar. Donanım yatırımı, enerji, yedeklilik, güvenlik yamaları ve motor güncellemeleri tamamen sizin sorumluluğunuzdadır. Kullanabileceğiniz model büyüklüğü de elinizdeki donanımla sınırlıdır.

Yerel kurulum kendiliğinden güvenli değil

Yerel modele geçmek riski sıfırlamaz, yalnızca etki alanını daraltır. Kendi sunucunuzda da büyük ihtimalle SGLang veya vLLM gibi aynı açık kaynak motorları çalıştıracaksınız. O SGLang sürümünü ayrık prefill/decode modunda, bağlam penceresi KV havuzundan büyük olacak şekilde kursaydınız, aynı hata sizin kurulumunuzda da ortaya çıkardı. Fark şu: sızıntı başka bir şirkete değil, şirket içindeki başka bir kullanıcıya giderdi.

Bu da hafife alınacak bir durum değil. İnsan kaynakları müdürünün bordro sorusunun bağlamı satış ekibindeki bir stajyerin ekranına düşerse, veri binadan çıkmamış olsa bile ciddi bir olay yaşamışsınız demektir. Bu yüzden şirket içinde çok kullanıcılı bir yerel model kuruyorsanız ekip veya departman bazında önbellek ayrımını, hatta hassas birimler için ayrı örnekleri düşünmek gerekir.

Operasyon tarafında dürüst olmak lazım. Cloudflare gibi büyük bir güvenlik ekibi olan bir şirket bile #30233 numaralı kaydı lansmandan önce görmedi. Tek kişilik bir BT ekibinin açık kaynak motorların sorun kayıtlarını düzenli takip edeceğini varsaymak gerçekçi değil. Yama disiplini oturtamayacak, kurulumu yapıp unutacak bir şirket için yerel model, kâğıt üzerinde daha güvenli görünüp pratikte daha riskli olabilir.

Yerel kurulumun doğru seçim olduğu durum, verinin gerçekten dışarı çıkmaması gerektiği ve bunu sürdürecek operasyon kapasitesinin (kendi ekibiniz ya da bakım sözleşmesi olan bir tedarikçi) bulunduğu durumdur. İkisinden biri eksikse ayrılmış bulut örneği çoğu zaman daha makul bir orta yoldur.

Hangi veri nereye gitmeli

Elimde hangi veri türünün hangi izolasyonu gerektirdiğine dair kaynaklı bir sınıflandırma yok, bu yüzden aşağıdakini bir uygulayıcının görüşü olarak okuyun. Benim ölçütüm şu: veri sızdığında kimin zarar göreceği ve bu zararın geri alınıp alınamayacağı. Yayımlanmış bir ürün açıklaması sızarsa kimse zarar görmez. Bir işten çıkarma görüşmesinin dökümü sızarsa zarar geri alınamaz.

Toplantı kayıtları bu açıdan özel bir yerde duruyor. Bir yönetim toplantısının dökümünde strateji, personel kararları, müşteri adları ve henüz açıklanmamış rakamlar aynı metinde bir araya gelir. Üstelik saatlerce süren bir toplantının dökümü uzun bir bağlam demektir; Cloudflare'deki sızıntının yalnızca çok uzun istemlerde tetiklendiğini hatırlayın. Bu tür içerik için yerel LLM seçeneğiyle kurulabilen Toplantı AI gibi araçlar, transkripsiyonu ve özetlemeyi veriyi şirket dışına çıkarmadan yapma imkânı veriyor.

Hukuki yazışmalar, disiplin dosyaları, sağlık bilgisi içeren İK kayıtları ve kamu kurumlarının iç görüşmeleri de aynı kefeye giriyor. Bunlarda paylaşımlı sunucusuz çıkarımı varsayılan seçenek yapmamanızı öneririm.

• Herkese açık veya yayımlanacak içerik: Paylaşımlı sunucusuz çıkarım yeterli.
• Şirket içi ama hassas olmayan belgeler: Önbelleği kuruluş veya çalışma alanı düzeyinde ayıran kurumsal bir API, araya ağ geçidi koymadan.
• Müşteri verisi ve ticari sırlar: Ayrılmış bulut örneği veya sözleşmeyle güvence altına alınmış izole bir kurulum.
• Yönetim ve kurul toplantıları, hukuk, İK disiplin ve sağlık kayıtları: Ayrılmış örnek ya da yerel model, departman bazında erişim ayrımıyla.

Karar vermeden önce sorulacak sorular

Cloudflare olayından sonra tedarikçiyle yapılacak görüşmelerin içeriği değişmeli. Genel 'verileriniz güvende' cümleleri yerine somut teknik sorular sormak gerekiyor. Aşağıdaki listeyi hem bulut sağlayıcısına hem de yerel kurulum yapacak ekibe yöneltebilirsiniz.

Bu sorulardan birine net cevap alamıyorsanız, o veri sınıfını o altyapıya göndermemek en sağlıklısı. Cevabı bilmemek de bir cevaptır.

• Önbellek hangi düzeyde ayrılıyor: istek, anahtar, çalışma alanı, kuruluş?
• Araya bir ağ geçidi giriyor mu ve o katman sağlayıcının izolasyonunu koruyor mu?
• Hangi çıkarım motoru ve hangi sürüm kullanılıyor, motorun sorun kayıtlarını kim takip ediyor?
• Bağlam penceresi ile KV havuzu kapasitesi uyumlu mu, sınırı aşan istekler reddediliyor mu?
• Başka bir oturumun içeriği yanıtta görünürse bunu kim, nasıl fark eder? Başarılı dönen bir HTTP 200 yanıtı bunu gizleyebilir.
• Yerel kurulumda güvenlik yamaları için sorumlu kişi veya sözleşme var mı?