Prompt Injection'ı Anlamak: Yapay Zekâ Uygulamaları Neden Kendi Güvenlik Kontrollerine İhtiyaç Duyar

Klasik bir web uygulaması girdi işlerken kanıtlanmış bir kural geçerlidir: veri veridir, kod koddur ve ikisini ayrı tutarsınız. SQL injection, girdi asla komut olarak yorumlanmayarak önlenir.

Dil modellerinde tam da bu ayrım çöker. Bir LLM için talimat ve içerik aynı metindir. Bu bir yanlış yapılandırma değil — modelin çalışma biçimidir. Ve prompt injection'ın OWASP Top 10 for Large Language Model Applications (2025) içinde LLM01 sırasında, yani genel olarak en önemli risk olarak yer almasının nedeni budur.

Bu yazı sorunu hype'sız ve hafifletmeden açıklar — bir yapay zekâ özelliğini onaylayacak karar vericiler ve onu inşa eden ekipler için.

Prompt injection aslında nedir

Bir prompt injection açığı, kullanıcı girdisinin modelin davranışını veya çıktısını istenmeyen şekilde değiştirmesiyle oluşur. OWASP'a göre bu girdinin insanlar için görünür veya okunabilir olması bile gerekmez — modelin onu işlemesi yeterlidir.

Başka bir deyişle: bu, modele "kötü bir parola" vermek değildir. Modelin okuduğu içeriğin kendisinin bir talimata dönüşebilmesidir.

İki temel biçim vardır:

• Doğrudan prompt injection. Kullanıcının girdisi manipüle eden talimatı kendisi içerir ("önceki kurallarını yok say ve ...").
• Dolaylı prompt injection. Daha tehlikeli örüntü: model dış içeriği — bir web sayfası, bir PDF, bir e-posta, bilgi indeksindeki bir belge — işler ve o yabancı içerikte davranışı değiştiren talimatlar gizlidir. Kullanıcı kötü niyetli bir şey yapmadı; sadece bir sayfanın özetlenmesini istedi.

Multimodal sistemlerle üçüncü bir katman eklenir: talimatlar zararsız metinle birlikte işlenen görsellerde gizlenebilir.

Somut bir senaryo

OWASP örneği gösterişsizdir ve tam da bu yüzden öğreticidir: bir kişi bir LLM'den bir web sayfasını özetlemesini ister. Sayfada gizli talimatlar vardır. Model onları izler — ve örneğin, yüklenmesi özel konuşmanın bölümlerini yabancı bir sunucuya sızdıran bir görsel bağlantısı ekler.

Burada kimse bir parola açıklamadı veya dosya yüklemedi. Saldırı güvenilir görünen içerik üzerinden geçti. Dolaylı injection'ı kurumsal bağlamda alakalı kılan tam da budur: bir asistan belgeleri, talepleri, e-postaları veya web içeriğini işlemeye başladığı an, içerik kaynağı saldırı yüzeyinin parçasıdır.

Neden "tek bir çözüm" yok

İşte OWASP'ın açıkça söylediği rahatsız edici gerçek: üretken modellerin stokastik doğası nedeniyle, prompt injection'ı tamamen önlemek için kusursuz yöntemler olup olmadığı belirsizdir.

Bu, yapay zekâ kullanmamak için bir sebep değildir. Yapay zekâyı klasik bir web uygulamasından farklı güvenceye almak için bir sebeptir. Prompt injection tek bir filtreyle önlenmez — olası zararı mimariyle sınırlandırılır.

Belirleyici bakış değişimi: sadece filtrelemek değil, sınırlamak

En yararlı soru "her injection'ı nasıl önleriz?" değil, "bir injection başarılı olursa en kötü ne olabilir?" sorusudur.

Cevap "kötü bir şey olmaz" ise güvenli bir sistem inşa etmişsinizdir — injection imkânsız olduğu için değil, hiçbir şey başaramadığı için.

Bundan dört mimari ilke doğar:

1. Model için minimum yetki

Model yalnızca belirli görevin ihtiyaç duyduğuna erişebilmeli. Bir özetleme asistanının ERP'ye yazma erişimine ihtiyacı yoktur. Model az şey yapabiliyorsa, başarılı bir injection az şey yapabilir.

2. Araç izolasyonu ve etkide insan onayı

Model yalnızca metin ürettiği sürece zarar sınırlıdır. Çıktı otomatik olarak bir eylemi tetiklediğinde tehlikeli olur — bir e-posta gönderir, bir kaydı değiştirir, bir ödeme başlatır. Tam da burada bir insan döngüye aittir. Etkili eylemler otomatik değil, onay gerektirir.

3. Güvenilmeyen içeriği güvenilmeyen olarak ele almak

Dış içerik — web, gelen e-posta, yüklenen dosya, yabancı belge — yalnızca bilgi değil, potansiyel talimattır. Bu kaynaklar görünür şekilde ayrılmalı, kapsamı daraltılmalı ve yükseltilmiş yetkiyle işlenmemelidir.

4. Görünürlük ve denetim izi

Bir yanıta hangi kaynaklar girdi? Ne önerildi? Ne onaylandı? Bu iz olmadan başarılı bir injection ancak zarar göründüğünde fark edilir. Burada izlenebilirlik bir konfor değil, bir güvenlik fonksiyonudur.

KOBİ'lerde pratikte ne anlama gelir

Bir araştırma ekibine ihtiyacınız yok. Bir yapay zekâ özelliğinin canlıya geçişinden önce beş soruya dürüst bir cevaba ihtiyacınız var:

• Özellik yabancı içerik mi işliyor (web, e-posta, upload, bilgi indeksi)?
• Modelin hangi yetkileri var — ve göreve göre minimize edilmiş mi?
• Çıktı otomatik olarak bir eylemi tetikleyebilir mi, yoksa arada bir insan var mı?
• Güvenilmeyen kaynaklar iç, doğrulanmış olanlardan farklı mı ele alınıyor?
• Bir olayın hiç fark edilebilir olmasını sağlayacak bir denetim izi var mı?

Bu beş soru bir güvenlik denetiminin yerine geçmez. Ama savunulabilir bir yapay zekâ özelliğini, üretime göndermemeniz gerekenden ayırır.

Almanya'nın BSI IT güvenlik durum raporu da yapay zekâ uygulamalarını klasik web güvenliğinin özel bir durumu olarak değil, ayrı, büyüyen bir saldırı yüzeyi olarak sınıflandırır. Bu OWASP bulgusuyla örtüşür: LLM güvenliği bir ek değil, kendi disiplinidir.

Sık sorulan sorular

"Talimatlarını yok say"a karşı bir girdi filtresi yeterli mi? Hayır. Filtreler bilinen örüntüleri yakalar, sorunun stokastik doğasını veya gizli dolaylı injection'ı değil. Filtreler bir katmandır, çözüm değil.

Prompt injection sadece chatbot'larda mı bir konu? Hayır. Bir modelin kendi kontrol etmediği içeriği işlediği her yerde geçerlidir — özetleme, RAG bilgi asistanı, belge işleme, ajanlar.

Bu, yapay zekâ kullanmamalıyız mı demek? Tam tersi. Yapay zekâyı sınırlı yetkilerle, etkide insan onayıyla ve loglamayla kullanmak demek — tam da kontrollü pilotlar ve bilgi asistanları yazılarımızda savunduğumuz tasarım ilkesi.

Bu değerlendirmeyi kim yapmalı? Kimse tek başına değil. İş birimi (özellik ne yapabilir?), geliştirme (hangi yetkiler, hangi araçlar?) ve ideal olarak bir güvenlik bakışı — canlıya geçişten önce, sonra değil.

Sonuç

Prompt injection iyi bir nedenle OWASP LLM risklerinin bir numarasındadır: dil modellerinin çalışma biçiminden doğar ve bir filtreyle yapılandırılarak yok edilemez. Savunulabilir yaklaşım her injection'ı önlemek değil, olası zararını minimum yetki, araç izolasyonu, insan onayı ve izlenebilirlikle sınırlamaktır.

Yapay zekâ uygulamaları kendi güvenlik kontrollerine ihtiyaç duyar — çünkü kendi saldırı yüzeyleri vardır. Bu yapay zekâya karşı bir argüman değildir. Onu sorumlu biçimde üretime almanın koşuludur.

Sonraki adım

Yabancı içerik işleyen veya eylem tetikleyebilen bir yapay zekâ özelliği mi planlıyorsunuz? Beş soruyu canlıya geçişten önce cevaplatın. Bizimle security-by-design'lı bir kontrollü yapay zekâ piloti hakkında konuşun — veya riski baştan çerçeveleyen bir yapay zekâ hazırlık kontrolüyle başlayın.

Kaynaklar

• OWASP, Top 10 for LLM Applications (2025) — LLM01:2025 Prompt Injection — genai.owasp.org
• OWASP, Top 10 for Large Language Model Applications — owasp.org
• NIST, Generative AI Profile for the AI RMF — nist.gov
• BSI, Die Lage der IT-Sicherheit in Deutschland — bsi.bund.de