Model Context Protocol (MCP), AI uygulamalarının harici araçları ve veri kaynaklarını ortak bir protokolle keşfetmesini ve kullanmasını sağlar. Bu standartlaşma entegrasyon maliyetini azaltır; ancak yeni bir güvenlik gerçeği oluşturur:
Bir MCP sunucusunu bağlamak, o sunucunun sunduğu kodu, araç açıklamalarını, şemaları ve sonuçları agent'ın karar alanına dahil etmektir.
MCP bir güvenlik ürünü değildir. Güvenli kullanım; protokolün etrafında kurulan kimlik, ağ, allowlist, credential, doğrulama, onay ve audit kontrollerine bağlıdır.
“MCP uyumlu” ifadesi sunucunun güvenilir, araçların güvenli veya sonuçların doğru olduğu anlamına gelmez. Uyumluluk iletişim biçimini; güvenlik ise kurumun izin sınırlarını tanımlar.
MCP neden stratejik bir katman?
Geleneksel entegrasyonda her uygulama, her hedef sistem için özel bağlantı kodu yazar. MCP; araçların adını, açıklamasını ve giriş şemasını makine tarafından keşfedilebilir hale getirir. Agent, doğal dildeki görevi uygun araç çağrısına dönüştürebilir.
Bu yaklaşım üç önemli avantaj sağlar:
- Taşınabilirlik: Aynı araç sunucusu farklı AI istemcileri tarafından kullanılabilir.
- Keşfedilebilirlik: Agent mevcut yetenekleri ve parametreleri çalışma anında görebilir.
- Modülerlik: Yeni bir sistem, ana uygulamayı değiştirmeden araç katmanına eklenebilir.
Aynı özellikler risk de üretir. Dinamik keşif, değişen araç listesi ve harici tool output; klasik API istemcisindeki sabit sözleşmenin ötesinde kontroller gerektirir.
1. Önce güven sınırını tanımlayın
Bir MCP mimarisinde en az dört ayrı güven alanı vardır:
- AI host: Agent'ı, model çağrılarını ve kullanıcı bağlamını yönetir.
- MCP client: Sunucu bağlantısını, keşfi ve araç çağrılarını yürütür.
- MCP server: Araçları yayınlar ve hedef sistemlerle konuşur.
- Hedef sistem: CRM, dosya sistemi, veritabanı veya kurum içi uygulama.
Bunların aynı makinede çalışması aynı güven seviyesinde oldukları anlamına gelmez. Yerel bir
stdio sunucusu host dosyalarına ve environment variable'lara erişebilir. Uzak HTTP sunucusu
ise ağ üzerinden veri çıkarabilir veya ele geçirilebilir.
Her bağlantı için veri akışını belgeleyin:
- Sunucu hangi süreç ve kullanıcı kimliğiyle çalışıyor?
- Hangi dosya, ağ ve secret'lara erişebiliyor?
- Tool input ve output nerede loglanıyor?
- Sonuç modele veya başka araca aktarılıyor mu?
- Hedef sistem işlemi hangi credential ile görüyor?
2. Sunucu kaynağı bir tedarik zinciri kararıdır
Bir MCP sunucusu kod çalıştırır. Bu nedenle bir npm paketi, container image veya Git repository'sini “sadece connector” diye değerlendirmek hatadır.
Üretim öncesi şu kanıtları arayın:
| Kontrol | Beklenen kanıt |
|---|---|
| Sahiplik | Bilinen geliştirici/kurum ve destek kanalı |
| Kaynak | Doğrulanmış repository veya registry |
| Sürüm | Sabitlenmiş tag/digest; floating latest değil |
| Bağımlılık | SBOM, bağımlılık taraması veya en azından kilit dosyası |
| Değişiklik | Release note ve geriye dönük uyumluluk politikası |
| Açıklar | Güvenlik bildirim ve yama süreci |
| Dağıtım | Minimum kullanıcı, dosya ve ağ yetkisi |
Paket kurulum sırasında script çalıştırıyorsa bunu ayrıca inceleyin. Üretim ortamında dinamik olarak en son paketi indirmek yerine onaylanmış artifact'ı kurum registry'sinden dağıtın.
3. Transport seçimi tehdit modelini değiştirir
stdio
Host, MCP sunucusunu alt süreç olarak başlatır. Ağ portu gerektirmez; ancak süreç host yetkileriyle kod çalıştırır.
Kontroller:
- Çalıştırılabilir dosya ve argüman allowlist'i
- Ayrı işletim sistemi kullanıcısı
- Salt-okunur dosya sistemi veya sandbox
- Minimum environment variable
- Gerekli değilse outbound ağ yasağı
- CPU, bellek, süreç ve süre limiti
Streamable HTTP
Merkezi veya uzak sunucu için uygundur. Ağ ve kimlik sınırı ekler.
Kontroller:
- TLS ve sertifika doğrulama
- OAuth veya karşılıklı doğrulanmış servis kimliği
- İzinli domain/IP ve egress proxy
- SSRF koruması; kullanıcı girdisiyle keyfî URL'ye bağlanmama
- Origin ve host doğrulaması
- Rate limit, timeout ve gövde boyutu
- Tenant ve workspace izolasyonu
“İç ağda” olmak TLS, kimlik veya oran sınırlamasını gereksiz yapmaz.
4. Keşif ile yetkiyi birbirine karıştırmayın
MCP sunucusu araç listesini yayınlar. Keşfedilen bir araç otomatik olarak agent'a açılmamalıdır. İki ayrı katalog tutun:
- Keşfedilen katalog: Sunucunun sunduğu bütün araçlar
- Onaylı katalog: Kurum tarafından incelenmiş, sürümü ve risk seviyesi kaydedilmiş araçlar
Agent yalnızca onaylı katalogdaki, kendi Space ve görev kapsamına uygun operasyonları görmelidir.
Araç drift'ini izleyin
Sunucu güncellendiğinde:
- Yeni araç eklenebilir.
- Mevcut aracın açıklaması değişebilir.
- Parametre zorunluluğu veya türü değişebilir.
- Salt-okunur araç yazma davranışı kazanabilir.
Refresh işlemi sonrası eski ve yeni katalog diff edilmelidir. Yeni ya da anlamlı biçimde değişen araçlar yeniden onaylanmadan üretim agent'larına açılmamalıdır. Workflow'ların hangi araç sürümüne bağlı olduğu görünür olmalıdır.
5. Araç açıklaması güvenlik yüzeyidir
Model, aracı ne zaman kullanacağına açıklama üzerinden karar verir. Kötü veya belirsiz bir açıklama yanlış seçimlere neden olabilir.
Zayıf:
Records üzerinde işlem yapar.
Daha iyi:
Yetkili kullanıcının workspace'indeki destek taleplerini salt-okunur listeler.
Müşteri profili, ek dosya veya silinmiş kayıt döndürmez.
Kayıt oluşturmak ya da güncellemek için kullanılmaz.
Açıklamada:
- Amaç
- Okuduğu/değiştirdiği kaynak
- Kullanılmaması gereken durum
- Yan etki
- Onay gereksinimi
- Sonuç sınırı
net olmalıdır. Sunucudan gelen açıklamayı doğrudan güvenilir sistem talimatı gibi kullanmayın; kurum gerekirse onaylı açıklama katmanı uygulamalıdır.
6. Şema doğrulaması modelden sonra tekrar yapılmalı
Model JSON şemasına uygun araç çağrısı üretmeye çalışsa da güvenlik kararı model davranışına bırakılamaz. Yürütme katmanı:
- Bilinmeyen alanları reddetmeli
- String uzunluğu ve liste boyutunu sınırlamalı
- Enum dışı değerleri engellemeli
- ID formatını ve kaynak kapsamını doğrulamalı
- URL ve dosya yolunu canonicalize etmeli
- Path traversal ve SSRF girişlerini engellemeli
- İşlem başına sonuç ve veri hacmini sınırlandırmalı
- Yetkiyi yeniden hesaplamalı
Tool calling formatının geçerli olması, çağrının yetkili veya güvenli olduğu anlamına gelmez.
7. Credential'ı modelden ve sunucudan mümkün olduğunca ayırın
En güçlü yaklaşım, credential broker kullanmaktır:
- Agent araç çağrısı önerir.
- Host kullanıcı, Space ve operasyon yetkisini doğrular.
- Broker yalnızca bu çağrı için uygun credential referansını çözer.
- Token modele gösterilmeden sunucuya iletilir.
- Sonuç maskelenerek geri döner.
Tercih sırası:
- Kullanıcıya bağlı, kısa ömürlü OAuth token
- Göreve özel, dar kapsamlı servis hesabı
- Zorunluysa paylaşılan ve yoğun biçimde izlenen credential
Secret'ları MCP config dosyasında düz metin, agent prompt'unda, hata mesajında veya tool output'ta tutmayın. Token rotation ve iptal akışını bağlantı kurulurken test edin.
8. Tool output güvenilmeyen içeriktir
MCP aracı yalnızca veri döndürür; bu verinin doğru veya zararsız olduğu garanti edilmez. Özellikle web sayfası, e-posta, belge, issue ve sohbet mesajı şunları içerebilir:
- Prompt injection
- Sahte talimat veya yetki iddiası
- Başka aracın çağrılmasını isteyen metin
- Hassas veri
- Çok büyük veya bozuk içerik
- HTML/script ve kaçış karakterleri
Savunma yaklaşımı:
- Sonucu kaynağı ve araç adıyla etiketleyin.
- Sistem talimatından ayrı veri kanalında tutun.
- Yapısal alanları şemayla doğrulayın.
- Gereksiz alanları ve aktif içeriği temizleyin.
- Boyut ve token sınırı uygulayın.
- Tool output'un yeni araç çağrısı üretmesine otomatik yetki vermeyin.
- Hassas içeriği LLM Secure Gateway politikasından geçirin.
9. Onayı araç adına değil, etkiye bağlayın
send_email yüksek riskli görünebilir; kurum içi test adresine taslak göndermek düşük riskli
olabilir. search_customers salt-okunur görünür; bütün müşteri verisini dışa aktarmak kritik
olabilir.
Risk motoru şu bağlamı değerlendirmelidir:
- Veri sınıfı ve kayıt sayısı
- Hedef sistem ve ortam
- Okuma/yazma yönü
- Dış alıcı veya domain
- Finansal/operasyonel eşik
- İşlemin geri alınabilirliği
- Kullanıcı ve agent risk profili
- Model güveni ve kaynak yeterliliği
Onay ekranı gerçek parametreleri göstermeli ve onay bu parametrelere kriptografik olarak bağlanmalıdır. Onay sonrası değişen çağrı yeniden değerlendirilmelidir.
10. Multi-tool zincirlerini sınırlandırın
Tek bir araç çağrısı güvenli olsa bile zincir tehlikeli olabilir:
- E-postadan içerik oku.
- İçindeki URL'yi ziyaret et.
- Dosyayı indir.
- İçeriği başka sisteme yükle.
- Harici alıcıya bildirim gönder.
Her adım kendi başına izinli olsa bile toplam veri akışı kurum politikasını ihlal edebilir. Bunun için:
- Maksimum araç çağrısı ve süre bütçesi
- Araçlar arası veri sınıfı takibi
- Kaynak→hedef aktarım politikası
- Belirli araç kombinasyonları için yasak/izin
- Dış iletişim öncesi onay
- Döngü ve tekrar tespiti
uygulayın. Agent'ın planı görünür olmalı; yürütme motoru planın her adımını yeniden yetkilendirmelidir.
11. Audit ve gözlemlenebilirlik
MCP audit kaydı şu zinciri kurmalıdır:
Kullanıcı/trigger → agent → MCP sunucusu → araç → parametre özeti → credential türü → politika/onay → sonuç
İzlenecek metrikler:
- Sunucu bağlantı ve keşif hataları
- Araç listesi drift'i
- Çağrı sayısı, gecikme ve hata oranı
- Şema doğrulama reddi
- Yetki ve politika reddi
- Onay bekleme/kabul/ret
- Tool output boyutu ve maskeleme olayı
- Credential yenileme ve iptal hatası
- Agent başına araç zinciri uzunluğu
Loglarda token, Authorization header, kişisel veri ve tam belge içeriğini gereksiz yere tutmayın. Audit kanıt üretmeli; yeni bir veri sızıntısı deposu olmamalıdır.
12. Olay müdahalesi ve kill switch
Bir MCP sunucusu ele geçirilirse yalnızca sunucuyu kapatmak yetmeyebilir. Önceden hazırlayın:
- Sunucuyu bütün workspace'lerden devre dışı bırakma
- Belirli aracı global olarak kapatma
- Credential ve refresh token iptali
- Etkilenen workflow sürümlerini bulma
- Son başarılı keşiften sonraki çağrıları listeleme
- Dış sistemde oluşan işlemleri geri alma/telafi
- Paket veya image'ı güvenli sürüme sabitleme
- İlgili kullanıcılara ve veri sahiplerine bildirim
Kill switch merkezi olmalı; her workflow'u tek tek düzenlemeye ihtiyaç duymamalıdır.
Kurumsal MCP olgunluk modeli
| Seviye | Uygulama |
|---|---|
| 1 — Deney | Yerel test, sentetik veri, yazma yok |
| 2 — Kontrollü | Onaylı sunucu, araç allowlist'i, salt-okunur pilot |
| 3 — Yönetilen | Kullanıcı kimliği, şema doğrulama, audit, risk bazlı onay |
| 4 — Ölçekli | Merkezi katalog, drift yönetimi, politika şablonları, SLO |
| 5 — Dayanıklı | Tedarik zinciri kanıtı, otomatik izolasyon, test edilmiş olay müdahalesi |
Her yeni MCP bağlantısı en üst seviyede başlamak zorunda değildir; ancak veri ve işlem riski arttıkça gerekli kontrol seviyesi de artmalıdır.
Üretim kontrol listesi
- Sunucunun sahibi, kaynağı ve sabit sürümü doğrulandı mı?
- Çalışma süreci minimum dosya, ağ ve sistem yetkisine sahip mi?
- Transport için TLS, kimlik ve SSRF koruması var mı?
- Keşfedilen ve onaylı araç katalogları ayrılıyor mu?
- Araç/şema drift'i yeniden onay gerektiriyor mu?
- Agent yalnızca Space'e özel allowlist'i görüyor mu?
- Parametreler yürütme katmanında yeniden doğrulanıyor mu?
- Credential modele gösterilmeden broker üzerinden çözülüyor mu?
- Tool output güvenilmeyen veri olarak işleniyor mu?
- Multi-tool veri akışı ve döngüler sınırlandırılıyor mu?
- Onay, gerçek etki ve parametrelere bağlı mı?
- Merkezi kill switch ve credential iptali test edildi mi?
Sonuç
MCP, kurumsal agent mimarisinde güçlü bir standartlaştırma katmanıdır. Ancak protokol, sunucudan araca ve çağrıdan sonuca uzanan güven zincirinin yalnızca taşıma biçimini çözer.
Knowentra, MCP sunucularını ve araçlarını Space bağlamında keşfedilebilir hale getirirken allowlist, bağlantı testi, OAuth, şema doğrulama ve audit yüzeyleriyle kontrollü yürütmeyi hedefler. LLM Secure Gateway ve workflow onayları bu zinciri veri ve iş riski açısından tamamlar.
Teknik kurulum adımları için Araç Bağlama (MCP), genel agent yönetişimi için Agent sayfasını inceleyebilirsiniz.