Fatura PDF’sinden Gelen Dolaylı Prompt Injection Riski

Belge yalnız veri olmayabilir
Bir çalışan, tedarikçiden gelen PDF faturayı özetlemesi için bir AI aracına yükler. Dosyanın görünen kısmı normaldir; fakat metin katmanında, küçük puntoda veya bir görselin içinde modele yönelik talimat bulunabilir. Model bu talimatı iş verisi yerine komut olarak yorumlarsa başka belgeleri açıklamaya, yanlış alan üretmeye veya bağlı araçları kullanmaya yönelebilir. Kullanıcının kötü niyetli olması gerekmez; saldırı harici içerikten gelir.
OWASP bu durumu dolaylı prompt injection kapsamında ele alır. NCSC ise büyük dil modellerinin veri ile talimatı güvenilir biçimde ayırmamasının kalıcı bir tasarım riski olduğunu, yalnız filtreyle eksiksiz çözüm beklenmemesi gerektiğini vurgular. Bu nedenle amaç saldırıyı yüzde yüz tanımak değil, model kandırılsa bile doğabilecek etkiyi sınırlamaktır.
Risk hangi zincirde büyür?
Yalnız metin özetleyen, dış sisteme erişmeyen bir modelin etkisi görece sınırlıdır. Aynı model e-postaya, dosya deposuna, cari hesaplara veya ödeme aracına bağlandığında risk büyür. Şu zincir özellikle incelenmelidir:
Güvenilmeyen belge sisteme girer.
Ayrıştırıcı görünür ve görünmez içeriği modele taşır.
Model içeriği komut gibi yorumlar.
Uygulama model çıktısını güvenilir talimat kabul eder.
Araç çağrısı, veri sızıntısı veya yanlış iş işlemi oluşur.
Kontroller zincirin her halkasına yerleştirilirse tek bir savunmanın başarısızlığı bütün sistemi etkilemez.
Belge kabul katmanı
Dosya türü yalnız uzantıya göre kabul edilmemelidir. İçerik tipi, boyut, aktif bileşen, gömülü dosya, parola koruması ve ayrıştırma hataları kontrol edilebilir. PDF’nin metin katmanı ile görsel OCR sonucu beklenmedik biçimde ayrışıyorsa inceleme işareti üretilebilir. Zararlı yazılım taraması standart dosya tehditleri için gereklidir; ancak prompt injection tespiti yerine geçmez.
Belge mümkün olduğunca izole ortamda işlenmeli, ayrıştırıcıya gereksiz ağ veya sistem yetkisi verilmemelidir. Orijinal dosyanın bütünlük özeti, alınma kanalı ve zamanı korunursa olay araştırması yapılabilir. Bununla birlikte ham dosyaların süresiz saklanması veri minimizasyonu ve güvenlik riski doğurabilir.
Model bağlamını sınırlamak
Harici belgeden gelen içerik açıkça “güvenilmeyen veri” olarak ayrılmalıdır. Sistem talimatı, kullanıcı isteği ve belge içeriği farklı kanallarda tutulabilir; belge içindeki “önceki kuralları yok say” benzeri ifadeler uygulama yetkisini değiştirememelidir. Yalnız prompta “bu talimatları izleme” yazmak yeterli savunma değildir.
Modelin aynı anda görebileceği belge sayısı, erişebileceği müşteri alanı ve sorgulayabileceği dönem sınırlandırılabilir. İş için tek fatura gerekiyorsa bütün şirket arşivini bağlama eklemek gereksizdir. En az ayrıcalık, hem veri sızıntısının hem yanlış işlemin olası etkisini küçültür.
Araç kullanımında deterministik kapılar
AI çıktısı doğrudan ödeme başlatmamalı, banka hesabı değiştirmemeli veya muhasebe kaydını kesinleştirmemelidir. Model yalnız yapılandırılmış bir öneri üretebilir. Uygulama; izin verilen işlem türünü, alan biçimini, tutar tutarlılığını, kullanıcı yetkisini ve iş nesnesinin mevcut durumunu model dışı kurallarla doğrulamalıdır.
Yüksek etkili işlemde insan onayı zorunlu olduğunda inceleyen kişi yalnız “onayla” düğmesi görmemelidir. Kaynak belge, çıkarılan alanlar, uyarılar ve önerilen değişiklik görünür olmalıdır. Onaylayan kişinin işlemi reddetme ve güvenli inceleme kuyruğuna gönderme yetkisi bulunmalıdır.
Çıktı ve veri sızıntısı kontrolleri
Model cevabı beklenen şemaya uymuyorsa işlem durmalıdır. Serbest metinden araç parametresi üretmek yerine açık alan listesi, tip kontrolü ve izinli değerler kullanılabilir. Çıktıda başka müşteriye ait bilgi, sistem talimatı veya gizli anahtar örüntüsü aranabilir. Yine de otomatik sızıntı filtresi kusursuz değildir; hassas kaynağa erişim baştan daraltılmalıdır.
Harici bağlantı çağırma, URL açma veya e-posta gönderme gibi yetenekler varsayılan olarak kapalı tutulabilir. Gerçek ihtiyaç varsa hedef alan adı, yöntem ve veri miktarı ayrı izinlerle sınırlandırılır. Modelin ürettiği URL güvenilir kabul edilmez.
Bileşen değişikliğini izlemek
Dolaylı enjeksiyon savunması bir kez test edilip bırakılmamalıdır. PDF ayrıştırıcısı, OCR motoru, model, sistem talimatı veya araç izinlerindeki her değişiklik koruma sınırını değiştirebilir. Envanterde bu bileşenlerin sürümü ve değişiklik tarihi tutulabilir; güncelleme sonrasında aynı kötü niyetli belge setiyle regresyon testi yapılabilir. Tedarikçiden gelen “güvenlik iyileştirmesi” ifadesi tek başına kanıt sayılmamalı, hangi davranışın değiştiği ve müşterinin hangi ayarı yapacağı açıklanmalıdır. Üretim trafiğinde gölge değerlendirme yapılacaksa gerçek finansal işlemi tetiklemeyen, kişisel veriyi çoğaltmayan ve sonuçları yetkili inceleme altında tutan bir tasarım gerekir.
Test ve olay müdahalesi
Güvenlik testi yalnız bilinen saldırı cümlelerini denememelidir. Görünmez metin, farklı dil, OCR, tablo hücresi, resim ve çok aşamalı belge zinciri gibi varyasyonlar kontrollü ortamda sınanabilir. Amaç modele saldırı öğretmek değil, uygulama sınırlarının çalıştığını doğrulamaktır. Başarılı veya başarısız denemeler model, ayrıştırıcı ve politika sürümüyle kaydedilmelidir.
Şüpheli olayda belge karantinaya alınır, ilgili erişim belirteçleri ve oturumlar incelenir, gerçekleşen araç çağrıları doğrulanır. Finansal kayıtlar sessizce değiştirilmez; varsa düzeltme ayrı ve denetlenebilir işlemle yapılır.
Sonuç
Dolaylı prompt injection, yalnız daha iyi prompt yazarak kapanan bir açık değildir. Güvenilmeyen belgenin ayrıştırılmasından araç yetkisine kadar bütün sistem tasarımı ele alınmalıdır. AI belgeyi okuyabilir ve öneri sunabilir; fakat ödeme, muhasebe veya dış iletişim kararı deterministik kurallar ve yetkili insan kontrolü olmadan kesinleşmemelidir. Kalan risk açıkça kaydedilmeli ve kabul edilemiyorsa kullanım senaryosu daraltılmalıdır.
Kaynaklar
Kaynaklar
Mehmet Hakkı Yuvanç
FiscusAI ekibi
Mehmet Hakkı Yuvanç tarafından 1 Ekim 2026 tarihinde incelendi.
