Kurumsal Chatbot Güvenlik Testi:
Adım Adım Rehber

1. Kurumsal chatbot güvenlik testi nedir?

Kurumsal chatbot güvenlik testi, bir büyük dil modeli (LLM) tabanlı chatbot ya da asistan uygulamasının; prompt injection, talimat sızıntısı, kişisel veri çıkarımı, jailbreak, araç kötüye kullanımı ve bilgi tabanı zehirlenmesi gibi yapay zekâya özgü zafiyetlere karşı planlı ve tekrarlanabilir biçimde denetlenmesidir. Amaç, chatbotun tasarlanan güvenlik sınırlarını gerçek saldırgan davranışı altında koruyup koruyamadığını kanıta dayalı olarak ölçmektir.

Bu test türü, geleneksel yapay zekâ güvenlik testi yaklaşımının bir alt kümesidir ve klasik uygulama penetrasyon testinden bir noktada ayrışır: burada saldırı yüzeyi bir form alanı ya da API parametresi değil, modelin dili yorumlama biçimidir. Bir saldırgan koda enjeksiyon yapmaz; modele, geliştiricinin niyetinin dışında davranmasını söyleyen bir metin gönderir. Chatbotun bir web arayüzü, WhatsApp entegrasyonu, çağrı merkezi sesli asistanı ya da dahili operasyon aracı olması bu temel gerçeği değiştirmez.

Testin en zor yanı, LLM çıktısının olasılıksal olmasıdır. Aynı saldırı promptu bir denemede engellenip diğerinde başarılı olabilir. Bu yüzden ciddi bir LLM güvenlik testi, tek atışlık "çalıştı/çalışmadı" sonucuna değil; her senaryonun birden çok kez, farklı sıcaklık (temperature) ve bağlam altında koşturulmasına ve davranışsal başarı oranına dayanır.

2. Neden kurumsal chatbot güvenlik testi gerekir?

Bir chatbot canlıya çıktığında, kurumun adına konuşan ve çoğu zaman kurumun verilerine erişebilen bir yüzey haline gelir. Test edilmemiş bir asistan üç somut riski beraberinde getirir:

• Veri sızıntısı: Sistem promptu, iç dokümanlar, müşteri kayıtları veya diğer kullanıcıların konuşmaları hedefli promptlarla dışarı çekilebilir. Türkiye'de bu doğrudan KVKK yükümlülüklerini ilgilendirir.
• Yetki aşımı: Araç (tool) çağıran veya agentic bir chatbot, saldırganın talimatıyla e-posta gönderebilir, kayıt değiştirebilir veya arka uç sistemlere komut iletebilir.
• İtibar ve uyum: Politika dışı, zararlı veya taraflı çıktılar üreten bir asistan hem marka hem de düzenleyici açıdan sorumluluk doğurur.

Model sağlayıcıların "yerleşik güvenlik" katmanları bu riskleri tek başına ortadan kaldırmaz. Bu korumalar genel amaçlıdır, kurumun özel iş kurallarını, veri sınıflarını ve entegrasyon yetkilerini bilmez. Ayrıca sağlayıcı bir model güncellemesi çıkardığında chatbotun davranışı sessizce değişebilir — dün engellenen bir saldırı bugün geçebilir. Bu nedenle güvenlik testi tek seferlik bir onay değil, sürüm yaşam döngüsüne yerleşmesi gereken tekrarlı bir disiplindir.

3. Test kapsamı: Hangi zafiyetler test edilir?

Kapsamlı bir chatbot güvenlik testi altı temel zafiyet sınıfını hedefler. Aşağıdaki tablo her sınıfı kısa tanımıyla ve ilgili OWASP LLM Top 10 (2025) maddesiyle eşler.

Prompt injection

En temel ve en yaygın sınıftır. Doğrudan enjeksiyonda kullanıcı "önceki tüm talimatları yok say" türü ifadelerle sistem kurallarını ezmeye çalışır. Dolaylı enjeksiyonda ise saldırgan komutu bir e-postaya, PDF'e ya da web sayfasına gömer; chatbot bu içeriği okuduğunda komutu talimat sanır. Ayrıntılı tanım için Prompt Injection Nedir? yazısına bakılabilir.

Sistem-prompt sızıntısı

Sistem promptu genellikle chatbotun rolünü, kısıtlarını ve bazen gömülü kimlik bilgilerini içerir. Bu talimatın açığa çıkması, saldırgana korumaları atlatmak için tam bir harita verir. Test sırasında sistem promptunu çeşitli dolaylandırma teknikleriyle çekmeye çalışırız; ayrıntı için Sistem Promptu Sızdırma yazısı referanstır.

PII exfiltration ve veri çıkarımı

Chatbot bir müşteri kaydına, önceki konuşmalara veya iç dokümanlara erişiyorsa, saldırgan sahte yetki iması ve toplu sorgu kalıplarıyla bu verileri çekmeye çalışır. Türkiye bağlamında sağlık, biyometrik ve benzeri özel nitelikli veriler ayrı bir kritiklik taşır; bu boyut KVKK Madde 6 sızıntı vektörleri yazısında derinlemesine incelenir.

Jailbreak

Jailbreak, modelin reddetmesi gereken bir çıktıyı üretmesi için güvenlik politikasının atlatılmasıdır. Rol yapma (roleplay), nezaketle kademeli eskalasyon (crescendo), çeviri bahanesi, kodlama/obfuscation ve morfolojik hileler bu sınıfa girer. Türkçenin sondan eklemeli yapısının açtığı özel yüzeyler için Türkçe Morfolojik LLM Bypass yazısına bakılabilir.

Tool ve agent kötüye kullanımı

Modern chatbotlar sıklıkla araç çağırır: veritabanı sorgusu, e-posta gönderimi, ödeme, ticket açma. Bu yetkiler saldırganın eline geçerse chatbot bir saldırı aracına dönüşür. Aşırı ajans, yetersiz izin ayrımı ve doğrulanmamış tool girdileri test edilir; kavramsal çerçeve için AI Agent Güvenliği Nedir? yazısı temeldir.

RAG poisoning

Retrieval-Augmented Generation (RAG) mimarisinde chatbot, cevabını bir bilgi tabanından çektiği belgelerle zenginleştirir. Saldırgan bu kaynağa (ör. yüklenebilir doküman, indekslenen web içeriği) zararlı talimat gömebilir; chatbot bu içeriği "güvenilir bağlam" sanarak çalıştırır. RAG'a özgü saldırı ve savunma yüzeyleri için RAG Güvenliği Nedir? yazısına bakılabilir.

4. Kurumsal chatbot güvenlik testi nasıl yapılır? (9 adım)

Aşağıdaki metodoloji, bir LLM pentest çalışmasının uçtan uca akışını tanımlar. Adımlar sıralıdır ancak son adım (yeniden test) süreci döngüye çevirir.

Adım 1 — Kapsam ve varlık envanteri

Önce test edilecek yüzey netleştirilir: hangi chatbot(lar), hangi kanallar (web, mobil, WhatsApp, sesli), hangi model(ler), hangi tool entegrasyonları ve hangi veri kaynakları. Sistem promptunun, tool tanımlarının ve RAG kaynak listesinin envanteri çıkarılır. Beyaz kutu (sistem promptuna erişimli), gri kutu veya siyah kutu (yalnız son kullanıcı arayüzü) yaklaşımlarından hangisinin uygulanacağı burada kararlaştırılır.

Adım 2 — Tehdit modelleme

Chatbota göre gerçekçi saldırgan profilleri ve hedefler tanımlanır: dışarıdan kötü niyetli kullanıcı, kimliği doğrulanmış ama yetkisiz kullanıcı, ve dolaylı enjeksiyon yoluyla içeriğe komut gömen üçüncü taraf. Her varlık için "en kötü durum" hedefleri (ör. başka bir müşterinin verisine erişim, yetkisiz tool çağrısı) yazılır. OWASP LLM Top 10 ve MITRE ATLAS bu aşamada saldırı tekniklerinin sistematik listesini sağlar.

Adım 3 — Test ortamı hazırlığı

Testler mümkünse üretimden izole bir ortamda, gerçek kişisel veri yerine sentetik veriyle yürütülür. Çıktı ve olay kaydı (logging) açılır; testlerin tekrarlanabilir olması için model sürümü, sistem promptu versiyonu ve sıcaklık gibi parametreler sabitlenir. Canlı ortam testi zorunluysa, kapsam ve hız sınırları yazılı olarak mutabakata bağlanır.

Adım 4 — Otomatik payload taraması

Bilinen saldırı kalıplarından oluşan bir payload kütüphanesi otomatik olarak koşturulur. Bu, geniş yüzeyi hızlıca tarayıp düşük asılı meyveleri yakalar. Türkçeye özgü kalıpların İngilizce ağırlıklı açık kaynak setlerde eksik kaldığını göz önünde bulundurmak gerekir; yerel dil ve morfoloji varyantları kapsama dahil edilmelidir. Her payload tek atış değil, çoklu tekrarla çalıştırılıp başarı oranı ölçülür.

Adım 5 — Manuel kırmızı takım

Otomasyon kalıpları yakalar; yaratıcı saldırıyı insan bulur. Bu adımda uzman analist çok-turlu senaryolar kurar: kademeli güven inşası, bağlam kaydırma, rol yapma, çeviri/echo bahaneleri ve modelin önceki cevaplarını silaha çevirme. Manuel faz, otomatik taramanın gözden kaçırdığı bileşik ve bağlama duyarlı zafiyetleri ortaya çıkarır.

Adım 6 — Tool/agent ve RAG katmanı testi

Chatbot araç çağırıyorsa, her tool için yetki sınırı ve girdi doğrulaması ayrı ayrı zorlanır: modele izin verilmeyen bir tool'u çağırtabilir miyiz, bir tool'un çıktısına gömülü komut bir sonraki adımı yönlendirebilir mi? RAG varsa, bilgi tabanına kontrollü zararlı belge eklenip çıktının yönlendirilip yönlendirilemediği test edilir. Bu adım, saf metin testinin ötesine geçip mimarinin bütününü hedefler.

Adım 7 — Bulguların skorlanması ve önceliklendirilmesi

Her bulgu; etki (veri hassasiyeti, yetki genişliği), tekrarlanabilirlik (başarı oranı) ve istismar kolaylığı üzerinden skorlanır. Olasılıksal doğa nedeniyle "10 denemeden 7'sinde başarılı" gibi oranlar, ikili bir "var/yok" etiketinden daha bilgilendiricidir. Bulgular kritik/yüksek/orta/düşük olarak sınıflandırılıp düzeltme önceliğine bağlanır.

Adım 8 — Raporlama

Rapor hem yönetici özeti hem de teknik ek içerir. Her bulgu için: senaryo, tam payload/konuşma dökümü, gözlenen davranış, başarı oranı, etki, standart eşlemesi (OWASP/ATLAS) ve somut düzeltme önerisi verilir. Kanıt olmadan iddia yazılmaz; her bulgu yeniden üretilebilir olmalıdır. Raporlama ayrıntıları 7. bölümde ele alınır.

Adım 9 — Düzeltme sonrası yeniden test

Ekip düzeltmeleri (sistem promptu sertleştirme, çalışma zamanı guardrail, tool izin daraltma, girdi/çıktı filtreleme) uyguladıktan sonra, aynı senaryolar yeniden koşturularak bulguların gerçekten kapandığı doğrulanır. Bu adım, testi bir onay damgasından bir güvence döngüsüne çevirir.

5. Test kapsamı nasıl belirlenir?

İyi bir kapsam belgesi, testin neyi kapsadığını ve neyi kapsamadığını net biçimde çizer. Kurumsal bir LLM güvenlik testi için kapsam belgesinde şu başlıklar bulunmalıdır:

• Hedef varlıklar: Test edilecek chatbotlar, kanallar, model ve sürümler.
• Erişim düzeyi: Siyah/gri/beyaz kutu; sistem promptu ve tool tanımlarına erişim var mı?
• Zafiyet sınıfları: Bölüm 3'teki altı sınıftan hangileri kapsamda; RAG veya agent yoksa çıkarılır.
• Sınırlar: Test edilmeyecek arka uç sistemler, veri tahribatı yasağı, hız sınırları.
• Ortam: Staging mı üretim mi; sentetik veri mi kullanılacak.
• Zaman penceresi ve iletişim: Test aralığı, acil durum irtibatı, olay bildirim eşiği.

Kapsamın en sık atlanan yanı dolaylı yüzeydir: chatbotun okuduğu belgeler, indekslediği web içeriği ve entegre olduğu tool'ların girdileri. Yalnızca son kullanıcı sohbet kutusunu test etmek, saldırı yüzeyinin yarısını görmezden gelmek anlamına gelir.

6. Kabul kriterleri nasıl tanımlanır?

Kabul kriterleri, testin başlamasından önce yazılmalıdır — sonradan tanımlanan eşikler bulguları kabul edilebilir göstermeye eğilimlidir. Sağlam kabul kriterleri, olasılıksal doğayı hesaba katan ölçülebilir eşiklerdir. Örnek bir çerçeve:

Kritik bir noktada dürüst olmak gerekir: hiçbir chatbot "prompt injection'a karşı %100 bağışık" ilan edilemez. Bu, mevcut araştırma durumunda gerçekçi bir hedef değildir. Bu yüzden olgun kabul kriterleri, tek başına dönemsel testi değil; katmanlı savunma ve çalışma zamanı guardrail ile sürekli izlemeyi de bir gereklilik olarak yazar. Test bir anlık fotoğraf verir; guardrail sürekli koruma sağlar.

7. Raporlama nasıl yapılır?

Bir güvenlik testinin değeri, raporunun eyleme dönüştürülebilirliği kadardır. Kaliteli bir chatbot güvenlik testi raporu şu bileşenleri içerir:

• Yönetici özeti: Genel risk duruşu, bulgu dağılımı ve canlıya çıkış tavsiyesi — teknik olmayan okuyucu için.
• Metodoloji ve kapsam: Uygulanan erişim düzeyi, model sürümü, test tarihleri ve sınırlar.
• Bulgu detayları: Her bulgu için başlık, kritiklik, senaryo, tam konuşma/payload dökümü, gözlenen davranış, başarı oranı ve etki.
• Standart eşlemesi: Her bulgunun OWASP LLM Top 10 ve MITRE ATLAS karşılığı.
• Düzeltme önerileri: Somut, uygulanabilir öneriler (sistem promptu, guardrail kuralı, tool izni, filtreleme).
• Yeniden test durumu: Düzeltme sonrası hangi bulguların kapandığı.

Raporlamada iki yaygın hata vardır. Birincisi, kanıtsız iddia — "chatbot jailbreak'e açık" demek yerine, hangi konuşmanın kaç denemede hangi çıktıyı ürettiği gösterilmelidir. İkincisi, şişirilmiş istatistik — abartılı "başarı oranı" rakamları raporun güvenilirliğini zedeler. Her sayı doğrulanabilir bir denemeye dayanmalıdır.

8. Standart ve regülasyon eşlemesi

Kurumsal bir çalışmada bulguları tanınan çerçevelere bağlamak, hem iç uyum ekipleri hem de denetçiler için ortak bir dil kurar. Chatbot güvenlik testi tipik olarak şu çerçevelerle eşlenir:

Türkiye'de faaliyet gösteren kurumlar için KVKK boyutu özellikle önemlidir: chatbotun ürettiği veya sızdırdığı her kişisel veri, 6698 sayılı kanun kapsamındadır. Sektör bağlamı (finans, sağlık, kamu, telekom) ek yükümlülükler getirebilir; testin kapsamı bu regülatif zemine göre genişletilmelidir.

9. Sonuç

Kurumsal chatbot güvenlik testi, bir "güzel olsa iyi olur" kalemi değil; LLM tabanlı bir asistanı canlıya almanın önkoşuludur. Doğru yapıldığında süreç nettir: kapsam belirle, tehdit modele, izole ortamda otomatik ve manuel test et, tool ve RAG katmanını ayrıca zorla, bulguları skorla ve kanıta dayalı raporla, sonra düzeltmeleri yeniden test et. Kabul kriterleri baştan yazılır; hiçbir chatbot mutlak bağışıklık iddia edemez, bu yüzden dönemsel test ile sürekli çalışma zamanı koruması birlikte konumlanır.

AltaySec bu iki katmanı birlikte ele alır. LLM Pentest hizmeti bu rehberdeki dokuz adımlı metodolojiyi Türkçe saldırı yüzeylerini de kapsayacak biçimde uygularken, Guardian ürünü tespit edilen zafiyetlere karşı çalışma zamanında sürekli koruma sağlayan bir guardrail katmanı sunar. Testin ortaya koyduğu boşluk, Guardian'ın kapatmayı hedeflediği yüzeydir.

Kurumunuzun chatbot güvenlik test kapsamını netleştirmek veya bir POC planlamak için hizmetler sayfamıza göz atabilir ya da [email protected] üzerinden ulaşabilirsiniz.