LLMjacking, Çalınan Yapay Zeka API Anahtarlarının Bulut Faturasına Dönüşmesi

Kurumsal siber güvenlikte "kaynak kaçırma" (resource hijacking) yeni bir kavram değil. Kripto madencileri (cryptojacking) yıllarca müşterilerin CPU'sunu kendi kazancı için kullandı. LLMjacking aynı ekonominin yapay zeka çağrısındaki karşılığı: saldırgan, çaldığı bir bulut ya da model sağlayıcısı kimlik bilgisiyle sizin hesabınızdan inference satın alıyor. Fark, bu sefer ödemenin kripto değil fatura ve kota olarak yapılması.

Temel değerlendirme: LLMjacking bir "yapay zeka açığı" değildir. Temelinde çalınmış ya da yanlışlıkla dışarı verilmiş bir credential yatar. Modelin kendisiyle, prompt'la ya da ağırlıklarla ilgili hiçbir şey bozulmaz; bozulan şey ödeme hesabı ve kullanım kotasıdır. Bu yüzden savunması da ML ekibinin değil, kimlik ve bulut operasyon ekibinin işidir.

Neden Şimdi Bu Kadar Ciddi?

Üç değişiklik birleşti ve saldırının ekonomik profilini kökten değiştirdi:

1. Birim maliyet yüksek. Uzun bağlamlı, reasoning modunda, çoklu modal çağrılar tek istekte binlerce token yakar. Eski madencilikte saniyede hash sayısı vardı; burada saniyede token sayısı var ve saniye başına maliyet onlarca kat daha öngörülebilir.
2. Kota yoksa limit yok. Birçok hesap varsayılan olarak "kullan, ay sonunda öde" mantığında açılıyor. Bir kredi kartı ya da faturalı proje için doğal bir tavan yoktur; tavan, mutabakatın fark edilme hızıdır.
3. Anahtar artık her yerde. Mobil uygulama, tarayıcı eklentisi, kenar (edge) fonksiyon, otomasyon script'i, CI/CD adımı, bir analistin masaüstü notebook'u. Her yeni yüzey, sırrın istemci tarafına inme ihtimalini artırıyor.

Sonuç olarak saldırının getiri eğrisi değişti: eski credential stuffing'te saldırgan sizin verinizi çalar, bunu bir kez paraya çevirir. LLMjacking'te çaldığı kimlik bilgisi, tespit edilene kadar sürekli ve ölçekte üretken bir harcama makinesine bağlanır.

Anahtar Nereden Sızar?

Yıllık assessment'larda gördüğümüz sızıntı yolları, olasılık sırasıyla kabaca şöyle:

Dikkat: son iki satır en sık atlananlardır. Anahtarı siz vermemiş olabilirsiniz; ama fatura sizin üstünüze olabilir.

Saldırının Mekaniği

Tipik bir LLMjacking zinciri beş adımda ilerler:

1. Kimlik bilgisi ele geçirme. Yukarıdaki yollardan biriyle anahtar ya da OAuth token alınır.
2. Geçerlilik kontrolü. Saldırgan tek bir ucuz istek atar. Amaç modeli kullanmak değil, anahtarın canlı olduğunu ve hangi limitlere sahip olduğunu öğrenmektir.
3. Aracı katman kurma. Çoğu zaman anahtar doğrudan kullanılmaz. "LLM mixer" tipi arayüzler, çalınmış anahtarları havuzlayıp üçüncü taraflara satan ara proxy'ler üzerinden trafik üretilir. Bu, hem saldırganın IP'sini sizden uzaklaştırır hem de trafiği meşru görünen istemci kimlikleriyle (User-Agent, SDK sürümleri) doldurur.
4. Hacim üretme. Uzun sistem prompt'ları, tekrarlı üretim, büyük çıktı limitleri (max_tokens yukarıda), bazen synthetic data üretimi için döngüsel çağrılar. Amaç birim istekte maksimum token.
5. Yeni kimlik arayışı. Bir anahtar kotaları ya da bütçe alarmlarıyla sınırlandığında, saldırgan aynı sızıntı kaynağından yeni anahtar üretir. Tek bir depodan sızan 12 anahtar, 12 ayrı projenin faturasını yakabilir.

Bu mekaniğin en önemli sonucu şudur: saldırı, uygulamanızın en normal görünen davranışının taklididir. Güvenli bir istemciden, geçerli bir şemayla, yetkili bir anahtarla gelen istekler. Uygulama güvenlik testi (pentest) açısından bu, klasik "auth bypass" senaryolarından ayrışır; burada sınır ihlali uygulama katmanında değil, faturalama ve kimlik katmanında gerçekleşir.

Maliyet Matematiği

Karar vericilerin en sık sorduğu soru "ne kadar büyük olabilir" sorusudur. Rakam vermeden önce hesabı göstermek gerekir.

Kabaca: 100K girdi + 2K çıktı token'lık tek bir çağrı, orta sınıf bir frontier modelde onlarca cent'e mal olabilir. Böyle bir çağrı saniyede 4 kez giden 4 paralel iş, saatte ~14.400 istek üretir. Günde 20 saat çalışırsanız tek iş için aylık fatura, tek haneli binlerce dolardan altı haneli rakamlara taşınabilir. Üste üç iş, iki bölge, iki ayrı servis hesabı eklerseniz, "yüz binlerce dolar" tabiri abartı olmaktan çıkar.

Bu hesabın pratik karşılığı üç kısıt üretir:

• Limit, içeriden gelmeli. Sağlayıcının varsayılan kotası bir güvenlik kontrolü değildir; sadece bir fiyatlama aracıdır. Kendi tarafınızda harcama eşiği, kota ve anında devre kesici olmalı.
• Algılama süresi = hasar. 500.000 dolarlık hasarın çoğu, mutabakatın haftalık yapıldığı hesaplarda olur. Günlük mutabakat hasarı bir güne indirir; saatlik mutabakat bir saate.
• Fark edilebilirlik tasarlanmalı. Bir anahtarın "normal" kullanım profili bilinmiyorsa, anormal kullanım tanımlanamaz.

Tespit: Hangi Sinyal Gerçekten Çalışır?

Uyarı listelerinin çoğu gürültüdür. İşe yarayan sinyaller, harcama ve kimlik verisini birleştirenlerdir.

Kullanım profili sapmaları. Coğrafi veya zaman tabanlı anomaliler zayıftır (araçlar, proxy'ler bunları kolayca düzleştirir). Güçlü olan iş yükü şekli anomalisidir:

• Beklenenden uzun ortalama prompt ve tam max_tokens çıktı.
• Tek istemci kimliğinden gelen paralel istek sayısı.
• Normalde hiç olmayan bir model ailesine (ör. en pahalı reasoning modeli) ani yönelim.
• Durağan dönemlerde (gece, hafta sonu) lineer olarak artan token hacmi.

Anahtar kapsamı envanteri. Kaç aktif anahtar var, her biri hangi ortamda, hangisi son 90 günde kullanılmadı? Kullanılmayan anahtar bir risk, aktif bir masraf kalemi değil; silmek sıfır maliyetlidir.

Sır sızıntısı izleme. Public kod arama, depo geçmişleri, mobil uygulama paketleri (tersine çevrilmiş binary içindeki strings), JS bundle'ları ve yapılandırma dosyaları. Buradaki kritik ayrım: yalnızca HEAD taramak yetmez, geçmiş commit'ler de taranmalı; silinmiş bir anaftar çoğu zaman commit geçmişinde yaşamaya devam eder.

Faturalama akışı. Sağlayıcı faturalama API'si ile muhasebe sistemi arasındaki fark. Yüzde birlik bir sapma, tek başına en yüksek güvenlidir anormallik sinyalidir ve hiçbir SIEM entegrasyonu bunu kimlik bilgisi korelasyonu olmadan veremez.

Savunma: Sıralı ve Uygulanabilir

Aşağıdaki sıralama, efor/etki oranına göre dizilmiştir. Önce ucuz ve kesin olanlar.

1. Sırları istemci tarafından çıkarın. Tarayıcı ya da mobil uygulama doğrudan model sağlayıcısına gidememeli. Arkanızda bir proxy/gateway katmanı olmalı: kimliği uygulamanız taşır, anahtarı yalnızca o katman görür. Bu tek değişiklik, saldırı yüzeyinin büyük bölümünü kapatır ve size merkezi bir denetim kaydı noktası verir.

2. Anahtar başına bütçe ve kota koyun. Her kullanım alanı (kullanım durumu) kendi anahtarını almalı; anahtarın limiti, o kullanım durumunun gerçek maliyetinden hafif yüksek olmalı. Kurumsal e-posta ile alınan deneme kredilerini de kapsama alın — bunlar maliyet merkezi takibinde olmadığı için en sık unutulan kalemdir.

3. Rotasyonu zorunlu ve sıkıcı hale getirin. Uzun ömürlü statik anahtar yerine kısa ömürlü, otomatik dönen kimlikler. Rotasyonun otomatik olmayan yerde LLMjacking penceresi, bir sonraki insan hatasına kadar açıktır.

4. Kaynağı tek yere indirin. Sır yönetimi (secret manager) + ara yazılım (broker) + makul kimlik değişimi. "Kim, hangi rolle, hangi anahtarı alabilir" sorusunun yazılı bir cevabı olmalı.

5. Ölçün ve faturala. Kullanımı kimlik bazına indirin: kullanıcı/istemci/iş akışı başına token ve maliyet. Bu veri olmadan ne anomali tanımlayabilir ne de olay sonrası "etki alanı" sorusunu cevaplayabilirsiniz.

6. Olay müdahale prosedürünü yazın. Şüpheli anahtar için iptal et → değiştir → etki alanını çıkar → faturayı dondur/müdahale et → sağlayıcı ile mutabakat → kök neden. Bu adımların hangisinin kimde ve ne kadar sürede yapılacağı önceden belli olmalı; olay anında yazılmaz.

Karar Tablosu

Hangi Sorular Gerçekten Fark Yaratır?

Bir yapay zeka güvenlik değerlendirmesinde, LLMjacking riskini ölçmek için soracağımız sorular:

1. Model sağlayıcısına giden kaç ayrı kimlik bilgisi var ve sahipleri kim?
2. İstemci (tarayıcı/mobil/edge) doğrudan sağlayıcıya mı gidiyor, aracı katman var mı?
3. Anahtar başına harcama limiti ve kota tanımlı mı? Tanımlıysa kim değiştirebilir?
4. Bütçe aşımı uyarısı kime gidiyor ve ne kadar sürede aksiyon alınıyor?
5. Rotasyon periyodu nedir; rotasyon manuel mi otomatik mi?
6. Public kod ve depo geçmişi taraması yapılıyor mu, sonuçları kim kapatıyor?
7. Kullanım logları kimlik (kullanıcı/istemci/iş akışı) bazına indirgenebiliyor mu?
8. Faturalama API'si ile muhasebe verisi karşılaştırılıyor mu?
9. Şüpheli bir anahtarın saniyeler içinde iptal edilebilmesi için prosedür yazılı mı?
10. Deneme/hibe kredileri maliyet takibine dahil mi?
11. Üçüncü taraf "AI gateway", prompt yönetim veya analitik araçları hangi anahtarı tutuyor?
12. Sağlayıcı tarafında erişim kayıtları ne kadar süre saklanıyor, dışarı alınabiliyor mu?

Kontrol Listesi

• İstemci tarafında hiçbir model sağlayıcısı anahtarı yok.
• Her kullanım durumunun ayrı kimliği ve ayrı limiti var.
• Anahtar envanteri çıkarılmış, 90 gün kullanılmayanlar kapatılmış.
• Rotasyon otomatik; manuel rotasyon kalan yerler risk kaydına işlenmiş.
• Bütçe alarmlı; alarmın sahibi ve SLA'sı var.
• Public kod + depo geçmişi taraması otomatik ve kapatma akışı tanımlı.
• Kimlik bazlı token/maliyet ölçümü bir rapora dönüşüyor.
• Sağlayıcı faturası ile iç kullanım kaydı düzenli karşılaştırılıyor.
• LLMjacking olay müdahale prosedürü yazılı ve masaüstü tatbikatı yapılmış.
• Deneme kredileri ve promosyon hesapları maliyet merkezine bağlanmış.

Bu Yazıyı Ne Kadar Ciddiye Almalısınız?

Eğer uygulamanız bir model sağlayıcısına faturalı bir kimlikle gidiyorsa ve o kimlik istemciye ya da dağınık script'lere inmişse, mesele "olup olmayacağı" değil "ne zaman ve kaç para olduğu"dır. Bu tipik bir "gizli maliyet + gizli ihlal" birleşimidir: muhasebe birini, güvenlik diğerini görür; ikisi birleştirilmezse hiçbiri saldırıyı görmez.

Eresus Security, bu çalışma tipinde bulgu listesi üretmez; sızıntı yolunu, etkilenen kimlikleri, gerçek harcama eğrisini ve kapatma takvimini birlikte verir. Model ve agent güvenliği taraflarımız yapay zeka güvenliği hizmetleri ve prompt injection testi sayfalarında; sürekli doğrulama tarafı ise Eresus Guard platformunda anlatılıyor.

Sıkça Sorulan Sorular

LLMjacking ile klasik cryptojacking arasındaki fark nedir?

İkisi de çalınan kaynağı saldırganın çıkarı için kullandırır. Fark, kaynağın cinsinde: cryptojacking işlem gücü çalar ve hasar genelde performans düşüşü olarak görünür. LLMjacking ise satın alınabilir bir hizmet tüketir; hasar fatura ve kotada görünür, birim maliyet yüksektir ve hızla ölçeklenir. Ayrıca LLMjacking çoğu zaman meşru API çağrısı biçiminde geldiği için ağ tabanlı tespit araçlarına yakalanmaz.

Sadece kurumsal (enterprise) hesaplar mı risk altında?

Hayır. Riskin büyüklüğü faturalı limitle, olasılığı ise anahtarın ne kadar çok yüzeyle yayıldığıyla orantılıdır. Bireysel geliştirici hesapları, ajanslar ve startup'lar daha düşük limitlere rağmen genellikle daha savunmasızdır; çünkü limit, rotasyon ve izleme adımlarının çoğu kurulmamıştır. Deneme kredisiyle açılan hesaplar hem limitsiz hem takipsiz olabilir.

Sağlayıcının kendi korumaları yeterli değil mi?

Sağlayıcılar anormal kullanımı görmekte oldukça iyidir, ama hedefleri öncelikle kendi platformları ve ödeme riskidir. Sizin iş profilinizi, hangi ekibin hangi model ailesini kullandığını ve hangi harcamanın "normal" olduğunu bilmezler. Ayrıca bir sağlayıcı sizin adınıza fatura durdurduğunda veya anahtarı kapattığında, bunu sizden bağımsız öğrenmiş olursunuz. Yani kendi izleme ve limit katmanınız yine gerekir.

Bu risk bir sızma testi ile anlaşılır mı?

Kısmen. Pentest anahtarın istemciye inip inmediğini, geçmiş commit'lerde sızıntı olup olmadığını ve gateway olup olmadığını çok iyi yakalar. Yakalamadığı şey üretimdeki gerçek harcama eğrisidir. Bu yüzden iki çıktı birlikte olmalı: yapısal değerlendirme (kimlik nerede duruyor, kim alabiliyor) ve operasyonel gözlem (kullanım profili, mutabakat farkı). Sürekli gözlem, tek seferlik testten sonra eskir.

Sonraki Adım

Bu yazıdan sonra yapay zeka tedarik zinciri saldırıları, AI agent kimlik saldırı yolları ve sıfır güven mimarisi ile model koruması aynı kimlik disiplini üzerinden okunmalıdır. Üçü de aynı soruya farklı yerden bakar: bu sırrı kim taşıyor ve kim taşıyabilir?