AI ajanlarında önce kontrol, sonra kanıt: hesap verebilirlik ilkesi
AI ajanlarının kritik eylemlerini önceden sınırlayan, sonradan kriptografik olarak kanıtlayan yeni bir hesap verebilirlik ilkesi tanıtıldı.
Para transferi ya da müşteri hesabına dokunan işlemler gibi gerçek yetkiler verilen AI ajanları, bir noktada açıklanamayan bir eylem yaptığında ekipler genelde tüm onay sürecini yeniden insan denetimine döndürüyor. Sorun modelin kendisi değil; yetkilendirme (policy engine) ile denetim kaydının (audit log) iki ayrı sistem olmasından kaynaklanıyor. Zamanla bu iki sistem birbirinden sapıyor ve bir anlaşmazlık anında hangi politikanın o an geçerli olduğunu kanıtlamak zorlaşıyor.
Önerilen yaklaşım, yetkilendirme ile kanıtı tek bir nesnede birleştiriyor. 'Önce kontrol' aşamasında ajana harcama limiti, karşı taraf listesi veya son kullanma tarihi gibi sınırları olan bir yetki (capability) tanımlanıyor; her kritik eylem bu politikaya göre anında izin/red kararı alıyor ve limit dışı eylemler gerçekleşmeden reddediliyor. 'Sonra kanıt' aşamasında ise kararın tüm bağlamı tuzlanarak (salted) özetleniyor, imzalanıyor ve değiştirilemez biçimde kayda geçiriliyor; bu kayıt, kararın alındığı anki politika sürümüne bağlanıyor.
Mimaride karar anlık (senkron) veriliyor, kalıcı kayıt ise transactional outbox üzerinden asenkron olarak işleniyor; böylece ajan kaydın diske yazılmasını beklemek zorunda kalmıyor ama 'izin verildi ama kayda geçmedi' riski de ortadan kalkıyor. Tek yazarlı yetki ve tekrar denemede çift kayıt önleme gibi teknik garantiler bu ayrımı güvenli kılıyor. Kayıtların doğruluğu, sunucuya güven gerektirmeden bağımsızca özet yeniden hesaplanarak kontrol edilebiliyor; imzalamada kuantuma dayanıklı ML-DSA (FIPS 204) kullanılıyor ve her kayıt için ayrı bir 'tuz' silinerek gerçek ve kanıtlanabilir bir silme hakkı sağlanıyor. İstemci SDK'ları TypeScript, Python ve Go için açık kaynak.
Sistem şu an özel, kuantuma dayanıklı bir blok zinciri üzerinde çalışıyor ancak geliştiriciye token, cüzdan veya gas maliyeti dayatmıyor. Şu an yönetilen beta aşamasında; imzalama anahtarları şirket tarafından KMS ile saklanıyor ve doğrulayıcılar da şirkete ait; müşteriye özel anahtarsız kullanım ve üçüncü taraf doğrulama hedef olarak belirtiliyor. Yazar, basit bir append-only Merkle log'un yeterli olduğu, sunucuya güvenmeden doğrulama veya kayıt bazlı silme ihtiyacının olmadığı durumlarda bu aracın gereksiz olabileceğini de açıkça belirtiyor.