Onaydan sonra kapsam büyürse yeniden sor

Kullanıcı ajandan bir fonksiyonun adını değiştirmesini istiyor. Ajan planını gösteriyor: üç dosya, adları belli. Kullanıcı planı okuyor, onaylıyor ve başka işe dönüyor. Ajan çalışırken fonksiyonun yirmi yedi dosyada daha çağrıldığını görüyor. Tutarlılık için onları da değiştiriyor. Kullanıcı döndüğünde otuz dosya değişmiş, aralarında başka bir ekibin raporlama kodu ve dışarıdaki istemcilerin kullandığı eski bir API var.

Ajanın gerekçesi makul. Fonksiyonun adı bir yerde değişip öteki yerlerde eski kalırsa kod derlenmez. Ama yirmi yedi dosyalık genişlemeye kullanıcı karar vermedi. Kullanıcı üç dosyalık bir işi onayladı. Ajan için onay "bu görev" anlamına geldi, görev büyüdükçe onay da onunla birlikte büyüdü.

Bedeli kullanıcı ödüyor. Üç dosyalık bir değişikliği okumaya hazırdı, önüne otuz dosyalık bir fark geliyor. Hangisinin planda olduğunu, hangisinin sonradan eklendiğini ayırmak zorunda. Bir sonraki planı daha az dikkatle okuyor, çünkü planın işi sınırlamadığını öğrendi. Kullanıcının onayladığı plan, ajanın yaptığı işin sınırı olmadıkça bir niyet beyanından öteye geçmiyor.

Onay çoğu üründe görev düzeyinde tutulur: kullanıcı başlattı, ajan çalışıyor. Ekipler ajanın işi kesintisiz bitirmesini başarı sayar, iş ortasında gelen her soru bir kesinti olarak ölçülür. Planın dosya listesini saklamak ve her adımı onunla karşılaştırmak ayrı bir altyapı ister, bu altyapı da demoda hiç görünmez.

Model kendiliğinden genişler. Bir görevi bitirmeye çalışan model, işin tamamlanması için gereken her adımı görevin parçası sayar. Durup sormak bu bakışta işi yarım bırakmak gibi durur. Kapsam sınırı yalnız konuşmada duruyorsa ayrıca kırılgandır. OpenClaw olayında kullanıcının "söyleyene kadar bir şey yapma" talimatı, Summer Yue'nin anlatımına göre bağlam sıkıştırması sırasında kayboldu¹.

Üçüncü neden ölçümde. Onay kaydı yalnız oturuma bağlıysa iş bittiğinde kimse planla gerçek değişikliği karşılaştırmaz. Büyük bir fark incelemede yalnız yorgunluk olarak görünür, kimse ona kapsam kayması adını koymaz.

Onay, adı geçen işe verilir. Ajan iş sırasında bu işin dışına çıkacaksa durur, farkı gösterir ve yalnız farkı sorar.

1. Onayı listeye bağla. Plan onaylandığında ajan onaylanan dosyaları, kayıtları, alıcıları ve eylem türlerini bir kayıtta tutar. Bu kayıt konuşmanın dışında, sistemde durur. Bağlam kısalsa da sınır yerinde kalır.
2. Her yazmadan önce karşılaştır. Yazma, silme ve gönderme yapan her adımdan önce hedef bu kayıtla karşılaştırılır. Hedef listede değilse adım çalışmaz. Karşılaştırmayı kod yapar.
3. Farkı göster. Yeniden onay ekranı planın tamamını tekrarlamaz. Yeni hedefleri klasör klasör sayar, neden gerektiğini söyler, riskli olanı ayrıca işaretler: dışa açık bir arayüz, başkasının kodu, canlı veri.
4. Parça parça onaylat. Kullanıcı genişlemenin bir kısmını kabul edip kalanını reddedebilir. Kabul edilen kısım kapsama eklenir. Reddedilirse ajan planla kalır ve yapılmayan işi raporda söyler.
5. Eylem türü büyürse de sor. Okuma onayıyla yazmaya, yazma onayıyla silmeye ya da göndermeye geçmek kapsam büyümesidir. Dosya sayısı aynı kalsa bile ajan sorar.

İzin dünyası bu sorunu token düzeyinde çoktan çözdü. Uygulama işe dar bir kapsamla başlar, daha fazlası gerektiğinde ayrıca ister. Bu desen aynı kuralı ajanın görevine taşır.

Aynı ad değişikliği, iki ayrı ajanla. Soldaki ajan plandaki üç dosyayı ve plan dışındaki yirmi yedi dosyayı aynı onayla değiştiriyor, farkı yalnız sondaki sayıda söylüyor. Sağdaki plan dışındaki dosyaları buluyor, dokunmadan duruyor, riskli klasörü ayrıca belirtiyor ve genişlemeyi parça parça soruyor.

Google'ın OAuth belgesi artımlı yetkilendirmeyi iyi kullanıcı deneyimi olarak tarif ediyor: uygulama kaynaklara ihtiyaç duyduğu anda yetki istiyor². Belgedeki örnekte müzik karıştırma uygulaması girişte yalnız kullanıcının adını alıyor, Drive erişimini ancak kullanıcı bir karışımı kaydederken istiyor. Google'ın iyi uygulama sayfası da kullanıcı bir kapsamı reddederse uygulamanın ilgili işlevi kapatmasını³ istiyor.

MCP'nin yetkilendirme belirtimi aynı kuralı AI araçlarına koyuyor. Sunucu, eldeki token'ın kapsamı yetmediğinde insufficient_scope hatasıyla gereken kapsamı bildiriyor ve kullanıcı adına çalışan istemci ek yetkiyi o anda istemeyi⁴ denemeli.

Kodlama ajanları kapsamı dizin ve komut düzeyinde çiziyor. Codex'in sandbox belgesine göre iş sınırların içinde kaldıkça ajan onay sormadan ilerliyor, sınırın dışına çıkması gerektiğinde onay akışı devreye giriyor⁵. Varsayılan ayarda Codex çalışma alanının dışındaki dosyaları düzenlemek ya da ağa erişen komut çalıştırmak⁶ için onay istiyor. Claude Code'da izin kuralları tek bir komuta ya da yola göre yazılabiliyor. Bir izin istemi "bir daha sorma" seçeneğini yalnız o seçeneğin izin vereceği her şeyi gösterebildiğinde⁷ sunuyor. Belgeye göre kuralları Claude Code'un kendisi uyguluyor, prompttaki talimat izinleri değiştirmiyor.

Bu sınırlar dizine ve komuta bağlı. Kullanıcının onayladığı planın dosya listesini sınır olarak kullanan bir ürün belgesi incelediğimiz kaynaklarda yoktu. Ajan çalışma dizininin içinde kaldığı sürece üç dosyalık planla otuz dosyalık iş aynı izinle geçebiliyor. Plan düzeyindeki sınırı ürünü yapan kurmalı.

OpenClaw, Şubat 2026. Summer Yue, OpenClaw'a gelen kutusunu da incelemesini ve neyi arşivleyeceğini ya da sileceğini önermesini, kendisi söyleyene kadar hiçbir şey yapmamasını¹ söyledi. Yue'ye göre aynı talimat daha küçük bir deneme kutusunda işe yaramıştı. Gerçek gelen kutusu büyüktü, bağlam sıkıştırması tetiklendi ve talimat kayboldu. Ajanın planı öneriden toplu silmeye büyüdü. Komutlarından biri saklama listesinde olmayan ve 15 Şubat'tan eski her şeyi çöpe atmayı⁸ hedefliyordu. Bir başkası eski e-postaların hepsi temizlenene kadar döngüyü sürdürüyordu⁹. Yue telefondan durmasını yazdı, ajan devam etti. Sonradan ajan planı göstermeden ve onay almadan yüzlerce e-postayı¹⁰ çöpe attığını ve arşivlediğini kabul etti.

Olayda iki şey üst üste bindi. Onaylanan kapsam, yani yalnız öneri, yalnız konuşmada duruyordu ve konuşmayla birlikte gitti. Çöpe atma adımlarının önünde onları onaylanan kapsamla karşılaştıran bir kontrol de yoktu. Kapsam kaydı sistemde olsaydı ilk toplu silme çalışmadan önce dururdu.

Desenin öteki dayanağı yaygın uygulama. OAuth'un artımlı yetkilendirmesi, MCP'nin ek yetki akışı ve kodlama ajanlarının dizin sınırları aynı kuralı farklı katmanlarda uyguluyor: onay belli bir kapsama verilir, kapsam büyüyünce yeniden istenir. Ajanların onaylanan planın dışına ne sıklıkla çıktığını ölçen yayımlanmış bir çalışma bulamadık.

• 23 Şubat 2026OpenClaw üç “dur” mesajına rağmen gelen kutusundaki e-postaları çöpe atmayı sürdürdü

Yeniden onay sayısı tek başına yanıltır. Hiç soru gelmemesi kontrolün çalışmadığını da gösterebilir. Bakılacak yer, onaylanan kapsam ile yapılan iş arasındaki fark.

• Onaysız plan dışı değişiklik. Her iş sonunda değişen dosyaları ve kayıtları onaylanan kapsamla karşılaştır. Onay almadan kapsam dışına çıkan değişiklik sayısı sıfır olmalı.
• Yeniden onay sıklığı. İşlerin ne kadarında kapsam büyüyor? Çok sıksa ajan planı baştan dar yazıyor, plan aşamasını düzelt.
• Genişleme kabul oranı. Kullanıcı genişlemelerin ne kadarını kabul ediyor? Hepsini kabul ediyorsa ekran okunmuyor olabilir. Çoğunu reddediyorsa ajan gereksiz genişliyor.
• Geri alınan genişleme. Onaylanmış bir genişlemenin sonradan geri alındığı durumlar. Yüksekse fark ekranı riski yeterince göstermiyor.

Üç metin var. Denetim promptu ajanının onayı nasıl kaydettiğine, kapsamın konuşmada mı sistemde mi durduğuna ve kapsam dışı bir adımın nasıl ele alındığına bakar, yalnız rapor yazar. Uygulama promptu onaylanan kapsamı yapısal bir kayda çevirir, her yazmadan önce karşılaştırma ekler ve fark için parça parça onay akışı kurar. Önce planı gösterir, onayınla uygular ve plan dışı bir yazmanın engellendiğini doğrulayan bir test ekler. Kural kodlama ajanının kendi çalışması için. Senin ajanın da onayladığın planın dışına çıkmadan önce sorsun.

Bu depoda kullanıcı adına çok adımlı iş yapan bir AI ajanı var ve ajan bir planı ya da işi kullanıcıya onaylatıyor. Görevin, ajanın iş sırasında onaylanan kapsamın dışına çıkıp çıkamadığını ve çıkarken yeniden onay isteyip istemediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Onayın alındığı yerleri bul: plan onayı, görev başlatma onayı, araç izni istemleri. Onay ne kaydediyor: yalnız "onaylandı" bilgisini mi, yoksa onaylanan dosyaların, kayıtların, alıcıların ve eylem türlerinin listesini mi?
2. Onaylanan kapsam nerede tutuluyor: sistemde (veritabanı, oturum durumu, yapılandırma) mı, yoksa yalnız konuşmanın içinde mi? Bağlam kısaltma ya da özetleme bu bilgiyi silebilir mi?
3. Yazma, silme ve gönderme yapan her araç çağrısından önce hedef onaylanan kapsamla karşılaştırılıyor mu? Karşılaştırmayı kod mu yapıyor, model mi?
4. Hedef kapsamın dışındaysa ne oluyor: ajan duruyor mu, soruyor mu, sessizce devam mı ediyor? İş sonunda yalnız toplam sayı mı raporlanıyor?
5. Eylem türünün büyümesi (okuma onayıyla yazmaya, yazma onayıyla silmeye ya da göndermeye geçmek) ayrıca yakalanıyor mu?
6. Yeniden onay ekranı ne gösteriyor: yalnız farkı (yeni dosyalar, neden gerektiği, hangisinin riskli olduğu) mı, yoksa planın tamamını mı? Kullanıcı genişlemenin bir kısmını kabul edip kalanını reddedebiliyor mu?

Rapor biçimi: her onay noktası için dosya ve satır, onaylanan kapsamın nasıl kaydedildiği, kapsam dışı bir adımın nasıl ele alındığı, olası sonuç (örnek: üç dosya onaylanır, otuz dosya değişir) ve önerdiğin düzeltme. Silme ve gönderme yapan yollardan başla.

Bu depodaki AI ajanına "onaydan sonra kapsam büyürse yeniden sor" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Kullanıcı bir planı onayladığında onaylanan kapsamı yapısal bir kayıt olarak sakla: dosya ya da kayıt listesi, izin verilen eylem türleri (okuma, yazma, silme, gönderme), alıcılar. Bu kayıt konuşmadan ayrı dursun, bağlam kısaltmasında kaybolmasın.
2. Yazma, silme ve gönderme yapan her araç çağrısından önce hedefi bu kayıtla kodda karşılaştır. Hedef kapsamın dışındaysa çağrıyı çalıştırma.
3. Kapsam dışına çıkması gereken işte ajan dursun ve yalnız farkı göstersin: yeni hedefler (klasöre göre gruplanmış sayı ve liste), neden gerektiği ve riskli olanlar (dışa açık arayüz, başkasının kodu, canlı veri).
4. Kullanıcı farkın bir kısmını kabul edip kalanını reddedebilsin. Kabul edilen kısım kapsam kaydına eklensin. Reddedilirse ajan planla kalsın ve yapılmayan işi raporda söylesin.
5. Eylem türünün büyümesini de kapsam büyümesi say: okuma onayıyla yazma, yazma onayıyla silme ya da gönderme yeniden sorulsun.

Uygularken:
- Plan içi mekanik yan etkiler için (import satırları, biçimlendirme, kilit dosyaları) planda açık bir sınıf tanımla, bunlar için her seferinde sorma.
- Kapsam kontrolünü modelin beyanına bırakma, araç katmanında uygula.
- Bir test ekle: iki dosyalık bir planı onayla, ajanın üçüncü bir dosyaya yazmaya çalıştığı bir durum kur ve yazmanın engellendiğini, kullanıcıya farkın sorulduğunu doğrula.

## Onaydan sonra kapsam büyürse yeniden sor
- Onaylanan planın dosya, kayıt ve eylem listesini iş boyunca sınır olarak kullan.
- Plan dışı bir dosyaya, kayda ya da alıcıya yazmadan, silmeden ya da göndermeden önce dur ve sor.
- Sorarken yalnız farkı göster: hangi hedefler, neden, hangisi riskli.
- Okumadan yazmaya, yazmadan silmeye ya da göndermeye geçmek de kapsam büyümesidir, ayrıca sor.
- Kullanıcı genişlemeyi reddederse planla kal ve yapılmayan işi raporda yaz.

Her yan etki için sormak işi boğar. Ad değişikliğinin dokunduğu import satırları, biçimlendirme ya da kilit dosyası için planda açık bir sınıf tanımla, ajan bunlar için sormasın. Desen anlamı değişen işler için.

Keşif işlerinde kapsamın büyümesi zararsız. Ajan sorunun kaynağını ararken otuz dosya okuyabilir. Yeniden sorma yazma, silme ve gönderme için.

Arka planda çalışan ajan soru soracak kimseyi bulamaz. Böyle işlerde ajan plan içindeki işi bitirsin, plan dışını kuyruğa koysun ve kullanıcıya fark listesiyle bir bildirim bıraksın.

Desen planın doğru olduğunu garanti etmez. Dar ama yanlış bir plan da onaylanabilir, ajan da ona sadakatle uyar. Planın kendisini göstermek ve okutmak ayrı bir desenin işi.