Web3 Arkadaşı: Açık Kaynaklı Güvenli Ajanlık Cüzdanı

GitHub: blocksecteam/web3-companion

Docker: blocksecteam/web3-companion

Yapay zekanın kullanıcılar adına zincir üstü işlemler gerçekleştirmesi, kripto dünyasının şu an en sıcak trendi. Coinbase, Şubat 2026'da Agentic Wallets'ı piyasaya sürdü ve McKinsey'nin tahminlerine göre yapay zeka ajanlarının aracılık ettiği ticaret hacminin 2030 yılına kadar küresel ölçekte 3–5 trilyon dolara ulaşabileceği öngörülüyor. Coinbase CEO'su Brian Armstrong'un ifadesiyle: Yapay zeka ajanları banka hesabı açamaz, ancak kripto cüzdanına sahip olabilir.

Sorun şu ki yapay zekanın zincir üstü varlıkları yönetmesine izin vermek, ona takvim veya e-posta yönetimini devretmekten çok farklı. Zincir üstü işlemler geri alınamaz. İade yok, ters ibraz yok. Tek bir kötü niyetli imza, bir blok içinde tüm cüzdanı boşaltabilir. Güvenlik olmadan hiçbir özelliğin önemi yok.

BlockSec, güvenlik odaklı bir Agentic Cüzdan olan Web3 Companion'ı açık kaynak olarak yayımladı. Bu makale, arkasındaki güvenlik tasarımını ele alıyor: mevcut Agentic Cüzdan mimarilerinin neden temelden kırık olduğunu ve güvenliği cüzdan mimarisine sıfırdan nasıl yerleştirdiğimizi.

Mevcut Ajanlar Ne Kadar Tehlikeli: OpenClaw Olayı

Bir yapay zeka ajanının güvenlik sınırı olmadığında ne olur? 2026'nın başındaki OpenClaw olayı bu soruyu yanıtlıyor.

OpenClaw, beş günde 100.000 GitHub yıldızı toplayan açık kaynaklı genel amaçlı bir yapay zeka ajanı. Genel amaçlı bir ajan olarak iyi çalışıyordu; ancak Web3 işlemlerine dokunduğu anda tüm güvenlik açıkları gün yüzüne çıktı.

Özel anahtarlar, ajanın okuyabildiği yerel dosyalarda düz metin olarak tutuluyordu. Bunları ele geçirmek için tek bir prompt enjeksiyonu e-postası yeterliydi.

İmzalamada yalıtım yoktu. Güvenilmez web sayfaları çeken aynı süreç işlemleri de imzalayabiliyordu; bu yüzden tek bir RCE açığı, saldırganın kötü niyetli bir web sayfası aracılığıyla hem ajanın hem de anahtarların tam kontrolünü ele geçirmesine olanak tanıdı.

Skills pazaryeri de başlı başına bir zayıf noktaydı. Araştırmacılar, ClawHub Skills'in %7,1'inin kimlik bilgilerini sızdırdığını, bir kısmının ise açıkça kripto cüzdanlarını boşaltmak amacıyla tasarlandığını buldu.

Rastgele sayı üretimi de bozuktu. OpenClaw, güvenlik açısından kritik işlem yollarında sistem saatiyle tohumlanan bir PRNG olan math/rand kullanıyordu. Araştırmacılar, arka arkaya iki token değerinin iç durumu yeniden oluşturmaya ve gelecekteki tüm token ile sorgulama değerlerini tahmin etmeye yettiğini gösterdi. Bazı kod yollarında bu durum, cüzdan anahtarının kurtarılmasına kadar uzanıyordu.

Hepsinden kötüsü, bir politika katmanının hiç olmamasıydı. Prompt enjeksiyonu ile fon transferi arasında hiçbir şey yoktu. Sıfır müdahale.

Çıkarılacak ders: Genel amaçlı yapay zeka ajanı mimarileri Web3 işlemleri için güvenli değil.

Mevcut Yapay Zeka Ajanı Mimarilerindeki Temel Kusur

Bu sorun yalnızca OpenClaw'la sınırlı değil. Model değiştirmek ya da daha sıkı promptlar yazmak sorunu çözmüyor. Mevcut yapay zeka ajanı mimarileri, özünde bir güvenlik açığı taşıyor: LLM'nin kendisi kalıcı olarak açık bir saldırı yüzeyi.

Temel neden: LLM'ler talimatları veriden ayırt edemiyor. Sistem promptları, kullanıcı mesajları, web sayfası içerikleri, hatta bir token'ın adı bile aynı token akışı olarak geliyor. Modelin "bunu çalıştır" ile "bunu sadece oku" arasında güvenilir biçimde ayrım yapacak bir mekanizması yok. Bundan üç sonuç doğuyor.

Birincisi, model katmanında prompt enjeksiyonu çözümsüz. Saldırganlar, ajanın tükettiği her şeye talimat gizleyebilir: e-postalar, sözleşme yorumları, web sayfaları, token adları. Ajan işlem imzalayabiliyorsa, başarılı bir enjeksiyon şakayı hırsızlığa dönüştürür.

İkincisi, ajanın kendi Skills tabanlı güvenlik incelemesi manipüle edilebilir. İşlem güvenliğini değerlendiren bir LLM tamamen bağlama dayalı çalışır. Bağlamı zehirleyin, karar tersine döner. Kötü niyetli imzalar rahatlıkla geçer.

Üçüncüsü, ajanlar yedi gün yirmi dört saat çalışır, sürekli güvenilmez girdi tüketir ve özerk biçimde işlem gerçekleştirebilir. Saldırı penceresi hiç kapanmaz; tek bir ihlal anında fon kaybına yol açabilir.

Güvenlik camiasının genel kanaati şu: Prompt enjeksiyonunun kesin bir tedavisinin olmadığı bir dünyada LLM'ye özel anahtarlara doğrudan erişim vermek, kullanıcı varlıklarını her an ele geçirilebilecek bir bileşenin içinde bırakmak anlamına gelir. Model katmanı güçlendirilemiyorsa, risk mimari katmanda kontrol altına alınmalı. Modelin tamamen ele geçirilmesi bile kullanıcı fonlarını hareket ettirebilmemelidir.

Web3 Companion'ın güvenlik mimarisi tam olarak bu fikir üzerine inşa edilmiş.

Tehdit Modeli: Ajan Güvenilmezdir

Web3 Companion'ın tehdit modeli tek cümleye sığıyor: Ajanın kendisi güvenilmezdir. Tüm mimari, ajanın her an ele geçirilebileceği varsayımı üzerine kurulu.

Ajanı her saldırıyı fark edecek kadar sağlam kılmaya çalışmıyoruz. Yukarıda gösterildiği gibi, model düzeyinde savunma işe yaramıyor. Bugün Mors kodu enjeksiyonlarını yakalamak için eğitin; yarın saldırganlar Base64'e, görüntülerdeki steganografik metne ya da masum görünümlü bir PDF'e geçer. Bunun yerine varsayımı tersine çevirdik. Ajan tehdit modelinin içinde yer alıyor, sistemin geri kalanı ise onu kontrol altında tutmak için tasarlandı. Bir saldırgan ajanı tamamen ele geçirse bile kullanıcı varlıkları güvende kalıyor. Tek satırlık konumlandırma: Güvenli Agentic Cüzdan — kendi ajanını varsayılan olarak güvenilmez kabul eden ve her koşulda güvenli kalan bir cüzdan.

Bu tehdit modelinden beş tasarım ilkesi türettik.

İlke 1: Ajan özel anahtarlara hiçbir zaman dokunamaz. Özel anahtarlar, zincir üstü varlıkları kontrol eden tek kimlik bilgisidir. Ajan bunları okuyabilirse, bir ele geçirme anahtarların kaybı demektir. Anahtarlar, ajanın mimari olarak ulaşamayacağı bir yerde bulunmalıdır.

İlke 2: Hazırlık, yetkilendirme değildir. İşlem oluşturmak ve onu onaylamak birbirinden ayrı eylemlerdir. Ajan, kullanıcıların zincir üstü durumu anlamasına ve niyetleri bir araya getirmesine yardımcı olabilir; ancak imzalama kararı, ajanın erişemeyeceği bağımsız bir arka uç modülüne aittir.

İlke 3: İnceleme tespit içindir, zorlama için değil. İşlem simülasyonu, calldata analizi ve adres etiketleme yaygın saldırı kalıplarını yakalar ve kullanıcıların riski anlamasına yardımcı olur; ancak bunlar nihai karar değildir. Simülasyonlar başarısız olabilir, etiketler eksik olabilir ve LLM'nin kendi analizi prompt enjeksiyonuna karşı savunmasızdır.

İlke 4: Sert politikalar son savunma hattıdır. Diyelim ki bir ajan 100.000 dolarlık bir transferi başlatmak için kandırıldı ve güvenlik incelemesi bunu onaylamak üzere manipüle edildi. Kodla zorlanan günlük 1.000 dolarlık limit yine de bunu engeller. Ajanın bu limitleri değiştirme yetkisi yoktur.

İlke 5: Kanıt yoksa yürütme de yok. Başarısız bir tarama geçiş değildir. Eksik veri "güvenli" anlamına gelmez. Güvenlik kanıtı yoksa, çelişkiliyse, eskiyse veya yetersizse sistem durur ve açık kullanıcı onayını bekler.

Bu beş ilke iki güvenlik modülü aracılığıyla hayata geçiriliyor: özel anahtar güvenliği ve işlem güvenliği.

Özel Anahtar Yalıtımı: Ajan Tarafından Mimari Olarak Erişilemez

İlk sorun basit. Zincir üstü işlemleri hazırlayan bir asistan istiyoruz; ancak ona imzalama yetkisi vermek, gerçek parayı hareket ettirme gücünü de devretmek anlamına geliyor. 2025 ve 2026'daki neredeyse her Web3 ajanı ihlali aynı senaryoyu izledi: özel anahtarlar ajan sürecinin içinde bulunuyordu ve saldırganlar bunları çıkarmanın bir yolunu buldu.

Bu yüzden soruyu yeniden çerçeveledik: ya ajan gerçekten imzalayamazsa? "İmzalamaması söylenmiş" değil, mimari olarak imzalayamıyor. Yazılım düzeyindeki erişim kontrolleri her zaman atlatılabilir. Daha güçlü bir şeye ihtiyacımız vardı.

Web3 Companion, süreç düzeyinde yalıtım uygular. Özel anahtarlara yalnızca bir bileşen dokunur: bağımsız bir Go süreci olan Güvenli İmzalama Modülü (SSM). Ajanın süreç belleği, ortam değişkenleri ve dosya sistemi sıfır anahtar materyali barındırır. Ajanın gördüğü tek şey bir işlem niyeti kimliğidir. SSM'den bu niyeti imzalamasını isteyebilir, ancak arkasındaki anahtarı asla göremez.

Anahtar depolama için üç seçeneği değerlendirdik. Diskte düz metin: bir disk okuması anahtarı anında açığa çıkarır. Reddedildi. Paroladan türetilmiş şifreleme: uzun süreli çalışan bir Docker hizmeti için pratik olmayan, her yeniden başlatmada yeniden giriş gerektirir. Reddedildi. Zarf şifrelemesini seçtik: her cüzdan anahtarı kendi veri anahtarıyla şifrelenir ve bu veri anahtarı bir ana anahtarla (AWS KMS veya yerel AES-256) sarılır. Şifrelenmiş dosyalar toptan sızdırılsa bile, ana anahtar olmadan işe yaramazlar. Anahtarlar yalnızca SSM belleğinde kısa süreliğine düz metin olarak bulunur ve imzalamadan hemen sonra sıfırlanır.

Her imzalama isteği aynı yolu izler. Hızlı yol yok, kısayol yok. Bir işlem sırayla yedi adımdan geçer: yetki devri kontrolü, simülasyon, güvenlik kontrolü, ajan güvenlik incelemesi, politika değerlendirmesi, Passkey onayı ve son olarak SSM imzalama. Bir adımı tamamlamak bir sonrakini atlamaz.

Belirtmeye değer düşük seviyeli bir ayrıntı: sistemdeki her rastgele bayt (özel anahtar üretimi, AES-GCM nonce'ları, kimlik doğrulama token'ları, WebAuthn zorlukları) işletim sisteminin kriptografik rastgele kaynağı olan crypto/rand'dan gelir. math/rand, tüm güvenlik açısından kritik kodlarda testler ve CI tarafından zorlanan bir kural çerçevesinde yasaklanmıştır.

İşlem Güvenliği: Dört Katmanlı Derinlemesine Savunma

Özel anahtar yalıtımı, anahtar güvenliğini kapsar; ancak işlem düzeyindeki riskler devam eder. Ele geçirilmiş bir ajan, kullanıcıları kandırmak veya otomatik imzalama politikalarını atlatmak amacıyla tamamen meşru görünen bir işlem niyeti oluşturabilir. Prompt enjeksiyonu özel anahtara ihtiyaç duymaz; yalnızca sistemin normal akış üzerinden kötü niyetli bir işlemi imzalamasını sağlaması yeterlidir.

Temel soru: işlemleri hazırlayan ajanın kendisi ele geçirilmiş olabilecekken, kötü niyetli bir işlemi nasıl tespit edersiniz?

Hiçbir tek savunma katmanı tek başına yeterli değildir. Yalnızca simülasyon mu? Simülasyonlar başarısız olur, RPC'ler çöker, yeni saldırılar bilinen kalıpların dışında kalır. Yalnızca LLM tabanlı inceleme mi? Ajanı ele geçiren enjeksiyon inceleyiciyi de ele geçirir; çünkü ikisi de LLM üzerinde çalışır. Yalnızca sabit bir sert limit mi? Meşru kullanıcılar duvara çarpar; her takas için 100 dolarlık bir üst sınır kullanılamaz hale gelir.

Dördünü birlikte katmanlıyoruz. Her katman, kendisinden önceki her katmanın zaten çökmüş olduğunu varsayıyor.

Katman 1: İşlem Simülasyonu. İmzalamadan önce sistem yürütmeyi simüle eder: calldata çözme, geri dönme tahmini, alan biçim kontrolleri. Simülasyon belirgin sorunları yakalar, ancak kör noktalara sahiptir. Yeni saldırı teknikleri ve RPC kesintileri onu bozabilir.

Katman 2: Karşı Taraf Değerlendirmesi. Bir dizi statik kontrol karşı tarafı hedef alır: alıcı/miktar eşleştirme, sınırsız onay tespiti, yakma adresi tespiti, beklenmedik temsilci çağrıları. Adres risk puanlaması, BlockSec'in x402 uyumluluk hizmeti üzerinden çalışır; ajan, API anahtarı veya abonelik gerektirmeksizin x402 mikro ödemeleriyle etiket ve risk puanı sorgular. 1. ve 2. katmanlar birlikte yaygın sorunların büyük çoğunluğunu yakalar; ancak ikisi de atlatılabilir. Rolleri kasıtlı olarak tespit ve açıklama ile sınırlandırılmış, nihai karar vermekle değil.

Katman 3: Sert Politika Zorlama. Go dilinde saf kod uygulaması. LLM dahil değil ve ajan kuralları değiştiremiyor. İşlem başına üst sınırlar, günlük bütçeler, alıcı beyaz listeleri, otomatik imzalama eşikleri: 100 dolarlık işlem başına limit karşısında 5.000 dolarlık bir transfer anında reddedilir. Politikayı değiştirmek Passkey gerektirir. Neden? Ajan politikaları düzenleyebilseydi, bir enjeksiyon önce limiti yükseltir, sonra cüzdanı boşaltırdı. Otomatik imzalama varsayılan olarak kapalıdır; kullanıcı açıkça etkinleştirene kadar her işlem manuel onay gerektirir.

Bu, tüm tespit katmanları atlatılsa ve tamamen ele geçirilmiş bir ajan kötü niyetli bir işlemi imzalasa bile, gerçek kaybın politikayla sınırlandırıldığı anlamına gelir. Kullanıcı günlük otomatik imzalama eşiğini 500 dolara ayarlamışsa, en kötü senaryodaki kayıp 500 dolardır; tüm cüzdan değil. Politika katmanı, bir ele geçirme olayını felaket boyutlu bir olaydan sınırlı bir kayba dönüştürür.

Katman 4: Kullanıcı Onayı (Passkey). Politika manuel onay gerektirdiğinde, sistem WebAuthn doğrulaması (parmak izi veya yüz) ister. Hiçbir yalnızca yazılım tabanlı saldırı bunu taklit edemez.

Dört katman karşılıklı güvensizlik üzerine işler. Her biri, kendisinden önceki her şeyin zaten başarısız olduğunu varsayar. Mükemmel simülasyon politikayı gevşetmez. Yanlış yapılandırılmış politika Passkey'i atlamaz. Her katman kendi başına ayakta durur.

Gözden kaçırılması kolay bir ayrıntı: karar yeniden kullanımı. Bilinen bir DeFi saldırı tekniği, eski bir güvenlik kararını değiştirilmiş bir işleme karşı yeniden oynatır. Web3 Companion, her yazma işlemini denetlenebilir durum geçişleri olan benzersiz bir işlem niyetine bağlar. Bir güvenlik kararı yalnızca incelediği tam niyete uygulanır. Ajan bir işlemi yeniden oluşturursa, yalnızca tutarı veya alıcıyı değiştirse bile, sistem bunu yepyeni bir niyet olarak ele alır ve tüm kontrolleri yeniden çalıştırır.

Dört savunma katmanı, üç bağımsız güven sınırıyla örtüşür: Özel Anahtar, Politika ve Passkey. Herhangi bir tek sınırın ihlali diğer ikisini ayakta bırakır:

Tasarım Gereği Güvenlik: Açık Kaynağın Arkasındaki Felsefe

BlockSec, ilk günden beri zincir üstü güvenlik üzerine çalışıyor. Milyarlarca dolarlık zincir üstü varlığı koruduk ve aynı dersi tekrar tekrar gördük: mimariye başından yerleştirilmeyen güvenlik her zaman çok geç gelir.

Yapay zeka ajanları, zincir üstü işlemlere açılan yeni bir kapı haline geliyor. Alan hızla ilerliyor, ancak güvenlik standartları neredeyse yok. Çoğu ekip ajanlarının neler yapabildiğine odaklanıyor. Bu ajan ele geçirilirse, mimari hasar yarıçapını sınırlayabilir mi? sorusunu ciddiye alanlar ise çok az.

Web3 Companion, BlockSec'in yıllar içinde biriktirdiği zincir üstü güvenlik birikimini bir Agentic Cüzdan mimarisine aktarma çabasıdır. Kod, MIT lisansı altında tamamen açık (şu an araştırma önizlemesi olarak etiketlenmiş). Sektörün şimdi somut bir güvenlik tasarımı referans noktasına ihtiyacı var. Tehdit modellerini nasıl yapılandıracağınız, anahtarları nasıl yalıtacağınız, işlem savunmasını ne kadar ileri götüreceğiniz: hiçbir ekip bunları sıfırdan yeniden icat etmek zorunda kalmamalı. Topluluğun üzerine inşa edebilmesi için tasarımın tamamını yayımlıyoruz.