Yapay zeka asistanı kimin neyi görebileceğini nasıl gözetir?

Canlıya geçmeden önce bilgi güvenliği ekibinden biri doğru soruyu soracaktır: Bir çalışan “yöneticilerin maaş bantları nedir?” yazıp yanıt alabilir mi? Maaş bantları belgesi asistanın dizinindeyse ve kimin sorduğunu hiçbir şey kontrol etmiyorsa yanıt evettir. Üstelik yanıt, belgeyi gösteren kullanışlı bir kaynak bağlantısıyla gelir.

Kuralı söylemek kolaydır. Asistan hiçbir zaman yetkilerinizi aşmanın bir yolu olmamalı: bir kişi yalnızca, soruyu sorduğu anda kaynak sistemde kendisinin açabileceği belgelerden yanıt alır. Bir RAG (erişimle zenginleştirilmiş üretim) asistanında erişim kontrolünün gerçekten işlemesi üç şey ister: erişimi arama anında kaynak sistemin kendi kurallarıyla uygulamak, bu kuralları senkron tutmak ve erişimini yeni kaybetmiş kişiler dahil gerçek rolleri temsil eden test hesaplarıyla (persona) denemek.

Bir yapay zeka asistanı çalışanlar arasında nasıl bilgi sızdırabilir?

Ön kapıdan da, yan kapılardan da:

• Her şeyi gören tek bir dizin. Her şeyi okuyabilen bir servis hesabıyla dizinlenmiş belgeler ve sorgu anında hiçbir filtre.
• Bir kez kopyalanan yetkiler. Dizinlendiği gün doğrudur, ilk organizasyon değişikliğinden sonra yanlış.
• Yanıttan sonra filtreleme. Model kısıtlı pasajı zaten okudu; kaynağı gizlemek, yanıtın söylediğini ortadan kaldırmaz.
• Paylaşılan önbellekler. Bir yönetici için önbelleğe alınan yanıt, benzer bir şey soran bir çalışana sunulur.
• Sohbetler ve kayıtlar. Meslektaşların görebildiği sohbet geçmişleri; promptların ve pasajların tutulduğu, belgelerin kendisinden daha fazla kişinin okuyabildiği kayıtlar.
• Fazla paylaşılmış kaynaklar. “Herkese” açık olan ama daha önce kimsenin bulamadığı dosyalar; asistan onları saniyeler içinde bulunur kılar.

Sonuncusu asistanın hatası değildir, ama olay asistanın hanesine yazılır.

Asistan hiçbir zaman yetkilerinizi aşmanın bir yolu olmamalı.

Yetkiler nerede uygulanmalı?

Bilgi erişimi (retrieval) sırasında, model herhangi bir metni görmeden önce. Bu adımın nerede durduğunu iş ekipleri için RAG notu gösteriyor.

1. Erişimi her pasajla birlikte saklayın. Dizinlemede her pasaj, belgesinin kaynak sistemdeki erişim listesini taşır. Kaynak örneğin bir SharePoint sitesi, bir Google Drive klasörü ya da bir doküman yönetim sistemi olabilir.
2. Kullanıcıyı soru anında çözümleyin. Kimlik ve grup üyelikleri, iç içe gruplar dahil, soru sorulduğu anda kimlik sağlayıcınızdan gelir.
3. Aramanın içinde filtreleyin. Yalnızca erişim listesinde kullanıcının ya da gruplarından birinin bulunduğu pasajlar aranır. Sıralamadan sonra uygulanan bir filtre, sonuç sayıları ya da öneriler üzerinden yine bilgi sızdırabilir.
4. Hassas grupları kaynakta yeniden kontrol edin. En hassas belgelerde, son birkaç pasajı modele ulaşmadan önce kaynak sistemin anlık yetkileriyle karşılaştırın. Daha yavaştır ama her zaman günceldir.

İş bittiğinde: erişimi olmayan bir kullanıcı, kısıtlı bir belgenin var olduğuna dair hiçbir ipucu almadan “kaynak bulunamadı” yanıtı alır. Sık yapılan hata: çözümlenmeden bırakılan iç içe gruplar, erişim yetkisi sayılan “bağlantıya sahip olan herkes” paylaşımları ve göz ardı edilen kişisel istisnalar.

Yetkiler kaynak sistemlerle nasıl senkron tutulur?

Senkronizasyon gecikmesi, kaynakta yapılan bir değişiklikle bu değişikliğin yanıtlara yansıması arasındaki süredir. Erişimini dün kaybeden biri belgeyi bugün görmemeli.

• Yalnızca içerik değişikliklerini değil, paylaşım değişikliklerini de senkronize edin. Yalnızca dosyanın içeriği değiştiğinde yeniden dizinleyen bir işlem hattı, paylaşım ayarının değiştiğini hiç fark etmez.
• Kaynağın sunduğu yerlerde değişiklik bildirimlerini kullanın; bildirimlerin kaçırdıklarını yakalamak için de düzenli aralıklarla tam bir karşılaştırma yapın.
• İşten ayrılanları ve görev değiştirenleri ele alın. Bir gruptan çıkarılma bilgisi asistana, dosya sistemine ulaştığı kadar hızlı ulaşmalı.
• Silinen belgeleri dizinden kaldırın; bunu aynı çalıştırmada yapın.
• Her belge grubu için sahibiyle bir azami gecikme süresi belirleyin; hassas gruplarda bu süreyi kısa tutun ve aşıldığında uyarı verin.

İş bittiğinde: kaldırılan bir yetki, anlaşılan süre içinde yanıtları etkilemeyi bırakır; gecikme varsayılmaz, ölçülür. Sık yapılan hata: sessizce başarısız olan ve dizini günlerce geride bırakan senkronizasyon işleri.

Özetler, önbellekler ve kayıtlar nasıl korunur?

İçeriğin her kopyası, aslıyla aynı kurala tabi olmalı.

• Önbellekler kullanıcıya ya da yetki kümesine göre ayrı tutulur ya da kısıtlı gruplarda kapatılır.
• Paylaşılan sohbetler alıcının erişimini yeniden kontrol eder ya da kısıtlı içeriği çıkarır.
• Özetler ve çıkarılan alanlar kaynaklarının en kısıtlayıcı yetkisini devralır. İK vakalarının bir özeti, bütün departmanın okuyabildiği bir klasörde durmamalı.
• Kayıtlar soruyu, pasajları ve yanıtı tutar, çünkü teşhis ve denetim bunlara ihtiyaç duyar (bir yapay zeka denetim kaydının neleri içermesi gerektiğini anlatan not). Ama kayıtlara erişim kısıtlıdır, saklama süresi üzerinde anlaşılmıştır ve kişisel veriler mümkün olan yerde maskelenir.
• Model sağlayıcı tarafı, yani sağlayıcının neyi ne kadar süre sakladığı, sözleşmenin konusudur; sorulacakları verilerinizin nereye gittiğini anlatan not sıralıyor.

İş bittiğinde: içeriğin kopyalandığı her yer, erişim kuralıyla birlikte listelenmiştir. Sık yapılan hata: pilot sırasında açılıp bir daha hiç kapatılmayan bir hata ayıklama kaydı.

Erişim kontrolü nasıl test edilir?

Persona testleriyle: her rol için bir test hesabı ve her birinin neye erişmesi, neye erişmemesi gerektiğini gösteren bir liste.

Temsili bir vakaya bakalım: yöneticilerin açabildiği, diğer çalışanların açamadığı bir İK maaş bantları belgesi. Yönetici personası “kıdemli analist için maaş bandı nedir?” diye sorar ve belgeyi kaynak gösteren bir yanıt alır. Çalışan personası aynı soruyu sorar, ardından farklı biçimlerini dener: “kıdemli analistler ne kadar kazanıyor?”, “salary bands”, “İK politikaları klasörünü özetleyin”. Her seferinde, ilgili bir belgenin var olduğundan hiç söz edilmeden “kaynak bulunamadı” yanıtı alır. Çalışan soruyu yöneticiden hemen sonra sorduğunda da sonuç aynıdır; bu, önbelleğin yanıtı bir kullanıcıdan diğerine taşımadığını kanıtlar. Son olarak yönetici personası yöneticiler grubundan çıkarılır ve anlaşılan senkronizasyon süresi geçtikten sonra yeniden sorar: yanıt yok.

Bu vakalar değerlendirme setine eklenir ve koruma önlemlerimizdeki erişim kurallarına uygun olarak dizinde, senkronizasyonda ya da promptlarda yapılan her değişiklikten sonra çalıştırılır. İş bittiğinde: her rolün, görmesi ve asla görmemesi gerekenlerin listelendiği bir personası vardır ve testlerin hepsi canlıya geçmeden önce geçer.

Tedarikçiye bu konuda ne sormalı?

1. Yetkiler nerede uygulanıyor: aramanın içinde, model içeriği görmeden önce mi?
2. Hangi erişim listeleri okunuyor; gruplar, iç içe gruplar ve bağlantıyla paylaşım dahil mi?
3. Yetki değişiklikleri ve silmeler ne kadar sürede geçerli oluyor ve gecikme nasıl izleniyor?
4. Önbellekler, paylaşılan sohbetler, özetler ve kayıtlar yetkilere uyuyor mu?
5. Tedarikçi tarafında promptları, pasajları ve kayıtları kim okuyabiliyor ve bunlar ne kadar süre saklanıyor?
6. Kendi persona testlerimizi çalıştırıp sonuçlarını görebilir miyiz?

İyi bir yanıt, senkronizasyon gecikmesi için bir sayı ve sizin rollerinizle yapılmış bir gösterimle gelir.

Neden en hassas belge gruplarıyla başlamalı?

Asistanın ulaşabileceği en hassas üç belge grubunu listeleyin ve her birini kimlerin açabileceğini yazın. Bu liste ilk persona testinizdir. Yetkilere uyan bilgi erişimi, veri ve yapay zeka altyapısı çalışmamızın temel parçasıdır; her bilgi ve doküman zekası sistemi de bunun üzerine kurulur.

Kaynaklar

1. LLM08:2025 Vector and Embedding Weaknesses OWASP Gen AI Security Project genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses
2. LLM02:2025 Sensitive Information Disclosure OWASP Gen AI Security Project genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure