MCP'nin asıl etkisi entegrasyon kolaylığı değil, yetkinin merkezileşmesi

Tez#

Model Context Protocol'ün anlatılma biçimi neredeyse tümüyle geliştirici ergonomisi üzerine kurulu: her model sağlayıcısı için ayrı araç tanımı yazmak yerine tek bir protokol konuşuyorsunuz, sunucular yeniden kullanılabiliyor, istemci değiştirmek ucuzluyor. Bunların hepsi doğru ve hepsi ölçülebilir kazanç.

Ancak bir kurumda MCP'nin bıraktığı kalıcı iz burada değil. Protokol yaygınlaştıkça tek bir istemci — bir geliştirici aracı, bir asistan, bir ajan çalıştırıcısı — aynı anda kod deposuna, biletleme sistemine, veri ambarına, müşteri kayıtlarına ve iç dokümantasyona erişen tek süreç hâline geliyor. Bu erişimlerin her biri ayrı ayrı onaylanmış olabilir; ama bir arada bulunmaları hiçbir onay sürecinden geçmiyor. Yetki mimarisindeki değişim sessiz gerçekleşiyor, çünkü her adım tek başına makul.

Bağlam: dağıtık yetkiden toplu yetkiye#

Değişimi görmek için MCP öncesi ve sonrası aynı tabloda yan yana konmalı. Fark, erişim sayısında değil erişimlerin birleşiminde.

Dördüncü satırın pratik sonucu çoğu kurumda henüz görülmedi: MCP sunucusu eklemek genellikle bir yapılandırma dosyasına birkaç satır yazmak. Bu, kurumsal bir entegrasyon kararının bir geliştirici tercihine dönüşmesi demek. Altı ay sonra hangi istemcinin hangi sunucuya bağlı olduğunu kimse bilmiyor ve bu envanteri çıkarmanın merkezî bir yolu yok.

Kanıt: birleşik yetkinin ürettiği somut açıklar#

Yetki merkezileşmesi soyut bir kaygı değil; belirli saldırı ve hata desenleri üretiyor. Aşağıdakiler tek istemcide toplanmış yetkinin doğrudan sonuçları.

• Okuma yetkisiyle yazma yetkisinin buluşması: bir sunucu müşteri kaydını okuyor, diğeri dışarıya mesaj gönderiyor. İkisi ayrı sistemdeyken sızıntı yolu yoktu; aynı istemcide var.
• Dolaylı istem enjeksiyonu için geniş hedef: modelin okuduğu bir bilet açıklaması, bir depo dosyası veya bir e-posta, bağlı tüm araçlara talimat verebilecek bir yüzey hâline geliyor.
• Yetki yükseltme gerekmeyen erişim: saldırganın ek yetki almasına gerek yok; istemcinin zaten sahip olduğu yetkiyi kullanmaya ikna etmesi yeterli.
• Denetim izinin kopması: sistem günlüğünde işlemi yapan kimlik istemcinin kendisi. Hangi kullanıcının hangi isteği tetiklediği, istemci bunu ayrıca kaydetmiyorsa kayıp.
• Kademeli onayın anlamsızlaşması: kullanıcı tek bir araç çağrısını onaylıyor ama o çağrının döndürdüğü içerik sonraki çağrıları belirliyor.

Birinci madde bu desenlerin en sık görüleni ve en az konuşulanı. Klasik güvenlik literatüründe buna veri akışı kontrolü deniyor: okuma yetkisi olan bir bileşenle yazma yetkisi olan bir bileşenin birleşmesi, tek başına hiçbirinde bulunmayan bir yetenek üretiyor. MCP bu birleşmeyi varsayılan hâle getiriyor ve genellikle kimse birleşimi ayrıca değerlendirmiyor.

Mekanizma: protokol yetkiyi taşımıyor, istemci taşıyor#

Ayrımı netleştirmek gerekiyor: MCP bir yetkilendirme protokolü değil. Sunucuya hangi kimlikle bağlanılacağını, o kimliğin neye erişebileceğini ve çağrının kimin adına yapıldığını protokol belirlemiyor. Bunları istemci ve sunucu yapılandırması belirliyor.

Bu, protokolün bir eksiği değil — kapsam tercihi. Ama pratik sonucu şu: güvenlik tümüyle uygulamaya kalıyor ve uygulamaların çoğu en kolay yolu seçiyor. En kolay yol, sunucuya geniş yetkili tek bir hizmet kimliği vermek. Böylece her kullanıcı, o hizmet kimliğinin tüm yetkisiyle iş görüyor ve kullanıcı bazlı yetki ayrımı kayboluyor. Doğru kalıp — çağrının son kullanıcı kimliğiyle yapılması ve yetkinin o kullanıcının kendi izinleriyle sınırlanması — teknik olarak mümkün ama daha fazla iş gerektiriyor ve bu yüzden nadiren yapılıyor.

Karşı görüş#

İki güçlü itiraz var. Birincisi: bu sorun MCP'ye özgü değil — her entegrasyon katmanı, her kurumsal hizmet veri yolu aynı merkezileşmeyi üretir ve çözümleri bilinir. İkincisi: merkezileşme bir kazanç; dağıtık kimlik bilgileri yönetilemez ve tek noktada toplamak denetimi kolaylaştırır.

Her sunucuyu ayrı ayrı güvenlik incelemesinden geçirdik. Altı ay sonra fark ettik ki incelemediğimiz şey bileşimdi: bir sunucu iç wiki'yi okuyor, biri dışarıya e-posta atıyordu. İkisi de tek başına zararsızdı.

Birinci itiraz doğru ama bir farkı atlıyor: klasik entegrasyon katmanlarında hangi çağrının yapılacağı kodda sabitti ve gözden geçirilebilirdi. MCP'de çağrı kararını model veriyor ve bu karar girdiden etkileniyor — yani saldırganın etkileyebildiği bir yerden. Merkezileşmenin kendisi yeni değil; merkezîleşmiş yetkiyi kullanacak kararın veri tarafından yönlendirilebilir olması yeni. İkinci itiraz da geçerli: merkezileşme yönetilebilirse gerçekten kazanç. Ama koşul 'yönetilebilirse' ve bugün çoğu kurumda hangi istemcinin hangi sunucuya bağlı olduğunun envanteri bile yok. Merkezileşme kendiliğinden denetim getirmiyor; denetim ayrı bir iş.

Sınırlar ve belirsizlik#

Bu analiz protokolün kendisine karşı bir argüman değil ve saha verisiyle desteklenmiş bir risk ölçümü sunmuyor.

• Protokol hızla gelişiyor: yetkilendirme ve kimlik doğrulama tarafı olgunlaştıkça bu analizin bazı maddeleri geçersizleşebilir.
• Olay verisi yok: birleşik yetkinin gerçek dünyada ne sıklıkta istismar edildiğine dair yayımlanmış veri bulunmuyor.
• Kurum ölçeğine bağlı: tek kişilik bir geliştirme ortamında merkezileşme risk değil kolaylık.
• Kullanıcı kimliğiyle çağrı yapmanın maliyeti ölçülmedi: doğru kalıbın ek karmaşıklığı alana göre değişiyor.

Sonuç#

MCP'nin entegrasyon kazancı gerçek ve tartışmasız. Ama bir kurumda protokolün bıraktığı asıl iz, yetki mimarisinde: daha önce farklı sistemlere dağılmış erişimler tek bir süreçte buluşuyor ve o birleşim hiçbir onay sürecinden geçmiyor.

Doğru soru 'MCP kullanmalı mıyız' değil — kullanılacak. Doğru soru şu: bu istemcinin taşıdığı yetkilerin birleşimi, tek bir insana verilse onaylanır mıydı? Cevap hayırsa, güvenlik incelemesi sunucu bazında değil bileşim bazında yapılmalı ve envanter merkezî tutulmalı. Bu iki adım, protokolün kazancını korurken yetki tarafındaki sessiz genişlemeyi görünür kılıyor.

Ne yapmalı?#

1. 1Bileşim incelemesi yapın

   Sunucuları tek tek değil, bir istemcide bir arada bulunduklarında ürettikleri yeteneği değerlendirin.

2. 2Okuma ve yazma yetkisini ayırın

   Dışarıya veri gönderebilen sunucuyla hassas veri okuyan sunucu aynı istemcide bulunmasın.

3. 3Son kullanıcı kimliğiyle çağrı yapın

   Geniş yetkili tek hizmet kimliği en kolay yol ama kullanıcı bazlı yetki ayrımını yok ediyor.

4. 4Sunucu envanterini merkezî tutun

   Hangi istemci hangi sunucuya bağlı? Bu envanter yoksa iptal etme de mümkün değil.

5. 5İstemci tarafında denetim izi tutun

   Sistem günlüğünde işlemi yapan kimlik istemci. Hangi kullanıcı tetikledi bilgisi ayrıca kaydedilmeli.

6. 6Araç çıktısını talimat değil veri sayın

   Bir aracın döndürdüğü metin sonraki çağrıları belirlememeli; zincirde bu sınır açıkça kurulmalı.