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 resmî sunucular yayınlıyor, topluluk tarafında binlerce entegrasyon dönüyor. Yani mesele artık “ölür 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 resmî 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 Dersler 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 işe 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 Hâli yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar 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’nın 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 tıp 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 Seçenek 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ı ölür.
| Zayıflık | Neye yol açabilir? | Pratik etkisi |
|---|---|---|
| Komut enjeksiyonu | Sistemde istenmeyen komut çalışması | Anahtar sızıntısı veya veri kaybı |
| Path traversal koruması yok | Dizin dışındaki dosyalara erişim | Duyarlı dosyaların okunması |
| Sabitlenmiş kimlik bilgileri | Kod içinden gizli bilgi sızması | Hesap ele geçirilmesi riski |
| Zayıf input validation | Zararlı girdilerin kabul edilmesi | Tahmin edilenden daha fazla hasar |
| SSRF açıklığı | Ağın iç servislerine istek atılması |
Sıkça Sorulan Sorular
MCP tam olarak ne işe yarar?
MCP (Model Context Protocol), yapay zekâ modelinizin dış araçlar ve veri kaynaklarıyla “standart” bir şekilde konuşmasını sağlar. Böylece her entegrasyonu sıfırdan özel kodlamak yerine, aynı protokol üzerinden farklı sunucular bağlayabilirsiniz. Benim gördüğüm en büyük fayda, hızlı prototiplemeden üretime geçerken entegrasyonun dağılmaması.
MCP’yi kullanmak güvenlik açısından ne değiştirir?
MCP, yetenekleri hızla çoğaltır; ama bu yeteneklerin kimlik doğrulama, yetkilendirme ve veri sızıntısı gibi risklerini de büyütür. Özellikle “dosya okuma + repo erişimi + mesajlaşma” gibi zincirler beklenenden fazla veri taşıyabilir. Bu yüzden ilk günden kapsam (scope) ve izin sınırlarını netleştirmek gerekiyor; yoksa kolaylık bir anda kontrol problemine dönüşüyor.
MCP sunucularını nasıl daha güvenli kurabilirim?
En pratik yaklaşım, her MCP sunucusu için en düşük ayrıcalık (least privilege) ve mümkünse kısa ömürlü kimlik bilgileri kullanmaktır. Ayrıca hangi araçların hangi bağlamlarda çağrılacağını uygulama tarafında kural bazlı sınırlamak iyi bir savunma olur. Bir projede benzer şekilde “sadece belirli klasör/repoya erişim” kuralı koyunca risk ciddi biçimde azalmıştı.
Topluluk entegrasyonları (GitHub/Slack/AWS vb.) ne kadar güvenilir?
Topluluk entegrasyonları çok hızlı ilerlediği için çeşitlilik yüksek; ama kalite ve güvenlik seviyesi aynı olmayabilir. Bu yüzden kodu incelemek, bağımlılıkları kontrol etmek, gerekirse kendi fork’unuzla güvenlik kontrollerini eklemek mantıklı. Ben genelde “önce sandbox/izole ortamda dene, sonra üretime al” yaklaşımını benimsiyorum.
Azure’da MCP benzeri bir mimariyi nasıl konumlandırabilirim?
Azure tarafında genellikle kimlik (Entra ID), gizli bilgiler (Key Vault) ve ağ/izolasyon (Private endpoints, network rules) gibi temel güvenlik bloklarıyla MCP araç erişimini çerçevelersiniz. MCP sunucularını da kendi servis sınırları içinde çalıştırıp loglama/izleme kurarak denetlenebilir hale getirmek daha kolay oluyor. Böylece “hızlı bağladık” kısmı kadar “kim neye ne zaman erişti” kısmı da yönetilebilir oluyor.
Kaynaklar ve İleri Okuma
Model Context Protocol (MCP) Resmi Site
GitHub: modelcontextprotocol Organizasyonu
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.
