Ajan Onay Mekanizması: İnsan Onay Kapısı Ne Zaman Zorunlu?

Ajan onay mekanizması neyi korur?

Ajanlar dil modeliyle karar verir. Model yanılabilir, eksik bağlamla çalışabilir ya da okuduğu belgedeki gizli talimatla yönlendirilebilir. Onay kapısı ajanın hatasını önlemez, hatanın gerçek dünyada sonuç doğurmasını durdurur. OWASP LLM03:2026 Excessive Agency maddesi bunu doğrudan önerir: yüksek etkili işlemler gerçekleşmeden önce bir insanın onaylamasını gerektiren kontrol kullanın. Model Context Protocol belirtimi de güvenlik için her zaman araç çağrısını reddedebilen bir insanın döngüde olmasını ve hassas işlemlerde onay istenmesini önerir.

Onay kapısının ikinci bir işlevi hesap verebilirliktir. Ödeme ya da yetki değişikliği gibi bir işlemde kararın kimde olduğu kayıtta görünür. Bu, olay incelemesinde ve denetimde ayrı bir değer üretir.

OWASP Agentic Top 10 (2026) aynı konunun öbür yüzünü ASI09 Human-Agent Trust Exploitation olarak ele alır: insanın ajana aşırı güvenmesi ya da ajanın insanı zararlı bir işlemi onaylamaya yönlendirmesi. Bu nedenle onay kapısı yalnız bir düğme değil, tasarlanması gereken bir arayüzdür. Ajan yetkisinin genel çerçevesi için least agency yetki modeli yazısına bakın.

Hangi işlemler onay gerektirir?

Ölçüt üç sorudur: işlem geri alınabilir mi, etkisi ne kadar büyük ve veri kurumun dışına çıkıyor mu? Sınıflandırmayı ajan devreye girmeden önce yazılı hale getirin.

Belirsizlik varsa sıkı tarafı seçin. İlk aşamada fazla onay isteyip kayıtlara bakarak gevşetmek, tersinden çok daha güvenlidir. Tarayıcıda çalışan ajanlarda bu sınıflandırmanın uygulaması için tarayıcı ajanı güvenliği yazısına bakabilirsiniz.

Onay ekranında ne gösterilmeli?

Onay ekranı, kullanıcının bilinçli karar vermesi için gereken bilgiyi eksiksiz ve yorumsuz vermelidir. Kritik kural şudur: gösterilen değerler ajanın yazdığı özetten değil, çağrının gerçek parametrelerinden üretilir. Ajan yanıltılmışsa kendi özeti de yanıltıcı olur. "Tedarikçiye ödeme yapılacak" yazan bir özet, hesap numarasının değiştiğini saklayabilir.

Onay ekranının içermesi gerekenler:

1. İşlemin türü ve hedefi: kime, nereye, hangi kayıt
2. Gerçek değerler: tutar, alıcı adresi, silinecek öğelerin listesi
3. İşlemin geri alınıp alınamayacağı
4. Ajanın bu işlemi neden önerdiği ve hangi kaynağa dayandığı
5. İlk kez görülen alıcı ya da olağandışı tutar için ayrı uyarı
6. Onayla ve reddet seçeneklerinin eşit görünürlüğü

Parametrelerin nasıl doğrulandığı ve onay ekranına nasıl taşındığı için araç çağrısında parametre doğrulama yazısına bakın.

Onay işlemin kendisine nasıl bağlanır?

Onay mekanizmasının kendisi de saldırı yüzeyidir. Ajan zararsız görünen bir işlemi onaya sunup onaydan sonra parametreyi değiştirebilir ya da bir onayı birden çok işlem için kullanabilir. Bunu önlemek için onay, işlemin parametrelerine kriptografik olarak bağlanır.

Bir politika örneği şöyle olabilir:

onay_politikasi:
  - arac: eposta_gonder
    kosul: "alici_alan_adi izin_listesinde_degil"
    onaylayan: [talep_eden_kullanici]
    gecerlilik_dk: 15
  - arac: odeme_baslat
    kosul: "tutar > 10000"
    onaylayan: [talep_eden_kullanici, finans_yoneticisi]
    gecerlilik_dk: 15
    tek_kullanim: true
    baglama: sha256(arac + parametreler)
  - arac: rol_ata
    onaylayan: [bt_yoneticisi]
    gecerlilik_dk: 10
    tek_kullanim: true

Yürütme anında sistem, çalıştırılacak parametrelerin özetini onaydaki özetle karşılaştırır. Fark varsa işlem durur ve olay kaydı açılır. Onay kayıtları değiştirilemez biçimde saklanır.

Onay yorgunluğu nasıl ölçülür ve azaltılır?

Onay yorgunluğu, kullanıcının çok sayıda onay isteği karşısında içeriğe bakmadan onaylamaya başlamasıdır. Anthropic, Claude Code için geliştirdiği sandbox yaklaşımını anlatırken sürekli izin istemlerinin bu yorgunluğu yarattığını ve kullanıcının neyi onayladığına dikkat etmeyebildiğini yazıyor. Şirket, işletim sistemi düzeyindeki sandbox sayesinde izin istemlerinin kendi kullanımında %84 azaldığını bildiriyor. Ders şudur: onay sayısını azaltmanın en iyi yolu, düşük riskli işlemleri teknik sınırlar içinde serbest bırakmaktır.

AB Yapay Zekâ Yasası Madde 14 de aynı riske işaret eder ve gözetim yapan kişinin sistem çıktısına otomatik olarak ya da aşırı güvenme eğiliminin, yani otomasyon yanlılığının farkında olmasını ister.

Önlemler:

• Aynı türden ve aynı hedefe yönelik istekleri tek onayda toplayın.
• İlk kez görülen alıcıyı ya da olağandışı tutarı görsel olarak öne çıkarın.
• Neredeyse hep onaylanan bir onay noktasını tutar tavanı gibi teknik bir sınırla değiştirin.
• Yüksek riskli işlemlerde onayı ikinci bir kişiye dağıtın.

Mevzuat insan denetimi hakkında ne diyor?

AB Yapay Zekâ Yasası (Tüzük 2024/1689) Madde 14, yüksek riskli yapay zekâ sistemlerinin kullanım süresince gerçek kişilerce etkili biçimde gözetilebilecek şekilde tasarlanmasını ister. Gözetim yapan kişi sistemin çıktısını kullanmamaya, geçersiz kılmaya ya da tersine çevirmeye karar verebilmeli, sisteme müdahale edebilmeli ve onu bir "durdur" düğmesi ya da benzeri bir yöntemle güvenli biçimde durdurabilmelidir. Ajanınız yüksek riskli kapsamda olmasa bile bu maddeler iyi bir tasarım ölçütüdür.

KVKK Madde 11, ilgili kişiye işlenen verilerin münhasıran otomatik sistemler vasıtasıyla analiz edilmesi suretiyle kendisi aleyhine bir sonucun ortaya çıkmasına itiraz etme hakkı tanır. Kişisel veriyle karar üreten ajanlarda anlamlı bir insan onayı ve itirazı inceleyecek bir süreç bu hakkın uygulamadaki karşılığıdır. Ayrıntı için KVKK ve otomatik karar itirazı yazısına bakabilirsiniz.

Onay kapısı teknik olarak nasıl uygulanır?

Onay kararı modelin içinde değil, uygulama kodunda verilmelidir. Model "onay gerekmez" diye düşünse bile politika katmanı onayı zorunlu tutar. Ajan çatıları bunu destekler. Örneğin LangGraph'ta interrupt() çağrısı grafiğin çalışmasını belirli bir noktada duraklatır, durum bir checkpointer ile saklanır ve insan kararı geldiğinde grafik Command(resume=...) ile devam ettirilir.

Uygulama sırası:

1. Ajanın kullanabildiği tüm araçları ve işlemleri listeleyin.
2. Her işlemi yukarıdaki tabloya göre sınıflandırın, sahibini belirleyin.
3. Onay politikasını kod olarak yazın ve değişiklikleri kod incelemesinden geçirin.
4. Onay servisini parametre özeti, geçerlilik süresi ve tek kullanımla kurun.
5. Onay kayıtlarını merkezi kayıt sistemine gönderin ve yorgunluk ölçütlerini izleyin.

Onay kapısı tek katman değildir. Ajan beklenmedik davranmaya devam ederse kademeli durdurma için ajan kill-switch ve durdurma merdiveni yazısındaki yaklaşım uygulanabilir.

Onay kapısını nasıl test edersiniz?

Onay kapısı belgede değil davranışta doğrulanmalıdır. Testleri ajan, model ya da yetki değiştiğinde tekrarlayın.

Başarısız her test bir düzeltme kaydına dönüşmeli, düzeltmeden sonra yeniden çalıştırılmalıdır.

Sık Sorulan Sorular

Her ajan işlemi için onay istemek doğru mu?

Doğru değil. Her adımda onay istemek kullanıcıyı yorar ve onayların içeriğe bakılmadan verilmesine yol açar. Anthropic de sürekli izin istemlerinin onay yorgunluğu yarattığını ve kullanıcının neyi onayladığına dikkat etmeyebildiğini belirtiyor. Onayı geri alınamaz, dışarıya veri çıkaran, para ya da yetki içeren işlemlere ayırın, düşük riskli işlemleri kayıtla otomatik bırakın.

Onay ekranında ne gösterilmelidir?

İşlemin türü, hedefi ve gerçek değerleri gösterilmelidir: alıcı, tutar, silinecek kayıtlar, paylaşılacak dosya. Bu değerler ajanın yazdığı özetten değil, doğrulama katmanının çağrıdan çıkardığı parametrelerden gelmelidir. Ajanın işlemi neden önerdiği ve hangi kaynağa dayandığı kısa biçimde eklenir. Reddet seçeneği onayla seçeneği kadar görünür olmalıdır.

Onay yorgunluğu nasıl anlaşılır?

Onay kayıtlarından ölçülür. Bir onay noktasında neredeyse bütün istekler onaylanıyorsa, karar süresi birkaç saniyeye inmişse ya da aynı kişi kısa sürede çok sayıda onay veriyorsa kapı fiilen işlemiyor olabilir. Bu durumda onay noktasını yeniden sınıflandırın, benzer istekleri gruplayın ya da riskli kısmı teknik bir sınırla, örneğin tutar tavanıyla değiştirin.

Onay kapısı ajanı yanıltmaya karşı korur mu?

Kısmen korur. Ajan dolaylı enjeksiyonla yanıltılsa bile kritik işlem onay beklediği için zarar durdurulabilir. Ancak onay ekranı ajanın yanıltıcı özetini gösteriyorsa ya da kullanıcı dikkatsizse koruma çalışmaz. Bu yüzden onay kapısını yetki sınırı, alıcı izin listesi, tutar tavanı ve kayıt tutma gibi katmanlarla birlikte kullanın.

İnsan onayı mevzuat açısından neden önemlidir?

AB Yapay Zekâ Yasası Madde 14, yüksek riskli sistemlerde etkili insan gözetimi ister ve gözetim yapan kişinin otomasyon yanlılığına karşı farkında olmasını, çıktıyı geçersiz kılabilmesini ve sistemi durdurabilmesini bekler. KVKK Madde 11 ise münhasıran otomatik analizle kişinin aleyhine çıkan sonuca itiraz hakkı tanır. Anlamlı insan onayı bu beklentilerin uygulamadaki karşılığıdır.

Kaynaklar

• OWASP GenAI: LLM06:2025 Excessive Agency
• Model Context Protocol Specification: Tools
• EUR-Lex: Regulation (EU) 2024/1689, Artificial Intelligence Act
• KVKK: 6698 sayılı Kişisel Verilerin Korunması Kanunu
• Anthropic Engineering: Beyond permission prompts, making Claude Code more secure and autonomous
• LangChain Docs: LangGraph Interrupts

İlgili Yazılar

• Otonom Ajan Kill-Switch Tasarımı: Ajan Durdurma Merdiveni Rogue agent müdahale runbook'u ve devre-kesici deseni
• AI Agent Yetki Modeli Least Privilege Yetmez, Least Agency Gerekir
• LLM Araç Çağrısı Doğrulama: Tool Calling İçin Şema, Yetki ve Politika
• Tarayıcı Ajanı Güvenli mi? Gizli Talimat, Oturum ve Onay Kontrolleri