Geçen ay bir ekip toplantısında, Londra’daki bir ürün yöneticisi bana “API’yi zaten bağladık, yapay zekâ da kullansın gitsin” dedi. Kulağa pratik geliyor, değil mi? Ama işin aslı şu: üretim sistemine bağlanan bir ajanı sadece “zekâ var ya, halleder” diyerek bırakınca ortalık çok hızlı karışıyor — bunu bizzat gördüm, birden fazla kez. Levi’nin yaptığı çalışma tam da bu can yakıcı noktayı gözler önüne seriyor; popüler API’leri MCP araçlarına dönüştürünce, güvenli görünen kapının arkasında düşündüğünüzden çok daha fazla yıkıcı işlem gizlendiği ortaya çıkıyor.
Stripe, GitHub, Twilio, Slack, Notion, Shopify… isimler tanıdık. Çoğu ekip için günlük ekmek gibi bunlar. Fakat bu servislerin ya resmi MCP sunucusu yok ya da sınırlı topluluk çözümleri var. Sonuç? Geliştiriciler tool tanımlarını elle yazıyor, auth işini kendileri bağlıyor. En kötüsü de ajanın eline pek çok CRUD setini veriyorlar. CRUD iyi güzel ama her düğmenin yanında kırmızı ışık yoksa sıkıntı büyüyor, büyüyor, büyüyor.
Asıl mesele MCP desteği değil
İlk bakışta problem “neden resmi MCP server yok?” gibi görünüyor. Evet, o da eksik bir parça — kimse inkâr etmiyor. Ama bence daha kritik nokta başka bir yerde: API spesifikasyonu ile risk sınıflandırması birbirinden çok farklı şeyler. OpenAPI dosyası sana endpoint listesini verir; hangisinin müşteri silebileceğini, hangisinin abonelik iptal edebileceğini kendi başına söylemez. Söylemez, çünkü söylemesi gerektiğini kimse düşünmemiş.
Editör masasında bu haberi ilk okuduğumda aklıma hemen 2024 baharında İstanbul’da yaptığımız bir iç test geldi. Küçük bir demo ajanına Slack ve GitHub araçları vermiştik; amaç “kanal özetle” idi, fakat yanlış prompt zincirinde ajan repository transferi gibi ağır işleri de görebiliyordu. Şanslıydık, prod’a çıkmamıştı… ama bu sefer konu şaka kaldırmıyor.
Bunu biraz açayım.
Neyse uzatmayalım. Levi’nin çalışmasının kıymeti tam da burada başlıyor. Adam oturmuş on yaygın API’nin açık spec’lerini almış, bunları MCP tool’lara çevirmiş — sonra da hangi endpoint’in veri sildiğine, abonelik kapattığına ya da erişimi geri alınamaz biçimde kestiğine tek tek bakmış. Emek isteyen iş bu, ama değiyor.
Rakamlar küçük değil, hiç değil
İtiraf edeyim, Kaba tabloyu görünce insan ister istemez duruyor. Toplamda 300’den fazla yıkıcı endpoint çıkıyor ortaya. Yani mesele birkaç unutulmuş DELETE çağrısı falan değil; bildiğin ciddi bir saldırı yüzeyi var karşınızda.
| API | Toplam Endpoint | Güvenli | Orta Risk | Yıkıcı | MCP Desteği |
|---|---|---|---|---|---|
| Stripe | 314 | 104 | 163 | 47 | Hayır |
| GitHub | 347 | 189 | 111 | 47 | Sadece topluluk |
| Twilio | 215 | — | — | — | — |
Tabloyu burada kesiyorum çünkü kaynak veri uzun; ama ana fikir net zaten. Stripe ve GitHub gibi devlerde bile onlarca silme, iptal, transfer işlemi var. Twilio’da mesaj silme veya telefon numarası bırakma; Shopify’da ürün ve sipariş temizleme; PagerDuty’de operasyonel alarm akışını alt üst etme… hepsi üretimde can sıkacak türden şeyler (ciddiyim). Şaşırtıcı mı? Biraz. Ama düşününce de mantıklı aslında.
Bazıları bunu “ajan zaten kullanıcının isteğini yerine getiriyor” diye geçiştiriyor. Açık konuşayım: hayır, bu yetmiyor. Bir insan operatörün bağlamla ayırdığı şeyi model her zaman ayıramıyor — hele ki prompt biraz gevşekse. Mesela “test verilerini temizle” dendiğinde canlı tenant ile sahte tenant arasındaki fark uçup gidebiliyor. Gitti mi de geri gelmiyor.
Nerede patlıyor? Gerçek dünya senaryosu aslında çok sade
Sadece okuma mı? Keşke öyle olsa…
Açık konuşayım, Ajanlar çoğu zaman bilgi çekmek için devreye giriyor gibi başlıyor işe. Sonra biri “bir de şu kaydı silsene” diyor ve süreç kayıp gidiyor. Ben bunu geçen sene Berlin’deki bir SaaS demosunda birebir gördüm; amaç müşteri notlarını toparlamakken, ajan yanlış filtreyle iki deneme hesabını askıya alma yoluna sapmıştı. Fark ettik, düzelttik. Ama fark etmeseydik? Agent’ler Ödeme Yaparken Kim Dur Diyecek?: Güvenlik Açığı yazımızda bu konuya da değinmiştik.
Evet, doğru duydunuz. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Klasik örnek Stripe tarafında görülüyor. delete_customer, cancel_subscription veya void_invoice gibi endpoint’ler açıkça tehlikeli olabiliyor. GitHub’da delete_org ya da transfer_repository varsa işin rengi iyice değişiyor. Bir ekip içinde böyle araçlar açıkta duruyorsa ve risk etiketi yoksa, ajanın tek bir hatası bile pahalıya patlayabilir. Çok pahalıya. Bu konuyla ilgili Base64, URL ve HTML: Üçü de Aynı Şey Değil yazımıza da göz atmanızı tavsiye ederim.
Bir ajana tüm API yüzeyini açmak biraz apartmanın anahtarını çilingire emanet etmek gibi… çilingir kötü niyetli olmayabilir ama siz yine de hangi kapıyı açtığını bilmek istersiniz.
Küçük startup ile enterprise aynı şey değil
Küçük startup tarafında genelde hız baskısı ağır basıyor. Anlaşılır. “Bir an önce çalışsın” yaklaşımı mantıklı bile geliyor bazen. Ama enterprise ortamda hukuk, uyumluluk ve operasyon üçlüsü sizi tokatlar — hem de sert tokatlar. Orada tek bir yanlış silme işlemi sadece teknik borç değil; bazen sözleşme ihlali demek oluyor.
Bence, Kendi deneyimimde en zor olan kısım teknikten çok organizasyonel oldu diyebilirim. 2023 sonbaharında Amsterdam’daki bir fintech bir düşüneyim… ekibiyle konuşurken herkes tool sayısını artırmak istiyordu. Ben ise tam tersini sordum: “Bunların kaçı gerçekten güvenli?” Cevap sessizlikti. İşte o sessizlik, bazen en dürüst cevaptır.
Neden elle klasman yapmak yetmiyor?
Lafı gevelemeden söyleyeyim: dokümantasyon iyi hazırlanmış olsa bile risk kategorisi çoğu zaman yazılı gelmiyor. Konu sadece HTTP method’u da değil aslında. DELETE genelde kötü kokar, evet — ama POST ile çalışan bazı uç noktalar da gayet yıkıcı olabiliyor (bu konuda ikircikliyim). Mesela ödeme iptali veya erişim kaldırma işi her zaman DELETE üzerinden gitmiyor. Gitmeyince de gözden kaçıyor. Kod Yazmaktan Kaçınırken: Yapay Zekâ Çağında Mühendislik yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
- sadece metoda bakmak yetmez;
- endpoint isim semantiği gerekir;
- false positive/false negative dengesi gerekir;
- manual review olmadan prod’a çıkmamalıdır;
- bazen kullanıcı onayı şarttır;
- bazen de rol bazlı kilit gerekir. — bunu es geçmeyin
Ajan neden yanılıyor?
Ajanın zihni bizimki gibi net bölmelere sahip değil. “Temizle”, “güncelle”, “yenile”, “senkronize et” gibi fiiller bağlama göre masum da olabilir, felaket de. Bu yüzden risk sınıflandırması mekanik olmalı — — itiraz edebilirsiniz tabi — ya tool seviyesinde ya policy seviyesinde uygulanmalı. Prompt’a güvenerek ilerlemek ise biraz kumar. Açıkçası, biraz değil, epey kumar.
Peki çözüm ne? Ruah conv’un mantığı burada değer kazanıyor
Kısacası bu araç, OpenAPI spec alıp MCP tool setine dönüştürüyor ve her araca safe / moderate / destructive etiketi koymaya çalışıyor. Önemli nokta şu: bu etiketleme HTTP method’una bakarak başlamalı, ama orada bitmemeli. Çünkü gerçek hayat kirli. GET çoğunlukla güvenlidir. Bu ne anlama geliyor? Bazen veri sızdırır; POST çoğunlukla orta risklidir ama kimi zaman abonelik iptal eder; DELETE ise çoğu senaryoda kırmızı bayraktır (şaşırtıcı ama gerçek)
# Basit risk düşüncesi
if method == "GET":
risk = "safe"
elif method in ["POST", "PATCH"]:
risk = "moderate"
elif method == "DELETE":
risk = "destructive"
else:
risk = "review"Yani, Bunu kendi test laboratuvarımda değerlendirdiğimde hoşuma giden şey şu oldu: araç sadece dönüşüm yapmıyor, ajan geliştiricisini düşünmeye zorluyor. Fena değil bu. Hatta baya işe yarıyor — hızla körleşen takımlara gerçek bir fren etkisi veriyor.
Peki ne yapmalı?
Bence ilk adım çok basit: hangi endpoint’in geri alınamaz olduğunu çıkarın. Silme mi? Abonelik iptali mi? Erişim kesme mi? Para iadesi mi? Bunların hepsi farklı seviyede dikkat istiyor ve bu listeyi yapmak sandığınızdan az zaman alıyor (en azından benim deneyimim böyle)
Daha sonra agent’a rol tabanlı sınırlar koyun. Destek botu müşteri notu okuyabilsin, ama hesap silemesin. Operasyon botu alarm düşürebilsin, ama kimseyi susturamasın. Mantıklı, değil mi? Bir de human-in-the-loop katmanı kurun — bazı aksiyonlar için ikinci onay hâlâ şart, bu konuda pazarlık olmaz. Aksi halde sisteminiz yapay zekâdan çok otomatik hasar makinesine dönüşür. Acı ama gerçek.
Sıkça Sorulan Sorular()
MCP nedir?
MCP,AI ajanlarının dış araçlarla standart biçimde konuşmasını sağlayan bir protokol olarak düşünülebilir.Kısaca ortak priz gibidir:her alet ayrı kablo istemez.
Neden bütün API’ler doğrudan ajana verilmemeli？?
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.
