Eylül 2026'da üç ay arayla üç benzer olay açıklandı: OpenAI'ın ajanları Hugging Face depolarına, Google'ın Gemini modelleri bir test sırasında üç gerçek şirketin sistemine, OpenAI'ın bir başka ajanı da Avustralya'nın Medicare istatistik portalına erişti. Üçünde de kimse modele "şu siteye sız" demedi. Model, kendisine verilen görevi yaparken kapalı olması gereken bir kapıyı açık buldu.

Bu rehber, o kapının sizin tarafınızda olduğu durumu ele alıyor: bir web sitesi, bir portal ya da bir iç sistem işletiyorsanız ne yapabilirsiniz?

Önce yanlış anlaşılan şey: robots.txt bir engel değil

robots.txt bir ricadır. Dosyaya "buraya girme" yazmak, uyumlu davranan tarayıcıları durdurur; uymayan bir yazılımı ya da bir görevi tamamlamaya çalışan bir ajanı durdurmaz. Cloudflare'in belgeleri bu ayrımı açıkça yapıyor: tercih bildirmek ayrı, uygulamak ayrı; güvenlik duvarı kuralları robots.txt'den önce devreye giriyor ve onu geçersiz kılıyor.

Daha kötüsü, robots.txt bazen bir haritaya dönüşüyor. Gizli kalmasını istediğiniz dizinleri oraya yazarsanız, dosyayı okuyan herkese onların yerini söylemiş olursunuz.

Asıl sorun: erişim denetimi

Bu olayların hiçbirinde model bir şifreleme kırmadı. OWASP'ın uygulama güvenliği listesinde birinci sırada duran sorun tam da bu: bozuk erişim denetimi. OWASP'ın ölçümünde test edilen uygulamaların yüzde 94'ünde bu kategoride bir bulguya rastlanmış ve veri kümesinde 318 binden fazla vaka sayılmış.

OWASP'ın saydığı tipik hatalar, ajanların bulmakta iyi olduğu hatalarla birebir örtüşüyor:

  • Adres çubuğundaki parametreyi değiştirerek kontrolü atlamak.
  • Başkasının kaydına, kimlik numarasını değiştirerek ulaşmak.
  • API'de POST, PUT ve DELETE için denetim koymayı unutmak.
  • Kimlik doğrulaması olmadan korumalı sayfaya ulaşabilmek.
  • Dizin listelemenin açık kalması ve kök dizinde hassas dosya bırakılması.

OWASP'ın önerdiği savunmalar da aynı yerden başlıyor: varsayılan reddet, yani herkese açık olmayan her kaynak varsayılan olarak kapalı olsun. Denetim tek ve tekrar kullanılan bir mekanizmadan geçsin, kayıt sahipliği sunucuda doğrulansın, dizin listeleme kapatılsın, erişim hataları kaydedilip uyarı üretsin, otomatik saldırılara karşı hız sınırı konsun.

Ajan çağındaki fark: hız ve kapsam

Bu hatalar yeni değil. Yeni olan, onları bulan tarafın hızı. Bir ajan dakikalar içinde yüzlerce adres deneyebiliyor, dizin yapısını çıkarabiliyor ve bulduğu dosyayı okuyup anlamlandırabiliyor. Avustralya vakasında model, bir istatistiği ararken erişim kısıtlamasını aşacak bir yol denedi ve buldu.

Bunun pratik anlamı şu: "bu adresi kimse bilmiyor" artık işlemiyor. Paylaşılmamış bir bağlantı, tahmin edilebilir bir dosya adı ya da eski bir yedek dosyası, bir ajanın rutin taramasında ortaya çıkabilir.

Yapılacaklar: kontrol listesi

Aşağıdakiler bir hafta sonunda yapılabilecek işler:

  1. Kök dizini tarayın. Yedek dosyaları (.zip, .sql, .bak), .env benzeri yapılandırma dosyaları ve eski test sayfaları kalmış mı bakın. Bunlar kimlik doğrulamasının arkasında değilse, herkese açıktır.
  2. Dizin listelemeyi kapatın. Bir klasörün içeriğinin listelenmesi, dosya adı tahmin etmeyi gereksiz kılıyor.
  3. Kimlik numarasıyla erişilen her uç noktayı test edin. Kendi hesabınızla giriş yapıp adresteki numarayı bir artırın. Başkasının kaydını görüyorsanız sorun burada.
  4. Yazma uçlarını ayrıca kontrol edin. Okuma tarafı korunup POST ve DELETE unutulduğunda açık, listede görünenden daha ciddi olur.
  5. Hız sınırı koyun. Sıradan bir kullanıcının dakikada 200 sayfa açması beklenmez; bu eşik hem ajanları hem tarayıcıları yavaşlatır.
  6. Erişim hatalarını kaydedin ve uyarı kurun. Kısa sürede yüzlerce 403 ve 404, size bir şeyin tarandığını söyler.

İç sistemler: asıl risk burada

Kamuya açık site çoğu zaman en iyi korunan yerdir. Asıl açıklar, kimsenin dışarıdan bakmadığını varsaydığı yerlerde birikiyor:

  • Panolar ve raporlama arayüzleri. "Sadece ofis ağından girilir" varsayımı, sistem buluta taşındığında sessizce geçersizleşiyor.
  • Test ve hazırlık ortamları. Genellikle gerçek verinin kopyasıyla çalışıyor ve üretim kadar sıkı korunmuyor.
  • Belge ve dosya sunucuları. Paylaşım bağlantıları çoğu zaman süresiz ve tahmin edilebilir.
  • Eski API sürümleri. Yeni sürüm yetkilendirme alırken, kapatılmayan eski uç aynı veriyi denetimsiz veriyor.

Bu dördünün ortak özelliği, kimsenin onlara bir saldırı yüzeyi gibi bakmaması. Bir ajan içinse fark yok: erişilebilen her adres denenecek bir adres.

Sık yapılan üç hata

  • Gizliliği adresin bilinmemesine dayamak. Uzun ve rastgele bir adres, paylaşıldığı anda kalıcı bir anahtara dönüşüyor ve geri alınamıyor. Süreli ve iptal edilebilir bağlantılar kullanın.
  • Yalnızca arayüzde gizlemek. Bir düğmeyi ekranda göstermemek, o düğmenin çağırdığı uç noktayı kapatmıyor. Denetim sunucuda olmalı.
  • Engellemeyi tek başına savunma sanmak. Bilinen tarayıcıları engellemek trafiği azaltır ama açığı kapatmaz; kimlik doğrulaması olmayan bir dosya, engeli aşan ilk istekte yine erişilebilir.

Ajan trafiğini görmek ve yönetmek

Kim geliyor sorusunun cevabı çoğu sitede kayıtlarda duruyor ama kimse bakmıyor. Kayıtlarınızda kullanıcı aracısı bilgisine göre bir döküm alın; yapay zeka tarayıcılarının payını görün. Cloudflare gibi sağlayıcılar bunun için hazır araçlar sunuyor: hangi yapay zeka servisinin içeriğinize eriştiğini gösteren panolar ve tek tek izin verme ya da engelleme kuralları.

Burada bir denge var. Yapay zeka tarayıcılarını tümden engellemek, sitenizin bu araçların cevaplarında hiç görünmemesi anlamına gelebilir. Karar içeriğinize bağlı: haber ve tanıtım içeriğinde görünürlük değerliyken, ücretli arşivde ya da kullanıcı verisinde tam tersi geçerli.

Kimlik doğrulama tarafında da dikkat edilecek bir nokta var: kullanıcı aracısı dizesi kolayca taklit edilebilir. "Bu istek Googlebot diyor" demek, isteğin Google'dan geldiği anlamına gelmez; doğrulama, sağlayıcının yayımladığı adres aralıkları ya da doğrulanmış bot listeleriyle yapılmalı.

Kayıtlarda ajanı nasıl ayırt edersiniz?

Bir ziyaretçinin insan mı yoksa otomatik bir istemci mi olduğunu anlamak için tek bir işaret yetmiyor; birkaçının bir arada görülmesi gerekiyor:

  • İstek ritmi. İnsan okuma arası verir; otomatik istemci sabit aralıklarla ve çoğu zaman gece de ister.
  • Varlık istemeyen istekler. Sayfayı isteyip görselleri, yazı tiplerini ve betikleri hiç istememek güçlü bir işaret.
  • Sıralı kimlikler. Adresteki numaranın birer birer artması, tarama demektir.
  • 404 kümeleri. Var olmayan yolların art arda denenmesi, dizin tahmininin izidir.
  • Ağ kaynağı. İsteklerin geldiği ağın bir bulut sağlayıcısına ait olması, ev ya da mobil bağlantıdan gelmemesi.

Bu beş işareti tek bir panoda toplamak, ayda bir bakmanız yeterli olan bir gösterge üretir. Amaç her otomatik isteği engellemek değil; olağandışı bir desen belirdiğinde bunu aynı gün fark etmek.

Bir olay yaşandığında

Avustralya vakasının en çok eleştirilen kısmı sızma değil, bildirimdi: olay haziranda oldu, şirket ağustosta fark etti, kuruma eylülde ve yalnızca genel bir posta kutusuna bildirdi. Kendi tarafınızda hazırlıklı olmak için üç şey yeterli:

  • Ulaşılabilir bir güvenlik adresi. Sitenizde security.txt benzeri bir dosya ve izlenen bir e-posta adresi bulunsun; sizi uyarmak isteyen kişinin genel form doldurmasını beklemeyin.
  • Kayıtları saklayın. Bir erişim şüphesi doğduğunda cevap verebilmek için en az birkaç aylık erişim kaydı gerekiyor.
  • Kimin haberdar edileceğini önceden yazın. Kişisel veri söz konusuysa Türkiye'de KVKK bildirimi gündeme gelir; bunu olay anında araştırmak yerine önceden belirleyin.

Türkiye'de ek bir adım: bildirim yükümlülüğü

Kişisel veri içeren bir sisteme izinsiz erişim yaşandığında, Türkiye'de mesele yalnızca teknik değil. Kişisel Verilerin Korunması Kanunu kapsamında veri sorumlusunun ihlali Kurul'a ve ilgili kişilere bildirme yükümlülüğü doğuyor. Bunun pratik karşılığı, olay anında yapılacak üç hazırlığın önceden yapılmış olması:

  • Kimin karar vereceği belli olsun. Bildirim kararını verecek kişi, olay gecesi aranacak kişi değil; önceden yazılmış olmalı.
  • Hangi sistemde hangi kişisel veri var, listelensin. Bir erişim şüphesi doğduğunda "o klasörde ne vardı" sorusuna saatler içinde cevap verebilmek gerekiyor.
  • Kayıtlar ihlalin kapsamını gösterebilsin. Hangi dosyaya kimin eriştiğini gösteremiyorsanız, ihlalin kapsamını da belirleyemezsiniz.

Bu hazırlık aynı zamanda teknik tarafı da disipline ediyor: hangi verinin nerede durduğunu yazmak, çoğu zaman kimsenin fark etmediği eski kopyaları ortaya çıkarıyor.

Son söz

Son bir not: bu rehberdeki işlerin hiçbiri yapay zekaya özel değil. Erişim denetimi, kayıt tutma ve hız sınırı, on yıldır aynı listede duruyor. Değişen tek şey, bu listeyi ertelemenin bedeli. Eskiden korumasız bir dosyayı bulmak için birinin özellikle sizi hedef alması gerekiyordu; şimdi sıradan bir araştırma görevi bunu tesadüfen yapabiliyor.

Bu üç olayın ortak dersi, modellerin kötü niyetli olması değil. Ders şu: yıllardır "teorik" diye ertelenen erişim denetimi açıkları, artık yorulmayan ve dakikada yüzlerce deneme yapan bir tarafça sınanıyor. Yapılacak iş de yeni bir şey değil; yalnızca ertelenemez hâle geldi.