# Agentic cüzdan güvenliği: gerçekte ne ters gidiyor

> Arkasında kanıt olan başarısızlıklar ile yalnızca istatistiği olanlar ayrı ayrı. Çok alıntılanan bir rakam incelemeye dayanmıyor.

- Source: https://defiloops.com/tr/blog/agentic-wallet-security-what-actually-goes-wrong
- Published: 2026-06-02
- Category: Security
- Tags: agentic-wallet, ai-agents, security, prompt-injection
- Author: DeFiLoops

---
Agentic cüzdan güvenliğini aratın; aynı rakamların, çoğu zaman nereden geldiğine dair bir
bağlantı olmadan, onlarca sayfada tekrarlandığını görürsünüz. Bazıları sağlam. En az biri
kontrol edilir edilmez dağılıyor.

Kanıtın gerçekte desteklediği şey bu; desteklemediği yerler de burada.

## Ayakta kalmayan rakamla başlayalım

Bu kategorinin en çok alıntılanan rakamı, **2026'nın yalnızca ilk çeyreğinde yapay zekâ ajanı
protokol zafiyetlerine 45 milyon doların üzerinde kayıp verildiği**. İzini sürene kadar biz
de alıntıladık.

O toplamın yaklaşık 40 milyon doları tek bir olay: Solana portföy yöneticisi Step Finance'in
Ocak 2026 ihlali. Ajan güvenliği yazılarında bu, izinleri fazla geniş olduğu için yetkisiz
transfer yapan ajanlar olarak geçiyor.

Birincil kaynaklar başka bir şey söylüyor.

<Quote cite="Step Finance olayına dair haberler">
  İhlal herhangi bir akıllı sözleşme zafiyeti içermiyordu; yönetici donanımındaki uç nokta
  ihlalleri dahil operasyonel zayıflıklardan kaynaklandı.
</Quote>

Saldırganlar yönetim ekibi üyelerinin cihazlarını ele geçirip hazine ve ücret cüzdanlarına
ulaştı. Bu bir dizüstü bilgisayar ve oltalama hikâyesidir ve hiç ajanı olmayan bir şirkete de
olurdu.

<Callout type="danger" title="Yani “ajan protokol zafiyetleri” toplamının kabaca %89’u o değil">
  Bu küçük bir düzeltme değil. 45 milyon dolarlık sorunu olan bir kategori ile en büyük
  doğrulanmış kaybı üç büyüklük mertebesi daha küçük olan bir kategori arasındaki farktır.
  Riski manşet rakamdan ölçen herkes yanlış şeyi ölçüyor.
</Callout>

Bundan iki şey çıkar. Birincisi, bu alandaki her rakamın kaynağını kontrol etmelisiniz —
bizimkiler dahil. İkincisi, gerçek başarısızlık biçimleri toplamın ima ettiğinden daha
belirli ve daha ilginç.

## Arkasında kanıt olan başarısızlıklar

### 1. İstem enjeksiyonu, kimsenin şüphelenmediği bir kodlamayla

En net belgelenmiş vaka Mayıs 2026'da 150.000 dolara mal oldu. Saldırgan, yapay zekâ entegre
bir cüzdana bir üyelik NFT'si gönderdi; bu, cüzdanı sessizce daha yüksek bir izin katmanına
taşıdı. Ardından X'te, içine **Mors alfabesiyle** talimat gizlenmiş bir yanıt paylaştı. Ajan
kodu çözdü, meşru bir komut sayıp transferi yetkilendirdi.

Açık yok. Çalınmış anahtar yok. Model, kimsenin filtrelemeyi düşünmediği bir biçimde,
nazikçe rica edildi.

<Callout type="warn" title="Kodlamaları sayıp bitiremezsiniz">
  Mors işe yaradı. Base64 de yarayacak, bir görsel de, bir homoglif de, korumaların hiç
  sınanmadığı bir dil de. Bir çözme ya da çeviri katmanından geçen her metin, potansiyel
  olarak enjekte edilmiş sayılmalı; çünkü baypas o katmandır.
</Callout>

Bunun bir adı ve numarası var: [OWASP LLM01:2025](https://genai.owasp.org/llm-top-10/), dil
modeli uygulamalarının bozulma biçimlerinin standart listesindeki ilk madde.

### 2. Aşırı yetki — maliyeti belirleyen yarı

Aynı olay aynı zamanda LLM06:2025. İkna edilmek ile eyleyebilmek aynı andı: model talimata
inandığı anda, o inanç ile saldırganın adresine giden transfer arasında hiçbir şey yoktu.

<Compare left="İstem enjeksiyonu" right="Aşırı yetki" verdict>
  <Fragment slot="left">
    Bunu kimse çözmedi. Modelin kandırılabileceğini varsayın, çünkü kandırılabilir.
  </Fragment>
  <Fragment slot="right">
    Bu bir model sorunu değil. Çevredeki sistemin neyin yazılmasına izin verdiğiyle ilgili
    bir soru — ve bu bir araştırma problemi değil, bir tasarım kararı.
  </Fragment>
</Compare>

Manşetleri ilk başarısızlık alır. Maliyeti ikincisi belirledi.

### 3. Bir filo boyunca paylaşılan kimlik bilgileri

[900'den fazla uygulayıcıyla yapılan ankete göre](https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control),
**ekiplerin %45,6'sı ajanlar arası kimlik doğrulama için hâlâ paylaşılan bir API anahtarı**
kullanıyor; %27,2'si ise elle yazılmış yetkilendirme mantığı.

Her ajan aynı kimlik bilgisini sunduğunda bir eylemi birine atfedemezsiniz; dolayısıyla
birini durduramazsınız. Ele geçirilme, kuruluşu gereği ya hep ya hiçtir.

### 4. Model değil, araç protokolü

Bildirilen olayların çoğunda saldırı yüzeyi modelin akıl yürütmesi değildi. Tesisattı:
ajanların dış araçları çağırmak için kullandığı protokoller ve turlar arasında taşıdıkları
bellek. Bir ajanın okuduğunu zehirlerseniz, düşündüğünü yenmenize gerek kalmaz.

En az konuşulan ve muhtemelen en önemlisi bu; çünkü ekiplerin saldırı yüzeyi değil altyapı
saydığı kısım burası.

## Bunların hiçbiri şu değil

Agentic cüzdanlara atfedilen ama aslında ajanlarla ilgisi olmayan başarısızlıkları da
adlandırmakta fayda var:

<Spec rows={[
  ['Uç nokta ihlali', 'Birinin dizüstü bilgisayarı. Ajanlar olmadan da olurdu. Kategorinin şimdiye kadarki en büyük kaybı'],
  ['Bir işletmeciyi oltalamak', 'Aynı kategori. Yığında bir ajan olması hiçbir şeyi değiştirmez'],
  ['Sıradan sözleşme hataları', 'Ajanın çağırdığı bir protokoldeki zafiyet, o protokolün zafiyetidir'],
]} />

Bunları bir araya yığmak kategorinin riskini şişirirken, belirli ve çözülebilir
başarısızlıkları görmeyi zorlaştırıyor.

## Riski gerçekten ne azaltır

Daha çok filtreleme değil. Daha az ifade gücü.

<Quote>
  Enjeksiyonu engelleyemezsiniz. İfade gücünü kaldırabilirsiniz.
</Quote>

Bir ajan rastgele işlem kurabiliyorsa, her kontrol birinin önceden hayal ettiği saldırılara
göre yargılanan bir filtredir. Ajan yalnızca kapalı bir listeden alınmış etiketli kutuları
doldurabiliyorsa — hedef adres kutusu ve veri yükü kutusu olmadan — "bana gönder" talimatının
yazılacağı bir yer yoktur ve hiçbir şeyin onu yakalaması gerekmez.

<Steps>
  <Step title="Ajanın neyi yazabildiğini sorun">
    Cevapta bir adres varsa, gerisi filtrelemedir.
  </Step>
  <Step title="Harcama limitinin nerede uygulandığını sorun">
    İşletmecinin arka ucundaki limit bir politikadır. Yalnızca sizin kontrol ettiğiniz bir
    hesaptaki limit, onların yükseltebileceği bir şey değildir.
  </Step>
  <Step title="Ele geçirilmiş bir ajanın maliyetini sayı olarak sorun">
    İyi bir cevap sizin belirlediğiniz bir rakamdır. Belirsiz bir cevap, kimsenin hesaplamadığı
    anlamına gelir.
  </Step>
  <Step title="Neyin, kim tarafından kanıtlandığını sorun">
    Kendini sınamanın değeri vardır. Denetim değildir ve ikisini birbirine karıştıran biri
    size bir şey anlatıyordur.
  </Step>
</Steps>

## Bizim cevabımız, rahatsız edici yarısı dahil

Buradaki ajan hiç anahtar tutmaz ve hedef adlandıramaz. Limitler hesabınızda yaşar ve bizim
tarafımızdan yükseltilemez. Ajanın ataması tek yönlüdür: hesabınız asla farklı bir ajana
yönlendirilemez, yalnızca hiçbirine.

Ve: koruma, izin verilenlerin değil yasaklananların listesi olarak çalışır. Devralmayı
tamamen engeller, ama kimsenin yasaklamayı düşünmediği bir eylem üzerinden değerin hareket
edebileceği her yolu engellemez. **Kendimize karşı bu türden dört saldırı kanıtladık**,
gerçek Base ağının bir kopyasında. **Dış denetim yoktur.** Keeper anahtarımızı tutan servis,
o anahtarı şu anda bellekte tuttuğu için üretim ayarında bilerek başlamayı reddediyor.

Bir sağlayıcının güvenlik sayfasında bu paragrafa benzeyen bir bölüm yoksa, o bölüm yine de
vardır — yalnızca yazılmamıştır.