Jul 31, 2026

Bir AI ajanına ödeme yapmadan önce kimliğini nasıl doğrularsınız

Güven
Bu yazıda ne var

Ajanınız başka bir ajana para göndermek üzere. Cevaplamanız gereken tek bir soru ve birkaç yüz milisaniyeniz var. Neye, hangi sırayla bakmalı ve her cevap gerçekte ne kadar değerli.

Soru "bu ajan iyi mi" değil

Ajanınız başka bir ajana ödeme yapmak üzereyken işe yarayan soru, soyut olarak "bu karşı taraf güvenilir mi" değildir. "Bu belirli ödeme, bu tutarda, bu tarafa, şu anda gerçekleşmeli mi" sorusudur. Bunlar farklı sorulardır ve yalnızca ikincisinin üzerine harekete geçebileceğiniz bir cevabı vardır.

Fark önemli, çünkü risk maruziyetin bir fonksiyonudur. Bir dolar ödemekte tereddüt etmeyeceğiniz bir karşı taraf, otomatik olarak on bin dolar ödemeniz gereken bir karşı taraf değildir. Tutarı bilmeden karar döndüren her kontrol, sormadığınız bir soruyu cevaplıyordur.

Birinci kontrol: ortada bir kimlik var mı

Karşı tarafın zincir üzerinde kayıtlı olup olmadığıyla başlayın. ERC-8004 kapsamında bir ajanın kimlik kaydında bir girdisi bulunur: bir token kimliği, bir sahip ve uçlarını tarif eden meta veri. Bunu kontrol etmek de taklit etmek de ucuzdur, dolayısıyla bunu bir sinyal değil bir filtre olarak görün. Kaydı olmayan bir ajan yabancıdır. Kaydı olan bir ajan, form doldurmuş bir yabancıdır.

Burada elediğiniz şey en basit durumdur ve bunu ilk yapmaya değer, çünkü çalıştıracağınız en hızlı kontrol budur.

İkinci kontrol: kendi cüzdanını kontrol ettiğini kanıtladı mı

Bu, çoğu kişinin atladığı kontroldür ve iddiayı kanıttan ayıran şey tam olarak budur. Herkes bir cüzdan adresi listeleyen bir ajan kaydedebilir. Ajanın o adresi gerçekten kontrol ettiğini kanıtlamak ise ilgili anahtarla bir meydan okumayı imzalamayı ve sonucu zincire yazmayı gerektirir.

KYA, yani Know Your Agent, budur: operatör hakkında bir geçmiş araştırması değil, ajan ile cüzdanın aynı aktör olduğunun kriptografik gösterimi. Bu olmadan bir saldırgan, itibarlı bir cüzdanı sahiplendiğini iddia eden bir ajan kaydedip o geçmişi bedavaya devralabilir.

Bir itibar skoru okuduğunuzda, neyin üzerinden hesaplandığını sorun. Altındaki cüzdan hiç kanıtlanmadıysa skor başka birini tarif ediyordur.

Üçüncü kontrol: gerçekte ne yapmış

İtibar ancak burada anlam kazanır. İstediğiniz sayı, puanlamalardan değil, tamamlanmış ödemelerden hesaplanan sayıdır. Puanlama üretmek ucuzdur; bir settlement ise gerçek değer taşımış ve arkasında bir işlem özeti bırakmış bir işlemdir.

Bir skoru kullanılabilir kılan iki özellik var. Deterministik olmalı ki aynı girdiler her zaman aynı sayıyı üretsin ve bize güvenmek yerine kendiniz yeniden hesaplayabilesiniz. Ve zamanla azalmalı ki bir yıl önce iyi davranıp o zamandan beri susan bir ajan, geçen hafta iyi davranan bir ajanla aynı görünmesin.

Skor sağlayan herkesten yöntemini isteyin. Yayınlamıyorlarsa o skor bir ölçüm değil, bir markadır.

Dördüncü kontrol: anlaşmanın kendisi şüpheli mi

Yukarıdakilerin hepsi tek bir tarafı inceler. En yaygın manipülasyonların bazıları ise ancak iki tarafa birden bakınca görünür.

Kalıp basit: bir operatör iki ajan kaydeder, onlara birbirlerine tekrar tekrar ödeme yaptırır ve ikisi için de settlement geçmişi imal eder. Her ajan tek başına bakıldığında düzgün görünür. Aradaki ilişki ele veren şeydir ve tek taraflı bir tarama bunu yapısı gereği göremez.

Bu yüzden son kontrol, önerilen anlaşmanın iki tarafını birden alıp bağımsız olup olmadıklarını sorar. Ortak fonlama kaynakları, ortak dağıtım kalıpları ve sürekli kendi üzerine kapanan ödeme grafikleri bunu ele verir.

Bir karar nasıl görünmeli

Tüm bunların çıktısı bir gösterge paneli değil, bir karar olmalı. Ajanınız 0.72 risk skoruyla hareket edemez. ALLOW, WARN veya DENY ile edebilir.

Önemli olan WARN ve genellikle eksik olan da odur. Ödemeye izin verildiği ama bir insanın bakması gereken bir çizgiyi geçtiği anlamına gelir. WARN kararını ALLOW gibi işleyen bir ajan, elindeki tek "insan çağır" sinyalini çöpe atmış olur.

Hangi kararı alırsanız alın, yanında sade bir dille gerekçeler gelmeli. Er ya da geç, engellenmiş bir ödemeyi o ödemenin geçmesini bekleyen birine açıklamak zorunda kalacaksınız ve "model hayır dedi" bir açıklama değildir.

Karardan sonra çalışan kontrol

Karşı tarafı doğrulamak, ödeme yapmalı mısınız sorusunu cevaplar. Ödeme yapmaya izniniz var mı sorusunu cevaplamaz. Bunlar ayrı şeylerdir ve ikisini birbirine karıştırmak, ajanların her kontrolü geçerken bütçeyi aşmasının yoludur.

Bir karşı taraf tamamen meşru olabilir ve ödeme yine de sahibinin koyduğu bütçenin dışında kalabilir. O sınırın, ajanın tartışamayacağı bir yerde durması gerekir: sunucu tarafındaki ön kontrol pratiktir, ama sunucu yanıldığında hâlâ ayakta duran şey, limit aşan transferi geri çeviren zincir üstü kasadır.

Önce karşı tarafı doğrulayın, sonra kendi limitlerinizi kontrol edin. İkincisini atlamak, bir ajanla bakiyeniz arasında duran tek şeyin ajanın kendi muhakemesi olması demektir.

Bunu tek çağrıda yapmak

A-Identity bu dört kontrolü çağrı başına ödemeli uçlar olarak sunar. `risk_check` karşı tarafı ve amaçlanan tutarı alır, kararı gerekçeleriyle döndürür. `counterparty_check` iki tarafı birden alır ve kendi kendine ticaret durumunu yakalar. `trust_preview` ücretsiz ve hız sınırlıdır, böylece hiçbir şey harcamadan cevabın nasıl göründüğünü görebilirsiniz.

Ödeme, x402 üzerinden USDC ile çağrı başınadır: hesap yok, API anahtarı yok. Ödenmemiş bir istek, tam olarak ne borçlu olduğunuzu anlatan HTTP 402 döner ve kaynak ödenmiş tekrar denemede sunulur.

Skorlama yöntemi tamamıyla yayında ve aldığımız her settlement işlem özetiyle birlikte listeleniyor. Bir güven sağlayıcısına güvenmek zorunda kalmamalısınız; bize inanılmasındansa kontrol edilmeyi tercih ederiz.

Okumaya devam et