LLM Uygulamalarında Yetkilendirme

• Büyük dil modelleri (LLM), insan kullanıcıların belirsiz girdilerini işleyen öngörülemez sistemler olduğu için, en az ayrıcalık ilkesi (least privilege) uygulanması zorunludur
• LLM'ler pratikte dahili arama, otomasyon ve çeşitli işlerde kullanıldıkça, güvenlik olaylarını ve kötüye kullanımı önlemek için yalnızca asgari yetkinin verildiği “etkin izinler (effective permissions)” içinde çalışmaları gerekir
• RAG (retrieval-augmented generation) mimarisinde veri embedding'i ve yetki kontrolleri veri kaynağından ayrılır; bu nedenle kaynak düzeyinde hassas yetki denetimi gerekir
• Harici (3rd party) veri/RAG, Agent, MCP gibi karmaşık kullanım senaryoları arttıkça, yetkilerin gerçekte nerede ve nasıl uygulandığı güvenliğin temel konusu haline geliyor
• OAuth gibi token tabanlı kimlik doğrulama, kaynak bazında ayrıntılı yetki kontrolünde sınırlıdır; bu yüzden gerçek yetkilendirme mantığı uygulama katmanında doğrudan uygulanmalıdır

---

Terimler ve temel kavramlar

• Prompt: LLM'e iletilen kullanıcı isteği (komut, soru vb.)
• RAG (Retrieval-Augmented Generation): LLM yanıtlarının doğruluğunu artırmak için prompt'a ek veri ekleyen iş akışı (ör. şirket izin listesini otomatik eklemek)
• Context: Prompt'a eklenen yardımcı veri (aranan ilgili belgeler vb.)
• Embedding: Metnin sayısallaştırılmış vektör temsili; veri arama/eşleştirmede kullanılır
• Agent: Prompt'a göre aksiyon gerçekleştiren LLM tabanlı yürütme motoru (araçların otomatik çağrılması vb.)
• Tool: LLM'in doğrudan çağırabildiği API/uygulama gibi harici işlevler
• Model Context Protocol (MCP): Anthropic'in önerdiği, LLM'in araç erişimi için standart protokol

LLM yetki modelinin temel ilkeleri

• Golden Rule:

  LLM, kullanıcının isteğini işlemek için kesinlikle gerekli olan en az yetkiyle çalışmalıdır

• İnsan kullanıcılarda "alışkanlığa bağlı fazla yetki" bir ölçüde tolere edilebilir; ancak LLM'ler öngörülemez, hızlıdır ve hata durumunda büyük çaplı zarara yol açabilir.
  → Bu nedenle LLM'in “etkin izinleri (effective permissions)”, kullanıcı, LLM ve görev izinlerinin kesişimiyle sınırlandırılmalıdır

Etkin izinlerin (effective permissions) hesaplanması

• LLM uygulamasının etkin izinleri =
  1. LLM'in sahip olduğu izinler
  2. Kullanıcının sahip olduğu izinler
  3. İstenen görev için gerekli izinler
     Bu üçünün kesişimi
• Kullanıcı, kendi rolünü LLM'e (chatbot vb.) “devreder (impersonation)”;
  ancak bu süreçte ne LLM'in ne de kullanıcının sahip olduğu yetki sınırları aşılmamalıdır
• Yetki Venn diyagramı ile sezgisel olarak açıklanabilir
  • Yalnızca görev izinleri kesişim kümesine tamamen dahil olduğunda çalıştırmaya izin verilir

RAG (retrieval-augmented generation) ve yetki yönetimi

1. 1st Party (kurum içi) veri RAG'i

• Örnek: Dahili bir chatbot'un kurum içi kaynak kodunda “gizli anahtar içeren dosyaları” bulması
• Embedding: Tüm dosyalar vektöre dönüştürülerek veritabanına kaydedilir, prompt da vektöre dönüştürülür ve benzerlik tabanlı eşleştirme yapılır
• Yetkinin uygulandığı yer:
  • Arama sonucu dönen “dosya”nın gerçek sahibi olan organizasyon, tür, repository ve kullanıcı yetkileri anında doğrulanır
  • Kullanıcının ilgili dosyaya erişip erişemediği kontrol edilir (kaynak düzeyi yetki)
  • Embedding → kaynak veri bağlantısı kurulurken uygulama katmanında yetki kontrolü yapılır
• Yetki mantığını doğrudan LLM'in içine koymak güvenilir değildir (olasılıksal yapısı nedeniyle garanti edilemez)
• Özet:
  • RAG'in özü, embedding ile özgün veriyi ilişkilendirdikten sonra kullanıcı bazlı/kaynak bazlı yetkileri güçlü biçimde uygulamaktır

2. 3rd Party (harici) veri RAG'i

• Harici API'ler/sistemler (ör. wiki, ticket sistemi vb.) üzerindeki veriler embedding'e dönüştürülerek kullanılır
• Sorun: Embedding ile özgün veri farklı sistemlerde bulunur → yetkinin nerede uygulanacağı belirsizleşir
• Yetki yönetimi için üç yöntem
  1. Yetkiyi harici sisteme devretmek (her API isteğinde gerçek yetkiyi doğrulamak; yavaş yanıt ve rate limit sorunları)
  2. ACL'yi (erişim kontrol listesi) uygulamaya senkronize etmek (doğruluk/güvenilirlik yüksek, ancak ACL yönetimi ve senkronizasyon maliyeti artar)
  3. Harici yetkilendirme mantığını içeride yeniden uygulamak (yönetim/senkronizasyon yükü ve mantıksal karmaşıklık artar)
• Sonuç: Gerçek senaryoya göre “yetkinin uygulandığı yer” ve yöntemi arasındaki trade-off kritik önem taşır
  (performans-sadelik, yönetim maliyeti-hassasiyet vb. arasında seçim gerekir)

Agent tabanlı LLM'ler (AI Agent) ve yetkiler

• Örnek: Bir chatbot'un repository branch silme, issue kapatma gibi otomatik bakım işleri yapması
• MCP (Model Context Protocol) ile araçlar (fonksiyon/API'ler) LLM'e standart bir biçimde sunulur
• MCP'deki her isteğe etkin izin modeli uygulanmalıdır
  (kullanıcı/agent/görev izinlerinin kesişimi)
• OAuth gibi token tabanlı kimlik doğrulamanın sınırları
  • Yetki bilgisi token içinde bulunabilir, ancak gerçek zamanlı varlık/kaynak düzeyindeki yetkileri kapsayamaz
  • Pratikte token'a yalnızca bazı bilgiler konur; geri kalanı için uygulama katmanında ayrıca yetkilendirme mantığı uygulanması gerekir

Sonuç ve pratik özet

• LLM/RAG/Agent ortamlarında yetki yönetiminin özü, “yetkinin nerede ve nasıl uygulanacağına” karar vermektir

• Etkin izin modeli ile LLM'in yalnızca “kullanıcı + LLM + görev” kesişimi içinde çalışması sınırlandırılır

• OAuth gibi kimlik doğrulama token'ları yalnızca “isteği kimin yaptığı”nı belirlemek için kullanılmalı,
  gerçek kaynak bazlı yetki doğrulaması mutlaka uygulama içinde yapılmalıdır

• Harici sistem entegrasyonunda,
  1) yetkiyi devretme (performans kaybı), 2) ACL senkronizasyonu (operasyonel karmaşıklık), 3) yetkilendirme mantığını yeniden uygulama (yüksek bakım maliyeti)
  gibi çeşitli trade-off'lar dikkate alınarak tasarım yapılmalıdır

• Nihai özet:

  LLM, kullanıcı isteğini işlemek için kesinlikle gerekli olan en az yetki içinde çalışmalı;
  etkin izinler (effective permissions), LLM izinleri, kullanıcı izinleri ve görev izinlerinin kesişimi olarak tanımlanmalıdır
  gerçek yetki doğrulaması ise kaynak bazında, mutlaka uygulama katmanında yapılmalıdır