Yapay Zeka Ajanına Hangi Yetkiler Verilmeli? En Az Yetki Tasarımı

Ajan yetkilendirmesi neden ayrı bir tasarım konusudur?

Sıradan bir uygulama öngörülebilir kod yollarını izler; kodun yapabileceği şeyler tasarımda bellidir. Yapay zeka ajanı ise hangi aracı hangi sırayla ve hangi parametrelerle çağıracağına çalışma anında karar verir. Aynı girdiye her seferinde aynı yanıtı vermeyebilir, belirsiz bir talebi yanlış yorumlayabilir, okuduğu içerikteki gizli komutlarla yönlendirilebilir.

Bu nedenle ajanın erişebildiği her şey, yanlış bir kararla kullanılabilecek bir yüzeydir. Ajana geniş yetki vermek, modelin hata yapma olasılığını değil, hatanın sonuçlarını büyütür. Güvenliğin dayanağı 'model doğru davranacaktır' varsayımı olamaz; sınır, model ne yaparsa yapsın aşılamayacak bir katmanda uygulanmalıdır.

Bu yaklaşım insan onayından farklı bir sorudur. Onay, bir eylemin yapılıp yapılmayacağına kimin karar verdiğini belirler; yetkilendirme ise ajanın teknik olarak neye erişebildiğini sınırlar. Bunlar birbirini tamamlar: yetkiyle sınırlanmış bir ajan, onay noktasında bile yalnız izin verilen alanda hata yapabilir.

Ajanın kimliği ve erişim katmanları

Ajana kendi kimliğini verin. Bir kullanıcının oturumunu ya da paylaşılan yönetici anahtarını kullanan ajan, kimin ne yaptığını ayırt edilemez kılar ve yetkisini kullanıcıdan miras alır. Ayrı bir servis hesabı, yetkiyi görev tanımına göre belirlemenize ve eylemleri doğrudan ajana atfetmenize olanak verir.

Yetkiyi katmanlarda düşünün. En üstte iş ihtiyacı vardır: ajan hangi görevi yapacak? Onun altında hangi sistemlerle konuşacağı, daha altında her sistemde hangi kaynaklara ve eylemlere erişeceği, en altta ise erişimin hangi veri aralığıyla sınırlandığı gelir. Her katman bir üst katmanın izin verdiğinden fazlasını açmamalıdır.

Kullanıcı adına çalışan ajanlarda yaygın olarak farklı yaklaşımlar görülür. Ya ajan kendi dar yetkisiyle çalışır ve kullanıcının talebini bu yetkinin içinde yerine getirir, ya da kullanıcının yetkisini sınırlı ve geçici olarak temsil eder. İkinci yaklaşımda ajanın yetkisi, hem kullanıcının hem de ajanın kendi izinlerinin kesişimi olmalıdır; ajan kullanıcının sahip olmadığı yetkiyi hiçbir koşulda kullanmamalıdır.

Araç bazlı izin matrisi nasıl hazırlanır?

Ajanın kullanacağı her aracı listeleyin ve her araçtaki eylemleri ayrı satırlara bölün. Her satır için şu soruları yanıtlayın: ajanın bu eyleme gerçekten ihtiyacı var mı, eylem geri alınabilir mi, etkisi tek bir kayıtla mı sınırlı yoksa toplu mu, harici bir tarafa veri çıkarıyor mu?

Eylemleri risk düzeyine göre gruplayın. Salt okuma eylemleri çoğunlukla düşük risklidir, yine de hassas verilere okuma erişimi ayrıca değerlendirilir. Yazma ve güncelleme eylemleri orta risklidir; kayıt sınırı ve doğrulama kuralı gerekir. Silme, toplu değişiklik, ödeme, harici e-posta gönderimi ve izin değiştirme yüksek risklidir: ya ajana hiç verilmez ya da yalnız insan onayıyla birlikte verilir.

Matrisi bir tabloya dökün: ajan, araç, eylem, izin durumu, kısıt ve gerekçe. Tabloyu güvenlik ve iş sahipleriyle gözden geçirin, değişiklikleri sürüm kontrolünde tutun. Yeni bir araç eklenmeden önce matrisin güncellenmesi, yetkinin sessizce genişlemesini önler.

Araç tanımlarını da dar tutun. 'Herhangi bir sorguyu çalıştır' gibi genel bir araç yerine 'şu tabloda bu alana göre ara' gibi amaca özel araçlar tanımlamak, hem modelin kararını kolaylaştırır hem de sınırı araç düzeyinde uygular.

Sınırı nerede uygularsınız?

Sınır istem metninde değil, sistemde uygulanmalıdır. 'Asla veri silme' diye yazılmış bir sistem istemi, modelin yönlendirilmesiyle ya da yanlış yorumlamasıyla aşılabilir. Silme izni hiç verilmemiş bir servis hesabı ise model ne derse desin silme yapamaz.

Sınırları şu noktalarda uygulayın: veritabanı ve uygulama arayüzü düzeyinde hesabın izinleri, araç katmanında parametre doğrulaması ve izin verilen değer aralıkları, ağ düzeyinde ajanın ulaşabileceği adreslerin sınırlanması, yürütme ortamında dosya ve komut kısıtları. Araç katmanı, modelin gönderdiği parametreleri güvenilmez girdi olarak ele almalıdır; çünkü model hatalı ya da yönlendirilmiş parametre üretebilir.

Dolaylı istem enjeksiyonu riskini de yetki tasarımının içine katın. Ajan bir web sayfasını, e-postayı ya da dokümanı okurken içine gizlenmiş komutlarla yönlendirilebilir. Bu durumda yetkinin darlığı en önemli koruma olur: yönlendirilen ajan da yalnız kısıtlı izinleri kullanabilir. Dış içerik okuyan ajana veri gönderme veya harici bir adrese yazma yetkisi birlikte verilmemelidir.

Kısa ömürlü erişim, denetim ve gözden geçirme

Ajanın kullandığı anahtarları ve belirteçleri mümkün olduğunca kısa ömürlü tutun, otomatik olarak yenileyin ve gizli değerleri model bağlamına hiç yazmayın. Anahtar istem metninde ya da araç çıktısında görünürse model onu başka bir yere iletebilir. Gizli değerlerin yalnız araç katmanında kullanılması, modelin onları hiç görmemesini sağlar.

Ajanın her eylemini kaydedin: hangi araç, hangi parametre, hangi hedef, hangi zaman ve hangi talep sonucu. Denetim izi, bir olay sonrasında ne olduğunu anlamayı, hatalı eylemleri geri almayı ve izin matrisini gerçek davranışa göre ayarlamayı sağlar. Anormal kullanım için uyarılar tanımlayın: beklenmedik sayıda silme, alışılmadık bir veri hacmi, yeni bir hedefe yazma.

Yetkileri düzenli gözden geçirin. Kullanılmayan izinleri kaldırın, yeni eklenen araçların etkisini yeniden değerlendirin, ajanın görevi değiştiğinde matrisi güncelleyin. Yetki zamanla genişleme eğilimindedir; düzenli gözden geçirme olmadan en az yetki ilkesi birkaç ay içinde aşınır.

Örnek senaryo: BT destek ajanı

Kurgusal bir kurumda bir BT destek ajanı, çalışanların şifre sıfırlama ve yazılım erişimi taleplerini karşılar. İlk tasarımda ajan, kimlik yönetim sisteminde geniş yönetici yetkisiyle çalışmaktadır. Tasarım gözden geçirilince risk görülür: ajan herhangi bir hesabı değiştirebilir, grup üyeliklerini düzenleyebilir ve kullanıcı bilgilerini dışarı aktarabilir.

Yeni tasarımda ajana ayrı bir servis hesabı verilir. İzin matrisine göre ajan kullanıcı bilgisini yalnız okuyabilir, şifre sıfırlama eylemini yalnız talep sahibinin kendi hesabı için çağırabilir ve belirli bir uygulama grubuna ekleme yapabilir. Yönetici grubuna ekleme, hesap silme ve toplu aktarma izinleri hiç tanımlanmaz. Kullanıcı kimliği, talep eden oturumdan alınır; modelin ürettiği metinden okunmaz.

Erişim anahtarı kısa ömürlüdür ve yalnız araç katmanında bulunur. Ajanın her çağrısı kayıt altına alınır. Test sırasında bir kullanıcı ajanı 'başka bir çalışanın şifresini sıfırla' diyerek yönlendirmeye çalıştığında, araç katmanı talep sahibi ile hedef hesabın eşleşmediğini görüp çağrıyı reddeder. Güvenlik, modelin dürüstlüğüne değil, sistemin izin yapısına dayanmaktadır.

Sık yapılan hatalar

En yaygın hata, ajanı geliştirme sırasında kullanılan geniş yetkilerle üretime almaktır. Deneme sırasında kolaylık sağlayan bu yetkiler, sonradan kimsenin aklına gelmediği için kalıcı olur.

Sınırı yalnızca sistem istemine yazmak, ajanın kullanıcı oturumunu devralmasına izin vermek ve gizli anahtarları model bağlamında bulundurmak da sık görülen hatalardır. Genel amaçlı araçlar vermek, hesap ya da veri kapsamı belirlememek ve denetim kaydı tutmamak sorunu görünmez kılar.

Bir diğer hata, yetki tasarımını yalnız güvenlik ekibinin işi saymaktır. İş sahibi hangi eylemin gerçekten gerekli olduğunu, geliştirici araç katmanını, güvenlik ekibi ise riskleri değerlendirir; bu taraflar birlikte çalışmadığında matris ya gereğinden geniş ya da işi yapamayacak kadar dar kalır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Yapay Zeka Ajanlarıyla Geliştirme Otomasyonu (Agentic Coding) programının araç tasarımı ve yetki sınırları ile insan gözetimi ve güvenlik modülleri, ajanın hangi araçlara hangi sınırlarla erişeceğini tasarlamayı doğrudan ele alır. Python ile Yapay Zekâ Ajanları Geliştirme Eğitimi ise ajanları araçlarla donatma, etik, risk ve sorumluluk ile izleme başlıklarıyla uygulama tarafını tamamlar.

Ajan geliştiren mühendisler ve ajan projelerinin güvenlik ve risk değerlendirmesini yapan ekipler için bu modüller, sınırları istemde değil sistemde kurma alışkanlığını pekiştirir.