Paylaşılan ajanın yetkisini soran kişiye göre daralt

Şirketin ortak asistanı ekip kanalında. BT ekibi onu kurarken bir hizmet hesabına bağlamış ve hesaba bütün şirket klasörlerini okuma yetkisi vermiş, asistan her soruya cevap bulabilsin diye. Pazarlamaya yeni katılan Deniz kanala yazıyor: ekibin ücret bantlarını kıdeme göre özetler misin? Asistan aramayı kendi hesabıyla yapıyor, İK'nın ücret tablosunu buluyor ve özetliyor. Deniz'in o dosyayı açma yetkisi yok. Cevap kanalda ve kanaldaki herkes okuyor.

Kimse bir güvenlik açığı kullanmadı, kimse bir kuralı çiğnemedi. Dosyanın izinleri doğru, kanalın izinleri doğru. Sızıntı ikisini birleştiren ajanda. Ajan iki ayrı kaynaktan gelen yetkiyle çalışıyor: kendi hesabının geniş yetkisi ve sorunun sahibinin isteği. Hangi işi hangi yetkiyle yaptığını ayırmıyor. Soran kişi, ajanın elindeki geniş yetkiyi bir cümleyle ödünç almış oluyor.

Zarar ajanın açıldığı kişi sayısıyla büyüyor. Ortak ajan ne kadar çok kişiye cevap verirse en geniş yetkili hesabın gördüğü o kadar çok kişiye ulaşıyor. Hedef sistemin kaydında her okuma ajanın hesabına yazılıyor. Dosyayı aslında kimin istediği o kayıttan bulunmuyor.

Ortak ajanın cevabı, soran kişinin kendi başına açabileceğinden fazlasını içermemeli.

Geniş tek bir hesap kurulumu kolaylaştırır. Ajan ilk günden her şeyi bilir, kimseye ayrıca oturum açtırmak gerekmez, demo parlak geçer. Microsoft'un Copilot Studio belgesi bu kolaylığın bedelini açıkça yazıyor. Ajanı kuran kişi bir aracı kendi kimlik bilgisiyle bağladığında ajanı kullanan herkes o kimlikle çalışıyor ve son kullanıcı yalnız kurucunun hesabının yapabileceği şeyleri yapabiliyor¹. Aynı belgeye göre kurucunun kimlik bilgisiyle bağlama seçeneği varsayılan olarak açık.

İkinci neden modele duyulan güven. Ekip sistem promptuna “İK verisini paylaşma” yazar ve işi bitmiş sayar. Model soranın neyi görebileceğini bilmez. Bildiğini sansa bile bir talimat izin denetimi değildir. OWASP'ın LLM uygulamaları listesi bir eylemin yapılıp yapılamayacağına modelin karar vermesine güvenmek yerine yetkilendirmeyi hedef sistemlerde uygulamayı² öneriyor. Aynı liste aşırı yetkiyi örnekle anlatıyor: tek bir kullanıcının belgelerini okuması gereken bir eklenti, bütün kullanıcıların dosyalarına erişen ayrıcalıklı bir hesapla bağlanıyor.

Üçüncü neden testte. Ajanı deneyenler çoğu zaman geniş yetkili kişiler: kurucu, yönetici, BT ekibi. Onların sorusuna verilen cevap zaten görebildikleri belgelerden gelir, sızıntı testte hiç görünmez. Cevap kalitesi ölçüldüğünde de geniş erişim ödüllendirilir, çünkü daha çok belge daha dolu bir cevap demek.

Ortak ajan her soruyu soranın kimliğiyle cevaplar. Ajanın kendi yetkisi bir tavandır, gerçek sınırı soranın yetkisi çizer.

1. Aramayı soranın kimliğiyle yap. Ajan veriye kendi geniş hesabıyla değil, soran kişiyi temsil eden bir jetonla ulaşır ve izinleri hedef sistem uygular. Arada bir sunucu varsa eline gelen jetonu arkasındaki sisteme olduğu gibi taşımaz. MCP belirtimi bunu kural yapıyor: sunucu, istemciden aldığı jetonu arkasındaki API'ye olduğu gibi iletmemeli³, o API için ayrı bir jeton almalı.
2. Süzmeyi kodda yap. Soranın erişemediği belge modele hiç girmez. Süzme arama sonucunda, özetlemeden ve önbellekten önce, erişim listesiyle yapılır.
3. Görmediğinin varlığını da söyleme. Soranın açamadığı belgenin adı, sahibi ve sayısı cevapta geçmez. “Erişebildiğin belgelerde bulamadım” yeter. Yol göstermek gerekiyorsa belgeyi değil, soruyu kime soracağını söyle.
4. Cevabın kime göründüğüne bak. Soranın yetkisiyle üretilen cevap ortak kanala yazılınca kanaldaki herkes soranın gördüğünü görür. Cevabı önce yalnız sorana göster, kanala taşımayı ona bırak. Ajan kanalda kendiliğinden cevap veriyorsa kanaldaki herkesin erişebildiği kaynaklarla yetin.
5. Kimsenin sormadığı işe de bir kimlik ver. Zamanlanmış özetler ve otomatik raporlar adı konmuş, dar yetkili ayrı bir hesapla çalışır. Çıktı, onu alacak kişilerin en dar yetkisine göre sınırlanır.
6. Kayda iki adı yaz. Hedef sistemin kaydında hem ajan hem soran durur. Microsoft Entra'nın ajan kimliklerinde kullanıcı adına alınan jetonun öznesi kullanıcı, eylemi yapan ise ajan⁴. Bir sızıntı şüphesinde kimin neyi sorduğu kayıttan bulunur.

Aynı soru İK yöneticisinden gelince ücret tablosuyla, yeni çalışandan gelince İK'ya yönlendirmeyle cevaplanır.

Aynı soru, aynı kanal. Soldaki asistan aramayı kendi hesabıyla yapıyor, İK dosyasını özetliyor ve cevabı herkesin önüne koyuyor. Sağdaki aramayı Deniz'in yetkisiyle yapıyor, göremediği dosyanın varlığını bile söylemiyor ve cevabı önce yalnız ona gösteriyor.

Microsoft 365 Copilot kurum verisinden yalnız kullanıcının en az görüntüleme izni olduğu içeriği⁵ getiriyor. Aynı belge bu sınırın altta yatan izinlere dayandığını da söylüyor ve kurumlara, doğru kişilerin doğru içeriğe erişmesi için Microsoft 365'in izin modellerini kullanmanın önemini hatırlatıyor.

Slack'in mühendislik ekibi Slack AI'ın temel ilkesini soran kullanıcının görebildiği veriyle sınırlı kalmak⁶ diye yazıyor. Arama ve özet, soranın erişim listesiyle yapılıyor, AI araması standart aramanın göstermeyeceği bir sonucu göstermiyor. Aynı yazıya göre üretilen cevabı yalnız Slack AI'ı çağıran kullanıcı görüyor. Bu, desenin dördüncü kuralı.

Copilot Studio ters yönden örnek. Ajanı kuran kişi bir aracı kendi kimlik bilgisiyle bağlayabiliyor ve belge bunun aşırı paylaşıma yol açabileceğini yazıyor. Yöneticiler bu seçeneği kapatıp yalnız son kullanıcının kimlik bilgisine izin verebiliyor. Bedeli de belgede: kapatılınca zamanlanmış ya da arka planda çalışan ajanlar eksik kimlik bilgisi yüzünden çalışmıyor¹.

Norm Hardy 1988'de Tymshare'de yaşanan bir olayı anlattı (kendi deyişiyle ayrıntıları değiştirilmiş, neredeyse gerçek bir hikâye). Bir derleyiciye istatistik dosyasını yazabilsin diye kendi dizinine yazma yetkisi verilmişti. Fatura kayıtları da aynı dizindeydi. Bir kullanıcı, hata ayıklama çıktısının yazılacağı dosya olarak fatura dosyasının adını verdi. İşletim sistemi derleyicinin yetkisine baktı, yazmaya izin verdi ve fatura kayıtları kayboldu⁷. Hardy'ye göre temel sorun derleyicinin iki ayrı kaynaktan gelen yetkiyle çalışması ve bunları ayıramamasıydı. Bu yüzden ona “şaşkın vekil” (confused deputy) adını verdi.

Ortak ajan aynı vekil. Kendi hesabının yetkisini taşıyor, işi ise soran kişiden alıyor. Copilot Studio'nun belgesi riski bugünkü ürün diliyle tekrarlıyor: kurucunun kimlik bilgisiyle çalışan ajan aşırı paylaşıma yol açabilir. OWASP aynı durumu aşırı yetki başlığı altında sayıyor ve kullanıcı adına yapılan işlerin hedef sistemde o kullanıcının bağlamında ve en az yetkiyle² yürütülmesini öneriyor.

Bu desen için bir olay kaydı ya da sızıntının ne sıklıkla yaşandığını gösteren bir ölçüm bulamadık. Dayanak, sorunun güvenlik literatüründe adıyla tanınması, satıcı belgelerinin riski kendi ürünlerinde yazması ve varsayılan kurulumların onu kendiliğinden kapatmaması.

• Ajan hesabıyla yapılan okuma. Hedef sistem kayıtlarında soranın kimliği olmadan, yalnız ajanın hesabıyla yapılan okumaların payı. Bilinçli tanımlanmış zamanlanmış işler dışında hedef sıfır.
• Yetki farkı testi. Aynı soruyu geniş ve dar yetkili iki test hesabıyla sor. Dar hesabın cevabında geniş hesabın gördüğü belgenin içeriği, adı ya da varlığı geçmemeli. Testi her sürümde otomatik çalıştır.
• Varlık sızıntısı. Cevaplardan bir örneklem al, soranın erişmediği belge adlarını, sahiplerini ya da sayılarını ara. Hedef sıfır.
• Kanala düşen cevap. Ortak kanala yazılan cevapların kaçı kanaldaki herkesin erişemediği bir kaynağa dayanıyor? Hedef sıfır.
• Erişim isteği. “Erişebildiğin belgelerde bulamadım” cevaplarından sonra açılan erişim istekleri. Çok sıksa izin modeli işi gereksiz yere zorlaştırıyor demektir.

Üç metin var. Denetim promptu ajanın her veri bağlantısının hangi kimlikle çalıştığını, soranın kimliğinin hedef sisteme ulaşıp ulaşmadığını, süzmenin nerede yapıldığını ve cevabın kime göründüğünü raporlar, hiçbir dosyayı değiştirmez. Uygulama promptu deseni koda geçirir. Önce planı gösterir, onayınla araç bağlantılarını soranın kimliğine taşır, süzmeyi modelden önceye alır ve geniş ile dar yetkili iki test kullanıcısıyla çalışan bir test ekler. Kural kodlama ajanının kendi çalışması için: senin için bir entegrasyon yazarken geniş bir hizmet hesabını varsayılan yapmasın.

Bu depoda birden çok kişinin kullandığı bir AI ajanı var: ekip kanalındaki bir asistan, şirket içi arama, ortak bir destek ya da raporlama ajanı. Görevin, ajanın veriye kimin yetkisiyle ulaştığını ve cevabın soran kişinin göremeyeceği bir şey içerip içermediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz. Bulduğun gizli değerleri ve kişisel verileri rapora yazma.

1. Ajanın veri okuduğu ve eylem yaptığı her bağlantıyı bul: belge arama, veritabanı sorguları, e-posta ve takvim, dosya depoları, dış API'ler, MCP sunucuları ve araç tanımları.
2. Her bağlantı hangi kimlikle çalışıyor: bir hizmet hesabıyla mı, ajanı kuran kişinin hesabıyla mı, soran kişinin kendi oturumuyla mı (kullanıcı adına alınmış jeton, OAuth)? Hizmet hesabının yetkisi ne kadar geniş?
3. Soran kişinin kimliği istekten araca kadar taşınıyor mu? Araç çağrısı soranın kimliğini hedef sisteme iletiyor mu, yoksa izin kontrolü yalnız uygulama içinde, modelin ya da promptun kararına mı bırakılmış?
4. Arama sonuçları modele girmeden önce soranın erişim listesine göre süzülüyor mu? Süzme vektör aramadan, özet üretiminden ve önbellekten önce mi yapılıyor?
5. Cevap soranın açamadığı belgelerin adını, sahibini, sayısını ya da varlığını söylüyor mu?
6. Cevap nereye yazılıyor: yalnız sorana mı, ortak bir kanala mı? Ortak kanala yazılan cevap kanaldaki herkesin erişebildiği kaynaklarla sınırlı mı?
7. Zamanlanmış ve kimsenin sormadığı işler hangi kimlikle çalışıyor, çıktıları kimlere gidiyor?
8. Hedef sistemlerin kayıtlarında soran kişi görünüyor mu, yoksa her erişim ajanın hesabına mı yazılıyor?

Rapor biçimi: her bağlantı için bir satır: dosya ve satır, kullandığı kimlik, yetkisinin genişliği, soranın kimliğinin taşınıp taşınmadığı, süzmenin nerede yapıldığı, cevabın kime göründüğü. Soranın göremeyeceği verinin cevaba girebildiği yollardan başla ve her biri için bir sızıntı senaryosu yaz (örnek: yeni çalışan ortak kanalda ücret bantlarını soruyor, ajan İK dosyasını kendi hesabıyla okuyup özetliyor).

Bu depodaki ortak AI ajanına "paylaşılan ajanın yetkisini soran kişiye göre daralt" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Ajan her aramayı ve eylemi soran kişinin kimliğiyle yapar: kullanıcı adına alınmış bir jetonla ya da soranın kendi oturumuyla. İzinleri hedef sistem uygular, ajanın kendi hesabı yalnız bir tavan olarak kalır.
2. Arama sonuçları modele girmeden önce soranın erişim listesine göre süzülür. Süzme kod katmanında yapılır, prompttaki bir talimata bırakılmaz.
3. Soranın açamadığı belgenin adı, sahibi, sayısı ve varlığı cevapta geçmez. Ajan "erişebildiğin belgelerde bulamadım" der ve soruyu kime sorabileceğini söyler.
4. Soranın yetkisiyle üretilen cevap önce yalnız sorana gösterilir, ortak kanala taşımak soranın kararıdır. Ajan kanalda kendiliğinden cevap verecekse cevabı kanaldaki herkesin erişebildiği kaynaklarla sınırlar.
5. Kimsenin sormadığı işler (zamanlanmış özet, otomatik rapor) adı konmuş, dar yetkili ayrı bir hesapla çalışır. Çıktı, onu alacak kişilerin en dar yetkisine göre sınırlanır.
6. Hedef sistem kayıtlarında her erişim hem ajanı hem soran kişiyi taşır.

Uygularken:
- Kurulumu yapan kişinin ya da geniş bir hizmet hesabının kimlik bilgisiyle çalışan araç bağlantılarını listele ve tek tek soranın kimliğine taşı. Taşınamayanları raporla.
- Gelen jetonu aşağıdaki sisteme olduğu gibi iletme. Her hedef sistem için o sisteme verilmiş, soranı temsil eden ayrı bir jeton al.
- Testler ekle: (a) geniş ve dar yetkili iki test kullanıcısıyla aynı soruyu sor, dar kullanıcının cevabında geniş kullanıcının gördüğü belgenin içeriği, adı ya da varlığı geçmesin. (b) ortak kanalda istenen cevap kanala yazılmadan önce yalnız sorana görünsün. (c) soranın kimliği eksik bir araç çağrısı hata versin, ajanın hesabına düşmesin.

## Paylaşılan ajanın yetkisini soran kişiye göre daralt
- Ortak bir ajanın veri okuyan ya da eylem yapan her aracını soran kişinin kimliğiyle çalıştır. Geniş bir hizmet hesabını ya da kurulumu yapan kişinin hesabını varsayılan yapma.
- İzin kontrolünü modele ya da prompta bırakma. Sonuçları modele vermeden önce kodda süz.
- Soranın erişemediği belgenin adını, sahibini ya da varlığını cevaba yazma.
- Ortak kanala yazılan cevabı kanaldaki herkesin erişebildiği kaynaklarla sınırla ya da cevabı önce yalnız sorana göster.
- Hedef sistemin kaydına hem ajanı hem soran kişiyi yaz.

Ajan yalnız senin hesabınla, yalnız senin için çalışıyorsa soran ile sahip aynı kişi. Herkese açık belgeleri okuyan bir yardım botu için de bu desen gerekmez.

Desen aşırı paylaşımı düzeltmez. Soranın yetkisi zaten fazla genişse, herkese açılmış bir İK klasörü gibi, ajan da onu gösterir. Microsoft'un belgesinin izin modellerini vurgulaması bu yüzden. Desen ajanın yetkisini soranınkine indirir, soranınkini denetlemez.

Desen talimat enjeksiyonunu durdurmaz. Slack AI 2024'te aramayı soranın görebildiği kanallarla yapıyordu. PromptArmor, bir saldırganın herkese açık kanala yazdığı talimatın da bu kapsama girdiğini ve kullanıcının özel kanalındaki anahtarın bir bağlantıya konduğunu⁸ gösterdi. Yetki soranın yetkisiydi, veri yine de dışarı çıktı. Okunan içeriğin talimat sayılmaması ayrı bir desenin işi.

Bedeli var. Her kullanıcı kendi oturumunu açmak zorunda kalır, kimsenin başında olmadığı işler soranın kimliğiyle çalışamaz. Bu işler için adı konmuş, dar yetkili ayrı bir hesap tanımla ve çıktısını alanların en dar yetkisine göre sınırla.