Şirket Verilerinizi Sessizce Sızdıran 7 AI Ajan Veri Gizliliği Hatası (ve Bunlardan Nasıl Kaçınılır)

Çoğu AI ajan veri sızıntısı, modelin şirketinizi gizlice ezberlemesi değildir. Bunlar, adını koyabileceğiniz ve düzeltebileceğiniz yapılandırma ve mimari hatalarından kaynaklanır. En büyükleri: varsayılanları girdilerinizle eğitilen tüketici seviyesindeki bir hesapta çalışmak, bir ajanın tek bir kişinin geniş izinlerini devralmasına izin vermek, halka açık bir ajanı dahili sistemlere bağlamak ve "ölümcül üçlüyü" (özel veri, güvenilmeyen içerik ve harici bir gönderim yolu) bozulmadan bırakmak, böylece tek bir istem enjeksiyonu verilerinizi okuyup posta ile dışarı gönderebilir. Bu son kalıp, tam olarak EchoLeak'in (CVE-2025-32711) özenle hazırlanmış bir e-postadan, herhangi bir kullanıcı tıklaması olmadan, Microsoft 365 Copilot aracılığıyla hassas verileri nasıl ifşa ettiğidir. Çözümler egzotik değildir ve neredeyse hepsi, bir şey sızdıktan sonra size verilen bir kontrol listesi değil, ajan lansmandan önce alınan kararlardır.

Bu, inşa ettiğimiz bir ajanı başka bir şirketin yığınının içine koymadan önce üzerinden geçtiğimiz listedir; teknik olmayan bir işletme sahibinin kendi kurulumunda veya bir tedarikçinin kurulumunda aynı hataları fark edebilmesi için yazılmıştır. Bu çizgiyi sizin için olması gereken yerde tutmamızı tercih ederseniz, sorumlu AI yönetişimi ve riskini nasıl yürüttüğümüze bakın. Aşağıdaki her şey, her iki şekilde de kullanmanız için sizindir.

Önce, bu konudaki neredeyse her makalenin bulanıklaştırdığı bir ayrım, çünkü bunu yanlış anlamak sıfırıncı hatadır. Bir ajan üzerinden verilerin çıkmasının tamamen farklı iki yolu vardır ve bunların tamamen farklı çözümleri vardır:

• Sağlayıcı veri işleme. Model sağlayıcısı girdilerinizi saklıyor mu veya onlarla eğitiliyor mu? Bu, imzaladığınız bir sözleşme ve seçtiğiniz bir hesap seviyesidir. Koşullar ve yapılandırma ile çözülür.
• Çalışma zamanı sızdırması. Ajan, çalıştığı anda, verilerinizi gitmemesi gereken bir yere göndermesi için kandırılabilir mi? Bu, bir sözleşmeyle değil, mimariyle çözülür.

Anket rakamları, alıcıların bunu adını koyamasalar bile hissettiklerini söylüyor. Cloudera'nın 14 ülkede yaklaşık 1.500 üst düzey BT liderini kapsayan araştırmasında, yüzde 96'sı önümüzdeki yıl AI ajan kullanımını genişletmeyi planlıyor, ancak yüzde 53'ü (yarısından fazlası) veri gizliliğini birincil benimseme engeli olarak adlandırıyor. Aşağıdaki yedi hata, bu korkunun gerçek bir sızıntıya dönüştüğü ve çözümün yaşadığı yerdir.

Hata 1: üretim ajanlarını tüketici seviyesindeki hesaplarda çalıştırmak

Bu, yapılması en ucuz ve düzeltilmesi en kolay hatadır. Birisi, zaten orada olduğu için bir iş akışını kişisel bir ChatGPT veya tüketici Gemini hesabına bağlar ve artık iş verileriniz, asla bunun için tasarlanmamış tüketici koşullarıyla yönetilir.

Tüketici ve kurumsal seviyeler arasındaki uçurum keskindir. Kurumsal tarafta, kalıp sağlayıcılar arasında tutarlıdır: varsayılan olarak verilerinizle eğitim yok, kötüye kullanım izleme için kısa bir saklama penceresi ve talep üzerine daha güçlü seçenekler. OpenAI API, verileri kötüye kullanım izleme için 30 gün saklar, ardından siler ve varsayılan olarak onlarla eğitilmez. 14 Eylül 2025 itibarıyla Anthropic, API günlük saklama süresini 30 günden 7 güne düşürdü ve API girdileri ve çıktıları asla eğitim için kullanılmaz. Google'ın Vertex AI'sı (kurumsal seviye) eğitim kullanımı olmadan yapılandırılabilir. Tüketici tarafında varsayılanlar tersine döner: tüketici ChatGPT, siz silmediğiniz sürece konuşmaları süresiz saklar ve tüketici Gemini saklama süresi 36 aya kadar çıkar ve ürünleri iyileştirmek için kullanılabilir.

Çözüm: her üretim ajanını bir kurumsal API'ye veya iş hesabına koyun, asla kişisel bir oturuma değil. Teknoloji aynıdır. Koşullar değildir ve koşullar, yönetilen kalan veri ile sessizce eğitim materyaline dönüşen veri arasındaki tüm farktır.

Hata 2: ajanın devraldığı aşırı geniş izinler

En yaygın çalışma zamanı sızıntısı zekice değildir. Bir ajana bir çalışanın erişimi, ya da daha kötüsü bir yönetici anahtarı verilir, böylece teknik olarak o kişinin görebildiği her şeyi görebilir. Sonra ona, işinin çok ötesine ulaşan bir soru sorulur ya da böyle bir soruya kandırılır.

Microsoft'un Bulut Benimseme Çerçevesi kuralı açıkça belirtir: "Ajanlara yalnızca işlevleri için gereken belirli veri kaynaklarına erişim verin. Tüm kurumsal verilere geniş erişim sağlamayın." Bir destek ajanı, bordro sisteminize ihtiyaç duymaz. Bir planlama ajanı, müşteri veritabanına ihtiyaç duymaz. Bir ajan bir kişi adına hareket ettiğinde, o kişinin kimliğini güvenli bir şekilde aktararak izinlerini devralmalıdır, böylece bir yardım masası ajanı bir çalışana herkesinkini değil, yalnızca kendi İK kaydını gösterir.

Çözüm: her ajana, en az ayrıcalığa kapsamlandırılmış kendi kimliğini verin ve sabit bir üst küme taşımak yerine hareket eden kullanıcının izinlerini devralmasını sağlayın. Test basittir. Ajan yarın kandırılırsa, hasar, aşırı izinli bir hesabın ulaşabileceği her şeyle değil, ona tanınan dar kümeyle sınırlıdır.

Hata 3: halka açık ajanların dahili verilere bağlanması

Web sitenizdeki bir sohbet botu ve dahili raporlar hazırlayan bir ajan, iki farklı güvenlik dünyasıdır ve sızıntı, biri onların bir arka uç paylaşmasına izin verdiği anda olur. Halka açık bir ajan, internetteki herkesten girdi alır. Aynı ajan dahili iş verilerini de sorgulayabiliyorsa, halka açık web'den doğrudan özel sistemlerinize bir kapı inşa etmişsiniz demektir.

Microsoft'un çerçevesi burada en sert çizgiyi çeker: "Halka açık ajanlar dahili iş verilerine erişmemelidir." Gizli ve halka açık olanı fiziksel veya mantıksal bir sınır ile ayrı tutun (örnekleri ayrı "corp" ve "online" yönetim grupları kullanır). Mesele, sınırın istemin tutacağına dair bir umut değil, yapısal olmasıdır.

Çözüm: güvenilmeyen halka açık girdi alan ajanlar ile gizli verilere dokunan ajanlar arasına gerçek bir sınır koyun. Tek bir ajan gerçekten her ikisini de yapmak zorundaysa, bu seçebileceğiniz en yüksek riskli tasarımdır ve sadece dikkatli bir sistem istemine değil, sonraki hatalardaki üçlüyü bozan kontrollere ihtiyaç duyar.

Hata 4: ölümcül üçlüyü görmezden gelmek

Bu, ilk üçünü gerçek bir sızdırmaya dönüştüren hatadır. "İstem enjeksiyonu" terimini ortaya atan bağımsız uzman Simon Willison, AI ajanları için "ölümcül üçlüyü" adlandırdı: bir araya geldiklerinde tek bir enjekte edilmiş talimatın verilerinizi çalmasına izin veren üç koşul.

Üçü de mevcut olduğunda, bir saldırgan güvenilmeyen içeriğin içine bir talimat gizler. Model, Willison'un sözleriyle, "operatöründen mi yoksa başka bir kaynaktan mı geldiklerine bakılmaksızın, modele ulaşan herhangi bir talimatı seve seve izleyecektir." Özel verilerinizi okur ve dışarı gönderir ve istemde hiçbir şey ona e-postaya güvenmemesini söylememiştir.

Açık kısım ve bunun bir istem mühendisliği sorunu değil mimari olmasının nedeni: "bunun olmasını yüzde 100 güvenilir şekilde nasıl önleyeceğimizi hâlâ bilmiyoruz." Belgelenmiş istismarlar Microsoft 365 Copilot'a, GitHub'ın MCP sunucusuna ve GitLab Duo'ya isabet etti. Ocak 2026'da bir hafta içinde, dört AI verimlilik aracında dolaylı istem enjeksiyonu güvenlik açıkları açıklandı, hepsi aynı üçlü kalıbıydı.

Çözüm: bir ayağı kırın. Çalınan verinin gidecek bir yeri olmaması için harici gönderim yolunu reddedin, ya da güvenilmeyen içerik okuyan bir ajanın aynı bağlamda özel veri erişimine de sahip olmasına asla izin vermeyin. Her enjeksiyonu yakalamanın kazanılamaz savaşını kazanmanıza gerek yok. Başarılı bir enjeksiyonun bile dışarı çıkış yolu olmamasını sağlamanız gerekir.

Hata 5: EchoLeak'i başkasının sorunu olarak görmek

Gerçek bir olaya adını koymak değerlidir, çünkü "ölümcül üçlü" siz onun uygulandığını görene kadar soyut gelir. EchoLeak (CVE-2025-32711), Microsoft 365 Copilot üzerinde sıfır tıklama gerektiren bir saldırıydı. Bir saldırgan özenle hazırlanmış bir e-posta gönderdi. Copilot, normal işini yaparken o e-postayı işledi (güvenilmeyen içerik), kullanıcının dahili verilerine erişimi vardı (özel veri) ve bilgi dışarı gönderme yolu vardı (harici iletişim). Gizli talimat, hiçbir kullanıcı etkileşimi olmadan hassas veri ifşasını tamamladı. Kimse hiçbir şeye tıklamadı.

Buradaki hata, bir sızıntının dikkatsiz bir çalışan gerektirdiğini varsaymaktır. EchoLeak hiçbiri gerektirmedi. Önemli olan savunma "personeli kimlik avını fark etmesi için eğitin" değildi, çünkü bir insanın fark edeceği hiçbir şey yoktu. Savunma mimariydi: hem saldırgan kontrolündeki içeriği okuyup hem de sızdıramayan bir ajan, bu şekilde size karşı çevrilemez.

Çözüm: sıfır tıklamayı istisna değil, tehdit modeli olarak varsayın. Ajanınız bir dış kişinin etkileyebileceği herhangi bir şeyi okuyorsa (e-posta, web içeriği, yüklenen dosyalar, biletler) ve verileri de dışarı gönderebiliyorsa, bu iki yetenekten birini kapatana veya gönderim yolunu sıkıca çitleyene kadar EchoLeak biçiminde bir deliğiniz var demektir.

Hata 6: veri ikametgâhı veya saklama sınırının olmaması

Bazı sızıntılar dramatik sızdırmalar değildir, yavaş kaymalardır. Veri, hiçbir zaman kabul etmediğiniz bir bölgede depolanır halde, ya da politikanızın izin verdiğinden daha uzun süre günlüklerde oturur halde sonlanır, sadece kimse sınırı belirlemediği için. Microsoft'un çerçevesi bunu çekirdek yönetişim olarak listeler: her veri kaynağının, ajan çalışma zamanının ve çıktı depolamasının konumunu belirleyin, verileri ikamet politikanıza uyan bölgelerde veya şirket içinde tutun ve durağan halde şifreli tutun.

İçinizi rahatlatan haber, neredeyse hiçbir makalenin açıkça belirtmediği şey, ne kadarını sabitleyebileceğinizdir. Sağlayıcılar arasındaki kurumsal kalıp, varsayılan olarak eğitim yok artı kısa bir saklama penceresi artı talep üzerine daha güçlü garantilerdir. Anthropic, uygun kurumlara, girdilerin ve çıktıların kötüye kullanımı tarama için gerekenin ötesinde saklanmadığı bir Sıfır Veri Saklama (ZDR) anlaşması sunar. OpenAI, müzakere edilmiş bir anlaşma yoluyla ZDR ve veri ikametgâhı sunar. Her ikisi de verinin nerede yaşayacağını seçmenize izin verir. Açık bir modeli kendi kendine barındırmak (örneğin Ollama ile), veriyi üçüncü tarafların sıfır saklamasıyla tamamen yerel tutar.

Çözüm: sınıra lansman öncesinde karar verin ve belgeleyin. Veriyi hangi bölge tutacak, günlükler ne kadar yaşayacak, ZDR'ye ihtiyacınız var mı ve hassas veri çekiminin kendi VPC'nizde mi yoksa şirket içinde mi çalışması gerektiği. ZDR genellikle yalnızca API'ye özgüdür ve müzakere edilir ve siz eklemediğiniz sürece her ürünü otomatik olarak kapsamaz, bu yüzden ayrıntı önemlidir.

Hata 7: gizliliği teslim ettiğiniz bir kontrol listesi olarak görmek

Son hata yapısaldır. Mükemmel Microsoft çerçevesi de dahil olmak üzere çoğu kılavuz, ajanı kendiniz inşa edip yöneteceğinizi varsayar, bu yüzden size 3.000 kelimelik bir Entra kimlikleri, Purview etiketleri ve yönetim grupları yığını verir. Bu, büyük bir BT ekibi için doğru cevaptır. Çoğu işletme için bu, kimsenin tam olarak uygulamak için zamanı veya uzmanlık becerisi olmayan bir kontrol listesidir, dolayısıyla yarım kalır ve boşluklar tam olarak verilerin sızdığı yerdir.

Hata, kontrolleri uçtan uca birinin sahiplendiği bir mimari olarak değil, dokümantasyon olarak görmektir. "Gizli verileri izole edin" ve "harici entegrasyonları güvenilir MCP sunucularıyla sınırlayın" diye listeleyen bir kontrol listesi, ancak onu bağlayan, her harici iletişimi doğrulayan ve bir şey ters gittiğinde bir ajanı hızla devre dışı bırakacak olay planını ayağa kaldıran kişi kadar iyidir.

Çözüm: sadece belgeyi değil, sınırı gerçekten bir tarafın sahiplendiğinden emin olun. Ya tüm yığını uygulamak ve sürdürmek için şirket içi yeteneği inşa edersiniz, ya da bu arıza modlarını mimari olarak eleyip çalıştıran bir operatörünüz olur, işaret edebileceğiniz yayımlanmış bir sınırla. Yanlış orta yol, bir kontroller listesi ve onların tutulmasından kimsenin sorumlu olmamasıdır.

Yedi hata ve çözüm nasıl hizalanıyor

İşte yedisi bir arada, çözümün imzaladığınız bir sözleşme mi yoksa inşa ettiğiniz bir mimari mi olduğuna göre sıralanmış. Bu ayrım, her birinin hangi ekibe ait olduğunu bilmenin en hızlı yoludur.

Yedisinden yalnızca ikisinin bir sözleşmeyle çözüldüğüne dikkat edin. Diğer beşi, en iyi uygulamaların bir PDF'inin sizin için yapamayacağı kısım olan mimari ve sahipliktir. Aynı zamanda, yetkili kaynakların bir boşluk bırakmasının dürüst nedeni de budur: size neyi inşa edeceğinizi söylerler, kendi belirli sistemlerinizin içinde onu doğru kim inşa edeceğini değil.

Sınır doğru inşa edildiğinde gerçekte asla ne çıkmaz

Yedi hatayı okuyup AI ajanlarının bir gizlilik mayın tarlası olduğu sonucuna varmak kolaydır. Çizgi kasıtlı olarak çekildiğinde değildirler. Kurumsal koşullarda, girdileriniz eğitim verisi değildir ve saklama süresi sonsuza kadar değil, günlerdir (Anthropic API için 7, OpenAI için 30, ardından silinir). ZDR ile, kötüye kullanım taramasının ötesinde saklanmazlar. Veri ikametgâhı sabitlenmiş halde, bölgenizde kalırlar. VPC veya şirket içi veri çekimi ile, hassas veri çevre sınırınızdan hiç çıkmaz. Sınırda maskeleme ile, asla seyahat etmemesi gereken alanlar herhangi bir şey gönderilmeden önce çıkarılır. Kullanıcının izinlerini devralan en az ayrıcalık kapsamı ile, ajan yalnızca hareket eden kişinin zaten ulaşabileceği şeye ulaşabilir.

Bu, belirli, savunulabilir bir sınırdır ve onu açıkça ifade edebilmek bütün meseledir. Tehlike hiçbir zaman modelin şirketinizi sessizce özümsemesi değildi. Yukarıdaki yedi yapılandırma ve mimari hatasıdır, her biri ilk ajan devreye girmeden önce önlenebilir.

Bu, başka şirketlerin yığınlarının içinde yaptığımız iştir: koşulları seçmek, kimlikleri kapsamlandırmak, halka açık olanı gizli olandan izole etmek, üçlüyü bozmak ve tutması için sınırı sahiplenmek. Bu hataların, ajanlarınız gerçek herhangi bir şeye dokunmadan önce mimari olarak elenmesini istiyorsanız, aşağıdan ücretsiz bir danışmanlık görüşmesi ayırtın, sınırınızı birlikte haritalandıralım.