Kapsam ve tehdit modeli

Klasik sızma testinde kapsam çoğu zaman IP ve alan adı listesidir. LLM testinde liste uzar: model sağlayıcısı, sistem promptu, belge deposu, araçlar, arayüz ve günlükler. Bunların bir kısmı üçüncü tarafa aittir ve ayrı izin ister. Altay Kargo'nun müşteri asistanını düşün.

Asistan gönderi sorgular, iade açar ve müşteri yorumlarından öğrendiklerini yanıtlara katar. Güvenlik ekibi bu asistanı test etmek istiyor. İlk soru "hangi istemi deneyelim" değildir.

İlk soru şudur: test neyi kapsıyor, neyi kapsamıyor ve hangi sonuç kritik sayılıyor? Cevabı tek sayfalık bir kapsam notu verir. Not beş parçadan oluşur: envanter, güven sınırı, tehdit aktörü, etki eşiği ve angajman kuralları.

NIST SP 800-115, sızma testini dört aşamada anlatır: planlama, keşif, saldırı ve raporlama. Planlamada kuralları belirler, yönetim onayını alır ve hedefleri yazarsın. LLM testi bu iskeleti miras alır, ama planlama ağırlaşır.

OWASP'ın üretken yapay zekâ kırmızı takım rehberi (GenAI Red Teaming Guide) işi dört alana böler. Model değerlendirmesi modelin kendi zaaflarına, örneğin önyargı ve dayanıklılığa bakar. Uygulama testi prompt ve guardrail'lerin üretimdeki etkisini ölçer.

Sistem değerlendirmesi tedarik zincirini, dağıtım hattını ve veri güvenliğini inceler. Çalışma anı analizi ise çıktının insanlarla ve bağlı sistemlerle etkileşimine bakar. Kapsam notun bu alanlardan hangisine girdiğini açıkça yazar.

Planlamanın ilk ürünü varlık envanteridir. Hangi model kullanılıyor, hangi sürümde? Hangi araçlar bağlı ve hangi yetkiyle çalışıyor? Hangi veri kaynakları bağlama giriyor?

Kim hangi kiracıda (tenant) duruyor? Envanter çıkmadan yapılan test yalnız sohbet kutusunu yoklar. Asıl risk ise çoğu zaman belge deposunda ya da araçların yetkisinde saklanır.

Envanteri her bileşenin sahibiyle birlikte yaz. Her sahip ayrı bir izin ve ayrı bir düzeltme ekibi demektir.

# varlık envanteri: Altay Kargo müşteri asistanı
bileşen              sahibi           yetki / not
model API            sağlayıcı        kiracıya özel anahtar
sistem promptu       ürün ekibi       sürüm denetiminde
RAG deposu           içerik ekibi     SSS + müşteri yorumları
araç: gonderi_sorgu  kargo ekibi      salt okuma, takip no ile
araç: iade_ac        ödeme ekibi      yazma, 500 TL üst sınır
günlükler            güvenlik ekibi   istem + yanıt, 90 gün

Tabloyu satır satır oku. Model API'sinin sahibi sağlayıcıdır. Onun altyapısına yönelik test ayrı izin ister ve çoğu zaman kapsam dışı kalır.

Sistem promptu sürüm denetimindeyse hangi sürümü test ettiğini kesin yazabilirsin. RAG deposuna müşteri yorumları giriyor. Yani herkes indekse metin yazabilir ve belge hattı ayrı bir giriş noktası olur.

İki araçtan yalnız iade_ac yazma yetkisi taşır. Kritik etki büyük olasılıkla bu satırdan doğar, çünkü işin ucunda para hareketi var. Son satır tespit tarafını gösterir. Günlük yoksa testte bulduğun davranışı üretimde kimse göremez.

Envanterin üstüne tehdit modeli kurarsın. Tehdit modellemesi dört soruya dayanır. Ne üzerinde çalışıyoruz?

Ne ters gidebilir? Buna karşı ne yapacağız? İşi yeterince iyi yaptık mı? Test ekibi en çok ilk iki soruda çalışır.

Son iki soruyu savunan ekiple birlikte cevaplar, çünkü önlemi uygulayacak olan o ekiptir. İlk sorunun cevabı bir çizimdir. OWASP'ın tehdit modelleme kılavuzu bunun için veri akış şeması (data flow diagram, DFD) önerir. Şemada beş öğe bulunur: dış varlık, süreç, veri deposu, veri akışı ve güven sınırı.

Güven sınırı, verinin güvenilirlik düzeyinin değiştiği yerdir. Kullanıcı girdisi, getirilen belge ve araç çıktısı sınırın dış tarafındadır. Sistem promptu, sunucudaki yetki kontrolü ve yapılandırma iç tarafta durur.

Sınırı geçen her ok bir soru doğurur: bu veri nerede doğrulanıyor? Altay Kargo örneğinde müşteri yorumu dışarıdan gelir, indekse yazılır ve haftalar sonra bir yanıtın bağlamına girer. Ok uzun olduğu için sınır kolay gözden kaçar. Şemayı çizerken her okun kaynağını ve hedefini yaz.

Şemada model tek kanal okur. Sistem promptu, kullanıcı mesajı ve dış belgeden gelen metin aynı bağlama yazılır.

Model hangisinin talimat, hangisinin veri olduğunu kesin biçimde ayıramaz. Bu yüzden modelin okuduğu her dış kaynak, test planında ayrı bir giriş noktası olur. Araç çıktısı da bu listeye girer, çünkü sonuç yeniden modele döner.

Sık yapılan bir hata da sistem promptunu sır kasası saymaktır. Prompt senin denetimindedir, ama içine koyduğun parola modelin yazabildiği her yere taşınabilir. Sırrı prompta değil, sunucu tarafına koy.

İkinci soruyu sistemli cevaplamak için STRIDE'ı kullanırsın. Ad, altı tehdit sınıfının baş harflerinden oluşur. İlk üçü kimlik sahteciliği (Spoofing), kurcalama (Tampering) ve inkârdır (Repudiation). Son üçü bilgi ifşası (Information disclosure), hizmet engelleme (Denial of service) ve yetki yükseltmedir (Elevation of privilege).

Şemadaki her öğeyi ve her oku bu altı soruya tutarsın. OWASP rehberi bir sınır da çizer: STRIDE önyargı ya da zararlı içerik gibi toplumsal riskleri kapsamaz. Model bir müşteriye hakaret ederse STRIDE satırlarının hiçbiri bunu yakalamaz. Bu riskleri tablonun altına ayrı satır olarak yaz.

# STRIDE: Altay Kargo asistanı
S kimlik sahteciliği : asistan başka müşterinin takip numarasıyla sorgu yapıyor
T kurcalama          : müşteri yorumu indekse talimat taşıyor
R inkâr              : iade_ac çağrısının oturum kimliği kaydedilmiyor
I bilgi ifşası       : yanıtta başka müşterinin adresi görünüyor
D hizmet engelleme   : uzun istemler jeton bütçesini tüketiyor
E yetki yükseltme    : sohbetteki metin iade_ac aracını tetikliyor

Her satır bir test senaryosuna dönüşür. S satırı yetki kontrolünün modelde mi, sunucuda mı yapıldığını sorar. Takip numarasının sahibini sunucu doğrulamıyorsa model ikna edilerek başkasının gönderisi sorgulanabilir.

T satırı yorumların indekse hangi denetimle girdiğini sorar. R satırı tespitin ön koşuludur: araç çağrısı oturum kimliğiyle kaydedilmezse olaydan sonra kimin ne yaptığını kanıtlayamazsın. I ve E satırları en ağır etkiyi taşır.

Biri veriyle, öbürü para hareketiyle ilgilidir. D satırı ise fatura üretir. Tablodaki her satıra bir savunma sahibi de ekle.

Tablonun yanına tehdit aktörlerini koyarsın. Anonim kullanıcı, kayıtlı müşteri, kötü niyetli çalışan ve belge deposuna yazabilen tedarikçi farklı yetkilerle gelir. Aktörün ilk hamlesi yetkisine bağlıdır. Anonim kullanıcı sohbet kutusundan doğrudan enjeksiyon dener.

Müşteri kendi yüklediği belgeye talimat gömer. Çalışan iç wiki sayfasını zehirler. Tedarikçi ise paylaşılan veri akışına yük ekler.

Modelle hiç konuşmadan, okunacak metne talimat bırakmaya dolaylı enjeksiyon denir. Her aktör için ayrı senaryo yaz. Yoksa test yalnız en kolay aktörü ölçer ve rapor yanıltıcı bir güven verir.

Asistan araç çağırıp kendi başına adım atmaya başlayınca şema büyür. Cloud Security Alliance, Şubat 2025'te bunun için MAESTRO çerçevesini yayımladı. Ad, Multi-Agent Environment, Security, Threat, Risk and Outcome ifadesinin kısaltmasıdır. Çerçeve ajanlı sistemi yedi katmana böler: temel modeller, veri işlemleri, ajan çerçeveleri, dağıtım ve altyapı, değerlendirme ve gözlemlenebilirlik, güvenlik ve uyum, ajan ekosistemi.

Güvenlik ve uyum katmanı dikeydir ve öbür altısını keser. Yazarına göre klasik yöntemler ajanın öngörülemez davranışını ve ajanlar arası etkileşimi tam karşılamaz. MAESTRO bu boşluğu katman katman doldurmayı dener.

Pratikte her katmana aynı soruyu sorarsın: burada ne ters gidebilir? Altay Kargo'nun iade ajanını düşün. Temel model katmanında jailbreak dayanıklılığı durur.

Veri işlemleri katmanında RAG indeksi, ajan çerçevesi katmanında araç tanımları ve onay kapısı yer alır. Dağıtım katmanında anahtarların nerede saklandığına, gözlemlenebilirlik katmanında araç çağrılarının kaydına bakarsın. Ekosistem katmanı ajanın konuştuğu öbür ajanları ve dış servisleri kapsar.

Katman listesi kapsam notunda bir kontrol listesi gibi çalışır. Boş kalan katman ya kapsam dışıdır ya da unutulmuştur. İkisini ayırt etmek için durumunu açıkça yaz.

Sonraki iş etki eşiğini yazmaktır. Hangi sonuç kritik sayılır: kişisel veri kaçağı, başka kiracının verisine erişim, para hareketi ya da üretim verisinde değişiklik? Eşiği önceden yazarsan rapor tartışması görüşe değil, ölçüte oturur. Yıkıcı testlerin sınırını da belirle.

Sınırsız tüketim denemesi gerçek fatura üretir. Zehirli belge denemesi üretim indeksini kirletir. Araç denemesi gerçek e-posta gönderebilir ya da gerçek iade açabilir. Bu üç aile için ayrı ortam, ayrı kota ve geri alma planı iste.

Bu kurallar angajman kurallarında (rules of engagement) toplanır. OWASP rehberi onları üç gruba ayırır. Operasyonel yönergeler test ortamını, onaylı araç ve teknikleri, belgeleme standardını, iletişim protokolünü, yükseltme ve acil durum adımlarını kapsar.

Emniyet kontrolleri (safety controls) veri işleme kurallarını, model erişim denetimini, çıktı izlemeyi, olay müdahalesini ve geri alma yeteneğini kapsar. Etik sınırlar ise hassas konuları, gizliliği ve mevzuat gereklerini çizer. Kurallar denenecek her istemi tek tek listelemez. Tekniği onaylar ve sınırı çizer.

Bir de zamanlama var. Sağlayıcılar takma adın (alias) arkasındaki modeli zamanla günceller ve dünkü davranış bugün değişebilir. Bu yüzden her denemeye tarih ve tam sürüm kimliği yaz. Test penceresini kısa tut, uzarsa ölçümler farklı modellere ait olabilir.

Kapsam notunun son satırı dışarıda kalan alanlardır. Onları açıkça yazmak raporu savunulabilir kılar. Müşteri "sistem güvenli mi" diye sorduğunda cevabın bu listeye dayanır. Test edilmeyen bir alanı güvenli saymak, en sık görülen rapor hatalarından biridir.

# kapsam notu
Kapsam       : asistan arayüzü, 2 araç, RAG deposu, günlükler
Aktörler     : anonim, müşteri, çalışan, tedarikçi
Kritik etki  : çapraz kiracı veri erişimi, para hareketi
Kapsam dışı  : sağlayıcı altyapısı, model ağırlıkları
Sürüm        : asistan 3.2, model anlık görüntüsü 2026-08

Aynı yöntem yalnız müşteri sohbetine özgü değildir. İç ekibe açık bir asistan düşün. Takvime ve e-postaya erişiyor, belge deposundan özet çıkarıyor.

Envanter, güven sınırı, aktör ve etki eşiği yine aynı sırayla yazılır. Bu kez kritik etki büyük olasılıkla onaysız giden bir e-posta ya da başka birimin belgesine erişimdir. Kapsam dışına da kurumsal e-posta sunucusunu ve sağlayıcının altyapısını yazarsın. Araç adlarını tek tek saymak, testin hangi düğmelere dokunabileceğini herkese baştan gösterir.