İzni ihtiyaç anında iste

Kullanıcı yeni bir AI asistanı kuruyor. Daha ilk soruyu yazmadan karşısına bir izin ekranı çıkıyor. E-postalarını oku, gönder ve sil. Dosyalarını gör ve düzenle. Takvimini yönet. Kişilerini gör. Altında tek bir düğme var. Kullanıcı asistanın ne iş yapacağını henüz bilmiyor, o yüzden istenenin gerekli olup olmadığını tartamıyor. Onay veriyor, çünkü ürünü kullanmanın başka yolu yok.

Haftalar sonra asistandan toplantılarını öğleden sonraya taşımasını istiyor. AI toplantıları taşıyor ve katılımcılara bir e-posta gönderiyor. Kullanıcı gönderme iznini verdiğini o e-postayı görünce hatırlıyor. Kurulumdaki onay o gün hiçbir işe bağlı değildi. Bugün AI'ın yaptığı bir işin dayanağı olarak çalışıyor.

Geniş izni çoğu kullanıcı geri almaz, çünkü verdiğini hatırlamaz. Sonraki her özellik aynı izin üstüne kurulur ve izin ekranı bir daha hiç görünmez. Kurulumda verilen izinde kullanıcının kararı yok, yalnız tıklaması var.

Her izin ekranı bir terk noktası ve ürün ekipleri terk noktalarını teke indirmek ister. Bütün izinleri kurulumda bir kerede istemek ölçülen huniyi kısaltır, ileride çıkacak her izin sorusunu ortadan kaldırır. MCP'nin güvenlik rehberi bunu yaygın hatalar arasında sayıyor: ileride çıkacak izin sorularının önünü almak için ilgisiz yetkileri paketlemek¹.

AI ürünlerinde buna bir neden daha ekleniyor. Klasik bir uygulama hangi özelliğin hangi izni kullandığını bilir. AI'da hangi aracın çağrılacağına model konuşmanın içinde karar veriyor. Ürün kullanıcının ne isteyeceğini önceden bilmediği için her ihtimale karşı her şeyi istiyor. MCP'nin yetkilendirme belirtimi de istemcilerin kapsam seçmek için gereken alan bilgisinden çoğu zaman yoksun olduğunu kabul ediyor ve sunucu kapsam belirtmezse desteklenen bütün kapsamların istenmesini² yedek yol olarak tarif ediyor. Belirtim aynı yerde sunucudan bu listeyi temel işlevle sınırlı tutmasını, gerisini işin içinde istemesini bekliyor. Yedek yol ise listenin geniş tutulduğu her sunucuda kurulumda her şeyi istemeye dönüşüyor.

Üçüncü neden ölçümde. Kurulumda verilen izin panoda başarı gibi görünür, bağlantı tamamlandı. Kullanıcının neye onay verdiğini anlayıp anlamadığı hiçbir panoda yok. Android'in izinleri kurulumda topluca gösterdiği dönemde yapılan bir çalışmada katılımcıların yalnız %17'si kurulum sırasında izinlere dikkat etti³. Anketi dolduranların %3'ü izinlerle ilgili üç sorunun üçünü doğru cevapladı³. Onay oranı yüksek, anlama oranı düşük.

İzin, onu gerektiren işle birlikte gelir. Kullanıcı neye onay verdiğini o anda yaptığı işten anlar ve reddederse yalnız o iş durur.

1. Başlangıçta en dar kapsam. Giriş ve kurulumda yalnız ürünün çalışması için gereken izin istenir. Google'ın OAuth rehberi de çekirdek işlev için şart değilse ilk girişte veri erişimi istememeyi⁴ öğütlüyor.
2. İzin ilk gerektiği işin içinde. AI bir işe başlarken izin eksikse durur ve izni orada ister. Hangi iş için ve hangi kapsamla istediğini tek cümleyle söyler.
3. Okuma önce, yazma sonra. Okuma izniyle başlayan iş yazma, gönderme ya da silme adımına gelince ayrıca sorar. Gönderme izni, AI bir şey göndermeyi önerdiği anda gündeme gelir.
4. Ret de bir cevap. Kullanıcı reddederse ürün çalışmaya devam eder. O izni gerektiren adım atlanır ve nedeni söylenir. Aynı izin aynı oturumda tekrar tekrar sorulmaz.
5. Yetersiz izin hatası soruya dönüşür. Bir araç izin yetmediği için hata aldığında ajan hatayı yutmaz. Eksik kapsamı hatadan okur, kullanıcıya sorar ve izin gelirse işi bir kez yeniden dener.

Desen izin ekranlarının sayısını artırır, her birini küçültür. Kullanıcı on izni bir kerede okumak yerine her seferinde bir izni, yaptığı işin yanında okur.

Aynı takvim işi, iki ayrı izin akışıyla. Solda kurulum ekranı dört servisin en geniş iznini birlikte istiyor ve AI takvim işi sırasında e-posta da gönderiyor. Sağda AI izni takvim işi başlarken yalnız takvim için istiyor, e-posta iznini ancak bir e-posta önerdiğinde soruyor.

Apple'ın arayüz kılavuzu uygulamalardan izni yalnız veriye ya da kaynağa açıkça ihtiyaç duyduklarında⁵ istemelerini, ideal olarak kullanıcı o izni gerektiren özelliği kullandığında sormalarını istiyor. Açılışta izin istemeyi yalnız uygulama o veri olmadan çalışamıyorsa uygun buluyor.

Android 6.0 ile tehlikeli izinler kurulum ekranından çıktı, uygulama onları çalışırken istiyor. Android'in geliştirici belgesindeki ilk ilke izni bağlamında, kullanıcı o özellikle etkileşime başladığında⁶ istemek. Belge kullanıcı izni reddederse uygulamanın çalışmayı sürdürmesini de istiyor.

Gemini'de kullanıcı @ ile bağlı olmayan bir uygulama seçtiğinde, Google'ın yardım sayfasına göre uygulama ya bağlanıyor ya da Gemini bağlamak için izin istiyor⁷. Bağlantı sorusu kullanıcının o uygulamayı istediği anda geliyor.

Claude'da Team ve Enterprise planlarında yönetici bir bağlayıcıyı kurum için açsa bile, paylaşılan bir kimlik bilgisi kullanılmıyorsa her kullanıcı servise bağlayıcıyı ilk kullandığında⁸ kendisi giriş yapıyor. Kurum aracı açıyor, kişinin kendi hesabına erişim o kişinin ilk kullanımında isteniyor.

Bu desenin en güçlü dayanağı yaygın uygulama. Apple, Android ve Google'ın OAuth rehberi aynı kuralı ayrı ayrı yazıyor, MCP belirtimi de kuralı AI araçlarına taşıyor. MCP'nin yetkilendirme bölümüne göre izin yetmediğinde sunucu insufficient_scope hatasıyla eksik kapsamı bildirmeli ve kullanıcı adına çalışan istemci ek izni o anda istemeli². Güvenlik rehberi de başlangıç kapsamını yalnız düşük riskli keşif ve okuma işlemleriyle¹ sınırlamayı öneriyor.

Kurulumda istenen iznin neden işlemediğini Android'in eski modeli üzerinde yapılan bir çalışma gösteriyor. Felt ve arkadaşları 2012'de 308 kişilik bir anket ve 25 kişilik bir laboratuvar çalışmasıyla kullanıcıların kurulumdaki izin listesine ne kadar dikkat ettiğini ölçtü. İki çalışmada da katılımcıların %17'si³ kurulum sırasında izinlere baktı. Araştırmacılar bu uyarıların çoğu kullanıcının doğru güvenlik kararı vermesine yardım etmediği sonucuna vardı. Android sonraki yıllarda, 6.0 sürümüyle, tehlikeli izinleri çalışma sırasına taşıdı.

Bu ölçüm telefon uygulamalarında ve on dört yıl önce yapıldı. AI ürünlerinde bağlam içi izin ile kurulumdaki toplu izni karşılaştıran yayımlanmış bir ölçüm bulamadık. Yine de mekanizma aynı. İş başlamadan okunan bir izin listesi kullanıcıya karar verebileceği bir bağlam vermiyor.

Onay oranı tek başına yanıltır. Kurulumdaki toplu ekran da yüksek onay alır. Bakılacak yer, verilen iznin ne kadarının gerçekten kullanıldığı ve reddin ürünü nasıl etkilediği.

• Girişteki kapsam sayısı. Yeni bir hesabın girişte verdiği kapsamları say. Hedef, ürünün çalışması için gereken en küçük küme. Yazma ve gönderme kapsamı burada olmamalı.
• Kullanılmayan izin. Verilen her kapsam için ilk kullanım zamanını kaydet. Verilip otuz gün içinde hiç kullanılmayan kapsam yanlış zamanda istenmiş kapsamdır.
• Bağlam içi ret. İşin içinde istenen izinlerin ne kadarı reddediliyor? Sık reddedilen bir izin ya gerekçesi anlatılamayan ya da gereksiz bir izin.
• Retten sonra kalış. Bir izni reddeden kullanıcı ürünü kullanmayı sürdürüyor mu? Sürdürmüyorsa ürün reddi kilitlenme gibi yaşatıyor.
• Sessiz izin hatası. Araçların aldığı yetersiz izin hatalarından kaçı kullanıcıya soruya dönüşüyor, kaçı sessizce düşüyor? Sessiz düşen hata sıfır olmalı.

Üç metin var. Denetim promptu ürünündeki her izin isteğini bulur, istendiği yeri ilk kullanıldığı özellikle karşılaştırır ve yalnız rapor yazar. Uygulama promptu izinleri kurulumdan işin içine taşır. Önce planı gösterir, onayınla uygular ve girişte yazma izni istenmediğini doğrulayan bir test ekler. Kural kodlama ajanının kendi çalışması için. Yeni bir özellik eklerken ajan izni o özelliğin içinde istesin, giriş akışına dokunmasın.

Bu depoda kullanıcı hesaplarına (e-posta, takvim, dosya, kod deposu gibi) bağlanan bir AI ürünü var. Görevin, ürünün izinleri ne zaman ve ne kapsamla istediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Yetkilendirme isteklerini bul: OAuth kapsam (scope) listeleri, MCP sunucularının scopes_supported değerleri, kurulum, giriş ve kayıt akışları, sabit kodlanmış kapsam dizileri.
2. Her kapsam için bak: ilk kez hangi özellik onu kullanıyor? Kapsam o özellik ilk çalıştığında mı, yoksa girişte ya da kurulumda mı isteniyor?
3. Girişte istenen ama ilk oturumda hiç kullanılmayan kapsamları listele. Okuma yetecekken yazma, gönderme ya da silme içeren geniş bir kapsam isteniyor mu?
4. Yetersiz izin durumunu ara: bir araç 403, insufficient_scope ya da benzeri bir hata aldığında ürün ne yapıyor? Kullanıcıya bağlamıyla yeni izin soruluyor mu, yoksa iş sessizce mi düşüyor?
5. Kullanıcı bir izni reddettiğinde ürün çalışmaya devam ediyor mu? Reddedilen izin, onu gerektiren işe gelindiğinde gerekçesiyle yeniden soruluyor mu?
6. İzin ekranındaki metni oku: hangi iş için istendiğini söylüyor mu, servisin teknik kapsam adı yerine kullanıcının anlayacağı eylemi mi yazıyor?

Rapor biçimi: her kapsam için istendiği yer (dosya ve satır), onu ilk kullanan özellik, ikisi arasındaki fark ve önerdiğin değişiklik. Yazma, gönderme ve silme kapsamlarından başla.

Bu üründe "izni ihtiyaç anında iste" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Girişte ve kurulumda yalnız ürünün çalışması için gereken en dar kapsamı iste. Geri kalan her kapsamı onu ilk kullanan özelliğe taşı.
2. AI bir işe başlarken gereken izin yoksa işi durdur, kullanıcıya hangi iş için hangi izni istediğini tek cümleyle söyle ve izni o anda iste.
3. Yazma, gönderme ve silme izinlerini okuma izninden ayrı ve ancak ilk gerektiklerinde iste.
4. Bir araç yetersiz izin hatası aldığında (403, insufficient_scope) hatayı yutma. Eksik kapsamı hatadan oku, kullanıcıya bağlamıyla sor, izin gelirse işi bir kez yeniden dene.
5. Kullanıcı reddederse ürün çalışmaya devam etsin ve o izni gerektiren adım "bunun için şu izin gerekiyor" desin. Reddedilen izni aynı oturumda tekrar tekrar sorma.

Uygularken:
- Kapsam listesini tek bir yerde tut ve her kapsamın yanına onu kullanan özelliği yaz.
- İzin isteğinde kullanıcının anlayacağı eylemi yaz: "gmail.readonly" yerine "e-postalarını okuyabilir, gönderemez".
- Var olan kullanıcıların verdiği izinleri geri alma, yalnız yeni akışı değiştir.
- Bir test ekle: yeni bir hesapla giriş yap, girişte istenen kapsamları al ve yazma ya da gönderme kapsamı içermediğini doğrula. Sonra o kapsamı gerektiren özelliği çalıştır ve iznin o anda istendiğini doğrula.

## İzni ihtiyaç anında iste
- Yeni bir özellik için kapsam eklerken onu giriş ya da kurulum akışına ekleme. Özellik ilk çalıştığında iste.
- Her kapsam için en dar seçeneği kullan. Okuma yetiyorsa yazma ya da gönderme isteme.
- Yetersiz izin hatasını yutma. Eksik kapsamı, hangi iş için gerektiğini söyleyerek kullanıcıya sor.
- İzin metnini kullanıcının anlayacağı eylemle yaz, servisin kapsam adıyla yazma.
- Reddedilen izinde ürünü kilitleme. O izni gerektiren adımı atla ve nedenini söyle.

Ürünün tek işi bir veriye dayanıyorsa izni baştan istemek doğru. Navigasyon uygulaması konumsuz çalışmaz, Apple'ın kılavuzu da bu durumda açılışta istemeyi uygun buluyor. Yalnız e-posta özetleyen bir AI için e-posta okuma izni de böyle.

Her adımda yeni bir izin sorusu başka bir yorgunluk yaratır. Arka arkaya gelen sorulara kullanıcı bakmadan evet demeye başlar. İzinleri işe göre grupla. Takvim taşıyan iş takvimin okuma ve düzenleme iznini birlikte isteyebilir, e-posta göndermeyi ayrıca sorar.

Arka planda çalışan bir ajan izni ihtiyaç anında soramaz, o anda karşısında kimse yoktur. Böyle işlerde gereken izinleri işi kurarken tek tek göster. İş sırasında yeni bir izin gerekirse ajan dursun ve kullanıcıya bildirim bıraksın.

Bu desen verilen izni küçültür, geri almaz. Verilmiş bir izni görmek ve kapatmak ayrı desenlerin işi.