MCP (Model Context Protocol) Güvenliği: İş Sistemleri İçin Rehber

MCP ile ERP ve API bağlantılarında dar yetki, insan onayı ve veri sınırları. Prompt injection riskine karşı işletmeler için uygulanabilir pilot planı.

2026-09-05

Bir yapay zeka asistanının sipariş durumunu sorgulaması, aynı asistanın siparişi iptal edebilmesiyle farklı sorumluluklar doğurur. İki işlem sohbet ekranında birbirine benzer görünebilir; işletmenin kayıtları, müşterileri ve yetki politikası açısından sonuçları farklıdır. MCP bağlantısı kurarken ilk karar, hangi işin asistana devredileceğidir.

MCP, yapay zeka uygulamalarının dış veri ve araçlarla ortak bir protokol üzerinden çalışmasını sağlar. 28 Temmuz 2026 tarihli resmi belirtim bu iletişimin kurallarını tanımlar. İşletmenizin hangi müşteriye ait kaydı kimin değiştirebileceği gibi kararları ise uygulamanızın ayrıca uygulaması gerekir. Aşağıdaki plan, sipariş ve destek süreçlerini bağlamak isteyen bir işletme için önerdiğimiz başlangıç yaklaşımıdır.

İki yazılım uzmanının dizüstü bilgisayarda araç bağlantılarını ve erişim izinlerini incelemesi

Aynı bağlantıda iki farklı risk

Bir destek asistanının müşterinin mesajını okuyup ERP üzerinden sipariş durumunu bulduğunu düşünelim. Müşteri mesajına, asistandan tüm müşteri listesini dışarı göndermesini isteyen bir talimat eklenmiş olsun. Bu, açıklama için oluşturulmuş varsayımsal bir örnek: kayıttaki metin, asistanın görevini değiştirmeye çalışır. Buna prompt injection, yani istem enjeksiyonu denir.

Mesajı güvenilir bir destek sistemi taşıyor olabilir; bu, mesajın içeriğinin güvenilir olduğu anlamına gelmez. Anthropic, ajanları sınırlandırma üzerine mühendislik yazısında güvenilir bir bağlayıcının da zararlı talimat içeren veri getirebileceğini ve model savunmalarının tek başına yeterli olmadığını açıklıyor.

Bu örnekte ikinci soru şudur: Asistan yanlış talimatı izlese bile müşteri listesini okuyup gönderebiliyor mu? Yalnızca ilgili siparişin durumuna erişiyorsa ve dışarı gönderim aracı yoksa bu saldırı yolunun etkisi daralır. Dolayısıyla metni ayıklamak ile araçların yetkisini denetlemek ayrı kontrollerdir. Başarılı bir giriş işlemi, kullanıcının her kaydı okumaya veya her işlemi yapmaya yetkili olduğunu kanıtlamaz.

Yetkiyi araç adına ve gerçek işleme bağlayın

Başlangıçta tüm API uç noktalarını asistana açmak yerine üç küçük araç tasarlamak daha yönetilebilirdir: sipariş durumu sorgulama, cevap taslağı hazırlama ve onaylanmış cevabı gönderme. Sorgulama aracının işlem kapsamı, kullanıcının bağlı olduğu şirket ve izin verilen siparişler üzerinden sunucuda denetlenmelidir. İstekte gelen şirket kimliğine doğrudan güvenilmemelidir.

orders:read ve orders:write gibi adlar, uygulamanızda tanımlayabileceğiniz örnek yetki kapsamlarıdır; MCP’nin zorunlu tuttuğu hazır iş izinleri değildir. Okuma yetkisine sahip bir hesap, yazma aracını doğrudan çağırmayı denediğinde de engellenmelidir. Aracı yalnızca ekrandan gizlemek veya açıklamasına “salt okunur” yazmak bu denetimin yerini tutmaz.

HTTP üzerinden korunan MCP bağlantıları için resmi yetkilendirme belirtimi, OAuth 2.1 tabanlı akışı ve erişim belirtecinin hedef sunucuya ait olduğunun doğrulanmasını tarif eder. OAuth 2.0 sözlük maddesi bu yaklaşımın temelini açıklar. Yerel stdio bağlantılarında aynı HTTP akışı uygulanmaz; çalıştırılan sürecin ortamı ve erişebildiği kaynaklar ayrıca yönetilir.

MCP sunucusu başka bir servise bağlanıyorsa, istemciden aldığı herhangi bir belirteci o servise aynen aktarmamalıdır. Resmi MCP güvenlik rehberi, bu “token passthrough” yöntemini yasaklar. İki bağlantının yetkilerini ayrı ele alın; arka sistem hesabını da işin gerektirdiği izinlerle sınırlandırın.

Onay ekranı gerçek değişikliği göstermeli

Önerdiğimiz sipariş akışında asistan önce bir değişiklik taslağı üretir. Kullanıcı; sipariş numarasını, değişecek alanı, eski ve yeni değeri, müşteri üzerindeki etkiyi görür. Sunucu, yürütme sırasında onayın aynı işleme ait olduğunu denetler. Onaydan sonra tutar veya hedef kayıt değişmişse taslak yeniden incelenir.

Bu kontrolü yalnızca “önce izin iste” şeklindeki bir sistem mesajına bırakmayın. Onay kaydı, işlem kimliği ve yürütme koşulu uygulama tarafından bağlanmalıdır. Bir destek cevabına verilen onay, sonraki bütün mesajları gönderme iznine dönüşmemelidir. Onay metni teknik araç adını göstermenin yanında, işletme açısından ne olacağını anlaşılır biçimde açıklamalıdır.

MCP araç belirtimi, kişinin araç çağrılarını reddedebilmesini ve görünür işlem göstergelerini önerir; belirli bir arayüzü zorunlu kılmaz. Buradaki taslak ve değişiklik karşılaştırması, bu ilkeyi sipariş yönetimine uygulayan tasarım önerimizdir. Yetki denetimi, kullanıcı yanlışlıkla onay verse bile geçerli kalmalıdır.

Okuma erişiminin de sınırları olmalı

Salt okunur pilot, veri gizliliği açısından sınırsız değildir. Siparişin kargoya verilip verilmediğini öğrenmek için tüm müşteri profiline ihtiyaç yoktur. Aracın cevabını gerekli alanlarla sınırlayın; adres, telefon ve ödeme bilgilerini görev gerektirmedikçe model bağlamına taşımayın. Hangi verinin hangi sunucu ve model sağlayıcısına gönderildiğini bağlantı envanterinde kaydedin.

Kimlik bilgilerini sohbet metnine veya araç çıktısına koymayın. Mümkün olan sistemlerde kısa ömürlü, dar kapsamlı belirteçler kullanın ve iptal yolunu test edin. Bir rate limiting kuralı sorgu hacmini sınırlar; yanlış şirkete ait kaydın okunmasını engelleyen yetki kontrolünü sağlamaz. Kayıtlarda işlem sonucunu izlerken sırları ve gereksiz kişisel verileri maskeleyin.

Küçük bir pilot için kabul listesi

Pilotun başarısını yalnızca asistanın doğru cevap üretmesiyle ölçmeyin. Önerdiğimiz sıra şu:

  1. Tek görev seçin. Örneğin, belirli bir mağazanın sipariş durumundan destek cevabı taslağı üretmek. İptal, iade ve dışarı toplu veri aktarımı kapsam dışında tanımlansın.
  2. Sahte verilerle sınırları deneyin. Başka şirkete ait sipariş kimliği, eksik yetki ve talimat içeren müşteri mesajı testleri hazırlayın. Başarısız erişimde veri dönmediğini kontrol edin.
  3. Üretimde sınırlı okuma açın. Az sayıda kullanıcı ve gerekli alanlarla başlayın. Hatalı eşleşme, reddedilen erişim ve gereksiz veri dönüşünü inceleyin.
  4. Bir yazma işlemini ayrı değerlendirin. Önizleme, somut onay, tekrar denemede çift işlem oluşmasını önleme ve işlem sonrası doğrulamayı tamamlayın. Yanıt kesilirse işlem oluşmuş mu kontrol etmeden yeniden göndermeyin.
  5. Durdurma yolunu doğrulayın. Bağlantıyı kapatma ve yetki iptalinden kimin sorumlu olduğu belli olsun. Araç izinleri veya sağlayıcının davranışı değiştiğinde pilot kontrollerini tekrarlayın.

AI destekli yazılım geliştirme yazımızda anlattığımız insan denetimi yaklaşımı, iş sistemlerinde böyle somut sınırlar kazanır. Mevcut ERP veya müşteri destek sisteminiz için bu kapsamı çıkarmak isterseniz API geliştirme ve entegrasyon ve güvenlik denetimi hizmetlerimiz üzerinden bize ulaşabilirsiniz.

Resmi kaynaklar

Kaynak kontrolü: 5 Eylül 2026. Protokol sürümü, kullandığınız istemci ve sunucunun desteklediği sürümle ayrıca karşılaştırılmalıdır.