Token’ın Körlüğü: LLM’ler Neden Prompt Injection’a Karşı Yapısal Olarak Savunmasız? Giriş: Bir Hata Değil, Bir Özellik
Yapay zekâ güvenliği tartışmalarında “prompt injection” (istem enjeksiyonu) çoğu zaman sıradan bir yazılım açığı gibi sunuluyor: bulunur, yamanır, kapatılır. Oysa bu çerçeve yanıltıcı. Prompt injection, belirli bir modelin ya da belirli bir ürünün hatası değil; büyük dil modellerinin (LLM) çalışma biçiminin, yani mimarinin kendisinin doğrudan bir sonucu. OWASP’ın LLM uygulamaları için hazırladığı risk listesinde prompt injection, 2025 sürümünde de bir numaralı güvenlik açığı olarak yer alıyor . Üstelik bu bir moda ya da abartı değil: 2025’te Microsoft 365 Copilot’a yönelik EchoLeak açığı (CVE-2025-32711, CVSS 9.3), tek bir e-postayla — kullanıcı hiçbir şeye tıklamadan — kurumsal veri sızdırılabildiğini kanıtlayarak bu tehdidin üretim sistemlerinde gerçek bir istismar sınıfı olduğunu gösterdi .
Bu yazının temel savı şu: LLM’lerin prompt injection’a açık olmasının nedeni, talimat (instruction) ile veri (data) arasındaki farkı token düzeyinde ayırt edememeleri; bu körlük ne ön eğitimle (pre-training) ne de son eğitimle (post-training) giderilebilir; agent’ların yükselişi sorunu katlayarak büyütüyor; ve mimari kökten kaynaklanan bu zaafın kısa vadede yapısal bir çözümü görünmüyor. Sorunun Mimari Kökü: Her Şey Aynı Token Akışında
Klasik bilgisayar sistemlerinde kod ile veri arasında donanımsal ve işletim sistemi düzeyinde sınırlar vardır: bellek koruması, çekirdek/kullanıcı kipi ayrımı, tip sistemleri. Transformer tabanlı bir dil modelinde bunların hiçbiri yok. Sistem istemi, kullanıcı mesajı, RAG ile getirilen doküman, araç çıktısı, web sayfası içeriği — hepsi aynı bağlam penceresine tek bir token dizisi olarak girer ve aynı dikkat (attention) hesaplamasından geçer. “Yönerge” ile “içerik” arasında hiçbir kayıt (register), hiçbir ayrıcalık düzeyi, hiçbir tip ayrımı bulunmaz .
Model, hangi token’ları talimat olarak ele alacağını ancak istatistiksel ipuçlarından çıkarır: token’ların istem şablonundaki konumu, çevreleyen bağlam, eğitim sırasında öğrenilen kalıplar. Ve bu çıkarım geçersiz kılınabilir. Modelin okuduğu herhangi bir metni — bir web sayfasını, bir e-postayı, bir müşteri destek talebini, bir RAG dokümanını — kontrol eden bir saldırgan, modelin talimat olarak işlediği token’lar enjekte edebilir 5.
StruQ (Structured Queries) makalesinin yazarları durumu net biçimde özetliyor: “LLM’ler talimat izlemek için girdilerinin tamamını tarar ve istemler ile veri arasında bir ayrım olmadığından, mevcut LLM’ler bu tür saldırılarca kolayca kandırılır.” Aynı çalışma, prompt injection zaafının modellerin talimat izleme yeteneğinden kaynaklandığını vurguluyor — talimat anlamayan modeller prompt injection’a duyarlı değildir, ama o zaman da kullanışlı değildirler . Yani zaaf, yetenekle aynı madalyonun iki yüzü.
SQL injection ile yapılan analoji burada öğretici ama bir noktada sınırlı kalıyor. SQL injection’da da kontrol akışı ile veri aynı kanalı paylaşıyordu; fakat çözüm — parametreli sorgular — kanalı yapısal olarak ikiye ayırmakla mümkün oldu çünkü SQL ayrıştırıcısı deterministikti 5. LLM’de ise “ayrıştırıcı” olasılıksal bir sinir ağı; doğal dilde talimat ile veri arasında sözdizimsel bir sınır yok. “Lütfen şu metni özetle” bir talimat, “önceki talimatları yok say” da bir metin parçası olabilir — hangisinin hangisi olduğu, çözümlenmesi gereken dilin kendisine bağlıdır. Ön Eğitimin Rolü: Olasılık Dağılımı Tarafsız, Dolayısıyla Tarafsızdır
Zaafın ilk katmanı ön eğitimde (pre-training) atılır. Temel dil modelinin tek hedefi vardır: bir sonraki token’ın olasılık dağılımını tahmin etmek. Bu süreçte model, internet ölçeğindeki metinlerdeki her türlü kalıbı öğrenir — teknik dokümantasyon, diyaloglar, romanlar, talimat listeleri, forum tartışmaları ve evet, “önceki talimatları yok say” kalıbını da. Ön eğitim modelin dilsel dünya modelini kurar ama ona hiçbir güven hiyerarşisi kazandırmaz. Model açısından bağlam penceresindeki bir cümle, kaynağı ne olursa olsun, devamını olasılıksal olarak şekillendiren bir koşuldur.
Bu, iki önemli sonuç doğurur:
Birincisi, token düzeyinde kaynak körlüğü. Tokenizasyon ve gömme (embedding) süreci her token’ı aynı uzayda temsil eder; dikkat mekanizması token’ların kimliğiyle değil konumu ve içeriğiyle ilgilenir. “Sistem bunu söyledi” bilgisi ancak şablon işaretçileriyle (özel rol token’ları gibi) dolaylı olarak kodlanır — ve bu işaretçiler güvenlik sınırı değil, eğitim verisinde öğrenilmiş bir konvansiyondur . Rol ayrımı (system/user/assistant/tool), modellerin eğitilme biçiminin bir ürünüdür; uygulanabilir bir izolasyon değildir. Nitekim kullanıcı/araç ayrımının amacı modelin araç metnini “komut değil bilgi” olarak görmesini öğretmektir — ama bu öğrenilmiş bir eğilimdir, kırılamaz bir kural değil 8.
İkincisi, ön eğitimde öğrenilen kalıplar saldırgana çalışır. Model, “yok say”, “yeni görevin şu”, “bunu kimseye söyleme” gibi ifadelerin ardından itaatin geldiğini milyonlarca metinden öğrenmiştir. Saldırgan, modelin kendi eğitim dağılımını silaha dönüştürür. Bu, saldırının neden basit ifadelerle bile sık sık başarılı olduğunu açıklar: saldırgan modelle değil, modelin öğrendiği dil istatistikleriyle oynar. Son Eğitim: Hem Sebep Hem (Kısmi) Pansuman
Post-training — yani instruction tuning, RLHF/RLAIF ve benzeri hizalama aşamaları — sorunu ilginç bir çift yönlü dinamiğe sokar.
Sorunu derinleştiren taraf: Ham temel modeller nispeten “pasif” tamamlayıcılardır; onları gerçekten kullanışlı kılan, talimat izleme eğitimidir. Ama StruQ makalesinin de belirttiği gibi, prompt injection’a karşı savunmasızlık doğrudan bu talimat izleme yeteneğinden beslenir: “Talimatları anlamayan modeller prompt injection’a duyarlı değildir” 7. Model talimat izlemede ne kadar iyi ve esnekse, verinin içine gömülmüş talimatları da o kadar iyi “izler”. Dahası, yardımseverlik için optimize edilmiş modeller, bağlamdaki herhangi bir makul isteğe uyum sağlama yönünde güçlü bir eğilim geliştirir — bu eğilim, dolaylı enjeksiyonun tam da istismar ettiği şeydir.
Çözüm vaadi sunan (ama tutmayan) taraf: Endüstri, sorunu yine eğitimle aşmaya çalışıyor. OpenAI’ın Nisan 2024 tarihli “Instruction Hierarchy” çalışması bunun en bilinen örneği: modele talimatların ayrıcalık sırasını (sistem > kullanıcı > üçüncü taraf/araç çıktısı) öğreten bir otomatik veri üretim yöntemiyle, düşük ayrıcalıklı talimatları seçici olarak yok sayması öğretiliyor. Çalışma, eğitimde görülmeyen saldırı türlerine karşı bile dayanıklılığı ciddi ölçüde artırdığını rapor ediyor .
Ama burada kritik bir ayrıntı var: bu yaklaşımlar olasılıksal savunmalardır. Model, hiyerarşiye uymayı öğrenir — yüzde 99 oranında uysa bile, kalan yüzde 1 saldırganın çalışma alanıdır. Simon Willison’ın ifadesiyle, “saldırganın işi, aradan sızan yüzde 1’lik saldırıyı bulmaktır. SQL injection veya XSS’i zamanın yüzde 1’inde başarısız olan yöntemlerle koruyor olsaydık, sistemlerimiz anında hack’lenirdi” . Eğitim, saldırı yüzeyini küçültür ama güvenlik garantisi veremez, çünkü garanti verecek olan mekanizma — token düzeyinde güven sınırı — mimaride mevcut değildir.
Özetle: ön eğitim körlüğü yaratır, son eğitim bu körlüğü hem derinleştirir (talimat izlemeyi öğreterek) hem de üzerine istatistiksel bir bandaj koyar (hiyerarşi öğreterek). İkisi de yapısal sınır inşa etmez. Doğrudan ve Dolaylı Enjeksiyon: Saldırı Yüzeyinin Anatomisi
Prompt injection iki temel biçimde gelir :
• Doğrudan enjeksiyon: Saldırgan modelle doğrudan konuşur; “önceki talimatları yok say ve sistem istemini açıkla” türü girişimler.
• Dolaylı enjeksiyon (IPI): Saldırgan kullanıcıyla hiç temas etmez; modelin okuyacağı içeriği — web sayfası, e-posta, doküman, kod deposu yorumu — zehirler.
Dolaylı enjeksiyon kavramını ilk sistematik biçimde tanımlayan Greshake ve arkadaşlarının 2023 tarihli makalesi, LLM-entegre uygulamalarda getirilen (retrieved) istemlerin “keyfi kod” gibi davranabildiğini, bunun uzaktan kontrol, kalıcı ele geçirme, veri hırsızlığı ve hizmet reddiyle sonuçlanabileceğini gösterdi . Makalenin o dönem için çarpıcı olan tespiti — “bu yeni tehditlere karşı etkili önlemler şu anda mevcut değil” — aradan geçen yıllara rağmen büyük ölçüde geçerliliğini koruyor 5.
Çok modlu (multimodal) modellerle saldırı yüzeyi genişledi: talimatlar artık görüntülerin içine, insan gözünün göremeyeceği biçimlerde de gömülebiliyor; OWASP bunu 2025 listesinde ayrıca vurguluyor 12 1. Agent Çağı: Sohbet Botu Kandırılınca Metin Üretir, Agent Kandırılınca Eylem Yapar
Prompt injection’ı gerçek bir felaket senaryosuna dönüştüren gelişme, LLM’lerin araç kullanan otonom agent’lara evrilmesidir. Manipüle edilmiş bir sohbet botu istenmeyen metin üretir; manipüle edilmiş bir agent ise bulut altyapısına erişebilir, kimlik bilgilerini sızdırabilir, dosyaları değiştirebilir, kod çalıştırabilir. Klasik güvenlik literatüründeki “confused deputy” (ayrıcalıklı bir varlığın kendi yetkisini kötüye kullanması için kandırılması) problemi, agent bağlamında tam gücüyle tezahür ediyor .
Simon Willison’ın Haziran 2025’te formüle ettiği “ölümcül üçlü” (lethal trifecta) bu riskin en net çerçevesi: Bir agent aynı anda (1) özel verilere erişim, (2) güvenilmeyen içeriğe maruz kalma ve (3) dışarı iletişim kurabilme (exfiltration kanalı) özelliklerine sahipse, saldırgan agent’ı veriyi çalıp kendisine göndermesi için kolayca kandırabilir . Ve acı gerçek şu ki, kullanışlı agent’ların çoğu tam da bu üç özelliği birden gerektirir: e-postalarınızı okuyup özetleyen, web’de araştırma yapan, sizin adınıza işlem yapan bir asistan, tanımı gereği üçlüyü barındırır .
Veri sızdırma teknikleri de artık standartlaşmış durumda: URL parametrelerine gizli veri kodlama, çıktı filtrelerini aşmak için Base64, saldırgan kontrollü URL’lerden Markdown görüntüsü render ettirme, harici depolamaya dosya yazma 14.
Gerçek vakalar teorinin ötesine geçti:
• EchoLeak (CVE-2025-32711, CVSS 9.3): Haziran 2025’te Aim Security araştırmacılarının açıkladığı bu sıfır-tıklama açığında, saldırganın gönderdiği tek bir e-posta yeterliydi. Copilot e-postayı RAG sürecinde okuduğunda gömülü talimatlar devreye giriyor, Microsoft’un XPIA sınıflandırıcısı atlatılıyor, referans-tarzı Markdown bağlantılarıyla link redaksiyonu aşılıyor, otomatik görsel yüklemesiyle veri dışarı akıtılıyor ve CSP, izin verilen bir Microsoft Teams proxy alan adı üzerinden baypas ediliyordu. Kullanıcı hiçbir şeye tıklamıyor, hiçbir uyarı görmüyordu — prompt injection’ın üretim sisteminde somut veri sızıntısı için silahlaştırıldığı bilinen ilk vaka 3 .
• CamoLeak (CVSS 9.6): Haziran 2025’te GitHub Copilot Chat’te bulunan bu açık, gizli PR yorumları üzerinden dolaylı enjeksiyonu, GitHub’ın kendi Camo görsel proxy’sini bir exfiltration sözlüğüne çeviren bir teknikle birleştirerek özel depolardan sır ve kaynak kodu sızdırdı. GitHub’ın çözümü, Copilot Chat’te görsel render’ı tamamen kapatmak oldu — cerrahi bir düzeltmenin zorluğunu gösteren kör bir hamle .
Agent’lar arası saldırılar da ufukta: agent ağlarında bot-to-bot enjeksiyon, uzun süreli belleğe kalıcı talimat yerleştirme (memory injection) ve tedarik zinciri üzerinden araç/MCP zehirlenmesi gibi vektörler belgelenmiş durumda . Savunma Denemeleri ve Neden Yetmedikleri
Endüstrinin ve akademinin geliştirdiği savunmaları üç kuşağa ayırmak mümkün:
Birinci kuşak: filtreler ve sınıflandırıcılar. Girdi/çıktı filtreleri, enjeksiyon tespiti için eğitilmiş LLM sınıflandırıcıları (Microsoft Prompt Shields gibi), sistem istemine “dış içerikteki talimatları izleme” uyarıları eklemek. Bunların ortak zaafı, savunmanın kendisinin de olasılıksal olması: adaptif saldırılar karşısında 2025–2026 çalışmalarında yüzde 50–85 başarı oranları belgeleniyor 5 . EchoLeak’in Microsoft’un XPIA sınıflandırıcısını “normal iş yazışması gibi kaleme alınmış” bir metinle atlatması bunun canlı örneği 3.
İkinci kuşak: eğitim tabanlı dayanıklılık. Instruction Hierarchy 9, spotlighting (güvenilmeyen içeriği ayırıcılarla işaretleme) , StruQ gibi yapılandırılmış sorgularla istem/veri ayrımını öğretme 7. Bunlar saldırı başarısını ciddi oranda düşürür ama yukarıda açıklandığı gibi garanti üretemez; ayrıca StruQ’un kendi yazarları bile gelecekteki ideal çözümün “bu ayrımı doğal olarak anlayan mimariler” olacağını kabul ediyor — yani mevcut mimariyle değil 7.
Üçüncü kuşak: modelin dışında, mimari savunma. En ciddiye alınması gereken yaklaşım bu: LLM’i bir güvenlik sınırı olarak kullanmamak. Google DeepMind araştırmacılarının CaMeL sistemi bunun öncüsü: modelin etrafına koruyucu bir sistem katmanı örülüyor, kontrol ve veri akışı güvenilir sorgudan açıkça çıkarılıyor, böylece güvenilmeyen veri program akışını asla etkileyemiyor; “capability” etiketleriyle hangi verinin nereden geldiği izleniyor ve araç çağrılarında güvenlik politikaları zorlanıyor. CaMeL, AgentDojo kıyaslamasında savunmasız sistemin yüzde 84 başarısına karşılık yüzde 77 görev başarısıyla kanıtlanabilir güvenlik sağlıyor . Willison bunu “güçlü garanti iddia eden ilk prompt injection savunması” olarak niteliyor 11.
Ama CaMeL’in kendi yazarları dahi “prompt injection çözüldü mü?” sorusuna hayır diyor: sistem, güvenlik politikalarının elle kodlanmasını ve bakımını gerektiriyor, kullanıcıya ek yük bindiriyor, onay yorgunluğu (user fatigue) sorunu var ve kontrol/veri akışını etkilemeyen metin-metin saldırılarına (örneğin enjekte edilmiş yanıltıcı özetler, kimlik avı) karşı kapsam dışı 11 . Dahası bu yaklaşım, modelin kendisini değil etrafındaki sistemi güçlendiriyor — yani LLM’in token körlüğü olduğu yerde duruyor; sadece sonuçları sınırlandırılıyor. Neden Yapısal Çözüm Yakın Zamanda Gelmeyecek?
Buraya kadar olan tabloyu birleştirince, karamsar ama iyi temellendirilmiş bir sonuca ulaşıyoruz:
1- Zaaf, hatanın değil tasarımın parçası. Talimat ile veriyi aynı kanaldan işlemek, LLM’lerin doğal dilde esnek biçimde yönlendirilebilmesinin ta kendisi. Bu esnekliği kaldırırsanız elinizde LLM kalmaz 7 5.
2- Eğitim, olasılıksal iyileştirmeden öteye gidemez. İster ön eğitim ister son eğitim, ister hiyerarşi eğitimi — hepsi modelin eğilimlerini değiştirir, garantilerini değil. Saldırgan adaptif ve sonsuz ifade biçimine sahipken, yüzde 99’luk savunma güvenlik anlamında başarısızlıktır 11 5.
3- Doğal dilde talimat/veri sınırı tanımsal olarak belirsiz. SQL için deterministik ayrıştırıcı yazılabildi; doğal dil için bu mümkün değil çünkü “talimat mı, veri mi?” sorusunun cevabı çoğu zaman ancak anlamsal bağlamla — yani manipüle edilebilir bağlamla — verilebilir .
4- Sektörün kendisi bunu kabul etmeye başladı. Birleşik Krallık Ulusal Siber Güvenlik Merkezi (NCSC), Aralık 2025’te prompt injection’ın “asla tamamen düzeltilemeyecek bir problem olabileceği” uyarısında bulundu; Şubat 2026’da ise OpenAI, ChatGPT için Lockdown Mode’u duyururken AI tarayıcılarında prompt injection’ın “asla tamamen yamanamayabileceğini” kamuoyu önünde kabul etti 28 22. Bunlar, sorunun yol haritasındaki geçici bir engel değil, kalıcı bir yapısal özellik olarak görülmeye başlandığının itiraflarıdır.
5- Gerçekçi ufuk, “çözüm” değil “etki sınırlama”. Bugün çalışan şey — CaMeL tarzı capability sistemleri, ayrıcalık ayrımı, ölümcül üçlüden kaçınma, deterministik API düzeyi garantiler, en az ayrıcalık ilkesi — modelin dışında inşa edilen mimari kontrollerdir 17 5 25. Yani sektör, SQL injection’da olduğu gibi kanalı ayırmayı öğreniyor; ama bu sefer ayrım, modelin içinde değil çevresindeki sistemlerde kuruluyor ve her uygulama için yeniden, elle, kusurlu biçimde.
Token düzeyinde gerçek bir güven sınırı — modelin mimarisine gömülü, eğitimle değil yapıyla dayatılan bir talimat/veri ayrımı — bugünkü transformer paradigmasının dışında bir yenilik gerektiriyor. Böyle bir mimari ne araştırma gündeminde olgunlaşmış durumda ne de üretim sistemlerine girecek kadar kanıtlanmış. O güne kadar prompt injection, yamanacak bir hata değil, yönetilecek bir risk olarak kalacak. Sonuç
LLM’lerin prompt injection’a açıklığı, onların en temel yeteneğinin — doğal dilde talimatları esnekçe izleyebilmenin — gölgesidir. Ön eğitim token’ları kaynağından habersiz kılar; son eğitim bu körlüğü hem büyütür hem de istatistiksel bandajlarla örter; agent’lar sorunu metin üretiminden gerçek dünya eylemlerine taşır; ve EchoLeak ile CamoLeak gibi vakalar, teorinin çoktan pratiğe döküldüğünü gösterir. Mimari değişmedikçe, savunmanın asimptotu yüzde 100’e ulaşamaz. Yapılması gereken, güvenlik mimarisini “model eninde sonunda kandırılacak” varsayımı üzerine kurmak — üçlüyü kırmak, ayrıcalıkları en aza indirmek ve etkiyi deterministik kontrollerle sınırlamaktır. Çaresizlik değil bu; mühendislik olgunluğudur. Kaynakça
1- Willison, S. (2025). The Lethal Trifecta for AI Agents. simonw.substack.com/p/the-lethal-trifecta-for-ai-agents
2- Willison, S. (2025). CaMeL Offers a Promising New Direction for Mitigating Prompt Injection Attacks. simonwillison.net/2025/Apr/11/camel/
3- Debenedetti, E. vd. (2025). Defeating Prompt Injections by Design (CaMeL). arXiv:2503.18813.
4- Chen, S. vd. (2024). Defending Against Prompt Injection with Structured Queries (StruQ). arXiv:2402.06363.
5- Wallace, E., Xiao, K., Leike, R., Weng, L., Heidecke, J., Beutel, A. (2024). The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions (OpenAI). arXiv:2404.13208.
6- Greshake, K. vd. (2023). Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. arXiv:2302.12173.
7- EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System (CVE-2025-32711) (2025). arXiv:2509.10540.
8- Microsoft MSRC (2025). How Microsoft Defends Against Indirect Prompt Injection Attacks. microsoft.com/en-us/msrc/blog.
9- OWASP Gen AI Security Project (2025). LLM01:2025 Prompt Injection. genai.owasp.org/llmrisk/llm01-prompt-injection/
10- Prompt Injection Attacks in Large Language Models and AI Agent Systems: A Comprehensive Review (2026). MDPI Information, 17(1), 54.
11- Prompt Injection Is a Structural Attack: You Can’t Filter Your Way Out (2026). arunbaby.com.
12- Prompt Injection Explained: The Top AI Security Threat (2026). Vectra AI. vectra.ai/topics/prompt-injection
13- Agent Security Boundaries: From Prompt Injection to Tool Misuse (2025). Medium.
14- Prompt Injection as Role Confusion. role-confusion.github.io
15- How Prompt Injection Attacks Compromise AI Agents (2026). Atlan. atlan.com/know/prompt-injection-attacks-ai-agents/
16- Real User Instruction: Black-Box Instruction Authentication Middleware Against Indirect Prompt Injection (2026). Preprints.org.
17- Testing AI’s “Lethal Trifecta” with Promptfoo (2025). promptfoo.dev/blog/lethal-trifecta-testing/
18- Prompt Injection: The OWASP #1 AI Threat in 2026 (2026). Securance. securance.com/blog
19- AI Security in 2026: Prompt Injection, the Lethal Trifecta, and How to Defend (2026). Airia. airia.com/blog
20- EchoLeak (CVE-2025-32711) Shows Us That AI Security Is Challenging (2025). Checkmarx. checkmarx.com
21- EchoLeak and Indirect Prompt Injection: The Copilot Vulnerability (2026). Sentra. sentra.io/blog/copilot
Yapay zeka enerjik bir çocuk gibi davranıyor. Bir LLM, ona bir görev verdiğinizde, amacına ulaşmak için elinden geleni yapıyor, yan sonuçları değerlendirmiyor. Bir ahlaki kodu yok. Bunun bir kısmı yapısal olarak makine öğrenmesi mimarisinden geliyor.
yapay_zeka prompt_injection