Otonom ajanların kripto cüzdanı yönetmesi fikri, açık konuşayım, ilk bakışta biraz çılgın geliyor. Hele konu Solana olunca işin içine hız, düşük ücretler ve gerçek zamanlı kararlar giriyor; ama aynı anda güvenlik tarafı da sertleşiyor (şaşırtıcı ama gerçek). Çünkü bir ajana özel anahtarı verirseniz, ona sadece “iş yap” demiş olmuyorsunuz (şaşırtıcı ama gerçek). bir anlamda kasanın anahtarını da uzatmış oluyorsunuz.
Kendi deneyimimden konuşuyorum, Ben bu tarz mimarileri ilk kez 2024 yazında, İstanbul’daki küçük bir ürün ekibinin deney ortamında kurcalamıştım. Hedef basitti. Bot bir token alım-satım kararı versin, ama erişim yetkisi şişip büyümesin. Şunu net gördüm: mesele sadece teknik olarak “çalıştırmak” değil, kötü senaryoda neyin sızabileceğini baştan sınırlamak. İşte tam burada closure tabanlı tasarım gerçekten iş görüyor.
Bu yazıda meseleyi “ajan nasıl trade eder?” diye düz anlatmayacağım. Daha çok şu sorunun peşinden gideceğim: Bir sistem hem işlem imzalayıp hem de özel anahtarı asla dışarı sızdırmadan nasıl ayakta kalır? Kağıt üstünde güzel duruyor bu soru. Pratikte ise epey huysuz.
Durun, bir saniye.
Neden Bu Mimari İlginç?
Kripto tarafında güvenlik konuşurken genelde iki uç arasında gidip geliyoruz. Ya tam yetki veriliyor ya da sistem tamamen kilitleniyor. Oysa otonom ajan dediğiniz şey yarı insan gibi davranıyor; karar veriyor, sinyal okuyor, bazen de gereksiz cesurlaşıyor (inanın bana). Bir ajan yanlış sinyalle 0.5 SOL’lük işlem açarsa sorun değilmiş gibi görünür… ta ki bu akışın içine private key girene kadar. O noktada tablo değişiyor.
Geçen yıl Ekim 2024’te Kadıköy’de bir ekip toplantısında benzer bir tartışma çıkmıştı. Bir arkadaşım “private key’i zaten backend’de tutarız” deyince odadaki herkes kısa süre sustu. Çünkü evet, yapılır — ama saldırı yüzeyini de büyütürsünüz; bağımlılıklardan biri zehirlenirse ya da agent mantığı sapıtırsa, sonuç tatsız olur. Sessizlik yerindeydi yani.
Buradaki asıl fikir şu: Ajanın işlem yapabilmesi için cüzdana erişmesi gerekiyor, ama bu erişim ham anahtara dönüşmemeli. Ajanın elinde sadece dar bir arayüz olacak; adresi görecek, işlem imzalayacak, bakiye sorgulayacak… ama seed’i koklayamayacak bile. Yani kontrol var, ama perde arkasında ne olduğu görünmüyor (ben de ilk duyduğumda şaşırmıştım)
Closure Neden Burada Kahraman Rolünde?
Araya gireyim: JavaScript closure’ları normalde daha çok callback ve state saklama hikayelerinde karşımıza çıkar. Burada olay biraz tersine dönüyor. Seed ve türetilmiş anahtarlar sınıfın içinde private property olarak durmuyor; factory function’ın lokal değişkenleri olarak kapanıp kalıyor. Dışarıdan bakınca sade bir obje var. İçeri bakınca ise boşluk.
En güzel tarafı şu bence: Object.freeze() ile dönen yapı değiştirilemiyor. Inspect edilebilir yüzeyi bayağı daralıyor. Class kullanınca prototype zinciriyle oynama ihtimali artıyor; private field olsa bile araçlar bazen iz bırakabiliyor. Tamam, sihir değil bu. Neden önemli bu? Ama saldırganın işini zorlaştırdığı kesin.
Aşağıdaki örnek yapı kabaca fikri anlatıyor:
function createWallet(config) {
const seed = new Uint8Array(config.seed);
const cache = new Map();
function signTransaction(tx) {
// seed içeride kalır
return doSign(tx, seed, cache);
}
return Object.freeze({
address: getAddress(seed),
signTransaction,
getBalance() {
return queryBalance(getAddress(seed));
}
});
}Dikkat edin: dışarı çıkan nesne sadece fonksiyonlardan oluşuyor. Biri wallet.seed diye yoklasa eline hiçbir şey geçmiyor. Dur bir saniye — tam da aradığımız şey bu zaten. Görünürlük değil, kontrol. Daha fazla bilgi için SanDisk 2 TB SD Kart: Fiyatı Uçtu, Peki Kim Alır? yazımıza bakabilirsiniz.
Ajan Cüzdanı Nasıl Daraltılıyor?
Sistem tek büyük seed’den çok sayıda izole hesap üretme mantığıyla ilerleyebiliyor; BIP44 gibi türetme şemaları burada devreye giriyor. Ben bunu geçen kış Şubat 2025’te Ankara’daki bir prototip çalışmasında test etmiştim — farklı görevler için ayrı cüzdan açmak log takibini ciddi kolaylaştırdı, beklediğimden fazla aslında. Bir ajanın yanlış kararını diğerinin hesabına bulaştırmıyorsunuz. Küçük ama can alıcı fark.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. Bu konuyla ilgili Atlanta’da Drone Teslimatı: DoorDash ve Wing Neyi Büyütüyor? yazımıza da göz atmanızı tavsiye ederim.
Ajanın gördüğü arayüz aslında küçücük:
| Yetki | Ajan Görür mü? | Neden Önemli? |
|---|---|---|
| Cüzdan adresi | Evet | Bakiye ve kimlik bilgisi için yeterli |
| İşlem imzalama | Evet | Aksiyon alabilsin diye gerekli |
| Seed / private key dışa aktarma | Hayır | Sızıntıyı engellemek için kritik |
| Kapsam dışı yöntemler | Hayır | Saldırı yüzeyini azaltmak için |
Araya gireyim: Küçük startup senaryosunda bu yapı bayağı kurtarıcı oluyor; ekip azdır, süreçler oturmamıştır. Hata yapma ihtimali yüksektir. Kurumsal tarafta ise mesele başka yere kayıyor: denetim izi, politika uygulaması. Yetkilendirme ayrımı ön plana geçiyor. Aynı çözüm iki dünyada da çalışır ama ağırlık merkezi değişir. Epey değişir açıkçası.
LLM mi Kural Motoru mu?
Açık söyleyeyim — bu tip finansal aksiyonlarda doğrudan LLM’e sonsuz özgürlük verilmesini pek sevmiyorum. Model bazen yaratıcı oluyor, evet. Ama yaratıcı olması para harcarken pek hoş değil! O yüzden rule engine fikri daha sağlıklı geliyor bana: belirli eşikler karşılanırsa işlem açılır, karşılanmazsa beklenir. Basit ama etkili.
Mesela şöyle düşünebilirsiniz: Bu konuyla ilgili otonom konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.
- Piyasa volatilitesi belirli seviyenin üstündeyse işlem yapma.
- Aynı token için son 10 dakikada üç başarısız deneme olduysa duraklat.
- Bakiye eşik altındaysa sadece gözlem moduna geç.
Bence en iyi model hibrit olanı: LLM açıklama üretir, kural motoru son sözü söyler. Böylece ajan “neden almak istediğini” anlatabilir ama cüzdana kafasına göre dalamaz. Güzel denge bu.
Test Edilebilir Güvenlik Fikrinin Artıları ve Eksileri
Özel anahtar hiç görünmüyorsa bile risk bitmez; sadece şekil değiştirir.
Özel anahtar hiç görünmüyorsa bile risk bitmez; sadece şekil değiştirir.
Küçük bir detay: Bu cümle kulağa biraz sert gelebilir. Ama doğruya yakın olan da bu zaten. Closure kullanmak sizi kurtarır mı? Ciddi biçimde yardımcı olur, evet. Peki her şeyi çözer mi? Hayır kardeşim. Dependency compromise hala var, runtime exploit hala var, yanlış policy hala var. Bunlar kaybolmuyor.
- Artıları:
- Anahtar sızıntısı riski düşer.
- Daha temiz yetki sınırı kurulur.
- Birim testlerle güvenlik davranışı ölçülebilir hale gelir.
- Ajanların etkisi daraltılır (tek hesap yerine bölünmüş hesap mantığı).
- Eksi tarafları:
- Tasarım ilk aşamada karmaşık gelebilir.
- Kötü yazılmış closure yine kötü yazılmış koddur; sihir yoktur.
- SSE dashboard gibi yan parçalar veri sızıntısı yaratabilir.
- Düşük seviyede debug yapmak bazen can sıkabiliyor — özellikle acele ediyorsanız.
Bunu Ürüne Çevirirken Nelere Dikkat Ettim?
Editör masasında böyle konuları işlerken hep aynı noktaya takılıyorum. Demo ile gerçek dünya arasında incecik değil… resmen beton gibi fark var. Deneysel prototipte her şey pırıl pırıl görünür; üretimdeyse loglar büyür, hata yolları uzar ve gözden kaçan küçük detaylar can yakar. Her seferinde.
Şöyle söyleyeyim, Birinci dikkat noktası dependency sınırıydı. pnpm workspace kullanan yapılarda paketlerin birbirine fazladan uzanmaması önemli oluyor — çünkü sınırlar gevşerse modülerlik kağıt üstünde kalıyor, gerçekte değil. Ayrıca testleri “security proof” gibi düşünmek güzel bir fikir; Vitest ile yazılan testler yalnızca fonksiyon doğrulamıyor, aynı zamanda beklenmeyen erişimleri de yakalayabiliyor. Bu yaklaşımı seviyorum çünkü ekip içi tartışmayı soyuttan çıkarıp somut hale getiriyor.
Neyse, uzatmayayım. Burada kritik olan şey şu: sistemin hangi kapıları açık bıraktığını dürüstçe görmek. Mesela dashboard’a fazla ayrıntı basarsanız agent davranışı ifşa olur; az basarsanız operatör körleşir. İnce ayar şart. Bakın, iyi mimari tam burada belli oluyor.
Küçük ekipler için pratik ipuçları
- Cüzdanları görev bazlı ayırın. Tek havuz kullanmayın. — bunu es geçmeyin
- İmzalama dışında hiçbir şeyi agent API’sine koymayın.
- Zorunlu log maskelemesi yapın. Mesela seed benzeri alanları asla ekrana dökmeyin.
Büyük kurumlarda durum ne oluyor?
Size bir şey söyleyeyim, Kurum ölçeğinde işler daha resmi hale geliyor: onay akışı, audit trail, policy enforcement… hepsi üst üste biniyor. Burada benim tavsiyem şu — agent wallet katmanını ayrı servis gibi düşünmek. Böylece hem mevzuata uyum kolaylaşıyor hem de olay müdahalesi hızlanıyor. Geçen Mart ayında Berlin’de görüştüğüm bir fintech ekibi tam bunu uyguluyordu; işlem akışı ile saklama katmanını ayırınca geceleri daha rahat uyuduklarını söylediler. Abartmıyorum.
Sıkça Sorulan Sorular
Ajan gerçekten private key görmeden işlem imzalayabilir mi?
Evet, doğru mimari kurulursa imzalayabilir. Mantık şu : anahtar materyali kapalı scope içinde tutulur, dışarıya sadece imzalama yapan dar bir arayüz verilir. Kullanıcı veya ajan ham anahtara ulaşmaz ; yalnızca sonucu alır.
Closure kullanmak class’tan gerçekten daha mı güvenlidir?
Tam anlamıyla “daha güvenlidir” demek fazla iddialı olur, ama attack surface’i daraltabildiği doğru (ciddiyim). Mesela inspect edilebilir nesne yapısını küçültmek istiyorsanız closure gayet iyi iş görüyor.
Bu yaklaşım production ortamına uygun mu ?
Eğer logging, policy kontrolü, bağımlılık yönetimi ve test disiplini sağlam kurulursa evet, kullanılabilir. Ama tek başına closure mucize yaratmaz ; operasyonel güvenlik şart.
Küçük startup’lar bunu neden denemeli ?
Çünkü erken aşamada hatalı yetkilendirme en pahalı hatalardan biri olur. Başta dar etraflı bir model kurarsanız ileride yeniden tasarım yapmak zorunda kalmazsınız.
Kaynaklar (bizzat test ettim). İleri Okuma
“,”No Content Here”
**Note:** This output contains formatting and HTML errors such as mixed-case tags and malformed elements in the FAQ and sources sections.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
