Kurumsal Yapay Zekâ Güvenliği ile Şirket Verileri Prompt Injection ve Yetkisiz Erişime Karşı Nasıl Korunur?

Kurumsal Yapay Zekâ Güvenliği Nereden Başlatılmalıdır?

Kurumsal yapay zekâ güvenliği, kullanılacak modelden önce veri, kullanıcı, sistem ve işlem envanterinin çıkarılmasıyla başlatılmalıdır. Hangi dokümanların LLM tarafından işleneceği, hangi kaynakların RAG dizinine alınacağı, hangi kullanıcıların hangi veri kümelerine erişebileceği ve AI agent’ın hangi sistemlerde işlem yapabileceği teknik keşif sırasında ayrı ayrı tanımlanmalıdır.

Tehdit modeli hangi varlıkları ve senaryoları kapsamalıdır?

özel GPT ve LLM çözümlerinin kurumsal mimarideki yerini değerlendirirken model, istemler, uygulama sunucusu, kimlik servisi, API'ler, doküman depoları ve vektör veri tabanı aynı güvenlik sınırı içinde incelenmelidir. Kullanıcının yetkili olmadığı belgeyi istemesi, zararlı içerikli dokümanın RAG üzerinden modele ulaşması, agent’ın yanlış aracı çağırması veya loglarda hassas veri tutulması gibi senaryolar önceden modellenirse kontrol tasarımı daha somut hâle gelir.

• İşlenen veri türleri ve gizlilik sınıfları
• Kullanıcı rolleri ve kimlik kaynakları
• Model RAG agent ve API bileşenleri
• Harici servisler ve veri çıkış noktaları
• Yüksek etkili işlem ve araç yetkileri
• Loglama izleme ve olay müdahale sorumlulukları

Security is a process, not a product.- Bruce Schneier

Şirket Verileri LLM ve RAG Sistemlerinde Nasıl Korunur?

Şirket verileri LLM ve RAG sistemlerinde, önce hangi içeriğin modele gönderilebileceği belirlenerek ve veri erişimi kullanıcı kimliğiyle ilişkilendirilerek korunur. Her dokümanı ortak bir bilgi havuzuna atmak yerine gizlilik sınıfı, departman, müşteri, proje veya veri sahibi gibi metadata alanları tanımlanmalı; sorgu sırasında yalnızca kullanıcının yetkili olduğu içerikler getirilebilmelidir.

Veri yaşam döngüsü hangi kontrollerle sınırlandırılmalıdır?

kurumsal AI asistanları şirket verileriyle çalışırken verinin kaynaktan indekslemeye, embedding üretiminden sorgu bağlamına ve yanıt kaydına kadar hangi aşamalardan geçtiği görünür olmalıdır. Gereksiz kişisel veya ticari sır niteliğindeki alanlar maskeleme ya da hariç tutma kurallarıyla azaltılabilir. Model sağlayıcısına gönderilen içerik, saklama seçenekleri ve veri işleme sınırları da kullanılan hizmetin sözleşmesi ve teknik mimarisiyle birlikte değerlendirilmelidir.

• Doküman ve veri sınıflandırma politikası
• Kaynak bazlı erişim etiketi ve metadata
• Gereksiz hassas alanların maskelemesi
• İndeks ve yanıt kayıtları için saklama kuralları
• Şifreli aktarım ve güvenli depolama
• Dış model servislerine veri çıkış kontrolü

RAG Erişim Kontrolü Veri Seviyesinde Nasıl Uygulanmalıdır?

RAG erişim kontrolü, yalnızca uygulama ekranında kullanıcı rolü kontrol ederek değil, doküman veya kayıt getirme aşamasında yetkiyi yeniden uygulayarak tasarlanmalıdır. Kullanıcı sorgusu embedding aramasına dönüştürüldüğünde erişim filtresi kimlik bilgisi, rol, organizasyon, müşteri veya proje kapsamıyla birlikte çalışmalı ve yetkisiz parçalar modele hiç ulaşmamalıdır.

Belge ve satır bazlı yetki modeli nasıl kurulabilir?

Belge seviyesinde erişimde her doküman, yetkili grup veya kullanıcı kapsamıyla etiketlenebilir; yapılandırılmış veride ise satır seviyesinde filtreleme uygulanabilir. Yetki değişikliği olduğunda yalnızca uygulama oturumunu değil, arama indeksindeki erişim metadata'sını da güncellemek gerekir. Ortak vektör koleksiyonları kullanılıyorsa sorgu filtresinin atlanamadığı doğrulanmalı; yüksek gizlilik gerektiren veri kümelerinde fiziksel veya mantıksal ayrıştırma seçenekleri ayrıca değerlendirilmelidir.

• Kimlik sağlayıcıyla rol eşleştirme
• Doküman bazlı erişim metadata'sı
• Satır ve kayıt seviyesinde filtreleme
• Departman müşteri ve proje sınırları
• Yetki değişikliklerinin indekse yansıtılması
• Yüksek gizlilik için veri ayrıştırma seçenekleri

Prompt Injection Saldırıları Nasıl Tespit Edilip Önlenir?

Prompt injection saldırıları, kullanıcının doğrudan yazdığı istemlerden veya RAG tarafından getirilen web sayfası, dosya ve e-posta gibi dolaylı içeriklerden gelebilir. Bu nedenle yalnızca sistem promptuna “talimatları yok sayma” benzeri kurallar eklemek yeterli değildir; güvenilmeyen içerik ile sistem talimatları ayrıştırılmalı, yüksek etkili işlemler modele bırakılmadan deterministik kontrollerden geçirilmelidir. OWASP da RAG kullanımının prompt injection riskini tek başına ortadan kaldırmadığını vurgular.

Savunma katmanları hangi noktalarda uygulanmalıdır?

Prompt injection önleme için girdi analizi, içerik kaynak etiketi, şüpheli komut örüntüsü kontrolü, görev sınırı doğrulaması ve çıktı incelemesi birlikte kullanılabilir. Kritik aksiyonlarda yalnızca model kararına güvenmek yerine izin verilen işlem listesi, parametre doğrulaması ve gerektiğinde insan onayı uygulanmalıdır. İndirekt saldırılar için doküman veya web içeriğinin “veri” olarak ele alındığını belirginleştiren ayrıştırma teknikleri ve saldırı örnekleriyle düzenli testler savunmanın dayanıklılığını artırır.

• Doğrudan ve dolaylı istem ayrımı
• Güvenilmeyen içerik için kaynak işaretleme
• Görev dışı talimat ve veri sızdırma tespiti
• Kritik çıktı ve aksiyon doğrulaması
• İzinli işlem listeleri ve parametre kontrolleri
• Prompt injection saldırı testleri

AI Agent Yetkilendirme ve Araç İzinleri Nasıl Sınırlandırılır?

AI agent yetkilendirme, agent'a “yalnızca gerekli işlemleri yap” demek yerine gerçek sistem izinlerini görev bazında sınırlandırarak uygulanmalıdır. Agent'ın erişebileceği araçlar, veri kaynakları, API operasyonları ve kaynak kapsamları açık bir izin modeliyle tanımlanmalı; okuma, oluşturma, güncelleme, silme ve dışa aktarma yetkileri birbirinden ayrılmalıdır.

Agent işlemlerinde en az ayrıcalık nasıl uygulanır?

AI agent ve otonom sistemler araç çağırabildiğinde risk, yalnızca yanlış yanıt üretmekten gerçek sistemlerde yetkisiz işlem yapmaya dönüşür. Agent için ayrı kimlik, dar kapsamlı rol, izinli araç listesi, kısa ömürlü erişim ve her aşağı akış sisteminde yeniden yetkilendirme kullanılması etki alanını sınırlar. Güncel kurumsal güvenlik rehberleri de agent fonksiyonlarında en az ayrıcalık ve araç erişiminin sıkı sınırlandırılmasını temel kontrol olarak öne çıkarır.

• Agent başına ayrı ve izlenebilir kimlik
• Görev bazlı rol ve kaynak kapsamı
• İzin verilen araç ve aksiyon listesi
• Yazma silme ve dışa aktarma ayrımı
• Yüksek riskli işlemlerde insan onayı
• Hızlı yetki iptali ve agent kapatma mekanizması

Girdi Çıktı Filtreleri ve Veri Maskeleme Nasıl Kurulur?

Girdi ve çıktı filtreleri, yapay zekâ veri güvenliği için tek başına güvenlik duvarı değildir; ancak hassas veri akışını azaltan önemli bir kontrol katmanıdır. Kullanıcı istemleri, yüklenen dosyalar, RAG bağlamı ve model yanıtları farklı riskler taşıdığı için her katmanda ayrı kontrol uygulanmalı; kişisel veri, kimlik bilgisi, erişim anahtarı veya ticari sırların gereksiz biçimde modele ulaşması ya da yanıtta açığa çıkması engellenmelidir.

Maskeleme ve doğrulama kuralları nerede uygulanmalıdır?

AI agent tabanlı otomasyon özel yazılımla kurulurken veri maskeleme, uygulama katmanında erişim kontrolünden sonra ve model çağrısından önce uygulanabilir; çıktı tarafında ise hassas alan tespiti ve politika doğrulaması yapılabilir. Kullanıcıdan gelen serbest metni doğrudan SQL, dosya yolu, komut veya API parametresine çevirmek yerine şemaya bağlı doğrulama ve izinli değerler kullanılmalıdır. Böylece model çıktısı güvenilir kabul edilmeden önce uygulama kurallarıyla sınanır.

• İstem ve dosya giriş kontrolleri
• Kişisel veri ve gizli bilgi maskeleme
• Model yanıtında hassas alan taraması
• Şemaya bağlı araç parametre doğrulaması
• İzinli değer ve hedef listeleri
• Riskli çıktılarda engelleme veya insan incelemesi

Vektör Veri Tabanı ve API Güvenliği Nasıl Sağlanmalıdır?

Vektör veri tabanı güvenliği, embedding kayıtlarının “anlamsız sayısal veri” olduğu varsayımına bırakılmamalıdır; indeksler şirket bilgisinin aranabilir temsilini içerdiği için erişim, ağ, yedekleme ve yaşam döngüsü kontrollerine tabi tutulmalıdır. Benzer biçimde RAG, model ve agent servislerini bağlayan API katmanı güçlü kimlik doğrulama, yetkilendirme, hız sınırlama ve güvenli hata yönetimiyle korunmalıdır.

Teknik altyapıda hangi sınırlar oluşturulmalıdır?

Üretim ve test ortamları ayrılmalı, servis sırları güvenli bir secret yönetim katmanında tutulmalı ve doğrudan istem içine gömülmemelidir. API'ler kullanıcının kimliğini ve erişim kapsamını aşağı akış servislere taşımalı; yalnızca “istek AI uygulamasından geldi” diye daha geniş izin vermemelidir. Vektör indekslerinde yedekler, silme talepleri ve veri güncellemeleri yönetilmeli; uygulama loglarının da hassas bağlam veya tam prompt metinlerini gereksiz biçimde saklamaması sağlanmalıdır.

• Vektör indekslerinde rol bazlı erişim
• Ağ segmentasyonu ve özel servis uçları
• Secret ve anahtar yönetimi
• API kimlik doğrulama ve hız sınırlama
• Test ile üretim ortamı ayrımı
• Yedekleme silme ve veri yaşam döngüsü kontrolleri

Çalışan Kaynaklı Veri Sızıntısı Riski Nasıl Yönetilmelidir?

Çalışan kaynaklı LLM veri sızıntısı riski, yalnızca çalışanlara “hassas veri paylaşmayın” demekle yönetilemez. Kurum hangi yapay zekâ servislerinin kullanılabileceğini, hangi veri sınıflarının bu servislere aktarılabileceğini ve hangi kullanım senaryolarının yasak veya onaya tabi olduğunu açık yönetişim kurallarıyla belirlemeli; mümkün olan noktalarda bu kuralları teknik kontrollerle desteklemelidir.

Yapay zekâ KVKK yaklaşımı nasıl ele alınmalıdır?

Yapay zekâ KVKK uyumu tek bir ürün özelliği veya güvenlik ayarıyla garanti edilemez. Kişisel verinin işlenme amacı, hukuki dayanağı, aktarım biçimi, saklama süresi ve erişim yetkileri kurumun veri koruma süreçleriyle birlikte değerlendirilmelidir; gerektiğinde uzman hukuk danışmanlığı alınmalıdır. Teknik tarafta veri minimizasyonu, rol bazlı erişim, maskeleme, kayıt tutma, saklama politikaları ve dış servislere veri çıkışının kontrol edilmesi mevzuat yükümlülüklerini destekleyen temel unsurlardır.

• Onaylı model ve servis kataloğu
• Veri sınıfına göre kullanım politikası
• Hassas veri için engelleme veya uyarı
• Kurumsal hesap ve kimlik zorunluluğu
• Kullanım logları ve periyodik erişim incelemesi
• Eğitim farkındalık ve olay bildirim süreci

Güvenlik Testi ve Saldırı Simülasyonu Nasıl Yürütülmelidir?

Kurumsal LLM güvenliği, yalnızca kod incelemesi veya klasik penetrasyon testiyle doğrulanmamalı; prompt injection, veri sızdırma, yetki aşımı, araç kötüye kullanımı ve zararlı RAG içeriği gibi AI'ya özgü senaryolarla test edilmelidir. Saldırı simülasyonu gerçek kullanıcı rollerini ve gerçekçi veri sınırlarını temsil eden kontrollü test ortamında yürütülmeli, bulunan zafiyetlerin hangi güvenlik katmanında engellenmesi gerektiği belirlenmelidir.

Red team çalışmasında hangi senaryolar önceliklendirilir?

yapay zekâ otomasyon firması değerlendirilirken yalnızca model yetkinliği değil saldırı testleri, güvenlik kayıtları ve düzeltme yaklaşımı da sorgulanmalıdır. Agent'ın yasak aracı çağırmaya zorlanması, başka kullanıcının belgesini istemesi, RAG dokümanına gizli talimat yerleştirilmesi veya çıktı üzerinden veri sızdırma denenmesi gibi testler savunmayı ölçer. Güncel rehberler de prompt injection, yetki ve araç davranışı için sürekli adversarial test ve red teaming yaklaşımını önerir.

• Doğrudan ve dolaylı prompt injection testleri
• Yetkisiz doküman ve veri erişimi denemeleri
• Agent araç ve yetki kötüye kullanım senaryoları
• Hassas veri sızdırma ve çıktı manipülasyonu
• Kimlik doğrulama ve oturum sınırı testleri
• Düzeltme sonrası yeniden doğrulama testleri

İzleme Olay Müdahalesi ve Kayıt Tutma Nasıl Planlanır?

İzleme ve kayıt tutma, yalnızca sohbet metnini saklamak yerine kullanıcı kimliği, agent kimliği, kullanılan veri kaynağı, çağrılan araç, yetki kararı, işlem sonucu ve korelasyon kimliği gibi güvenlik açısından anlamlı olayları görünür kılmalıdır. Böylece anormal veri erişimi, olağandışı araç kullanımı veya tekrar eden prompt injection denemeleri tespit edilip incelenebilir.

Olay müdahale planı AI sistemlerine nasıl uyarlanır?

Bir güvenlik olayı tespit edildiğinde yalnızca modeli kapatmak yerine erişim tokenlarının iptali, ilgili agent'ın devre dışı bırakılması, veri kaynağının karantinaya alınması ve şüpheli entegrasyonun kesilmesi gibi önceden tanımlanmış müdahale adımları bulunmalıdır. Logların hassas veriyi gereksiz yere içermemesi ve erişimlerinin ayrıca sınırlandırılması gerekir. Anomali eşikleri, olay sahipliği ve kanıt saklama süreçleri klasik güvenlik operasyonuyla AI uygulama ekibi arasında ortaklaştırılmalıdır.

• Kullanıcı agent ve işlem kimliklerinin loglanması
• Araç çağrısı ve yetki kararlarının kaydı
• Anormal sorgu ve veri erişimi uyarıları
• Agent kapatma ve erişim iptal prosedürleri
• Olay sahipliği ve eskalasyon akışı
• Hassas veriyi sınırlayan log saklama politikası

Güvenlik Mimarisinin Süresi ve Maliyeti Nasıl Hesaplanır?

Güvenlik mimarisi ve test projesinin süresi ile maliyeti; veri kaynaklarının sayısı, kullanıcı ve rol modeli, RAG yapısının karmaşıklığı, agent araçları, entegre sistemler, mevcut kimlik altyapısı, test senaryoları ve iyileştirme kapsamı belirlendikten sonra hesaplanmalıdır. Tek bir LLM sohbet arayüzü ile çok sayıda sisteme yazma yetkisi olan agent platformu aynı risk ve eforla değerlendirilemez.

Teklifte hangi güvenlik iş paketleri ayrı gösterilmelidir?

yapay zekâ otomasyon tekliflerini karşılaştırırken güvenliğin genel bir madde olarak geçmesi yerine mimari analiz, veri ve yetki incelemesi, prompt injection testi, agent araç denetimi, red team çalışması, loglama iyileştirmesi ve yeniden test gibi teslimatlar ayrıştırılmalıdır. Sağlıklı süre ve maliyet tahmini, saldırı yüzeyi ve mevcut kontroller teknik keşifle görünür hâle geldiğinde yapılabilir. Bu yaklaşım, hizmet sağlayıcıların önerilerini aynı risk kapsamı üzerinden karşılaştırmayı kolaylaştırır.

• Mimari ve veri akışı güvenlik analizi
• Kimlik rol ve erişim modeli incelemesi
• Prompt injection ve veri sızıntısı testleri
• Agent araç ve işlem yetkisi denetimi
• İyileştirme uygulaması ve yeniden test
• İzleme dokümantasyon ve devir teslim kapsamı