Shadow AI Tespiti: DNS ve Proxy Loglarından Gölge Yapay Zekâ Envanteri
Tanım değil, uygulanabilir tespit mühendisliği

Gölge yapay zekâ (shadow AI) nedir?

Gölge yapay zekâ (shadow AI), bir kurumun bilgi teknolojileri veya güvenlik ekiplerinin bilgisi, onayı ve envanteri dışında; çalışanların iş verileriyle kullandığı üretken yapay zekâ araçları, sohbet robotları, tarayıcı uzantıları ve API entegrasyonlarının tümüdür. Kavram, on yılı aşkın süredir bilinen gölge BT (shadow IT) olgusunun üretken YZ çağına uzanan biçimidir: fark, sızan şeyin artık yalnızca dosya değil, modele girdi olarak verilen sözleşme metni, müşteri listesi, kaynak kodu ve kişisel veri olmasıdır.

Pratikte gölge YZ üç katmanda görünür: (1) tarayıcıdan doğrudan kullanılan halka açık sohbet arayüzleri, (2) resmî satın alma sürecinden geçmeden bireysel kartla alınan ürün abonelikleri, (3) uygulamalara yerleşen tarayıcı uzantıları ve doğrudan model API'lerine giden istemci kütüphaneleri. Bu rehber tanımı burada bırakıp doğrudan tespit mühendisliğine geçiyor; kurumsal kullanım risklerinin genel değerlendirmesi için kurumsal ChatGPT kullanımı ve güvenlik yazısına bakabilirsiniz.

Beş adımlı tespit metodolojisi

Gölge YZ keşfi, tek bir aracın açıp kapatılmasıyla değil, mevcut telemetriyi katman katman süzmekle yapılır. Aşağıdaki beş kaynak, hiçbir yeni ajan kurmadan kurumun elinde zaten var olan verilerdir; sıralama pasiften aktife doğru ilerler.

İlk üç adım tekniktir ve kanıt üretir; dördüncü adım niyeti açıklar; beşinci adım keşfi kalıcı denetime çevirir. Bu ayrım önemli, çünkü yalnızca engelleyen bir kurum çalışanı kişisel telefona iter ve görünürlüğü büsbütün kaybeder. Bu sistemli keşif mantığının daha geniş bir çerçevesi için GenAI sistem keşfi: dokuz kategori kanıt yazısına bakılabilir.

Adım 1 — DNS ve proxy loglarından envanter

En yüksek getirili kaynak DNS çözümleme kayıtlarıdır: bir çalışan tarayıcıda bir YZ arayüzü açtığı anda, kurumsal çözümleyiciye ilgili alan adı için bir sorgu düşer. Amaç, YZ sağlayıcılarının alan adlarını bilinen bir sözlükle eşleştirmek ve kullanıcı/kaynak IP kırılımı çıkarmaktır.

# DNS veya proxy log'unda bilinen üretken YZ alan adlarını süz
grep -Eio \
  '(chatgpt|openai|anthropic|claude\.ai|gemini\.google|bard\.google|copilot\.microsoft|perplexity|poe\.com|huggingface|character\.ai|midjourney|mistral|deepseek|cohere|x\.ai|grok)[a-z0-9.-]*' \
  /var/log/dns/query.log | sort | uniq -c | sort -rn

Proxy loglarında (ör. Squid) aynı süzgeci kullanıcı bazında toplulaştırıp kimin ne sıklıkta bağlandığını çıkarabilirsiniz:

# Squid access.log: kullanıcı x hedef alan adı frekansı
awk '$7 ~ /openai|anthropic|claude\.ai|perplexity|gemini|copilot\.microsoft/ {print $8, $7}' \
  /var/log/squid/access.log | sort | uniq -c | sort -rn | head -50

İki uyarı: Birincisi, sözlük yaşayan bir varlıktır; her çeyrekte yeni sağlayıcı çıkar, listeyi sürüm kontrolünde tutun. İkincisi, alan adı temelli eşleştirme api.openai.com gibi doğrudan API çağrılarını da yakalar; bunlar bir çalışanın tarayıcı kullanımından çok, gölge bir entegrasyonun işaretidir ve önceliklendirilmelidir. Ham eşleşmeyi olaya çevirmenin tespit mühendisliği tarafı için LLM tespit mühendisliği yazısı yardımcı olur.

Adım 2 — SaaS harcama ve fatura analizi

DNS'in göremediği şey, ücretli aboneliğin kim tarafından ve hangi bütçeden alındığıdır. Bu bilgi finansın elindedir: kurumsal kart ekstreleri, masraf yönetim sistemi ve tedarikçi kayıtları. Üretken YZ ürünleri ödeme ekstrelerinde tanınabilir satıcı tanımlayıcılarıyla görünür; bu tanımlayıcıları taramak, resmî satın alma dışında ödenen her aboneliği ortaya çıkarır.

# Masraf/kart dışa aktarımı (CSV) içinde YZ satıcı tanımlayıcıları
grep -Ei \
  'openai|anthropic|chatgpt|cursor|perplexity|midjourney|copilot|huggingface|jasper|elevenlabs|replit' \
  masraf_ekim.csv | awk -F',' '{print $3, $5, $7}'  # tarih, tutar, açıklama

Burada aranan sinyal iki türlüdür: küçük ve tekrar eden tutarlar (bireysel aylık abonelikler) ve tek seferlik API kredisi yüklemeleri. İlki bir kullanıcı, ikincisi çoğu zaman bir geliştirici entegrasyonu anlamına gelir. Finans verisini İK dizinine bağladığınızda, kullanım envanterine bir sahiplik katmanı eklemiş olursunuz: her gölge araç artık bir isme iliştirilir ve bu, engelleme değil görüşme kapısı açar. Envanteri güvenlik sınırlarına bağlamanın bütünsel bakışı için YZ mühendisliği: envanter ve güvenlik sınırları yazısına bakın.

Adım 3 — Tarayıcı uzantıları ve istemci envanteri

En sinsi katman tarayıcı uzantılarıdır: bir yazma asistanı ya da özetleme uzantısı, kullanıcının gördüğü her sayfanın içeriğini üçüncü taraf bir modele gönderebilir; üstelik bunu DNS'te sıradan bir alan adı gibi görünen kendi arka ucu üzerinden yapabilir. Yönetilen cihazlarda uzantı envanteri, uç nokta yönetim çözümü (MDM/RMM) veya doğrudan tarayıcı profili üzerinden çıkarılır.

# Windows'ta Chrome kullanıcıları için yüklü uzanti kimliklerini listele
Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Extensions" -Directory |
  Select-Object Name  # her Name bir uzanti kimligidir; katalogla eşleştir

Çıkan uzantı kimliklerini bir izin listesiyle (allowlist) karşılaştırın; listede olmayan her kimlik incelemeye alınır. Uzantı manifestindeki izinler — özellikle <all_urls> ve webRequest — bir uzantının veri sızdırma potansiyelini belirler. Bu envanter tamamlandığında dördüncü adım olan anonim çalışan anketi devreye girer: teknik keşif neyin kullanıldığını, anket ise neden kullanıldığını söyler. Genellikle yanıt basittir — resmî bir aracın olmaması. Bu neden, yasaklama refleksinden çok yönetişimle çözülür; kurumsal çerçeve için YZ yönetişim komitesi kurulması yazısı bir başlangıç noktasıdır.

Adım 4-5 — Anketten kapıya: pasif keşfi aktif politikaya çevirmek

İlk dört adım fotoğraf çeker; beşinci adım filmi kontrol altına alır. Pasif log analizinin yapısal sınırı şudur: yalnızca geçmişi gösterir ve yeni bir sağlayıcı sözlüğe eklenene kadar kördür. Kalıcı görünürlük için üretken YZ trafiğinin tek bir çıkıştan, bir AI gateway (YZ ağ geçidi) üzerinden akması zorunlu kılınır.

Gateway modelinde tarayıcı ve uygulama trafiği, doğrudan sağlayıcıya değil, kurumun kontrol ettiği bir aracıya yönlendirilir. Bu aracı üç işi tek noktada toplar: her isteği ve modeli kaydederek canlı bir envanter tutar; girdideki kişisel veriyi ve gizli kalması gereken içeriği tespit ederek politikayı uygular; ve izin verilmeyen sağlayıcıları çıkışta engeller. Bu, engelleme ile kullanım arasındaki yanlış ikilemi çözer — çalışan aracı kullanmaya devam eder, kurum ise görünürlüğü ve denetimi kaybetmez. Ağ geçidi mimarisinin seçim kriterleri için YZ güvenlik duvarı seçim rehberi ve çalışma zamanı denetimleri için çalışma zamanı LLM korumaları yazılarına bakılabilir.

Merkezi envanter ve politika mimarisi (Guardian örneği)

AltaySec'in geliştirdiği Guardian (v3.1.0; hibrit regex ve makine öğrenmesi tabanlı bir LLM güvenlik duvarı), bu beşinci adımın mimari karşılığı olarak konumlanabilir. Aşağıdaki tasarım, gölge YZ keşfini kalıcı bir politika kapısına bağlamanın mimari bir önerisi olarak okunmalıdır; burada anlatılan uçtan uca envanter borusu Guardian'ın halihazırda üretimde kanıtlanmış bir keşif özelliği değil, önerilen bir dağıtım desenidir.

1. Tek çıkış: Kurumsal proxy ve DNS politikaları, bilinen sağlayıcı alan adlarını gateway'e yönlendirir; doğrudan çıkış engellenir.
2. Envanter kaydı: Gateway'den geçen her istek sağlayıcı, model, kullanıcı ve zaman bilgisiyle kaydedilir — bu, adım 1-3'te elle çıkarılan envanterin otomatik ve canlı hâlidir.
3. Politika uygulaması: Girdi, hibrit regex ve sınıflandırıcı katmanından geçer; kişisel veri maskelenir veya istek reddedilir. Türkçe metinde ML sınıflandırıcılarının zayıf kaldığı bilinen bir sorundur — AltaySec'in kendi ölçümü olan guardrail-arena değerlendirmesi, Türkçe girdilerde sınıflandırıcıların gözle görülür bir kaçırma oranı gösterdi; bu nedenle regex tabanlı deterministik kurallar Türkçe için tamamlayıcı bir katman olarak önerilir.

Bu mimarinin veri koruma boyutu ihmal edilemez: gölge bir araca gönderilen müşteri verisi çoğu zaman bir KVKK yükümlülüğünü tetikler. İlgili çerçeve için KVKK ve LLM güvenliği yazısına bakın. Kurumunuzda bir gölge YZ keşfi ya da gateway mimarisi değerlendirmesi yapmak isterseniz iletişim bölümünden AltaySec ekibine ulaşabilirsiniz.

Kaynaklar

• OWASP Top 10 for LLM Applications
• OWASP LLM Applications Cybersecurity and Governance Checklist
• NIST AI Risk Management Framework (AI RMF 1.0)
• MITRE ATLAS Matrix

İlgili Yazılar

• Kurumsal ChatGPT Kullanımı ve Güvenlik
• YZ Yönetişim Komitesi Kurulması
• YZ Mühendisliği: Envanter ve Güvenlik Sınırları
• YZ Güvenlik Duvarı (AI Firewall) Seçim Rehberi