Ajanınızın Onay Belirteci Tek Kullanımlık Olabilir, Peki Yazma İşlemi Neden Hâlâ İki Kez Gerçekleşir?

Yapay zekâ ajanları otonom kararlar alıp dış sistemlerde yazma operasyonları gerçekleştirdikçe, klasik web mimarilerindeki güvenlik ve durum yönetimi kalıpları yetersiz kalabilmektedir. Üretim ortamında karşılaşılan bu vaka, tek kullanımlık onay belirteçlerinin (one-shot confirm token) neden mükerrer işlemleri bütünüyle engelleyemediğini somut bir şekilde göstermektedir.

Olay (The Incident)

Bir okul yönetim platformunda görev yapan yapay zekâ asistanı; sınav salonu oluşturma ve yoklama düzeltme gibi doğal dille tetiklenen yazma işlemlerini yürütmektedir. Sistem altyapısı, Go ile yazılmış bir MCP (Model Context Protocol) sunucusunu çağıran Python tabanlı bir LangGraph ajanından oluşmaktadır. Sunucudaki 26 araçtan 12'si doğrudan veri tabanına yazma yapmaktadır.

Sistem canlıya alındıktan birkaç ay sonra veri tabanında mükerrer kayıtlar oluşmaya başladı: Tek bir onay verilmesine rağmen iki sınav salonu açılıyor veya iki yoklama düzeltmesi kaydediliyordu. Günlük kayıtlarında hiçbir anormallik yoktu; işlemler doğrulanmış, yetkilendirilmiş ve kullanıcının istediği parametreleri içeriyordu. Temel neden basitti: Kullanıcı yanıt yavaş hissettirdiği için butona tekrar tıklamış ya da model tek bir turda aynı aracı iki kez tetiklemişti. Kullanıcı tek eylem onaylamış, sistem ise iki kez yazmıştı.

İlk Çözüm (The First Fix)

Tüm yazma araçları iki aşamalı bir mimariye dönüştürüldü:

Önizleme Aşaması: Doğrudan yazma yapmaz; yapılacak işlemin önizlemesini ve bir onay belirteci (confirmation token) üretir.
Yürütme Aşaması: Bu belirteci doğrular ve yalnızca doğrulama geçerliyse yazma işlemini gerçekleştirir.

Belirteç; kullanıcı kimliği, araç adı, parametrelerin SHA-256 özeti ve tek kullanımlık bir rastgele değer (nonce) içeren bir HMAC imzasıyla üretildi. Süresi beş dakika olarak belirlendi ve içindeki nonce kullanıldığı anda yakılarak (burn_nonce) geçersiz kılındı. Parametre özeti, modelin kullanıcıya gösterdiğinden farklı bir parametre çalıştırmasını önlüyordu. Belirteç ayrıca SSE akışından filtrelendi. Bu hamleyle mükerrer yazmalar bıçak gibi kesildi ve sorun çözülmüş kabul edildi.

Gözden Kaçan Nokta (What I Missed)

Nonce mekanizması belirteci korur, ancak eylemin kendisini korumaz. Bir nonce'ın yakılması, sadece o belirtecin tekrar kullanılmasını engeller. Oysa otonom ajan eski belirteci yeniden kullanmak zorunda değildir; yeniden planlama (re-planning) yaparak aynı eylem için önizleme aşamasını tekrar çağırır ve tamamen taze, geçerli bir belirteç alır.

Kontroller adım adım incelendiğinde:

HMAC İmzası: Geçerli (yeni üretildi).
Nonce: Kullanılmamış ve taze.
Süre Aşımı: Geçerli.
Parametre Özeti: Tamamen eşleşiyor; çünkü aynı parametrelerle çağrıldı.

Tüm kontroller geçer. Buradaki ironi, parametre özetinin eşleşmesinin işlemin doğruluğunun değil, mükerrer bir işlem olduğunun en güçlü kanıtı olmasıdır. Kök neden, durumun eyleme göre değil belirtece göre anahtarlanmasıdır (keyed by token, not by action). Literatürde buna anlamsal yeniden oynatma (semantic replay) denir; yani eski bir belirteç kimliğini kullanmak yerine, bağımsız bir yetkilendirme bütçesini aşmak.

Öğrenme ve Geliştirme Çıkarımı: Ajan tabanlı sistemlerde güvenilirlik sağlamak için salt belirteç bazlı doğrulamalar yetersizdir. İş mantığı katmanında eylemlerin özetine dayalı idempotency kurgulanmalı ve eylemin yürütme bütçesi izlenmelidir.

Orijinal kaynağa buradan ulaşabilirsiniz.

Bu konuyu derinlemesine öğrenmek isterseniz: Production'da Agent Güvenilirliği modülüne göz atın.