Prompt injection, bir yapay zekâ uygulamasının işlediği girdideki talimatların, uygulamayı amaçlanan davranıştan saptırmasıdır. Kullanıcının yazdığı mesaj doğrudan etki edebilir. Yapay zekânın okuduğu belge, e-posta veya web sayfasındaki bir içerik de dolaylı etki yaratabilir.[1][2]
Risk, asistanın yetkilerine göre değişir. Yalnızca özet çıkaran bir uygulama metni yanlış düzenleyebilir. E-posta gönderebilen veya dosya düzenleyebilen bir ajan, dış içerikteki bir isteği yetkili kullanıcı talimatı gibi yorumladığında gerçek işlemler yapabilir. Bu rehber, bu farkı tanımayı ve kendi uygulamanızda sınırları denetlemeyi anlatıyor.[1][2]
Doğrudan ve dolaylı prompt injection farkı
Doğrudan örnekte kullanıcı girdisi uygulamanın amaçlanan davranışını değiştirir. Bir destek asistanından ürün bilgisi beklerken kullanıcı, uygulamanın kendi kapsamı dışındaki bir görevi yapmasını isteyebilir. Uygulama bunu kabul ederse sonucun etkisi hangi bilgilere ve araçlara erişebildiğine bağlıdır.[1]
Dolaylı örnekte asistan, kendisine verilen görevi yürütürken başka bir kaynağı okur. Kullanıcı bir web sayfasını özetlemesini istemiş olabilir. Sayfanın içindeki metin ise asistanın özet yerine farklı bir iş yapmasını isteyen ifadeler içerir. Bu ifadeler kullanıcının izni olarak değerlendirilmemelidir.[1][2]
Saldırı ihtimalini değerlendirmek için içerik kaynağıyla yetki kaynağını ayırın. “Bu dosyayı özetle” kullanıcı tarafından verilen görevdir. Dosyanın içindeki cümleler özetlenecek malzemedir. Dosya bir işlemi “onaylandı” diye tanımlasa bile, uygulamanın gerçekten onay verilip verilmediğini ayrı bir kanaldan kontrol etmesi gerekir.
Neden özellikle ajanlarda önemlidir?
Ajanlar, metin üretmenin yanı sıra bir uygulama üzerinden araç çağırabilir. Hangi aracı kullanabilecekleri ve bu aracın hangi veriye erişeceği sistem tasarımına bağlıdır. Araç çağrısı bir işlemle sonuçlanıyorsa, modelin yorum hatası ekrandaki yanlış bir cevaptan daha büyük etki yaratabilir.[1][2]
Örneğin bir e-posta asistanı gelen mesajı okur ve yanıt taslağı çıkarır. Bu iş için gönderim yetkisi gerekmiyorsa, taslak hazırlayan aşamaya gönderim izni vermeyin. Böylece bir mesajın içeriği asistanı yönlendirmeye çalışsa bile taslak aşaması kendi başına dışarıya ileti gönderemez. Uygulanabilir ayrım için AgentMail rehberimizi inceleyebilirsiniz.
Bir tarayıcı ajanı için risk, oturum açık hesapları ve erişilebilir sayfaları kapsayabilir. Asistanın bir sayfayı okuyabilmesi ile o sayfadaki formları doldurabilmesi farklı yetkilerdir. İlk pilotta yalnızca görevin gerektirdiği araçları açmak, hangi davranışların mümkün olduğunu belirlemeyi kolaylaştırır.[2]
Yanlış cevapla nasıl ayırt edilir?
Her hatalı cevap prompt injection sonucu değildir. Model belgedeki tarihi yanlış okuyabilir, arama yanlış bölümü getirebilir veya eski bir bilgi kullanılabilir. İnceleme sırasında yalnızca son cevaba değil, modele gelen kaynaklara ve işlem geçmişine de bakın.
Örneğin asistan 5 Kasım yerine 6 Kasım yazmışsa, önce kaynak metin ve arama sonucunu karşılaştırın. Eğer belgeye eklenen bir yönlendirme sonrasında asistan kendiliğinden başka bir çıktı üretmiş veya yetkisi dışında işlem denemişse, içerik kaynaklı yönlendirme ihtimalini değerlendirin.[1]
| Gözlem | İlk inceleme |
|---|---|
| Model yanlış tarih verdi | Belge, sürüm ve çıkarılan metin |
| Asistan yanlış dosyayı özetledi | Arama ve kaynak seçimi |
| Belge içeriği görevi değiştirdi | Dış içeriğin nasıl işlendiği |
| Araç çağrısı yetki dışında kaldı | Uygulama izinleri ve işlem denetimi |
| Kaynak gösterildi fakat iddia desteklenmedi | Cevap ile dayanak metnin eşleşmesi |
Bu tablo olayın nedenini kendiliğinden kanıtlamaz. Ekibin ilk olarak hangi kaydı inceleyeceğini gösterir. Zaman sırasını takip etmek, hatalı cevaptan önce hangi belgelerin ve araçların kullanıldığını belirlemeyi sağlar.
Bir belgeyi güvenli biçimde özetleme örneği
Kurgusal bir ekip, web sayfasındaki duyuruyu üç cümleyle özetleyen bir asistan hazırlıyor. İlk sürüm yalnızca metin okuyor. Dış içerikte bir işlemin “yetkili kişi tarafından onaylandığı” ileri sürülse bile uygulama bu cümleyi duyuru içeriği olarak ele alıyor. Kullanıcı bir işlem talep etmediği için herhangi bir araç çağrısı yapılmıyor.
İkinci sürüm, özetin yanında e-posta taslağı hazırlıyor. Burada kullanıcı seçtiği alıcıyı kendisi belirler. Web sayfasındaki alıcı adresi veya gönderim isteği otomatik onay sayılmaz. Taslak görünümünde konu, alıcı, metin ve varsa ekler ayrı gösterilir.
Üçüncü adımda ekip gerçekten gönderim özelliği ekleyecekse, onayı uygulamanın kendi denetiminden geçirir. Gösterilen taslak ile gönderilecek sürümün aynı olduğundan emin olur. Sonradan değişen alıcı veya ek, daha önceki onayı otomatik devralmaz. Bunlar bir örnek uygulamanın önerilen kurallarıdır.[1]
Yetkiyi uygulama katmanında sınırlayın
OWASP, modelin erişimini gerekli en dar kapsamda tutmayı, araç işlevlerini uygulama kodunda denetlemeyi ve ayrıcalıklı işlemlerde insan onayını değerlendirmenizi öneriyor. Bir sistem talimatına “yetki dışında hareket etme” yazmak, e-posta hizmetinin veya dosya sisteminin uyguladığı izin denetimiyle aynı korumayı sağlamaz.[1]
Bir belge asistanı yalnızca destek kılavuzlarını okuyacaksa, ücret ve müşteri hesaplarına erişen aracı aynı çalışma alanına koymayın. Kılavuz içinde dış bir adrese belge gönderilmesini isteyen metin bulunsa bile, uygulamanın bu işi yapacak erişimi olmayabilir.
Uygulama bir araç çağrısı aldığında hedefi, kapsamı ve işlemin sahibini kontrol edin. Örneğin taslak hazırlama ile gönderme iki ayrı izin olsun. Bir işlemin adı güvenli görünse bile parametrelerini inceleyin. Hangi alıcıya, hangi dosyanın ve hangi hesap üzerinden gönderileceği işlemin anlamını değiştirir.
Dış içeriği tanımlayın ve çıktıyı doğrulayın
Belge metnini kullanıcı talimatından ayrı bir alan olarak işlemek, modelin aldığı girdiyi daha anlaşılır kılar. Dış kaynağın nereden geldiğini ve hangi görev için kullanılacağını belirtin. OWASP, harici içeriğin ayrılmasını ve çıktının doğrulanmasını katmanlı savunmanın parçaları arasında değerlendiriyor.[1]
Örneğin ürün kodu çıkaran bir sistemde çıktı biçimini doğrulayın. Kodun izin verilen değerlerden biri olup olmadığını kontrol edin. Model fazladan alan veya işlem isteği üretirse, bunu uygulamanın yeni bir komutu gibi çalıştırmayın. Alan doğrulaması ile eylem yetkilendirmesi ayrı kontrollerdir.
Bu yöntemlerin her biri farklı bir noktayı korur. İçeriği etiketlemek, modelin kaynağı anlamasına yardımcı olabilir. Araç izni, hangi işlemin yapılabileceğini sınırlar. Onay ekranı ise kullanıcının tam olarak neye izin verdiğini gösterir. Testi sadece bir katmanın başarılı görünmesine göre bitirmeyin.[1][2]
RAG ve fine-tuning korumayı tek başına sağlar mı?
RAG, yanıt için belge getirir. Getirilen metin güvenilmeyen bir kaynaktan geliyorsa model onu da işler. Bir belgenin aramada üst sırada bulunması, içindeki talimatın yetkili olduğu anlamına gelmez. Kaynak yetkisi ve içerik güvenilirliği ayrı değerlendirilmelidir.[1]
Fine-tuning, bazı görevlerde modelin belirli örneklere uyumunu artırabilir. Uygulamadaki araç izinlerinin ve eylem denetiminin yerini tutmaz. Bu yöntemlerin amaçlarını karşılaştırmak için RAG ve fine-tuning rehberimize bakabilirsiniz.[1]
Kendi sisteminizde nasıl denersiniz?
Denemeyi yetkili olduğunuz bir ortamda, kurgusal veriyle yapın. İlk senaryoda asistan kısa bir ürün kılavuzunu özetlesin. İkinci senaryoda aynı belge, özet görevinden farklı bir istek içersin. Bu ek cümle gerçek hesap, adres, anahtar veya dış sisteme erişim içermesin.
İki çalıştırmada da beklenen iş aynı olsun. Asistanın göreve sadık kalıp kalmadığını, harici işlem isteği oluşturup oluşturmadığını ve kaynak dışı veri gösterip göstermediğini kaydedin. Gerçek e-posta veya dosya düzenlemesi yerine deneme sırasında yalnızca işlem niyetini kaydeden bir araç kullanabilirsiniz.
Testi tek belgeyle sınırlamayın. Farklı kaynak türleri, belge adları ve görevler deneyin. Örneğin metin belgesinde düzgün çalışan ayrım, web sayfası alındığında farklı biçimde işleniyor olabilir. Her giriş yolunda hangi verinin modele gittiğini ve uygulamanın hangi işlemi reddettiğini ayrı yazın.[1][2]
Deneme kayıtları hangi alanları içermeli?
Örnek bir kontrol kaydında görev, kaynak türü, beklenen çıktı ve izinli araçlar yer alsın. Ardından modelin araç çağrısı isteyip istemediğini ve uygulamanın isteği nasıl işlediğini yazın. Ekrandaki cevapla arka plandaki işlem kaydı farklı bilgi verir. Başarılı görünen bir özetin arkasında gereksiz araç çağrısı denenmiş olabilir.
Kurgusal testinizde belge, “Bu duyurunun rengi kırmızı olarak onaylandı” ifadesi içersin. Kullanıcı ise yalnızca tarih ve konuyu çıkarmayı istemiş olsun. Çıktıdaki tarih ve konunun doğru olması beklenir. Asistanın tasarım ayarlarını değiştirmesi veya belgeyi onaylanmış görev sayması beklenmez. Bu örnek, gerçek sistemlere zarar vermeden sınır davranışını kontrol etmek içindir.
Bir işleme izin çıkmadığında reddetme nedenini de kaydedin. Örneğin “bu çalışma alanı gönderim yetkisine sahip değil” ile “alıcı kullanıcı tarafından seçilmedi” farklı eksiklerdir. Bu bilgiyi açık tutmak, bir sonraki testte yanlış katmanı değiştirmeyi önler.
Üretime geçtikten sonra test setini model veya araç güncellemesinde yeniden çalıştırın. Yeni belge alma yöntemi eklediğinizde eski kontrollerin aynı şekilde uygulandığını doğrulayın. Bir denemenin başarılı olması, daha sonra bütün dış içerik türlerinin aynı davranışı göstereceğini kanıtlamaz.
Otomatik tespit sonucunu nasıl yorumlamalı?
Bazı platformlar, kullanıcı mesajlarında ve dış belgelerde yönlendirme belirtilerini inceleyen ayrı filtreler sunar. Microsoft’un Prompt Shields belgeleri bu iki giriş türünü farklı kontrol noktaları olarak ele alıyor. Belgede bulunan içeriğin kimden geldiği ve o kişinin yetkisi, uygulamanın kendi bağlantısı üzerinden tanımlanmalıdır.[3]
Kullanım kılavuzu gibi normal bir belge de talimat cümleleri içerir. Örneğin “Güç düğmesine üç saniye basın” ürünün nasıl kullanılacağını anlatır. Böyle bir cümle, tek başına saldırı göstergesi sayılmamalıdır. Önemli olan sistemin cümleyi ürün hakkında bilgi olarak mı, kendi aracını çalıştırma komutu olarak mı değerlendirdiğidir.
Bir filtre metni şüpheli işaretlediğinde kullanıcıya anlaşılır bir durum gösterin. Örneğin belgenin bir bölümünün inceleme gerektirdiğini açıklayabilirsiniz. Belgenin tamamını yok saymak bazı görevlerde gereksiz olabilir. İş akışınızın hangi durumda güvenli bir özet vereceğini, hangi durumda kullanıcıya kaynak göstereceğini ve hangi durumda duracağını önceden belirleyin.
Filtre bir belgeyi temiz bulduğunda da uygulamanın işlem izinleri geçerli olmalıdır. Bir dosyada bir gönderim isteğini fark etmeyen filtre, o isteğe yetki vermez. Kullanıcı gerçekten e-posta gönderilmesini istemişse alıcı, içerik ve ekleri kendi uygulamanızın onay düzeniyle doğrulayın. Böylece filtre sonucu ile işlemin sahibi arasındaki ayrımı korursunuz.
Olay incelemesinde önce gerçek bir işlem yapılıp yapılmadığını belirleyin. Araç isteğinin kaydedilmesi, dış sisteme ulaşıldığı anlamına gelmez. Başarı veya ret sonucunu ilgili hizmetin kaydıyla karşılaştırın. Hangi kaynağın okunduğunu, izin kontrolünün nerede çalıştığını ve kullanıcının ekranda ne gördüğünü kaydedin. Bu bilgiler sonraki düzeltmeyi doğru aşamaya yönlendirir.
Sık sorulan sorular
Prompt injection yalnızca gizli metinle mi olur?
Hayır. İnsan tarafından görülen normal bir metin de modelin davranışını yönlendirmeye çalışabilir. Önemli olan uygulamanın bu metni nasıl işlediğidir.[1]
Asistan sadece özet çıkarıyorsa risk var mı?
Özetin içeriği veya güvenilirliği etkilenebilir. Dosya düzenleme ve gönderim gibi dış etkiler, asistanın eriştiği araçlara ve uygulama denetimlerine bağlıdır.[1][2]
İlk koruma adımı ne olmalı?
Görevi ve izin verilen işlemleri açıkça tanımlayın. Ardından modelin bu kapsamın dışına çıkmasını uygulama katmanında engelleyin ve sonucu kendi deneme verinizle kontrol edin.[1]
Kaynaklar
- OWASP GenAI Security Project, LLM01:2025 Prompt Injection. Bilginin alındığı tarih: 6 Kasım 2026.
- Anthropic, Prompt injection defenses. Bilginin alındığı tarih: 6 Kasım 2026.
- Microsoft Learn, Prompt Shields. Bilginin alındığı tarih: 6 Kasım 2026.
