Kimlik doğrulama kim olduğunuzu kontrol eder; yetkilendirme ise neler yapabileceğinize karar verir. Giderek artan sayıda yapay zeka destekli uygulama, kullanıcının kimliğini oturum açarken bir kez doğrular ve ardından oturumun geri kalanında alttaki ajanın herhangi bir kaynak üzerinde işlem yapmasına izin vererek ona fiilen bir "açık çek" sunar. Bu tasarım; kazara veri sızıntılarına, istenmeyen e-postalara ve hatta yıkıcı veritabanı güncellemelerine kapı aralar; risk, bir yapay zeka asistanının milisaniye gecikmeyle birden fazla aracı çağırabildiği her an artar.
Bu hata neden sürekli tekrarlanıyor
Çoğu yapay zeka geliştiricisi, giriş ekranını tek güvenlik kapısı olarak görür. Kod bir şifre veya token ister, oturumu "doğrulanmış" olarak işaretler ve ardından sonraki tüm isteklerin güvenli olduğunu varsayar. Geleneksel bir web uygulamasında, insan kullanıcının yavaş tıklamaları doğal bir yavaşlatma noktası sağlar; bir insan "sil" butonuna basmadan önce duraksar. Ancak bir yapay zeka ajanı, saniyeler içinde düzinelerce araç çağrısı gerçekleştirebilir. Eğer platform sadece "Kullanıcı giriş yaptı mı?" diye soruyorsa, her çağrı aynı kısıtlanmamış yetkiyi devralır.
Kök neden kolaylıktır. Ekipler, kodun birden fazla token veya kapsam (scope) yönetmek zorunda kalmaması için genellikle tüm uygulama için tek bir uzun ömürlü servis hesabı tanımlar. Bu hesap tipik olarak tüm projeler genelinde geniş izinlere (okuma, yazma, silme) sahiptir. Bir yapay zeka asistanı bu oturum içinde çalıştığında, mevcut görevin bunu gerçekten gerektirip gerektirmediğine bakılmaksızın bu hakları otomatik olarak devralır.
Riskler nelerdir
- Veri ifşası – Kullanıcı giriş yaptıktan sonra herhangi bir dosyayı okuyabilen bir ajan, gizli belgeleri yanlışlıkla daha sonra kuruluş dışında paylaşılan bir yanıta dahil edebilir.
- İstenmeyen eylemler – Bir destek mühendisinin yapay zeka yardımcısı, sorgu üzerinde çalışılan biletle ilgili olmasa bile, sadece mühendisin oturumu hala aktif olduğu için üretim veritabanlarına karşı ham bir SQL sorgusu yürütebilir.
- Mevzuata uyum – Birçok veri koruma kuralı, erişimin yalnızca gerekli olan minimum düzeyle sınırlandırılmasını gerektirir. Genel bir izin modeli bu ilkelere aykırı düşebilir, denetimlere veya para cezalarına yol açabilir.
- Operasyonel maliyet – Kayıtları silen veya değiştiren hatalar, ekipleri değişiklikleri geri almaya, kök nedenleri araştırmaya ve kullanıcılarla güveni yeniden inşa etmeye zorlar; bunların tümü zaman ve para kaybına neden olur.
Eksik adım: eylem başına yetkilendirme
Yetkilendirme, sadece giriş kapısında değil, sistemin içindeki her "kapıda" değerlendirilmelidir. Soru, "Bu kim?"den, "Bu belirli kaynak üzerindeki bu belirli eylem şu anda gerçekleşebilir mi?"ye dönüşür. Bu kontrolü uygulamak tam bir yeniden tasarım gerektirmez; yalnızca tek bir oturum bayrağından (flag), kısa ömürlü ve kapsamlı (scoped) tokenlara geçiş yapılmasını gerektirir.
Uygulamada nasıl çalışır
- Belirli bir kapsamla token talep edin – Yapay zeka ajanının bir aracı çağırması gerektiğinde, önce tam olarak gereken izinleri listeleyen bir token alır (örneğin,
read:ticket,execute:sql_query). - Her çağrı için token'ı doğrulayın – Araç çalışmadan önce servis, token'ın gerekli kapsamı içerdiğini ve token'ın süresinin dolmadığını kontrol eder.
- Kaynağı kapsamla eşleştirin – İstek belirli bir projeyi veya veritabanını hedefliyorsa, token bu tanımlayıcıya erişimi açıkça sağlamalıdır.
- Reddet veya izin ver – Herhangi bir kontrol başarısız olursa çağrı reddedilir ve ajan, kullanıcıya iletebileceği bir hata alır.
Kod farkı oldukça basittir. "Kötü" bir yaklaşım şuna benzeyebilir:
if session.is_authenticated():
tool.run(params)
"İyi" bir yaklaşım kontrolü genişletir:
token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
tool.run(params)
else:
raise PermissionError
İkinci desen birkaç satır ekler ancak sistemin her işlem için doğru soruyu sormasını sağlar.
İşlemleri kolaylaştıran standartlar
OAuth 2.0 kapsamları (scopes), bir token'ın neler yapabileceğini sınırlamak için halihazırda yaygın olarak benimsenmiş bir yol sunar. Geliştiriciler, project:1234:write veya email:send gibi kapsamları kodlayan kısa ömürlü erişim tokenları yayınlayarak, doğrulama adımını gerçekleştirmek için mevcut kütüphanelere güvenebilirler.
Yeni Rich Authorization Requests (RFC 9396), bu fikri genişleterek istemcinin statik bir listeyi önceden tanımlamak yerine çalışma zamanında ayrıntılı izinler talep etmesine olanak tanır. Bu esneklik, bir yapay zeka iş akışının kullanıcı niyetine bağlı olarak yetenekleri anlık olarak eklemesi veya çıkarması gerektiğinde yararlıdır.
Karşı argüman: Basitlik ile güvenlik karşı karşıya
Bazı ekipler, özellikle yapay zeka asistanının çok sayıda aracı hızlı bir şekilde ardı ardına çağırması gerektiğinde, işlem başına yapılan kontrollerin gecikmeye ve kod karmaşıklığına neden olduğunu savunuyor. Tek bir oturum jetonunun (session token), her çağrı için yeni bir jeton getirme ve doğrulama yükünden kaçındığını belirtiyorlar. Ancak bunun karşılığında, kötüye kullanıma karşı çok daha yüksek bir risk oluşmaktadır. Modern jeton doğrulama servisleri mikrosaniyeler içinde çalışacak şekilde tasarlanmıştır ve ek ağ gidiş-dönüş süresi (round-trip), en az ayrıcalık ilkesinden ödün vermeden toplu halde işlenebilir veya önbelleğe alınabilir. Veri bütünlüğü ve uyumluluğun tartışmaya kapalı olduğu ortamlarda, düşük performans maliyeti, riskin azalmasıyla telafi edilmektedir.
Sırada nelere dikkat edilmeli
- AI SDK'larında kapsamlı (scoped) jetonların benimsenmesi – Büyük yapay zeka platformu araç kitlerindeki güncellemeleri takip edin; birçoğu OAuth tabanlı kapsamlar için yardımcı fonksiyonlar sunmaya başlıyor.
- Kod olarak politika (Policy-as-code) çerçeveleri – Gelişmekte olan çözümler, ekiplerin yetkilendirme kurallarını bildirimsel (declarative) bir dosyada tanımlamasına ve bunları çalışma zamanında otomatik olarak uygulamasına olanak tanıyor.
- İşlem başına kararları gün yüzüne çıkaran denetim günlükleri – Daha fazla platform her yetkilendirme kontrolünü kaydettikçe, kuruluşlar hangi yapay zeka eylemlerine izin verildiğini veya hangilerinin engellendiğini görerek gelecekteki politika düzenlemeleri için veri elde edecekler.
Özet
Oturum açılmış bir oturumu her şeyi yapma izni olarak kabul etmek, istenmeyen sonuçlara yol açacak bir yöntemdir. Yetkilendirme kararını oturum açma anından her bir araç çağrısına taşıyarak ve kısa ömürlü, kapsamlı jetonlardan yararlanarak, yapay zeka uygulamaları verileri korurken, düzenlemelere uyum sağlarken ve maliyetli hatalardan kaçınırken otonom ajanların kolaylığını koruyabilir. Ekstra kod satırları, her işlem denemesinde doğru soruyu soran bir sistem için küçük bir bedeldir.