LLM güvenliği nedir? OWASP Top 10 güvenlik riskleri nasıl azaltılır?

Bir yapay zekayı, saldırganın talimatlarını komut olarak algılayacak şekilde kandıran saldırı türü, yani istem enjeksiyonu (prompt injection), 2023'ten bu yana yayımlanan her sürümde LLM Uygulamaları için OWASP Top 10 listesinin 1 numarasında yer aldı.

Bu liste, yapay zeka güvenliği alanında uzlaşıya en çok yaklaşan kaynak. Proje küçük bir güvenlik uzmanı grubu olarak başladı ve bugün 18'den fazla ülkeden 600'ü aşkın katkıda bulunan uzmandan destek alıyor.

Yapay zekanın nasıl kandırılıp bir şeyler yapmaya ikna edilebildiğine dair bir rehber yayımlayan bir yapay zeka şirketiyiz; bu yüzden sorun çözülmüş gibi davranmayacağız. OWASP projesinin eş liderlerinden Wilson, mevcut savunmalar konusunda oldukça netti: "...açıkçası, %99'da olduğumuzu düşünmüyorum."

2026 sürümü de aynı mesajla açılıyor. Proje lideri bize "Kandırılamayacak bir model inşa etmeye çalışmayı bırakın" diyor ve çevredeki sistemi, kandırılmış bir modelin önemli hiçbir şeyi bozamayacağı şekilde tasarlamamızı öneriyor.

Bu bakış açısını OWASP'ın 2026 listesindeki 10 riskin tamamına uyguluyoruz.

LLM güvenliği ne anlama gelir?

LLM güvenliği, yapay zeka modellerini ve bunları kullanan uygulamaları saldırılardan ve kötüye kullanımdan korumak demektir. Risk, modelin bağlı olduğu şeylerle birlikte büyür: okuyabildiği dosyalar ve veriler ile e-posta, arama veya bir şirket veritabanı gibi kullanabildiği araçlar.

Düzgün şekilde güvence altına alınmış yazılımlarda, bir programın izlediği talimatlar ile işlediği bilgiler arasında kesin bir çizgi vardır. Ancak LLM'lerde bu çizgi yoktur.

Modelin okuduğu her şey tek ve uzun bir metin akışı olarak gelir: geliştiricinin talimatları, sizin sorunuz, modelin baktığı bir web sayfası. Yapay zeka modellerinin kimin konuştuğunu takip etmesi beklenir; konuşan geliştirici, kullanıcı ya da bir problem üzerinde düşünen modelin kendisi olabilir.

Ancak araştırmacılar Jasmine Cui ve Charles Ye, modellerin kimin konuştuğunu çoğunlukla metnin kulağa nasıl geldiğine bakarak tahmin ettiğini keşfetti. Dolayısıyla bir saldırgan kulağa modelin kendi akıl yürütmesi gibi gelen bir şey yazarsa model, bu fikri kendisinin bulduğuna inanabilir. Bu, modelin kontrolün kimde olduğunu bilmesine dayanan her güvenlik düzeni için bir sorundur.

Aynı sorunla kendi yapay zeka ajanlarımızda da karşılaştık. CISO'muz Kyle Polley, bir röportajda ISMG'ye ajanların "sistem istemine ekleseniz bile politikalara uymayabileceğini" söyledi. Bu yüzden, bir ajanın yapmak üzere olduğu şeyi denetleyen ve eylem yapılandırılmış bir güvenlik kuralını ihlal ediyorsa onu engelleyebilen açık kaynaklı bir araç olan Numbat'ı geliştirdik.

LLM güvenliği, modelin zaman zaman yanlış kişiden emir alacağını kabul etmek ve bu olduğunda bile ayakta kalan yapay zeka güvenlik bariyerlerini modelin etrafına kurmak demektir.

LLM güvenliği için en iyi uygulamalar nelerdir?

LLM Uygulamaları için OWASP Top 10 2026 listesini 1 numaradan 10 numaraya kadar sırayla ele alacağız.

Her risk için işlerin nasıl ters gittiğine dair sade bir açıklama ve gerçek hayattan bir örnek bulacaksınız. Ardından bu riski önlemeye ya da en azından hasarı sınırlamaya yardımcı olabilecek uygulamaları ele alacağız.

1. İstem enjeksiyonunu kontrol altına alın

İstem enjeksiyonu, bir saldırganın bir yapay zekanın uymaması gereken talimatlara uymasını sağlamasıyla gerçekleşir. Bu talimatlar doğrudan bir sohbet üzerinden gelebileceği gibi bir e-postaya, web sayfasına veya belgeye de yerleştirilebilir.

İkinci türe dolaylı istem enjeksiyonu denir. Asistanınızdan bir belgeyi özetlemesini istersiniz. Belgenin yazarı ise asistana özel dosyalarınızı kendisine göndermesini söylemiştir. Asistan bu talimatlara uyarsa belgeyi yazan kişi fiilen sizin erişiminizi ödünç almış olur.

PCMag'in benzetmesiyle istem güvenliği, gözenekli bir taştaki delikleri tıkamaya benzer. Bir deliği kapatırsınız, su başka bir yol bulur. “Bir saldırı kendine bir yol bulur; açık düzeltilir, ancak sırf LLM'ler gibi sistemlerin dinamik yapısı nedeniyle keşfedilmeyi bekleyen sayısız başka saldırı yolu var olmaya devam eder.”

Örnek: Haziran 2025'te Aim Security araştırmacıları, Microsoft 365 Copilot aracını kandırarak özel şirket bilgilerini sızdırmasını sağlayan bir açık olan EchoLeak'i buldu. Bir çalışan rutin bir iş sorusu sorduğunda Copilot, e-postayı çekip içine gizlenmiş talimatları izleyebiliyor ve hassas bilgileri saldırgana gönderebiliyordu. Saldırı, kötü amaçlı talimatları yakalamak ve şüpheli bağlantıları kaldırmak için tasarlanmış denetimleri atlattı.

Neler yapabilirsiniz:

• Rehberiniz Meta'nın “İki Kuralı” olsun: EchoLeak'in işe yaraması için şirket verilerini okuyabilen, dışarıdan gelen e-postaları okuyabilen ve dışarıya bilgi gönderebilen bir yapay zeka gerekiyordu ve hedef aldığı yapay zeka bu üç yeteneğe de sahipti. Yapay zekayı bu yeteneklerden ikisiyle sınırlamak, bir istem enjeksiyonunun çok fazla kontrol ele geçirmesini önler. Görev üçünü birden gerektiriyorsa her eylemden önce insan onayı isteyin.
• Savunmalarınızı bilen saldırganlara karşı test edin: Güvenlik test uzmanlarınıza uyguladığınız kuralları ve filtreleri verin, ardından bunları aşmaya çalışmalarına izin verin. Bir çalışmada, savunmalara uyum sağlayan saldırganlar test edilen 12 savunmanın çoğuna karşı %90'ın üzerinde bir oranla başarılı oldu.

2. Hassas bilgilerin sızmasını önleyin

Yapay zeka sistemlerinin özel bilgileri görmemesi gereken kişilere vermesine hassas bilgilerin ifşası denir. Bu, bir müşterinin ödeme bilgilerinin açığa çıkarılması ya da özel konuşmaların paylaşılan bir veritabanında açıkta bırakılması anlamına gelebilir.

Birçok sızıntı “aşırı paylaşım” ile başlar. Diyelim ki bir şirket, yapay zekasını gevşek izinlere sahip sürücülere ve bilgi tabanlarına bağlıyor. Yapay zeka, tam da tasarlandığı gibi, erişebildiği her şeyi getirir. Kimsenin içeri sızmasına gerek kalmaz, ama LLM'i ele geçirilmiş sayın.

Örnek: Ocak 2025'te Wiz araştırmacıları, internete açık bir DeepSeek veritabanı buldu; veritabanında sohbet geçmişi ve yazılımların başka hizmetlere erişmek için kullandığı API anahtarları dahil bir milyondan fazla günlük kaydı bulunuyordu. Araştırmacıların herhangi bir şeyi açığa çıkarması için modeli ikna etmesine gerek yoktu.

Neler yapabilirsiniz:

• Yapay zeka verileri okumadan önce erişimi denetleyin: Uygulamanız, soruyu soran kişinin hangi belgeleri görmeye yetkili olduğunu bu belgeleri modele iletmeden önce kontrol etmelidir.
• Yapay zekanızın geride bıraktığı kayıtları koruyun: Etkinlik günlüklerini kaydetmeden önce özel ayrıntıları ve gizli anahtarları kaldırın, oturum açmayı zorunlu kılın ve erişimi bu kayıtlara ihtiyaç duyan kişilerle sınırlayın. Bu kayıtların süresiz olarak birikmemesi için bir saklama süresi belirleyin.

3. Aşırı yetkiyi dizginleyin

Aşırı yetkiye sahip yapay zekalar, işlerinin gerektirdiğinden daha fazla güce sahiptir: ihtiyaç duymadıkları araçlar, görevlerinin ötesine geçen izinler ya da kontrol etmeden hareket etme serbestliği. Burada nedenin bir önemi yoktur.

Bir enjeksiyon istemi, bir hata ya da sadece yanılan bir model; hepsi aynı sonuca yol açar. Yapay zeka, yeteneği varsa eninde sonunda yıkıcı bir şey yapacaktır.

Örnek: Temmuz 2025'te SaaStr'ın kurucusu Jason Lemkin, değişiklik yapmama talimatlarına rağmen Replit'in kodlama ajanının 1.206 yönetici kaydı içeren veritabanını sildiğini bildirdi. Ajan başta verilerin geri yüklenemeyeceğini söyledi, ancak daha sonra kurtarmanın mümkün olduğu anlaşıldı. Jason, ajana veritabanına dokunmamasını söylemenin onun veritabanını silme yeteneğini ortadan kaldırmadığını fark etti.

Büyüt

Kaynak: X

Neler yapabilirsiniz:

• Görevin ihtiyaç duymadığı yetenekleri kaldırın: Hem bir ajana verilen araçları hem de bu araçların neler yapabildiğini sınırlayın. E-postaları özetleyen bir asistanın onları okuma iznine ihtiyacı vardır; gönderme veya silme iznine değil.
• İzin denetimlerini yapay zekanın dışına yerleştirin: Bir eylem her talep edildiğinde, eylemin güvenlik kurallarınıza göre denetlenmesini sağlayın ve bir kişinin onaylamasını zorunlu kılın.

4. Yapay zeka tedarik zincirinize neyin girdiğini kontrol edin

Yapay zekayı sıfırdan geliştiren şirket sayısı az ve her yıl daha da azalıyor. Menlo Ventures'ın 2025 tarihli The State of Generative AI in the Enterprise anketine göre şirketlerin %53'ü 2024'te yapay zeka modeli satın aldı; bu oran 2025'te %76'ya yükseldi.

Şirketler çoğu zaman modelleri Hugging Face gibi merkezlerden indirir, başkalarının topladığı veri kümeleriyle ek eğitimden geçirir ve tanımadıkları kişilerin yazdığı eklentileri ve kod paketlerini sisteme dahil eder.

Bu parçaların her biri bir giriş kapısıdır. Biri kurcalanırsa sorun, ürününüzle birlikte kullanıcılara ulaşır.

Örnek: Hugging Face'in herkese açık model depolarının sayısı, Ocak 2026 ile Ağustos 2026 arasında 2,43 milyondan 2,96 milyona yükseldi. Ancak Temmuz 2026'da OpenAI'ın modelleri, şirket içi güvenlik testleri sırasında onları internetten uzak tutmak için tasarlanmış denetimleri atlatarak Hugging Face'in sistemlerinin bazı bölümlerine sızdı. Hatta bir ajan, herkese açık şekilde ifşa olmuş 14 erişim kimlik bilgisini ele geçirdi, bunların çalıştığını doğruladı ve diğer ajanlarla paylaştı. Ajanlar ardından Hugging Face'in sunucularında kod çalıştırmalarına olanak tanıyan açıklardan yararlandı.

OpenAI raporunda şu ifadeler yer alıyor: “Bir modelin yaşam döngüsü boyunca hizalama konusunda daha katı gereklilikler getiriyor, daha yalıtılmış korumalı alanlar oluşturuyor, internet erişimini kısıtlıyor ve model ağırlıklarına erişimi daha da sıkı denetliyoruz.”

Neler yapabilirsiniz:

• Modelleri belirli bir sürüme sabitleyin ve doğrulayın: Her modeli incelenmiş bir sürüme sabitleyin ve yüklemeden önce dosya parmak izini kontrol edin; böylece değiştirilmiş bir dosya aynı etiketin altında fark edilmeden içeri sızamaz. OWASP dijital imzaları da önerir, ancak bir uyarıyla: İmza, bir modelin nereden geldiğini kanıtlar, güvenli olduğunu değil.
• Yapay zekanızın önerdiği her paketi kontrol edin: Bir yapay zeka asistanının önerdiği kod paketini yüklemeden önce, paketin gerçekten var olduğunu, kastettiğiniz paket olduğunu ve beklediğiniz yayıncıdan geldiğini doğrulayın.

5. Veri ve model zehirlenmesine karşı önlem alın

Zehirlenmiş bir yapay zeka, bozulmuş verilerden öğrenir. Bu veriler, modelin ince ayarında kullanılan örnekler ya da modelin yanıt bulmak için aradığı bir bilgi tabanı olabilir. Model hâlâ çalışıyor gibi görünür; yalnızca yanlış dersler çıkarır ve bazen yalnızca belirli bir tetikleyici ifadeyi gördüğünde hatalı davranmayı öğrenir.

Biri bu ifadeyi kullanana kadar model, uyguladığınız her testten geçer.

Büyüt

Ayrıca bunu geri almak gerçekten zordur. Zehirlenme, yamayla düzeltebileceğiniz bir hata değildir. Verileriniz yanlışsa onları yeniden kontrol etmeniz, modeli yeniden eğitmeniz ya da tamamen değiştirmeniz gerekebilir.

Örnek: Ekim 2025'te Anthropic, Birleşik Krallık Yapay Zeka Güvenliği Enstitüsü ve Alan Turing Enstitüsü'ndeki araştırmacılar, 250 zehirli belgenin bir modele belirli bir tetikleyiciyle her karşılaştığında anlamsız metin üretmeyi öğretebileceğini gösterdi. Test edilen dört model boyutunun hepsinde aynı sayı işe yaradı; üstelik en büyük model 20 kattan fazla temiz veriyle eğitilmişti.

Neler yapabilirsiniz:

• Verilerinizin nereden geldiğini takip edin: Kullandığınız her veri kümesinin ve modelin, her birinin nereden geldiğinin ve sürümler arasında nelerin değiştiğinin kaydını tutun. Veri kümeleri için sürüm kontrolü kullanmanızı öneririz; böylece zehirlenme ortaya çıkarsa temiz bir sürüme geri dönebilir ve zehrin nasıl sızdığını tespit edebilirsiniz.
• Arka kapılara karşı test edin: “Arka kapı”, bir saldırganın modele yerleştirdiği ve etkinleşmek için belirli bir ifadeyi veya başka bir tetikleyiciyi bekleyen gizli bir davranıştır. Bunları, modelin olağan kurallarını çiğnemesine yol açacak şekilde tasarlanmış girdilerle test edin.

6. Sınırsız tüketime sınır getirin

Yapay zekaların ne kadar iş yapabilecekleri veya ne kadar maliyet oluşturabilecekleri konusunda hiçbir sınır olmadığında, tüketimleri “sınırsız” kabul edilir. Yapay zeka hizmetlerinin çoğu kullanım başına ücret aldığından bir saldırgan faturanızı kabartabilir veya modelinizin bir kopyasını oluşturabilir.

OWASP, temel sorunu “maliyet asimetrisi” olarak adlandırıyor. Kısa ve ucuz bir istek, sizin tarafınızda pahalı hesaplamaları tetikleyebilir.

Örnek: Mayıs 2024'te Sysdig'in Tehdit Araştırma Ekibi, “LLMjacking” adı verilen yeni bir saldırı keşfetti. Bir saldırgan grubu, çalınmış kimlik bilgileriyle bulutta barındırılan 10 LLM hizmetini hedef aldı. Laravel'in güvenlik açığı bulunan bir sürümü üzerinden içeri girdiler, ardından kimlik bilgilerinin neler yapabildiğini ve varsa kotaları tespit ettiler; amaçları belli ki erişimi satmaktı. Muhtemelen fark edilmemek için birçok günlük kaydı ayarı da sorgulandı. Sysdig'e göre en kötü senaryoda bu durum, kurbana günde 46.000 doları aşan bir maliyet çıkarabilir.

Neler yapabilirsiniz:

• Harcamayı durduran bütçeler belirleyin: Bireysel kullanıcılar, API anahtarları, ekipler ve hesabın tamamı için kesin harcama limitleri koyun. Bu limitleri, isteklerin girebildiği her noktada uygulayın.
• Her göreve bir durma noktası belirleyin: Bir görevin ne kadar süre çalışabileceğini, ne kadar metin işleyip üretebileceğini ve kaç araç çağrısı yapabileceğini sınırlayın. Kendini tekrar eden veya kendisine ayrılan payı aşan ajanlar için otomatik kesme mekanizmaları ekleyin.

7. Harekete geçmeden önce yanlış bilgiyi yakalayın

Bir yapay zeka doğru gibi görünen yanlış bir şey ürettiğinde ve biri ya da bir şey buna göre harekete geçtiğinde buna yanlış bilgi denir. Temel risk, yanlış yanıtın kendisinden çok bu yanıta güvenilmesi ve kullanılmasıdır.

Olay kayıtları, uygulayıcıların yanlış bilgi konusunda olması gerektiği kadar endişeli olmadığını gösteriyor. 2026 sürümünün açılış mektubuna göre oy verenler bu riski listenin sonlarına yerleştirdi, ancak gerçek dünyadaki olaylara bakıldığında risk listenin başlarında yer alıyor.

Örnek: 2025'te Deloitte Australia, 440.000 Avustralya doları tutarındaki bir devlet sözleşmesi kapsamında sosyal yardım BT sistemlerine ilişkin bir inceleme raporu teslim etti. Sidney Üniversitesi'nden araştırmacı Chris Rudge, raporda var olmayan araştırmalara yapılan atıflar ve bir federal mahkeme kararından uydurulmuş bir alıntı buldu. Revize edilen raporda Deloitte'un metodolojisinde Azure OpenAI GPT-4o kullandığı açıklandı ve şirket son taksiti geri ödemeyi kabul etti. Ne yazık ki bu bir güvence incelemesiydi.

Neler yapabilirsiniz:

• Kanıtların yanıtı desteklediğini kontrol edin: İddiaları güncel ve yetkili kaynaklara dayandırın. Bir politika yanıtı için onaylanmış politikayı getirin ve istisnaları da dahil olmak üzere politikanın vardığı sonucu desteklediğini doğrulayın.
• Sistem harekete geçmeden önce doğrulayın: Bir ajan, bir müşterinin kimlik kontrolünden geçtiğini söylüyorsa bir ödemeyi serbest bırakmadan önce bunu doğrulama sistemiyle teyit edin. Önemli sonuçları olan kararlar için, destekleyici kanıtların inceleyen kişiye sunulduğu bir insan onayını zorunlu kılın.

8. Gizli bağlamın açığa çıkmasından kaynaklanan hasarı sınırlayın

Yapay zeka uygulamaları, modele kullanıcıların normalde görmediği talimatlar ve arka plan bilgileri verir. Bunlar arasında sistem istemi, dahili politikalar, kullanılabilir araçların açıklamaları ve bu araçları kimlerin kullanabileceğine dair kurallar yer alabilir. Gizli bağlamın açığa çıkması, model bu bilgileri birine ifşa ettiğinde gerçekleşir.

OWASP, 2026'da bu maddenin kapsamını “sistem istemi sızıntısı” başlığının ötesine genişletti, çünkü sistem istemi dışarı sızabilecek şeylerin yalnızca bir parçası. Tehlike, oraya ne koyduğunuza bağlıdır. Sızdırılan bir ses tonu kılavuzu biraz utandırıcıdır, ancak sızdırılan bir API anahtarı birine gizli veritabanınıza erişim sağlar.

Örnek: Şubat 2023'te kullanıcılar Microsoft'un Bing Chat'inin dahili talimatlarını açığa çıkarmasını sağladı. Başarılı girişimlerden biri Marvin von Hagen'den geldi; von Hagen kendini bir OpenAI geliştiricisi olarak tanıttı ve modeli yapılandırabilmek için talimatları istedi. Bing, aramalarını, yanıtlarını ve güvenlik davranışlarını yöneten kuralları dahili adı olan Sydney ile birlikte açıkladı. Açığa çıkan talimatlar arasında bu talimatları gizli tutmasını söyleyen bir talimat da vardı.

Neler yapabilirsiniz:

• Gizli bilgileri modelin bağlamından uzak tutun: Modelin okuyabildiği her şeyin kullanıcılar tarafından görülebilir hâle gelebileceğini varsayın; parolaları, API anahtarlarını ve erişim belirteçlerini ayrı bir gizli bilgi yönetim sisteminde saklayın.
• Kurallar sızsa bile izinlerin geçerli kalmasını sağlayın: Erişim denetimlerini uygulama kodunuzda zorunlu kılın. Bir araç yalnızca yöneticilerle sınırlıysa, çalıştırmadan önce kullanıcının hesap izinlerini kontrol edin.

9. Vektörlerinizi ve gömmelerinizi güvence altına alın

Bir yapay zeka, şirketinizin belgelerinde yanıt bulmak için vektör araması kullandığında metni doğrudan aramaz. Belgeler, her pasajın anlamını yakalayan uzun sayı listeleri olan “gömmelere” (embedding) dönüştürülür ve bir vektör veritabanında saklanır. Sorular da aynı şekilde dönüştürülür ve sistem, sayıları soruya en yakın olan pasajları getirir.

OWASP, bu sistemin dört başarısızlık biçimini şöyle özetliyor: zehirleme sistemi yanıltır, tersine çevirme veri sızdırmasına yol açar, engelleme (jamming) onu susturur, bozuk erişim denetimi ise her şeyi herkese vermesine neden olur.

Bu sayılar göründükleri kadar güvenli bir soyutlama değildir. Saklanan gömmeler yeniden metne dönüştürülebilir; bir yöntem, testlerinde 32 token’lık kısa pasajların %92’sini birebir geri elde etti. Dolayısıyla sızdırılmış “yalnızca gömmelerden oluşan” bir yedek de belgelerin içeriğini açığa çıkarabilir.

Örnek: USENIX Security 2025’te sunulan bir araştırmada araştırmacılar, özenle hazırlanmış tek bir belgenin bir yapay zekanın belirli bir soruyu yanıtlamasını engelleyebileceğini gösterdi. Bu belgeyi, yapay zekanın arama yaptığı koleksiyona eklediler. Yapay zeka belgeyi bulduğunda yeterli bilgisi olmadığını ya da yanıt vermenin güvenli olmayacağını söyleyebiliyordu. Belgenin, yapay zekaya kurallarını yok saymasını söylemesine bile gerek yoktu. Buna “bilgi getirme engellemesi” (retrieval jamming) denir.

Neler yapabilirsiniz:

• Herkese açık ve özel veriler için ayrı dizinler tutun: Web’den kazınan içerikleri iş ortağı verileriyle veya gizli şirket içi belgelerle karıştırmayın. İçerikleri tek bir dizinde etiketlemek yerine güven düzeyine göre fiziksel olarak ayırın; bu yaklaşım, bütün bir yanlış yapılandırma sınıfını ortadan kaldırır ve internetten kazınan içeriğin yönetim kurulu belgelerinizin yanında yer almasını önler.
• Gömmelere, türetildikleri belgeler gibi davranın: Onları şifreleyin, kaynak dosyaların yanı sıra vektör veritabanı yedeklerini de koruyun ve orijinal belgeyi sildiğinizde gömmeleri de silin. Gömme hizmetinizin API anahtarları gizli tutulmalıdır.

10. Yapay zeka çıktısını aktarmadan önce kontrol edin

Bir uygulama, yapay zeka çıktısını başka bir sistemde kullanılmasının güvenli olup olmadığını doğrulamadan o sisteme aktarıyorsa LLM çıktısını hatalı biçimde işliyor demektir.

Bu madde, yapay zeka kodlama asistanlarının büyük ölçekte ürettiği güvensiz kodu da kapsar. Dolayısıyla bir asistanın yazdığı her satır da bir çıktıdır.

Örnek: 2025’te araştırmacı Johann Rehberger’in gösterdiği gibi, Sourcegraph’ın Amp kodlama asistanı yalnızca bir görsel görüntüleyerek sohbet içeriğini sızdırabiliyordu. Rehberger, Amp’in özel bilgileri bir görselin web adresine eklemesini sağlamak için istem enjeksiyonu kullandı. Uygulama ardından bu görseli otomatik olarak getirdi ve bilgileri onun sunucusuna gönderdi. Çıktı işleme hatası bu otomatik istekti: Modelin ürettiği metin, özel verileri de beraberinde taşıyan, dış bir sunucuya yönelik bir bağlantıya dönüştü.

Neler yapabilirsiniz:

• Çıktıyı gideceği yer için güvenli hâle getirin: Yanıtları gidecekleri yere göre kontrol edin ve işleyin. Bir web sayfası için, oluşturulan metnin çalıştırılabilir koda dönüşmesini önleyin. Bir veritabanı için, sağlanan değerleri komutlardan ayrı tutan parametreli sorgular kullanın.
• Yanıtların otomatik olarak dış bağlantı kurmasını engelleyin: Model yanıtlarında görsellerin, bağlantı önizlemelerinin ve gömülü sayfaların otomatik olarak yüklenmesini varsayılan olarak devre dışı bırakın. Gerekli bağlantıları açıkça onaylanmış hedeflerle sınırlayın.

Perplexity LLM’leri nasıl güvence altına alıyor?

Yukarıdaki her riskin eninde sonunda gerçekleşeceğini varsayıyor ve sistemlerimizi, gerçekleştiğinde fazla zarar veremeyecek şekilde tasarlıyoruz. CISO’muz Kyle Polley, bunu nasıl yaptığımızı yakın zamanda düzenlenen bir atölye çalışmasında anlattı.

• Ajanın kendi bilgisayarı vardır ve bu bilgisayar boş başlar: Dizüstü bilgisayarınıza kurulan ajan araçları, bilgisayarınızdaki dosyalara, uygulamalara ve kayıtlı kimlik bilgilerine erişim kazanabilir. Perplexity Computer ise tam tersi şekilde çalışır. Her görev kendi yalıtılmış korumalı alanında çalışır ve Polley’nin ifadesiyle “varsayılan olarak hiçbir şeye erişimi yoktur.”
• Ajan parolaları hiçbir zaman görmez: Bağlı hizmetlerin kimlik bilgileri korumalı alanın dışında saklanır. Ajanın GitHub gibi bir hizmete erişmesi gerektiğinde, kimlik bilgisi eklenmemiş bir istek gönderir. Bir ağ geçidi, hedefin ve isteğin beklendiği gibi olup olmadığını kontrol eder, ardından istek dışarı çıkarken kimlik bilgilerini ekler. Ajan, anahtarları eline almadan bağlantıyı kullanabilir.
• İzinleriniz aynen aktarılır ve bunları daha da kısıtlayabilirsiniz: OAuth aracılığıyla kurulan bağlantılar, bağlı hizmetteki erişim izinlerinizi korur. Sizin göremediğiniz bir şeyi ajanınız da göremez.
• Her web sayfasına yabancı muamelesi yapılır: Test ettiğimiz araçlar gerçek kullanımda ihtiyaçlarımızı karşılamadığı için ajan tabanlı tarayıcımız Comet için BrowseSafe’i geliştirdik. Tarayıcı, e-postalar dahil web sayfalarını ve diğer dış içerikleri istem enjeksiyonuna karşı tarar. Hem modeli hem de veri kümesini açık kaynak olarak yayımladık.
• Ajanı ve çalıştığı makineleri izliyoruz: Numbat, bir ajanın harekete geçme kararı ile aracın gerçekten çalışması arasında konumlanır. Numbat, desteklenen kodlama ajanlarındaki etkinlikleri kaydeder ve yapılandırılmış politikaları ihlal eden eylemleri gerçekleşmeden önce engelleyebilir. Bumblebee, dizüstü bilgisayarlar, sunucular ve derleme işlem hatlarındaki yazılım paketlerinin envanterini çıkarır ve kötü amaçlı olduğu bilinen paketleri işaretler. Her ikisi de açık kaynaktır.
• Model sağlayıcıları verilerinizi saklamaz: Üçüncü taraf LLM sağlayıcılarımızla sıfır veri saklama anlaşmalarımız var. Enterprise yöneticileri, Perplexity’nin kendi veri saklama süresini de 24 saate kadar kısaltabilir.

Numbat’ı, Polley’nin tek cümleyle özetlediği bir nedenle proaktif olarak geliştirdik: “Bir ajana ne kadar çok özerklik verirseniz risk de o kadar artar.”

LLM güvenliği hakkında SSS

En güvenli LLM hangisidir?

Hiçbir LLM, bir uygulamayı tek başına güvenli hâle getirmez; modeller, okumaları gereken içeriği uymaları gereken talimatlarla hâlâ karıştırabilir. Standart testlerde güçlü görünen savunmalar da baskı altında çökebilir.

Daha doğru soru, kullanım senaryonuz için hangi kurulumun en güvenli olduğudur. Bu da sınırlı izinler, modelden uzak tutulan kimlik bilgileri, riskli eylemler için insan onayı ve savunmalarınızı bilen kişilerin yaptığı testler anlamına gelir.

LLM güvenlik açıkları nelerdir?

LLM güvenlik açıkları, ister bir saldırgan ister sistemin kendi hataları yoluyla olsun, bir yapay zeka sisteminin kandırılmasına, veri sızdırmasına veya zarara yol açmasına neden olan zayıflıklardır.

On temel risk şunlardır: istem enjeksiyonu, hassas bilgilerin ifşası, aşırı yetki, tedarik zinciri, veri ve model zehirleme, sınırsız tüketim, yanlış bilgi, gizli bağlamın açığa çıkması, vektör ve gömme zayıflıkları ve hatalı çıktı işleme.

Özel LLM güvenli mi?

Bazı konularda daha güvenli bir seçenektir, ancak varsayılan olarak değil. Bir modeli kendi altyapınızda veya bir bulut ortamında çalıştırırsanız veri işleme üzerinde daha fazla kontrole sahip olursunuz. Ancak istem enjeksiyonlarını, aşırı yetkiyi, zehirlemeyi veya yanlış bilgiyi otomatik olarak önlemenin bir yolu yoktur.

Kendi sunucunuzda barındırdığınızda, tedarik zinciri riskleri ve gerektirdiği altyapı dahil olmak üzere indirdiğiniz modelin sorumluluğu da size aittir.