MCP Ekosistemi Nereye Gidiyor: Hız, Açıklar, Güvenlik

Geçen ay bir ekip toplantısında şu cümleyi duydum: “MCP’yi bağladık, artık yapay zekâ her şeyi halleder.” Güldüm. Çünkü işin aslı o kadar düz değil. MCP, yani Model Context Protocol, gerçekten hızlı büyüyor; ama hızlı büyüyen her şey otomatik olarak oturmuş olmuyor. Hatta bazen tam tersi oluyor… biraz dağınık, biraz hevesli, biraz da riskli.

Doğrusu, Bu alanı ilk kez 2024 sonbaharında İstanbul’da bir ürün ekibiyle konuşurken yakından kurcaladım. O günlerde MCP çoğu kişi için hâlâ “güzel fikir” seviyesindeydi. Şimdi tablo değişti: IDE’ler destek veriyor, SaaS şirketleri resmi sunucular yayınlıyor, topluluk tarafında binlerce entegrasyon dönüyor. Yani mesele artık “olur mu?” değil; “bu iş nasıl güvenli kalacak?” (yanlış duymadınız)

MCP neden bu kadar hızlı yayıldı?

İşin çekiciliği aslında basit. Yapay zekâ modeline araç kullandırmak istiyorsunuz ve bunu tek tek özel entegrasyonlarla boğuşmadan yapmak istiyorsunuz. MCP tam burada devreye giriyor. Bir nevi herkesin konuşabildiği ortak bir priz gibi düşünün — cihaz farklı olabilir ama bağlantı standardı aynı kalıyor.

Eh, Bu yüzden ortam kısa sürede kabardı. Filesystem sunucusu dosyaya erişiyor, GitHub sunucusu repo ve PR dünyasını açıyor, Slack ile mesaj okuyup gönderebiliyorsunuz, Google Drive’dan belge çekiliyor, Puppeteer ile tarayıcı otomasyonu yapılıyor… Liste uzayıp gidiyor.

Açık konuşayım, Ha bu arada sadece resmi taraf yok. Toplulukta da bayağı ciddi bir hareket var. Linear, Notion, Jira gibi proje yönetim araçları; AWS, GCP ve Azure gibi bulut servisleri; Stripe ve Shopify gibi ticaret katmanı; Figma gibi tasarım dünyası… Hepsi bu trenin üstüne atlamış durumda.

Küçük ekipler için cazibe daha büyük

Küçük bir startup’ta çalışıyorsanız MCP neredeyse ilaç gibi geliyor. Tek geliştiriciyle hem dokümantasyon hem görev takibi hem de otomasyon yapmak istiyorsunuz ya — işte orada birkaç sunucu bağlayıp işleri epey hızlandırabiliyorsunuz. Daha fazla bilgi için dissectml: EDA ile AutoML Arasındaki Eksik Parça yazımıza bakabilirsiniz. Daha fazla bilgi için C++ Neden Hâlâ Ayakta? Stroustrup’tan Gelen Der… yazımıza bakabilirsiniz.

Ben geçen mart ayında Kadıköy’de çalışan küçük bir SaaS ekibinde buna benzer bir deneme gördüm. Ürün yöneticisi Slack’ten gelen talepleri not aldırdı, geliştirici GitHub üzerinden issue çektirdi… İlk hafta herkes mutlu oldu. İkinci hafta ise yetki sınırları sorunu ortaya çıktı. Yani kısacası kolaylık geldi ama kontrol ihtiyacı da peşinden geldi. Bu konuyla ilgili Bjarne Stroustrup ve C++: Eski Dilin Yeni Hali yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz … yazımıza bakabilirsiniz.

Büyüme güzel de… güvenlik nereye gitti?

Garip gelecek ama, Burada biraz frene basmak gerekiyor. Çünkü ekosistem öyle hızlı büyüdü ki güvenlik pratikleri aynı tempoda ilerleyemedi. Açık konuşayım: Bu tablo bana eski npm günlerini hatırlatıyor. Hani herkes paket kuruyordu da kimse paketin içinde ne olduğuna pek bakmıyordu ya… biraz o hava var.

MCP’nin asıl riski şurada yatıyor: Sunucu sadece “araç” değil; sizin makinenize ve hesaplarınıza uzanan canlı bir köprü olabiliyor.

Elde edilen tarama sonuçlarında oldukça sert rakamlar görülmüş durumda: topluluk sunucularının önemli kısmında command injection var, path traversal koruması eksik kalmış, kaynak kodda sabitlenmiş kimlik bilgileri bulunmuş… Bunlar teorik korkular değil; gerçek açıklar.

Bir de şu var: Bu tip sunucular çoğu zaman yerel makinede çalışıyor ve ortam değişkenlerine erişebiliyor. Yani API anahtarınızın bulunduğu klasörle aynı mahallede geziyor diyelim — fazla yakınlık bazen kötü haber getirir.

Saldırı yüzeyi sandığınızdan geniş

MCP server’a baktığınızda belki sadece “dosya okuma yazma” görüyorsunuz ama altta yatan gerçek daha geniş olabilir: shell çağrıları yapılırsa komut enjeksiyonu doğar, URL kabul eden tool varsa SSRF kapısı açılır, parametre doğrulaması zayıfsa zararlı input sistemin içine sızar. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir S… yazımıza bakabilirsiniz.

Bunu kendi test ortamımda Ocak 2025’te Ankara’da kurduğum ufak bir lab üzerinde denedim. Masum görünen bir örnek sunucuya (söylemesi ayıp) bilerek bozuk path verdim; çıktığı anda uygulamanın klasör dışına taşmaya çalıştığını gördüm (neyse ki sandbox içindeydi). İşte bu tarz şeyler kağıt üstünde küçük görünür ama prod ortamda can sıkıcı olur.

Dahili sistemlerin ifşası veya suistimali
Ağ tabanlı saldırılar

Tedarik zinciri meselesi hiç hafif değil

MCP dünyasında en ürkütücü senaryolardan biri tedarik zinciri saldırısı. Kulağa akademik geliyor ama olay basitçe şu: GitHub’daki temiz görünen proje önce güven veriyor… sonra bakımcı hesabı ele geçiriliyor ya da kötü niyetli sürüm yayınlanıyor ve siz otomatik güncelleme sayesinde onu içeri alıyorsunuz.

Bunu ben ilk kez Eylül 2024’te Levent’te düzenlenen kapalı bir güvenlik buluşmasında duyduğumda başımı iki yana sallamıştım çünkü sahne tanıdık geldi. event-stream vakası boşuna ders kitabına girmedi zaten; buradaki fark şu ki ajanlar yalnızca paket tüketmiyor — sizin adınıza işlem yapıyor.

Neden etkisi daha ağır?

• MCP server filesystem’e erişebiliyor olabilir.
• API anahtarlarını çevresel değişkenlerden okuyabilir.Ağ isteği atarak dışarı veri çıkarabilir.Bazıları kod bile çalıştırabiliyor veya kabuk çağırabiliyor.Kullanıcı bunu fark etmeden günlük akışın içine sokabiliyor.

Klasik paket bağımlılığıyla karşılaştırınca fark netleşiyor: Orada hata çoğunlukla uygulamanızı bozar ya da veri sızdırırdı; burada ise model aracılığıyla karar zincirine dokunuluyor. Bu ince ama kritik fark bazen gözden kaçıyor. Oysa risk tam merkezde duruyor.

Bunu biraz açayım.

Peki iyi MCP sunucusu nasıl anlaşılır?

Cevap README’de saklı olabilir mi? Bazen evet…

İlk baktığım şey belgeler oluyor. Dokuz satırlık havalı tanıtım metni yerine hangi verilere dokunduğunu açık açık anlatan README görmek isterim. Security.md dosyası varsa hoşuma gider, çünkü en azından yazar kafasını kumun içine gömmemiş demektir.

İkinci olarak input validation bakarım. Kullanıcıdan gelen değerin olduğu yerde temizlik şart ; yoksa agent’ın eline verdiğiniz oyuncak bıçak misali işler ters döner. Shell çağrılarında shell=True görürsem, tamam derim, burada dikkat lazım.

# Basit kontrol listesi
- Ne okuyor?
- Neye yazıyor?
- Hangi ağ isteklerini atıyor?
- Komut çalıştırıyor mu?
- Kimlik bilgisini nereden alıyor?
- Çekirdekte mi koşuyor yoksa izole mi?

Bana göre iyi sinyaller şunlar : aktif bakım, net sürüm notları, checksum paylaşımı, minimal izin prensibi ve issue cevaplarının neredeyse tamamen sessiz kalmaması. Sessizlik bazen kararsızlık değildir ; ihmal de olabilir. Aradaki çizgi ince.

Kötü sinyaller de genelde kendini belli ediyor : tek commit geçmişi, aşırı genel tool açıklamaları, gereksiz kimlik bilgisi isteme eğilimi, hiç test göstermeyen depo… Bunların hepsi bana durup düşünme sebebi veriyor.

Maliyet mi hız mı? Kurumsal tarafta denklem değişiyor

Küçük ekipler için MCP “biraz risk alalım” sınıfındaysa kurumsalda oyun hemen sertleşiyor. Enterprise seviyede mevzu yalnızca üretkenlik değil ; uyumluluk, kayıt tutma, rol bazlı yetkilendirme ve denetim izi meselesi de masaya geliyor.

Nisan 2025’te İzmir’de görüştüğüm orta ölçekli bir finans ekibi bunu çok net anlattı : “Deneyebiliriz ama hangi veri nereye gidiyor bilmiyoruz.” Haklılar tabii. Çünkü kurumsal tarafta yanlış yapılandırılmış tek bir tool bile yıllarca toplanan disiplinin altını oyabilir.

Bence önümüzdeki dönem şirketler kendi registry’sini kuracak. Onaylı server listeleri olacak ; hatta departmana göre ayrılmış kataloglar çıkacak. IT’nin “herkes istediğini kursun” yaklaşımı burada işlemiyor.

MCP nereye gidiyor? Tahmin etmek zor değil

IDEsiz gelecek pek mantıklı görünmüyor

Birkaç yıl içinde VS Code’da native destek görmek şaşırtmaz beni ; JetBrains zaten hazır pozisyon alacaktır ; Xcode tarafı ise Apple’ın ritmine bağlı olarak gelir geç gelir — klasik Apple temposu yani.

SaaS şirketlerinin resmi MCP server yayınlaması artık ekstra özellik sayılmayacak, ürün stratejisinin parçası olacak. OAuth tabanlı araç kimliği standartlaşırsa, bugün yamalı bohça olan yetkilendirme hikâyesi toparlanabilir. Ama henüz pişmedi, dürüst olayım.

Ajanların birbirine MCP üzerinden konuştuğu agent-to-agent senaryolarını ise abartılı bulmuyorum. Şu an kulağa sci-fi gibi geliyor, fakat beş-altı servis arasında manuel köprü kurmak yerine ajanların anlaşması gayet doğal yönde ilerliyor. Tabii bunun yanında loglama, sınırlandırma, politika motoru gibi parçalar şart olacak. Aksi halde karmaşa büyür.

Nerede umut var, nerede alarm çalmalı？.

Mesele yasaklamak değil, olgunlaştırmak. Ben teknoloji tarafında hep şunu söyledim: standart kötü değildir, kontrolsüz standart kötüdür. Bu yüzden enterprise registries, imzalı paketler, minimum permission modeli жәne policy enforcement bence kilit noktalar olacak.

Eğer üretimdeyseniz benim önerim sade : önce sandbox, sonra dar yetki, sonra loglama, en son genişleme. Sanki yeni eve taşınırken önce kutuları açıp sonra mobilya almaya benziyor — tersinden girerseniz salon çöküyor.

Güvenilir görünen her depoya otomatik güvenmeyin…
Bir yıldız sayısı sizi kurtarmaz.
Kodun davranışı kurtarır.
“

Bulut Tedarik Zinciri CodeBuild Açığı Ve GDDR6 Şoku

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Yazılımı Yapay Zekâya Bırakmak: Çok Ajanlı Sistemler9 Nis 2026

Apple, iPadOS 26.5 ve tvOS 26.5 için public beta 2’yi yayına aldı14 Nis 2026

GLM-5.1 neden bu kadar konuşuluyor? Sekiz saatlik yapay zekâ işi9 Nis 2026

Flutter’da LLM Maliyeti Nasıl Kırılır: API’siz Yol11 Nis 2026