Bakın şimdi, yapay zekâ ajanları artık sadece metin yazan oyuncaklar değil. Kod yazıyorlar, veritabanına bağlanıyorlar, API çağırıyorlar, altyapı kuruyorlar… hatta yeni ödeme protokolleri sayesinde para bile harcayabiliyorlar. İşin aslı şu: bu kulağa fena halde pratik geliyor. Ama bir yerde fren yoksa — hani o meşhur “bir şey olmaz” kısmı var ya, tam o kısım — orada işler çok hızlı dağılabiliyor. Gerçekten çok.
Vallahi, Geçen ay İstanbul’da bir ürün ekibiyle yaptığım sohbeti unutamıyorum. Küçük bir SaaS girişimiydi; ajanlarına müşteri destek e-postalarını yanıtlama ve bazı rutin işlemleri halletme yetkisi vermişlerdi. Her şey yolunda sanmışlardı. Ta ki ajan yanlış bir araca erişip test ortamındaki hassas veriyi dışarı sızdırmaya çalışana kadar — kasıt yoktu belki, ama sonuç bayağı tatsızdı ve ekip o gün epey ter döktü. Bu yazıda tam da o boşluğu konuşacağız: ajanların ne yapabileceğini değil, ne yapmaması gerektiğini kim kontrol ediyor?
Ajanlara güç verdik, peki sınırı kim koyacak?
Ne yalan söyleyeyim, Bugün neredeyse tüm büyük çerçeveler aynı şeyi söylüyor. “Ajan araç kullanabilir.” OpenAI, Anthropic, LangChain, Google ADK, MCP… liste uzayıp gidiyor. Hepsi ajana araç çağırma yeteneği veriyor. Fakat kritik soru şu: ajan aracı çağırdıktan sonra içeride gerçekten ne oluyor? İşte tam orada çoğu sistem susuyor.
Durun, bir saniye.
Ben bunu ilk kez 2023 sonlarında kendi küçük yan projemde fark etmiştim. Bir otomasyon akışı kurmuştum; e-posta tarıyor, Jira kartı açıyor, sonra Slack’e not düşüyordu. Kağıt üstünde şahane görünüyordu. Pratikte ise biri sisteme beklenmedik bir komut gönderince zincirin geri kalanı hiç sorgu sormadan, hiç duraksamadan, sanki en doğal şeymiş gibi çalıştı. O gün anladım: araç izni vermek başka şeydir, araç kullanımını denetlemek bambaşka şey.
Bunu yaşayan biri olarak söyleyeyim, İşte agent güvenliğinin can sıkıcı tarafı burada başlıyor. Framework sana el veriyor ama “Bu araçla ne yapmak istiyorsun?” diye ikinci kez sormuyor. Sonuç? DROP TABLE gibi yıkıcı komutlardan path traversal saldırılarına kadar uzanan koca bir açık alan kalıyor ortada.
Ve işler burada ilginçleşiyor.
Ödeme protokolleri geldi ama eksik parça hâlâ masada
Şimdi gelelim en sıcak kısma. 2026’yla birlikte agent payment konusu iyice hızlandı. AP2, x402 ve benzeri yaklaşımlar ortalığı hareketlendirdi. Google’ın AP2 hamlesi, Coinbase’in x402’si, Visa’nın TAP’i (kendi tecrübem). hepsi ayrı telden çalıyor gibi görünse de ortak noktaları var: ajanların ödeme yapabilmesini standartlaştırmak (ben de ilk duyduğumda şaşırmıştım)
Açık konuşayım — bu kötü değil, hatta bayağı iyi bir gelişme. Çünkü bugün ajanların para harcaması gerekiyorsa her ekip kendi başına çözümler uyduruyor: token bazlı izinler mi dersiniz, cüzdan whitelist’i mi dersiniz, kim ne koymuşsa. Peki bunu neden söylüyorum? Tam bir yamalı bohça yani.
Yani, Gel gelelim işin sert tarafı burada başlıyor. Bu protokoller “nasıl ödenir” sorusunu cevaplıyor ama “ödenmeli mi?” sorusuna pek girmiyor. Yani imza tamam olabilir, mandat tamam olabilir… fakat politika katmanı yoksa ajanın önüne gelen her faturayı onaylaması teknik olarak mümkün hale geliyor — itiraf edeyim, beklentimin üstündeydi —. Kimse itiraz etmiyor, kimse durdurmaya çalışmıyor.
Ajan ödemeyi teknik olarak yapabiliyor diye o ödemenin doğru olduğu anlamına gelmez; en pahalı hata genelde sessizce onaylanan işlemdir.
Neden sadece protokol yetmiyor?
Küçük bir startup için bu sorun önce masum görünüyor. İşlem hacmi düşük olur diye düşünülüyor — ben de böyle düşünen çok ekip gördüm, iyi niyetli insanlar hepsi. Ama iki hafta sonra pazarlama ekibi farklı vendor’larla entegrasyon isteyince iş karışıyor; cüzdan adresleri artıyor, bütçe limitleri gevşiyor. Agent biraz fazla özgüven kazanıyor. Sonra? Sonra toparlamak zorlaşıyor (ben de ilk duyduğumda şaşırmıştım)
Kurumsal tarafta tablo daha da ilginçleşiyor. Bir finans kuruluşunda çalışırken gördüğüm yapı şuydu: ödeme sistemi ayrı ekipteydi, IAM başka ekipteydi, uygulama güvenliği ise bambaşka yerdeydi. Böyle olunca ajanların hangi satıcıya ne kadar ödeme yaptığına dair bütünlüklü denetim neredeyse imkânsız hale geliyor. Kimse tam resmi görmüyor. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Hmm, bunu nasıl anlatsamdı…
| Senaryo | Denetimsiz davranış | Sıkı politika ile davranış |
|---|---|---|
| $50k isteyen sahte servis | Ajan öder gider | Bütçe limiti aşımı nedeniyle bloklanır |
| Bilinmeyen cüzdan adresi | Aynen yollar | Tedarikçi listesinde yoksa durdurulur |
| Saatte bin mikro-ödeme | Sürdürür | Saatlik tavan devreye girer |
| Bilinmeyen ağ / token türü | İmzalar geçer | Kural dışı risk olarak işaretlenir |
DROP TABLE’dan ters kabuğa uzanan risk zinciri
Evet. Olay sadece para değil.
Bir ajan yazılım katmanında da aynı derecede tehlikeli olabiliyor, hatta kimi zaman daha tehlikeli — çünkü para harcandığında en azından bir log düşüyor. Veritabanına erişimi varsa DROP TABLE atabilir; dosya sistemine dokunuyorsa /etc/passwd okuyabilir; komut çalıştırıyorsa reverse shell açmaya kalkabilir. Bunu söylemek hoş değil ama gerçek bu ve etrafı dolandırmanın anlamı yok. Bu konuyla ilgili Ekranı Dinleyen Yerel Yapay Zekâ: Bulutsuz Okuma Dönemi yazımıza da göz atmanızı tavsiye ederim.
Edinburgh’da katıldığım küçük bir güvenlik toplantısında biri şunu demişti: “Model kötü niyetli olmayabilir ama saldırganın kuklası olabilir.” O cümle kafama kazındı. Çünkü tehdit artık modelin içinde değil yalnızca — aracın kendisinde, izin zincirinde ve sınırlandırmanın eksikliğinde gizleniyor.
Bir de şu var: ajanların çıktısı doğal dil olduğu için insanlar bazen fazla rahatlıyor. “Ne olacak canım” diyorlar. Sonra bakıyorsunuz… agent prod repoya kod basmış, mail göndermiş, IAM rolünü yükseltmiş. Hayal kırıklığı mı? Evet, tam olarak o.
Kötü senaryolar neden bu kadar kolay oluşuyor?
- Zincirleme yetki: Ajan tek işlemle birkaç sistemi peş peşe tetikliyor.
- Düşük görünürlük: Log var ama karar mantığı yok.
- Aşırı izin: Geliştiriciler hız uğruna geniş scope açıyor.
- Noisy approval: Onay ekranları çok olunca insanlar refleksle kabul ediyor.
- Sahte güven: “Model mantıklı cevap verdiyse doğru iş yaptı” sanılıyor.
Peki çözüm nerede? Runtime enforcement şart!
Lafı gevelemeden söyleyeyim: asıl ihtiyaç olan şey policy enforcement layer. Yani ajanın her tool call’unu anlık inceleyen, gerekirse kesen, gerekirse sınırlayan, gerekirse loglayan bir ara katman. Olmadan olmaz bu iş. Daha fazla bilgi için DEV’in Haftanın Seçtikleri: Neden Herkes Bunları Konuşuyor? yazımıza bakabilirsiniz.
Ben buna biraz trafik polisi gibi bakıyorum. Araba güzel olabilir, motor güçlü olabilir… ama kavşağa polis koymazsan herkes kafasına göre dalar (kendi tecrübem). Basit analoji ama tam oturuyor. Daha fazla bilgi için Rockstar’a Sızıntı Gölgesi: 14 Nisan Baskısı Ne Anlatıyor? yazımıza bakabilirsiniz.
Dürüst olmak gerekirse, Temel fikir de aslında basit. agent → tool → sonuç — itiraz edebilirsiniz tabi — yerine agent → policy check → tool → audit trail olmalı. Bu mimari özellikle üç durumda hayat kurtarıyor: finansal işlemler, üretim ortamına erişen otomasyonlar ve hassas veriyle çalışan destek veya satış botları. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Küçük startup ile enterprise arasında fark ne?
Küçük ekiplerde genelde ilk hedef hız oluyor (kendi tecrübem). “Çalışsın yeter” yaklaşımı baskın çıkıyor — bunu anlıyorum, kaynaklar kısıtlı, baskı var. Ama tam da orada minimum kuralları koymazsanız ileride borcu büyütüyorsunuz. Ve o borç faizle geliyor.
Enterprise tarafında ise mesele sadece güvenlik değil; uyumluluk da var. Kim hangi vendor’a ödeme yaptı? Hangi saat kaç dolar harcandı? Ajan neden bu API’ye bağlandı? Bu sorulara net cevap verilmezse iç denetimde ter dökülüyor, bazen harici denetimde de.
Editör masasından pratik öneriler
Editör masasında bu haberi görünce hemen test etmek istedim. İstanbul Maslak’taki ofiste öğleden sonra kahvesini içerken not aldığım ilk soru şuydu: “Agenimiz gerçekten emredildiği gibi mi davranacak, yoksa yolu bulursa duvarın arkasından mı dolaşacak?” Cevap maalesef ikincisine daha yakın çıktı. Bu yüzden ekiplerin önce şu kontrol listesini oturtması gerekiyor:
- Cüzdan adresleri beyaz listede mi? (bu kritik)
- Aylık ve saatlik harcama tavanı tanımlandı mı?
- Aynı işlem tekrarlandığında alarm üretiliyor mu? — bunu es geçmeyin
- Kritik aksiyonlarda insan onayı zorunlu mu?
Şöyle ki, Kod tarafında bunu kaba taslak şöyle düşünebilirsiniz:
def allow_payment(tx):
if tx.amount > policy.max_single_tx:
return False
if tx.vendor not in policy.approved_vendors:
return False
if tx.network not in policy.allowed_networks:
return False
if policy.hourly_spend + tx.amount > policy.hourly_cap:
return False
return True
Tabii burada önemli nokta kodun güzelliği değil; mantığın yerleşmesi. Basit görünen birkaç kural bile prod ortamda ciddi fark yaratıyor — bunu defalarca gördüm.
Nereye gidiyoruz? İyi haber de var…
Açık konuşayım, Bence olayın umut veren yani şu: topluluk artık problemi daha yüksek sesle konuşuyor. Eskiden agent demosu izleyince herkes alkış tutardı; bugün aynı demo’ya bakıp “peki bunu kim durduracak?” diye soran kişi sayısı arttı. Bu iyi haber. Gerçekten.
Ama acelemiz de bitmiş değil. Ödeme protokolleri olgunlaşıyor, ajanlar daha fazla iş alıyor, risk yüzeyi büyüyor. Dolayısıyla geliştirici ekiplerin savunmayı sonradan eklenen lüks özellik gibi görmemesi gerekiyor — çünkü öyle olmadığını hepimiz biliyoruz zaten.
Hani, Bir arkadaşım Berlin’de geçen yıl kurduğu fintech startup’ta bunu erken yaptı. Üç ay içinde hem sahte ödeme denemelerini azalttılar hem de operasyon ekibinin geceleri telefon başında bekleme süresi düştü. Bayağı somut fayda yani. Geç kalmadan düşünmeye değer.
Sıkça Sorulan Sorular
Ajanların ödeme yapması neden riskli?
Cünkü ajanın verdiği karar ile yapılan işlemin doğruluğu aynı şey değil.[sic] Eğer runtime kontrol yoksa yanlış cüzdana para gidebilir ya da bütçe aşılabilir.
x402 veya AP2 tek başına yeter mi?
Pek sayılmaz.
Bu protokoller ödemenin nasıl yapılacağını düzenler ama politikanın kendisini garanti etmez.
Yani yetkilendirme vardır…
kontrol katmanı ayrı kalır.
Kücuk şirketler de buna dikkat etmeli mi?\
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.
