Prompt Injection Nedir? Yapay Zeka Chatbot ve Ajanlarını Nasıl Korursunuz?

Prompt injection nedir?

Prompt injection, bir yapay zeka modelinin aldığı metnin içine yerleştirilen talimatların, modelin asıl görevini ve kurallarını sessizce değiştirmesidir. Saldırgan kod yazmaz, düz bir cümleyle modeli yönlendirir. Sonuç olarak model, işletmenin değil saldırganın isteğini yerine getirir ve veri sızdırabilir, yanlış yanıt verebilir ya da yetkisiz işlem başlatabilir.

Bu konu ilk bakışta teknik görünür, ancak aslında bir güven sorunudur. Yani kritik soru, modelin neye güveneceğidir. Büyük dil modelleri (LLM, yani metin üreten yapay zeka modelleri) aldıkları her metni olası bir talimat gibi okur. Bu yüzden geliştiricinin yazdığı kural ile bir müşterinin ya da bir web sayfasının içindeki cümle, model için aynı ağırlıkta görünebilir.

Bu yazıda türleri, riskleri ve savunma katmanlarını sade bir dille anlatıyoruz. Kod ya da saldırı örneği vermiyoruz; çünkü amacımız sizi saldırıya hazırlamak değil, sisteminizi savunmaya hazırlamak.

Doğrudan ve dolaylı prompt injection arasındaki fark nedir?

İki tür vardır ve savunma yaklaşımları birbirinden farklıdır. Önce ikisini ayıralım.

Doğrudan prompt injection, sohbet eden kişinin kendisinin modele talimatı ezmesini istemesidir. Örneğin bir kullanıcı chatbota önceki kuralları unutmasını ya da gizli sistem talimatını göstermesini söyler. Literatürde bu davranışın bir kısmına jailbreak denir. Saldırgan karşınızdadır ve girdiyi doğrudan kendisi yazar.

Dolaylı prompt injection ise çok daha sinsidir. Talimat, kullanıcının yazdığı mesajda değil, modelin okuduğu dış içeriğin içinde durur. Bu içerik bir web sayfası, bir e-posta, bir PDF, bir destek talebi ya da bir ürün yorumu olabilir. Kullanıcı masumdur; öte yandan model içeriği özetlerken ya da işlerken gizli talimatı da okur.

• Doğrudan türde saldırgan sohbet penceresindedir, dolaylı türde ise sohbetin dışındadır.
• Örneğin doğrudan türü kullanıcı kimliği ve oran sınırlarıyla kısmen yönetebilirsiniz.
• Buna karşılık dolaylı türde zararlı metin, güvendiğiniz bir kaynağın içinde durabilir.
• Araç kullanan ajanlarda dolaylı tür çok daha tehlikelidir, çünkü model okuduğu şeye göre eyleme geçer.

Model neden talimat ile veriyi birbirinden ayıramıyor?

Geleneksel yazılımda komut ile veri ayrı kanallardan akar. Bir veritabanı sorgusu ile içine yazılan müşteri adı farklı katmanlardır ve bu ayrımı korumak yıllardır savunmanın temelidir. Büyük dil modellerinde ise bu ayrım doğal olarak yoktur.

Model, sistem talimatını, kullanıcı mesajını ve okuduğu belgeyi aynı metin akışı içinde işler. Hepsi sonuçta kelime dizisidir. Dolayısıyla "şu cümle kural, şu cümle veri" ayrımını modelin kendisinden beklemek gerçekçi değildir. Geliştiriciler bu ayrımı kâğıt üzerinde çizer, model ise olasılıklara göre yanıt üretir.

Üstelik model geliştiricileri, modelleri yardımsever olacak şekilde eğitir. Net ve otoriter görünen bir cümle, modeli yönlendirebilir. Bu nedenle sorunu tek bir yama ile kapatmak mümkün değildir. Güvenlik uzmanları bunu istatistiksel bir davranış olarak görür ve savunmayı tek bir filtreye değil, birden çok katmana yayar.

Pratik sonuç şudur: modelin çıktısına, içindeki talimatlara uyup uymadığını bilemeyeceğiniz bir girdiden gelmiş gibi yaklaşın. Yetkiyi modele değil, modelin etrafındaki sisteme bağlayın.

Prompt injection işletmeniz için neden gerçek bir risktir?

Risk, modelin ne kadar yetkisi ve ne kadar verisi olduğuyla orantılıdır. Örneğin hiçbir şeye erişmeyen bir chatbot en fazla yanlış bir cümle kurar. Buna karşılık müşteri kayıtlarına, e-postalara ya da ödeme araçlarına bağlanan bir sistem çok daha ağır sonuçlar doğurur.

İşletmeler için üç ana sonuç öne çıkar:

• Veri sızıntısı: Örneğin model, sistem talimatındaki iç kuralları, müşteri bilgilerini ya da belge içeriğini yanlış kişiye aktarabilir.
• Yetkisiz işlem: Ayrıca araç bağlı bir ajan, kayıt silebilir, e-posta gönderebilir ya da sipariş durumunu değiştirebilir.
• Marka itibarı: Chatbotunuz uygunsuz, yanlış ya da taahhüt niteliğinde bir cümle kurduğunda ekran görüntüsü hızla yayılır.

Kişisel veri söz konusu olduğunda konu hukuki boyut da kazanır. Yazılı bir ihlal, KVKK kapsamında bildirim yükümlülüğü doğurabilir; ayrıntı için KVKK ve GDPR uyumlu web sitesi rehberimize bakabilirsiniz. Bu yazı hukuki danışmanlık değildir; kendi durumunuz için bir hukukçuya danışın.

Chatbotlarda prompt injection riski nasıl ortaya çıkar?

Müşteri hizmetleri chatbotu, çoğu işletmenin yapay zekayla ilk tanıştığı yerdir. Bu botlar genellikle bir sistem talimatı, bir bilgi tabanı ve bazen sipariş sorgulama gibi küçük bir araç seti ile çalışır. Risk de bu üç parçanın birleştiği noktalarda doğar.

İlk risk, sistem talimatının dışarı sızmasıdır. Birçok ekip talimatın içine fiyat politikası, indirim sınırı ya da dahili süreç bilgisi koyar. Kullanıcı modeli ikna edip bu metni gösterdiğinde, rakip ya da kötü niyetli kişi bu bilgiye ulaşır.

İkinci risk, botun kapsam dışına çıkmasıdır. Örneğin bir mobilya mağazasının botu ilgisiz konularda uzun yanıtlar yazarsa, hem maliyet yükselir hem de marka tonu bozulur. Üçüncü risk ise bilgi tabanının kendisidir. Botunuz herkese açık sayfalardan ya da kullanıcıların gönderdiği belgelerden öğreniyorsa, oradaki gizli talimat dolaylı yoldan içeri girer.

Bu nedenle chatbotu kurarken "ne yanıt versin" sorusundan önce "neye erişebilsin" sorusunu yanıtlamanız gerekir. Chatbot geliştirme sürecimizi yapay zeka chatbot geliştirme sayfamızda bu sırayla anlatıyoruz.

Araç kullanan yapay zeka ajanlarında risk neden büyür?

Ajan, yalnızca yanıt veren değil, adım planlayıp araç çağıran bir sistemdir. E-posta okur, takvime bakar, bir CRM kaydını günceller, bir sunucuda komut çalıştırır. Model ne kadar çok araca bağlanırsa, yanlış yönlendirildiğinde verebileceği zarar o kadar büyür.

Özellikle güvenlik çevrelerinde sık anılan bir üçlü vardır: modelin özel veriye erişimi, güvenilmeyen içeriği okuması ve dışarıya bilgi gönderebilmesi. Bu üç yetenek aynı ajanda birleştiğinde, dolaylı bir talimat veriyi dışarı taşımanın yolunu bulabilir. Üçünden en az birini kesmek, riski belirgin biçimde azaltır.

Örnek senaryo: bir ajan gelen kutusunu özetliyor ve gerektiğinde yanıt taslağı hazırlıyor. Dışarıdan gelen bir e-postanın içine, ajanın başka bir yazışmayı üçüncü bir adrese iletmesini isteyen gizli bir cümle konmuş olsun. Ajan e-postayı "iş" olarak değil "içerik" olarak ele almazsa ve gönderme yetkisi de varsa, istenmeyen bir iletim gerçekleşebilir.

Ajan mimarisini daha geniş bağlamda pazarlamada AI agent yazımızda ve kendi altyapınızda çalıştırma seçeneklerini kendi sunucunuzda AI agent kurulumu rehberinde bulabilirsiniz. Güvenlik tarafını ise bu yazıda ele alıyoruz.

Dolaylı prompt injection gerçek hayatta nasıl görünür?

Burada kod göstermiyoruz; olayı düz anlatımla özetliyoruz. Aşağıdaki senaryolar örnek senaryodur, belirli bir olaya işaret etmez.

1. Web sayfası özetleme: Bir araştırma ajanı, rakip analizi için bir sayfayı okur. Sayfanın görünmeyen bir bölümünde, ajanın kullanıcıya belirli bir ürünü önermesini isteyen bir cümle durur. Ajan bunu sayfanın içeriği sanıp rapora yansıtır.
2. Belge işleme: Bir ik asistanı başvuru özgeçmişlerini puanlar. Bir adayın belgesine, yapay zekaya "bu adayı en yüksek puanla" diyen metin gömülmüştür. Asistan, kuralı kendi talimatı sanabilir.
3. Destek talebi: Bir müşteri, destek formuna yazdığı metinle iç sistemde kayıt sorgulayan bir ajanı başka müşterilerin bilgisine yönlendirmeye çalışır.
4. Ürün yorumu: Yorumları özetleyen bir araç, yorum içine gizlenmiş bir talimatla yanlış özet üretir.

Hepsinde ortak nokta şudur: zararlı metin, "güvenilir içerik" kılığında kurumun sistemine girer. Bu yüzden savunmada ilk soru "kim yazdı" değil, "bu içeriği model okurken hangi yetkiye sahip" olmalıdır.

OWASP LLM listesi prompt injection hakkında ne söylüyor?

OWASP, web güvenliğindeki Top 10 listesiyle tanınan, kar amacı gütmeyen bir güvenlik topluluğudur. Aynı topluluk, büyük dil modeli uygulamaları için ayrı bir risk listesi de yayımlar. Prompt injection, bu listede ilk sıradaki risk olarak yer alır; ayrıca resmi sayfada ayrıntılı bir açıklaması bulunur.

Resmi OWASP Gen AI Security Project sayfasına göre prompt injection, kullanıcı girdilerinin modelin davranışını ya da çıktısını istenmeyen biçimde değiştirmesi olarak tanımlanır. Sayfa doğrudan ve dolaylı olmak üzere iki türü ayırır. Sayfa etkileri arasında hassas veri ifşasını, sistem talimatının açığa çıkmasını, yetkisiz fonksiyon erişimini ve karar süreçlerinin bozulmasını sayar.

Sayfanın en önemli mesajı, kusursuz bir önlemin muhtemelen olmadığıdır. Modellerin olasılıksal çalışması nedeniyle savunma, katmanlı kurulmalıdır. Listedeki önlemler arasında sistem talimatıyla davranışı sınırlamak, beklenen çıktı biçimini doğrulamak, girdi ve çıktıyı filtrelemek, en az yetki vermek, riskli işlemde insan onayı istemek, dış içeriği ayırmak ve saldırı simülasyonu yapmak yer alır.

Liste zamanla güncellenir, dolayısıyla sürüm ve sıralama değişebilir. Güncel hâli için resmi sayfayı kontrol edin. Web uygulamaları tarafındaki klasik listeyi ise ayrı bir yazıda anlattık: OWASP Top 10 web güvenlik açıkları ve önlemler.

Prompt injection'dan korunmanın temel ilkesi nedir?

Temel ilke şudur: saldırının gerçekleşeceğini varsayın ve gerçekleştiğinde zararı sınırlayın. Modeli "ikna edilemez" hâle getirmeye çalışmak yerine, ikna edilse bile yapabileceklerini daraltırsınız. Bu bakış, güvenliği bir filtre sorusundan bir mimari sorusuna taşır.

Pratikte yedi katmandan söz ediyoruz:

• Modele ve araçlara yalnızca gereken en az yetkiyi verin.
• Geri dönüşü zor işlemleri insan onayına bağlayın.
• Girdi ve çıktıyı kontrol edin, ancak tek savunma olarak görmeyin.
• Gizli veriyi modelin bağlamına hiç koymayın.
• Dış içeriği ayırın ve güvenilmez olarak işaretleyin.
• Her araç çağrısını kaydedin ve izleyin.
• Düzenli olarak saldırgan gözüyle test edin.

Ancak bu katmanların her biri tek başına delinebilir. Birlikte kullanıldıklarında ise saldırganın aynı anda hepsini aşması gerekir. Kısacası, tek bir kilit yerine birden çok kapı kurarsınız. Bu nedenle aşağıdaki bölümlerde her katmanı ayrı ayrı ele alıyoruz.

En az yetki ilkesi yapay zeka ajanını nasıl güvenli kılar?

En az yetki, bir sisteme işini yapmaya yetecek kadar erişim vermek demektir. Prompt injection açısından bu ilke en güçlü savunmadır, çünkü modelin ele geçirilmesi durumunda saldırganın erişebileceği alanı doğrudan belirler.

Önce ajanın hangi araçlara gerçekten ihtiyaç duyduğunu listeleyin. Bir randevu botunun takvimi okuması ve randevu oluşturması yeterlidir; müşteri veritabanını silme yetkisi gereksizdir. Ardından her araç için okuma ve yazma izinlerini ayırın. Okuma izni verilen bir araç, yazma izni verilen araca göre çok daha az risk taşır.

• Ajan için ayrı bir hizmet hesabı açın ve tam yönetici hesabını asla paylaşmayın.
• Veri erişimini kullanıcı bazında daraltın; ajan, yalnızca o oturumdaki kişinin verisini görsün.
• Dışarıya bağlantı kurabilen araçları ayrıca sınırlayın.
• Kimlik bilgilerini modele metin olarak vermeyin; araç katmanında saklayın.
• Yetkileri düzenli aralıklarla gözden geçirin ve kullanılmayanları kapatın.

Bu yaklaşım ayrıca hataları da azaltır. Çünkü model kendi başına yanlış bir işlem yapsa bile, o işlemi yapacak yetkisi yoksa zarar oluşmaz.

Araç çağrılarında insan onayı ne zaman şarttır?

İnsan onayı otomasyonun hızını bir miktar yavaşlatır, ancak karşılığında en güvenilir emniyet supabını sağlar. Her işlemde onay istemek ajanı anlamsız kılar. Bu yüzden onayı, risk seviyesine göre kademelendirmek gerekir.

Düşük riskli işlemleri otomatik bırakabilirsiniz. Bir bilgiyi okumak, taslak hazırlamak ya da genel bir sorunun yanıtını yazmak bu gruptadır. Orta riskli işlemlerde ise kullanıcıya kısa bir özet gösterip onay alırsınız. Yüksek riskli işlemlerde ise yetkili bir çalışanın açık onayı şart olmalıdır.

• Para, fatura, iade ve fiyat değişikliği içeren her işlem.
• Kayıt silme, toplu güncelleme ve dışa aktarma.
• Kurum dışına e-posta ya da mesaj gönderme.
• Erişim izni verme, şifre sıfırlama ve hesap değişikliği.
• Başka bir sisteme yeni bağlantı kurma.

Onay ekranı açık ve sade olmalıdır. Kullanıcı, ajanın tam olarak ne yapmak istediğini ve hangi veriyle yapacağını görmelidir. Belirsiz bir "onaylıyor musunuz" sorusu, insanı da otomatik onay vermeye iter.

Girdi ve çıktı filtreleme prompt injection'a karşı yeterli mi?

Hayır, tek başına yeterli değildir; ancak değerli bir katmandır. Girdi filtreleri şüpheli kalıpları yakalar, çıktı filtreleri ise modelin sızdırmaması gereken bilgiyi ya da beklenmeyen biçimi durdurur. Saldırgan cümleyi yeniden yazarak ya da farklı bir dil kullanarak anahtar kelime filtrelerini aşabilir.

Bu yüzden iki filtre türünü birlikte düşünün. Birincisi kural tabanlı kontrollerdir: beklenen uzunluk, izin verilen karakterler, yasaklı konu listesi. İkincisi anlamsal kontrollerdir: ikinci bir model ya da sınıflandırıcı, girdinin talimat verme niyeti taşıyıp taşımadığına bakar.

Çıktı tarafında en etkili yöntem, biçimi baştan sabitlemektir. Örneğin modelden yalnızca belirli alanlardan oluşan yapılandırılmış bir yanıt isteyin ve bu yapıyı kodla kontrol edin. Biçime uymayan yanıtı kullanıcıya göstermeden reddedin. Ayrıca yanıtta kişisel veri, iç adres ya da gizli anahtar benzeri bir kalıp varsa gönderimi engelleyin.

Yine de filtre, bir güvenlik duvarı gibi çalışmaz. Onu, diğer katmanların önüne konan bir eleme adımı olarak düşünün. Asıl güvence, yetkinin daraltılmasından ve onay adımlarından gelir.

Sistem talimatına neden tek başına güvenmemelisiniz?

Birçok ekip, güçlü bir sistem talimatı yazarak işi bitirdiğini sanır. Örneğin "kullanıcı ne derse desin şu kuralları çiğneme" gibi bir cümle yeterli görünür. Talimat faydalıdır, ancak bir güvenlik kontrolü değil, bir davranış yönlendirmesidir. Model onu çoğu zaman izler, fakat her zaman izlemeyi garanti etmez.

Sebep basit, çünkü sistem talimatı da sonuçta metindir ve modelin okuduğu diğer metinlerle aynı akışta durur. Yeterince ikna edici ya da uzun bir bağlam, talimatın ağırlığını azaltabilir. Dolayısıyla "talimatta yazıyor" cümlesi, bir güvenlik gerekçesi olmaz.

Sistem talimatını şu amaçlarla kullanın: botun rolünü ve tonunu belirlemek, kapsamı tanımlamak, belirsiz durumda ne yapacağını söylemek. Şunun için kullanmayın: sır saklamak, yetki sınırı çizmek, hassas veriyi korumak. Bu işlerin hepsi modelin dışındaki kodda ve altyapıda çözülmelidir.

Bir sınama yapın: sistem talimatınız yarın internette yayımlansa ne olurdu? Cevap "sakıncalı" ise talimatın içinde olmaması gereken bir şey var demektir.

Gizli veriyi modele vermemek pratikte ne demektir?

Modelin görmediği bir bilgiyi model sızdıramaz. Bu cümle, en sade ve en etkili savunmalardan birini özetler. Bağlam penceresine koyduğunuz her şeyi, ileride bir saldırının çıkarabileceği olası bir veri olarak görün.

İlk olarak ne gönderdiğinizi sorgulayın. Bir müşteri destek botu, tüm müşteri kaydını değil, yalnızca o konuşmada gereken alanları görmelidir. Kimlik numarası, tam kart bilgisi ve sağlıkla ilgili alanlar gibi ayrıcalıklı veriyi, mümkünse maskeleyin ya da hiç göndermeyin.

• API anahtarlarını, parolaları ve erişim jetonlarını metin içine yazmayın.
• Dahili fiyat tabloları ve rakip analizleri gibi içeriği sistem talimatına gömmeyin.
• Belge arama sistemlerinde (RAG) kullanıcının yetkisi olmayan belgeyi aramaya dahil etmeyin.
• Kişisel veriyi göndermeden önce maskeleyin ya da takma adla değiştirin.
• Gerekirse veriyi kendi sunucunuzda çalışan bir model ile işleyin.

Özellikle belge tabanlı sistemlerde yetki denetimi kritik önemdedir. Konuyu RAG nedir yazımızda ayrıntılı anlattık. Orada gördüğünüz gibi, hangi belgenin bulunacağına model değil, arama katmanındaki yetki kuralları karar vermelidir.

Dış içeriği nasıl ayırır ve güvenilmez olarak işaretlersiniz?

Dolaylı saldırıya karşı en önemli alışkanlık, dış içeriği her zaman "veri" olarak ele almaktır. Bir web sayfasından, e-postadan ya da belgeden gelen metin, ajanın görevini değiştirecek bir kaynak olmamalıdır. Bu nedenle bunu mimaride görünür kılmanız gerekir.

İlk adım olarak, modele verdiğiniz bağlamı bölümlere ayırın: kurum talimatı, kullanıcının isteği ve dış içerik. Ayrıca dış içeriği belirgin sınırlarla çevreleyin ve modele bunun yalnızca incelenecek malzeme olduğunu açıkça söyleyin. Bu yöntem kusursuz değildir, ama saldırı yüzeyini küçültür.

İkinci adım, okuma ile eylemi ayırmaktır. Dış içeriği okuyan ajan ile işlem yapan ajanı ayrı süreçlere bölebilirsiniz. Böylece okuyan taraf yalnızca özet ya da yapılandırılmış veri döndürür; işlem yapan taraf ise ham metni hiç görmez. Böylece gizli bir cümle, eylem katmanına kadar ulaşamaz.

Üçüncü adım, kaynakların güvenilirliğini sınıflandırmaktır. Kendi bilgi tabanınız ile rastgele bir web sayfası aynı güveni taşımaz. Kaynak türüne göre izinleri ayarlayın; örneğin açık web içeriğini okuyan oturumda dışarıya mesaj gönderme aracını tamamen kapatın.

Loglama ve izleme prompt injection'ı nasıl yakalar?

Önlem almak kadar, olanı görmek de önemlidir. Örneğin kayıt tutmayan bir yapay zeka sistemi, bir olay yaşandığında ne olduğunu açıklayamaz. Bu yüzden her konuşmanın ve her araç çağrısının izlenebilir olması gerekir.

Özellikle kaydetmeniz gereken ana unsurlar şunlardır: kullanıcı girdisi, modelin okuduğu dış kaynaklar, modelin çağırdığı araç ve parametreleri, araçtan dönen sonuç ve son yanıt. Kayıtlarda kişisel veri bulunabileceğini unutmayın. Saklama süresini ve erişim yetkisini bu nedenle baştan belirleyin.

• Beklenmedik araç çağrılarını işaretleyin; örneğin bir destek botunun bir anda dışa aktarma yapması.
• Alışılmadık uzunlukta girdileri ve tekrarlayan deneme kalıplarını izleyin.
• Sistem talimatına benzeyen çıktıları yakalayan bir uyarı kuralı kurun.
• Onay ekranında reddedilen işlemleri düzenli olarak inceleyin.
• Olay yaşandığında konuşmayı baştan sona yeniden oynatabilecek kadar ayrıntı saklayın.

Genel sunucu kayıtlarını okuma alışkanlığınız varsa, log analizi aracımızla web tarafındaki trafik örüntülerini de gözden geçirebilirsiniz. Yapay zeka kayıtları için ise kendi izleme panonuzu kurmanız gerekir.

Red teaming ile prompt injection testi nasıl yaparsınız?

Red teaming, sisteminize bir saldırgan gibi yaklaşıp zayıf noktalarını önceden bulmaktır. Burada amaç kötü niyetli bir şey yapmak değil, canlıya çıkmadan önce kendi sisteminizi sınamaktır. Yalnızca kendi ortamınızda ve izniniz olan sistemlerde çalışın.

İlk olarak test ortamı kurun. Gerçek müşteri verisi içermeyen, sahte kayıtlarla dolu bir kopya hazırlayın. Ardından bir test planı yazın: hangi araçlar, hangi veriler ve hangi sonuçlar kabul edilemez? Yani bu liste, testin ölçütlerini oluşturur.

1. Doğrudan denemeler yapın: botu kapsam dışına çıkarmaya, kuralları göstermeye ve rol değiştirmeye çalışın.
2. Dolaylı denemeler yapın: ajanın okuyacağı sahte belgelere, kendi yazdığınız zararsız talimatları gömün ve ajanın itaat edip etmediğini izleyin.
3. Araç sınırlarını deneyin: ajanın yetkisi olmayan bir işlemi yapıp yapamadığını kontrol edin.
4. Sonuçları kaydedin, önem derecesine göre sıralayın ve düzeltin.
5. Her model, talimat ya da araç değişikliğinden sonra testleri yeniden çalıştırın.

Ancak test setini bir kez yazıp bırakmayın. Yeni saldırı fikirleri ortaya çıktıkça listeyi güncelleyin. Böylece sisteminiz, yaşayan bir güvenlik kontrolünden geçmiş olur.

Hangi savunma hangi riski azaltır?

Aşağıdaki tablo, savunma katmanlarını etkileri ve sınırlarıyla yan yana koyar. Değerlendirme, saha deneyimine dayalı genel bir çerçevedir; her sistemde ağırlıklar farklı olabilir.

Kısacası tablodan çıkan sonuç net: hiçbir satır tek başına yeterli değildir. En çok ağırlığı ise yetki daraltma, insan onayı ve veriyi hiç vermeme taşır, çünkü bunlar modelin davranışına değil, yapının kendisine dayanır.

Prompt injection için hızlı bir kontrol listesi nasıl olmalı?

Bir yapay zeka özelliğini yayına almadan önce şu soruları ekip olarak yanıtlayın. Cevaplardan biri "bilmiyoruz" ise, canlıya geçmeden önce o noktayı netleştirin.

• Model hangi araçlara ve hangi verilere erişiyor, ve bunların her biri gerçekten gerekli mi?
• Dış içerik (web, e-posta, belge, yorum) okuyor mu, ve bu oturumda dışarıya bilgi gönderebiliyor mu?
• Geri dönüşü zor işlemler için insan onayı var mı?
• Sistem talimatında sır, anahtar ya da iç fiyat bilgisi var mı?
• Çıktının biçimini kod kontrol ediyor mu?
• Her araç çağrısını kaydediyor ve düzenli inceliyor musunuz?
• Son model ya da talimat değişikliğinden sonra test yaptınız mı?
• Bir olay olursa ajanı hızlıca kapatacak bir düğme var mı?

Son madde sıklıkla unutulur, oysa çok değerlidir. Bir "acil durdurma" mekanizması, sorun büyümeden önce sistemi devre dışı bırakmanızı sağlar. Ayrıca olay sonrası kimin, neyi, hangi sırayla yapacağını önceden yazılı hâle getirin.

Küçük bir işletme prompt injection savunmasına nereden başlamalı?

Büyük bir güvenlik ekibiniz olmasa da önemli adımları atabilirsiniz. En büyük kazancı veren ilk üç hamle, çoğunlukla bütçe gerektirmez: yetkileri daraltmak, hassas veriyi bağlamdan çıkarmak ve riskli işlemlere onay koymak.

İlk olarak, hangi yapay zeka araçlarını kullandığınızı listeleyin. Çoğu işletme, çalışanların kullandığı sohbet araçlarını, web sitesindeki botu ve otomasyon servislerini ayrı ayrı sayınca beklenenden fazla nokta bulur. Ardından her biri için "en kötü senaryo nedir" sorusunu yazın.

Daha sonra çalışanlarınızla kısa bir eğitim yapın. Bilinmeyen kaynaklardan gelen belgeyi ve bağlantıyı yapay zeka asistanına yüklemenin riskini anlatın. Kurumsal verinin hangi araca girebileceğini yazılı bir kurala bağlayın. Deepfake ve sahte ses gibi yan tehditler için de deepfake ve ses klonlama dolandırıcılığı yazımıza göz atın.

Kendi sisteminizi kurmayı düşünüyorsanız, ekibimizle AI agent geliştirme sürecini güvenlik gereksinimleriyle birlikte planlayabilirsiniz. Komut yazım teknikleri için ise prompt engineering yazımıza bakın; ancak unutmayın, iyi bir prompt güvenlik önleminin yerini tutmaz.

Güvenlik hizmetleri, hukuki ve mali sonuçlar için bu yazı danışmanlık yerine geçmez. KVKK, telif ya da dolandırıcılık gibi hukuki konularda bir uzmana başvurun.