Üretime çıkmadan önce

Altay Kargo'nun ürün ekibi yeni bir iade asistanı hazırladı. Asistan müşterinin sorusunu okuyor, sipariş kaydına bakıyor ve uygun durumda iade talebi açıyor. Demo toplantısında her şey yolunda gitti ve ekip cuma günü yayına çıkmak istiyor. Güvenlik ekibinden görüş isteniyor ve iş sana düşüyor.

Soru basit: bu özellik canlıya hazır mı? Cevabı hisle veremezsin. Yayın öncesi değerlendirme belli bir sırayla ilerler.

Önce kapsamı yazarsın, sonra tehdit modelini çıkarırsın, sonra kontrolleri bir listeye bağlarsın. Kırmızı takım koşusunu önceden yazılmış bir eşikle karşılaştırır, en sonda yayın kapısını çalıştırırsın. Her adımın çıktısı bir sonrakinin girdisidir.

Yayın öncesi ilk iş kapsamı yazmaktır. Bu özellik ne yapar, ne yapmaz, hangi veriye erişir, hangi kullanıcıya açılır? Kapsam belirsizse tehdit modeli de belirsiz kalır ve test edeceğin şeyi seçemezsin.

Kapsamı yazarken üç sınırı somut koy. Veri sınırı, modelin hangi kaynaklardan okuduğunu söyler. Yetki sınırı, modelin hangi aracı çağırabildiğini ve bu aracın neyi değiştirdiğini söyler.

Kullanıcı sınırı ise özelliğe kimin eriştiğini söyler: oturum açmış müşteri mi, herkes mi, yoksa yalnız çağrı merkezi çalışanı mı? Her sınır saldırı yüzeyinin bir kenarıdır. Birini boş bırakırsan yüzey o yönde sınırsız kalır.

ozellik: iade-asistani
amac: Musterinin iade sorusunu yanitlamak ve uygun talebi acmak
veri_siniri:
  okur: [siparis_ozeti, iade_politikasi]
  okumaz: [odeme_bilgisi, musteri_notlari]
yetki_siniri:
  siparis_sorgula: salt okuma
  iade_talebi_ac: yazma, tutar <= 500 TL, insan onayi gerekir
kullanici_siniri: oturum acmis musteri, yalniz kendi siparisleri
sahip: musteri deneyimi ekibi
gozden_gecirme: her yeni arac ya da veri kaynagi eklendiginde

Belgeyi satır satır oku. Amaç satırı tek cümledir ve asistanın yapmayacağı her iş bu cümlenin dışında kalır. Veri sınırı iki liste tutar: okunan kaynaklar ve bilerek okunmayan kaynaklar.

Okumaz listesi gereksiz görünebilir. Ama altı ay sonra biri ödeme bilgisini eklemek istediğinde tartışmayı başlatan satır odur. Yetki sınırı her aracı ayrı yazar.

Sorgu aracı yalnız okur. İade aracı ise yazar, bu yüzden bir tutar sınırı ve insan onayı taşır.

Kullanıcı sınırı, müşterinin yalnız kendi siparişlerini görebileceğini söyler. Bu kural modelin içinde değil, aracın arkasındaki yetki denetiminde uygulanır. Son iki satır belgeye bir sahip ve bir gözden geçirme tetiği verir.

Bu sınırları atlayan ekipler genelde aynı hatayı yapar: özelliği geniş yetkiyle yayınlar, sonra daraltmayı erteler. Örneğin bir destek botu başta yalnız ürün açıklaması okusun diye kurulur. Birkaç ay sonra sipariş tablosuna da erişir, çünkü kimse yetkiyi gözden geçirmez. Bu kaymaya yetki sürüklenmesi denir.

Kapsam belgesi sürüklenmeyi önler, çünkü her yeni erişim yazılı bir karar ister. Sınırı önce sen çiz, sonra ekip genişletme talebini bu belgeye karşı tartışsın. Gerçek olaylarda sızıntının kaynağı çoğu zaman yeni bir saldırı tekniği değildir. Kaynak, kimsenin geri almadığı eski bir izindir.

Tehdit modeli kapsamın üstüne oturur ve dört soruya cevap arar. Ne üzerinde çalışıyoruz? Ne ters gidebilir? Buna karşı ne yapacağız?

Yeterince iyi yaptık mı? İlk sorunun cevabı kapsam belgesidir. İkinci soru için saldırganı ve giriş kanalını yaz. Dış kullanıcı sohbet kutusundan girer ve modeli kandırmaya çalışır.

İç kullanıcı yetkisini aşmak ister, örneğin başka bir bölgenin iadelerini görmek. Üçüncü taraf ise modele ulaşan bir belgeye, bir ürün yorumuna ya da bir e-postaya talimat yazar. Buna dolaylı enjeksiyon denir. Saldırgan modelle hiç konuşmadan sonuç alır.

Etkiyi de yaz. Bir açık gerçekleşirse ne olur? Yanlış cevap mı çıkar, kişisel veri mi sızar, para mı hareket eder, kayıt mı silinir? Etkiyi üç sınıfta toplamak işini kolaylaştırır: yanlış bilgi, veri sızıntısı ve kalıcı değişiklik.

Yanlış bilgi can sıkar ama çoğu zaman düzeltilebilir. Veri sızıntısı geri alınamaz, çünkü sızan bilgi artık başkasının elindedir. Kalıcı değişiklik ise para iadesi, hesap silme ya da e-posta gönderme gibi dünyada iz bırakan bir eylemdir.

En kötü etkisi para veya veri olan akışlar diğerlerinden önce sertleşir. İade asistanında bu akış, iade talebi açan araçtır.

Tehdit modelinde en sık hata, yalnız sohbet kutusunu düşünmektir. Saldırgan çoğu zaman en görünür kapıdan girmez. Asistanın okuduğu sipariş notu, kargo firmasından gelen durum mesajı ya da bilgi tabanındaki eski bir sayfa da modelin girdisidir.

Her girdi kaynağını tek tek say ve kimin yazabildiğini not et. Müşterinin yazabildiği her alanı saldırgan da yazabilir.

İkinci sık hata, etkiyi modelin cevabıyla sınırlamaktır. Gerçek etkiyi modelin söylediği değil, çağırdığı araç belirler. Tehdit modelini bu yüzden araç listesiyle yan yana oku.

Kontrol listesi, tehdit modelinden çıkan kararları denetlenebilir maddelere çevirir. Liste kısa ve karar verdirici olsun. Yirmi maddelik liste doldurulmaz, sekiz maddelik liste doldurulur.

Her madde evet veya hayır ile cevaplanabilsin, yoruma açık madde koyma. "Güvenlik yeterli mi?" gibi bir maddeye herkes farklı cevap verir. "Kalıcı değişiklik yapan araç insan onayına bağlı mı?" sorusunun ise tek cevabı vardır.

Listeyi kimin doldurduğu da önemlidir. Maddeyi özelliği geliştiren ekip doldurur, kanıtı ise güvenlik ekibi kontrol eder. Kanıtsız bir evet, boş bırakılmış bir maddeden farksızdır.

[ ] Kapsam yazili ve onayli mi
[ ] Tehdit modeli cikarildi mi
[ ] Arac yetkileri en az ayricalikla mi tanimli
[ ] Kalici degisiklik yapan arac insan onayina bagli mi
[ ] Girdi ve cikti kayitlari maskelenmis olarak tutuluyor mu
[ ] Kirmizi takim kosusu yapildi mi, esik asildi mi
[ ] Geri alma plani var mi
[ ] Kisisel veri isleniyorsa hukuk incelemesi tamam mi

Listedeki bir madde hayır dönebilir, ama bu her zaman yayını durdurmaz. Gerekirse istisna açarsın. İstisna kaydı dört şey içerir: hangi madde atlandı, riski kim üstlendi, hangi geçici önlem alındı ve madde ne zaman kapanacak.

Örneğin maskeleme kütüphanesi henüz hazır değilse ham kayıtların saklama süresini iki güne indirir, erişimi iki kişiyle sınırlarsın. Bu geçici önlemi yazar, riski ürün sahibinin üstlendiğini kaydeder ve kapanış için bir tarih koyarsın. İstisna sahibi olmayan bir hayır ise yayını durdurur, çünkü kimse sonucuna katlanmaz. Süresi geçmiş bir istisna da kapalı kapı sayılır.

istisna: IST-014
madde: 5 (girdi ve cikti kayitlari maskelenmis mi)
durum: hayir
gecici_onlem: ham kayit 2 gun saklanir, erisim 2 kisiyle sinirli
riski_ustlenen: urun sahibi, iade asistani
kapanis: 2026-10-15

Kontroller yerine oturduktan sonra kırmızı takım koşusunu alırsın. Sıra önemlidir. Kontrolleri uygulamadan koşu almak, zaten bildiğin açıkları yeniden bulmaya zaman harcamaktır.

Koşu, tehdit modelindeki her kanal için saldırı denemeleri içerir: doğrudan enjeksiyon, belge üzerinden dolaylı enjeksiyon, sistem promptunu sızdırma ve yetkisiz araç çağrısı. OWASP'ın üretken yapay zekâ kırmızı takım rehberi bu işi dört alana böler: modelin kendisi, uygulamadaki entegrasyon, altyapı ve çalışma anındaki davranış. İade asistanında ağırlığı entegrasyon ve çalışma anı alır, çünkü zarar araç çağrısında doğar.

Koşunun sonucu bir sayıdır ve bu sayı önceden yazılmış bir eşikle karşılaştırılır. Örneğin kritik kategoride saldırı başarı oranı yüzde beşi geçmesin. Kalıcı değişiklik yapan araçta ise tek bir başarılı deneme bile kapıyı kapatsın. Eşiği koşudan sonra yazarsan sonuca göre ayarlama eğilimine düşersin.

Bir başka sık hata, aynı test setini her sürümde yeniden kullanmaktır. Ekip zamanla bu sete göre ayar yapar. Set ezberlenir, oran düşer, ama gerçek dayanıklılık artmaz. Her koşuya yeni kalıplar ekle ve geçmiş olaylardan çıkan örnekleri kalıcı test olarak sakla.

Bu çalışma yalnız iyi mühendislik değildir, düzenleyicilerin beklentisiyle de örtüşür. Avrupa Birliği Yapay Zekâ Yasası'nın 15. maddesi, yüksek riskli sistemlerden doğruluk, sağlamlık ve siber güvenlik ister. Aynı madde, eğitim verisini zehirleme ve modeli yanıltmak için hazırlanmış girdiler gibi yapay zekâya özgü saldırılara karşı önlem bekler.

Yayın öncesi kırmızı takım koşusu, bu beklentinin mühendislikteki karşılığıdır. NIST'in yapay zekâ risk yönetimi çerçevesi de işi dört işleve ayırır: yönetişim, haritalama, ölçme ve yönetme. Kapsam belgesi haritalamaya, kırmızı takım koşusu ölçmeye, yayın kapısı yönetmeye denk düşer. Liste sahipleri ve istisna kayıtları da yönetişimin parçasıdır.

Yayın kapısı (release gate), listeyi ve koşu sonucunu karara bağlayan noktadır. Kapının üç çıktısı olur: aç, kısıtlı aç, kapat. Kısıtlı açmak çoğu zaman en doğru seçimdir.

Özelliği önce iç kullanıcıya, sonra küçük bir müşteri yüzdesine verirsin: yüzde bir, yüzde beş, yüzde yirmi beş. Her basamakta ne ölçeceğini önceden seç.

Kaç istek geldi, kaç tanesi filtreye takıldı, kaç şikâyet geldi, kaç araç çağrısı reddedildi? Yüzdeyi büyütme kararını da yazılı bir eşiğe bağla. Eşik olmadan karar veren kişi baskı altında iyimser tahmin yapar. Kâğıda yazılmayan eşik, hafızada büyür ve küçülür.

$ python kapi.py --ozellik iade-asistani --kosu kirmizi_takim_0930.json
[1] kapsam yazili ve onayli ............. evet
[2] tehdit modeli cikarildi ............. evet
[3] arac yetkileri en az ayricalikla .... evet
[4] kalici arac insan onayina bagli ..... evet
[5] kayitlar maskeli tutuluyor .......... hayir  istisna IST-014 (bitis 2026-10-15)
[6] kirmizi takim esigi ................. evet   kritik ASR %3,1 <= %5
[7] geri alma bayragi ................... evet   iade_asistani_acik
[8] hukuk incelemesi .................... evet
karar: KISITLI AC
asama: ic kullanici -> %1 -> %5 -> %25
buyutme kosulu: ret orani < %2 ve sikayet = 0, her asamada 48 saat

Çıktıyı satır satır oku. İlk dört madde evet döndü ve kanıtları ekte duruyor.

Beşinci madde hayır, ama yanında geçerli bir istisna var: kayıt numarası ve bitiş tarihi görünüyor. Kapı bu yüzden durmadı. Altıncı satır kırmızı takım sonucunu eşikle yan yana yazar. Kritik kategoride oran yüzde 3,1, eşik yüzde 5.

Yedinci satır geri alma bayrağının adını verir, böylece nöbetçi neyi çevireceğini arayarak vakit kaybetmez. Karar satırı KISITLI AC der, çünkü istisnalı bir madde varken tam açılış savunulamaz. Son iki satır basamakları ve büyütme koşulunu sabitler. İstisnanın tarihi geçerse betik aynı girdilerle KAPALI döner.

Aynı mantık tek bir araç eklerken de geçerlidir. Ajana yeni bir yetki tanımlarken kapsam belgesini baştan yazmana gerek yok. Ama aynı soruları küçük ölçekte sorarsın: bu araç neyi kalıcı değiştirir, kim onaylar, hata olursa nasıl geri alınır? Cevap net değilse araç henüz canlıya hazır değildir.

Kalıcı değişiklik yapan bir araçta en güçlü kontrol insan onayıdır. Enjeksiyon tutsa bile onay adımı zincirin son halkasını keser, çünkü model eylemi yalnız önerir. Onay ekranı da eylemin tam parametrelerini göstermeli. Tutarı ve hedef hesabı görmeyen bir onay göstermelik kalır.