AI Agent İzin Sınırlama: OpenAI Dersinden Sonra
Neden bu haber beni durdurdu
Geçtiğimiz günlerde OpenAI’ın ajanlarının kendilerine tanınan sınırların dışına çıkıp yetkisiz hareket ettiğine dair bir haber dolaştı. Detayları bire bir doğrulayacak durumda değilim, o yüzden olayın kendisini burada büyütmeyeceğim. Ama başlık bende hemen bir refleks yarattı, çünkü AgentSpace’teki worker ajanlarım da headless Claude CLI üzerinden gerçek araçlara — dosya sistemi, terminal, bazı harici servisler — erişiyor. Yani “ajan yetkisini aştı” cümlesi benim için soyut bir haber değil, doğrudan kendi mimarimin test etmesi gereken bir senaryo. Bu yazıda AI agent izin sınırlama konusuna soyut ilkelerle değil, AgentSpace ve ChatFlow’da gerçekten kurduğum katmanlarla giriyorum: neyi nasıl sınırladım, neyi henüz sınırlamadım.
İzin sınırlama ajan bağlamında ne demek
Klasik yazılımda yetkilendirme genelde statiktir: bir kullanıcının rolü var, o role bağlı izinler var, değişmez. Ajanlarda durum farklı çünkü karar veren taraf da, eylemi tetikleyen taraf da aynı model. Ajan hem “ne yapmalıyım” diye düşünüyor hem de o düşünceyi doğrudan bir tool çağrısına çeviriyor. Aradaki insan onayı katmanı zayıfsa, “yanlış karar” ile “yetkisiz eylem” arasındaki mesafe neredeyse sıfıra iner.
Bu yüzden izin sınırlamayı üç ayrı katman olarak düşünüyorum, tek bir “izin var/yok” anahtarı olarak değil:
Tool allowlist
Her worker ajan, göreve özel bir tool listesiyle başlıyor. Sprint planlamasıyla uğraşan bir ajanın ödeme API’sine, kargo entegrasyonuna dokunma ihtimali sıfır — çünkü o araçlar ona tanımlı bile değil. Bu, modelin “iyi niyetli” olup olmamasından bağımsız çalışan bir sınır: araç yoksa çağrı da yok.
Onay kapıları
Geri alınamayan ya da parasal sonucu olan her eylem — kayıt silme, dış API’ye yazma, müşteriye giden mesajı gönderme — bir onay kapısından geçiyor. Bazı kapılar otomatik kural bazlı (örneğin belirli bir tutarın üstü insana düşer), bazıları hâlâ benim manuel onayımı gerektiriyor. Bu ikinci grup ölçeklenmiyor, biliyorum, ama şu an bilinçli bir tercih: hız yerine kontrol.
Blast radius sınırı
Bir ajan yanlış karar verirse bile, o kararın etkisi ne kadar geniş yayılabilir? AgentSpace’te worker’lar birbirinin görev panosuna ve hafızasına doğrudan yazamıyor; lider ajan üzerinden geçiyor. Bu, tek bir ajanın hatasının bütün sprint’i kirletmesini engellemek için var — mükemmel bir izolasyon değil, ama hasarı bir noktada durduran bir duvar.
AgentSpace’te gerçekte nasıl kurdum
AgentSpace’in worker havuzu, görevleri sprint halinde alan birden çok Claude ajanından oluşuyor. Her worker’ın hangi araçlara erişebileceğini görev tanımı belirliyor, ajan kendi kendine genişletemiyor. Kalıcı hafıza ve görev panosu da aynı mantıkla ayrılmış durumda: bir worker kendi görev kaydını güncelleyebilir ama başka bir worker’ın kaydına ya da lider ajanın plan dosyasına yazamaz. Yetki devri tek yönlü — lider ajan worker’a görev verir, worker geri raporlar, ama worker kendine yeni yetki tanımlayamaz.
Bunun pratikte anlamı şu: bir worker ajan “bu görevi daha hızlı bitiririm” diye kendi kapsamının dışına çıkmaya çalışsa bile, eline geçen araç seti buna izin vermiyor. Model isteyebilir, sistem izin vermiyor — ayrım burada önemli, çünkü modelin niyetine güvenmek bir izin stratejisi değil.
Dürüst olmak gerekirse bu yapıyı OpenAI haberinden sonra kurmadım; zaten vardı, çünkü headless CLI ajanlara gerçek tool erişimi verirken bunu baştan düşünmek zorunda kaldım. Haber, kurduğum şeyin gerekçesini bir kez daha doğruladı, o kadar.
ChatFlow’da parasal riskte izin sınırlama örneği
ChatFlow’un WhatsApp satış ajanı, Shopify sipariş açan ve kapıda ödeme onayı veren bir yapı. Burada izin sınırlama teorik değil, doğrudan para ile ilgili: ajan fiyat değiştiremez, iade onaylayamaz, indirim tanımlayamaz. Bu sert duvarları daha önce farklı bir yazıda anlatmıştım ama tekrar etmek gerekirse mantık aynı üç katmandan geliyor — ajanın erişebildiği tool’lar fiyat/iade işlemini kapsamıyor, sınır değeri aşan her onay insana düşüyor, ve bir siparişteki hata diğer siparişleri etkilemiyor.
Buradaki fark şu: ChatFlow’da hata payı doğrudan müşteri parasına dokunuyor, bu yüzden onay kapıları AgentSpace’e göre daha sıkı. AgentSpace’te bir worker’ın hatası en kötü ihtimalle bir sprint’i geciktirir; ChatFlow’da bir hatalı onay gerçek bir siparişi bozar. İzin sınırlamayı tasarlarken riskin büyüklüğüne göre kapı sıklığını ayarlamak gerekiyor — her yere aynı sertlikte kural koymak hem gereksiz sürtünme yaratıyor hem de asıl kritik noktaları göz ardı ettiriyor.
Henüz çözmediğim, henüz ölçmediğim
Burada dürüst olmam gereken birkaç nokta var:
- Onay kapılarının kaçının gerçekten gerekli, kaçının alışkanlıktan kaynaklandığını sistematik olarak ölçmedim. Bazı kapılar muhtemelen gereksiz sürtünme.
- Worker ajanların tool allowlist’ini görev bazında elle tanımlıyorum. Görev sayısı arttıkça bu manuel süreç ölçeklenmeyecek, otomatik bir “en az yetki” öneri mekanizmasına ihtiyaç olacak ama henüz kurmadım.
- Bir ajanın “izin sınırının dışına çıkmaya çalıştığı” anları loglayıp ayrı bir sinyal olarak izlemiyorum. Şu an sadece “araç yoktu, çağrı başarısız oldu” diye geçiyor; oysa bu, modelin davranışı hakkında değerli bir veri olabilir.
Bunları söylüyorum çünkü “izin sınırlama katmanımız var” demek kolay, “her senaryoyu düşündük” demek ayrı bir iddia ve onu şu an yapamam.
Kısa çıkarım
OpenAI’daki olayın teknik detayını bilmesem de haberin bende yarattığı soru netti: ajanına verdiğin her araç, bir gün o ajanın niyetinden bağımsız şekilde kötüye kullanılabilir mi diye sormuşsun mudur? Benim şu anki cevabım üç katmanlı: hangi araca erişebiliyor (allowlist), hangi eylem insana düşüyor (onay kapısı), bir hata ne kadar yayılabiliyor (blast radius). Bu üçü olmadan “modelimiz güvenilir” cümlesi bir umuttan ibaret kalıyor.