Bu serinin son iki bölümünde Model Bağlam Protokolü'nün bir yük API'sine nasıl eşlendiği ve ardından 2026'da gönderilen yük MCP sunucularını söktü konularını ele almıştım. Her ikisi de aynı açık uçlu soruyla sona erdi, bu yüzden bu bölüm doğrudan bu soruyu yanıtlıyor: bir ajan gerçek navlun rezervasyonu yapabildiğinde, yanlış kişiye yanlış şeyi rezerve etmesini nasıl önlersiniz? Güvenlik, bir nakliye MCP sunucusunun bir geliştirici oyuncağı gibi görünmekten çıkıp para ve kamyonları hareket ettiren bir sistem gibi görünmeye başladığı yerdir.
Bir API'ye erişim sağlayan bir pazarın merkezinden çalışıyorum, bu yüzden önyargım akademik olmaktan çok pratiktir. Aşağıdaki tehditler, bir insan döngüde olmadan bir aracın hangi aracı çağırabileceğine karar verirken fiilen modellediğimiz tehditlerdir.
Neden bir yük sunucusu riskleri artırır
Takviminizi okuyan genel bir MCP sunucusu başarısız olduğunda bilgi sızdırır. Bir yük tahsis eden bir nakliye sunucusu daha maliyetli bir şey yapar. Kötü bir çağrı, bir kamyonu yanlış depoya gönderebilir, canlı bir sevkiyattaki alıcıyı değiştirebilir, bir müşterinin güvendiği bir rezervasyonu iptal edebilir veya hesaptan asla çıkmaması gereken bir konşimentoyu çekebilir. Bunlar veri açıklığı hatası değildir. Bunlar, kimsenin yazmadığı bir talimat üzerine hareket eden para ve fiziksel mallardır.
Bu fark, tüm sorunu yeniden çerçeveliyor. Bir sohbet asistanıyla en kötü senaryo utanç verici bir cevaptır. Yük taşımacılığında ise en kötü senaryoya bir navlun faturası eşlik eder ve sevkiyat olması gereken yerde değildir. Bu nedenle soru asla soyut olarak "bu sunucu güvenli mi" olmaz. Bu, "bir temsilci hangi özel eylemleri gerçekleştirebilir ve yanlış giderse her biri ne kadara mal olur" sorusudur.
Uykunuzdan olmaya değecek iki başarısızlık modu
2026'da en yüksek MCP riski iki desene indirgenir ve navlun her ikisini de kötüleştirir.
Prompt enjeksiyonu, eski bir web sorunudur ve yeni kıyafetler giymiştir. Bir aracı, tam olarak kontrol edemediği bir yerden, bir nakliye notundan, bir PDF'ten, bir e-posta gövdesinden metin okur ve bu metin, modelin uyduğu bir talimat içerir. Nakliye sektöründe, zehirlenmiş metin gün boyunca meşru kanallardan gelir: bir rezervasyon yorumu, bir gümrük açıklaması, bir taşıyıcının durum güncellemesi. Rezervasyon aracınız, modelin ona ilettiği her şeye güveniyorsa, bir teslimat notuna gizlenmiş bir cümle gerçek bir iptal olabilir.
**Araç Zehirlenmesi** daha ince ve MCP'ye özgüdür. Protokol, bir sunucunun kendi araçlarını tanımlamasına olanak tanır ve aracı, neyi çağıracağına karar vermek için bu tanımları okur. Kötü amaçlı veya tehlikeye atılmış bir sunucu, modele gizlice bir API anahtarını sızdırmasını veya bir sevkiyatı yönlendirmesini söyleyen bir açıklama yazabilir ve kullanıcı bu metni asla görmez. Anthropic ve bağımsız araştırmacılar 2026'nın başlarını bunun varyantlarını belgeleyerek geçirdi ve nakliye için ders kesindir: açıklama katmanı yürütülebilir olduğundan, üçüncü taraf bir araç açıklamasına üçüncü taraf koda davranacağınızla aynı şüpheyle davranın.
Oku versus yaz: kimlik doğrulamana karar vermesi gereken çizgi
Yaptığım en faydalı güvenlik kararı, "MCP sunucusunu" tek bir güven sınırı olarak düşünmeyi bırakıp her aracın dünyaya ne yaptığına göre bölmek oldu.
Ne açık kalabilir
Bir şeridi alıntılamak, kapasiteyi listelemek, bir geçiş süresi tahmini hesaplamak, bir liman kodunu sorgulamak. Bunların hiçbiri bir şeyi değiştirmez. Bir temsilcinin onlara minimum sürtünmeyle veya hiç sürtünme olmadan ulaşmasını sağlamak asıl amaçtır ve günlük değerin oturduğu yer burasıdır. Üç rotayı karşılaştırmak isteyen bir okuyucunun bunu yapabilmek için bir token basmak zorunda kalmaması gerekir. Yıkımdaki sunucular arasında, ciddi olanlar tam da bu nedenle alıntı ve referans araçlarını düşük sürtünmeli tuttu.
Neler engellenmeli
Rezervasyon, iptal etme, alıcı değişikliği, adres düzenleme, belge çekme, faturayla ilgili herhangi bir işlem. Bunların her biri gerçek dünyaya yazma işlemi yapar ve her biri arkasında kimliği doğrulanmış, yetkilendirilmiş, denetlenebilir bir çağrı gerektirir. İzlediğimiz kural belirtmesi basit, uygulaması ise daha zordur: okuma aracı açık olabilir, yazma aracı asla.
OAuth 2.1 ve PKCE, yapılandırma dosyasında uzun ömürlü bir anahtar değil
MCP yetkilendirme spesifikasyonu, uzak sunucular için OAuth 2.1 üzerinde anlaşmaya vardı ve bu seçim, taşımacılık için gerçek bir ağırlık taşıyor. Yapılandırma dosyasına yapıştırılan sabit bir API anahtarı, kendi makinesinde stdio üzerinden bir sunucu çalıştıran tek bir geliştirici için uygundur. Sunucu HTTP üzerinden erişilebilir olur olmaz ve bir temsilci, paylaşılan bir hesap içindeki adlandırılmış bir kullanıcının adına hareket ettiğinde bu yanlış bir modeldir.
Üç özellik öne çıkıyor. Kapsamlı belirteçler, alıntı yapmak için oluşturulan bir belirtecin rezervasyon yapamayacağı anlamına gelir. Kısa ömürlü belirteçler, sızan bir kimlik bilgilerinin sonsuza kadar bir günlükte kalmak yerine kendi kendine sona ermesi anlamına gelir. Geri alınabilir belirteçler, bir şeyler ters gittiğinde, herkesin güvendiği paylaşılan bir anahtarı döndürmek yerine saniyeler içinde erişimi kesebileceğiniz anlamına gelir. OAuth 2.1 ayrıca yetkilendirme kodu akışında PKCE'yi gerektirir, bu da eski OAuth dağıtımlarının açık bıraktığı kesinti boşluğunu kapatır. Bunların hiçbiri egzotik değil. Bir temsilci "rezervasyon yap" dediği ana uygulanan, herhangi bir ödeme API'sinin geçtiği sertleşmenin aynısıdır.
İşte zorunlu tuttuğumuz sınırın şekli, her yük sunucusunun yayınlamasını dilediğim tablo olarak yazılmıştır.
| Agent eylemi | Okur veya yazar | **Auth'a ihtiyacımız var** | **Yanlış giderse** |
| Teklif al | Oku | Açık veya temel anahtar | Boşa çaba, zarar yok |
| Kapasiteyi, transit sürelerini, takibi kontrol edin | Oku | Açık veya temel anahtar | En kötü ihtimalle güncel olmayan yanıt |
| Gönderi rezerve et | Yazmak | Kapsamlı OAuth belirteci, onay adımı | Gerçek maliyet, gerçek kamyon |
| İptal et veya yeniden rezervasyon yap | Yazmak | Kapsamlı belirteç, idempotent anahtar | Kayıp slot, ceza |
| Alıcıyı veya adresi değiştir | Yazmak | Kapsamlı jeton, insan onayı | Yanlış teslimat, dolandırıcılık |
| Bir konşimento veya fatura çekin. | Hassas oku | Kapsamlı jeton, belge başına denetim | Veri ve belge sızıntısı |
O tablodaki örüntü, gerçek ürün kararıdır. Okumalar solda yer alır ve ucuz kalır. Yazmalar sağda yer alır ve sürtünmelerine değer.
Açığa çıkan örnek sorunu
MCP riskinin şaşırtıcı derecede büyük bir kısmı hiç de zekice değil. Yerel olarak çalışması gereken bir sunucu, kimlik doğrulama olmadan açık internete maruz bırakılmış, çünkü bu şekilde göndermek daha kolaydı. Protokol iki taşıma katmanını destekler. Bir stdio sunucusu, istemcinin başlattığı yerel bir işlem olarak çalışır, bu da onu makinenizde tutar ve ağdan uzaklaştırır. Barındırılan bir HTTP sunucusu, URL'sini bulabilen her şey tarafından erişilebilir.
Salt okunur bir yardımcı sunucu için HTTP'ye maruz kalma büyük ölçüde zararsızdır. Rezervasyon araçları olan biri için ise her şey demektir. Yazma araçlarınız genel HTTP üzerinden erişilebiliyorsa, kimlik doğrulama daha sonra ekleyeceğiniz bir özellik değildir; yabancıyla gönderi kuyruğunuz arasındaki tek şeydir. Kuralımız, rezervasyon ve belge araçlarının asla kimliği doğrulanmamış bir HTTP uç noktası üzerinden sunulmayacağıdır, nokta. Şüpheye düştüğünüzde, yazma yetenekli bir sunucu varsayılan olarak stdio ve yerel başlatmaya yönelmeli ve yalnızca yukarıdaki OAuth akışı yerindeyken barındırılan HTTP'ye yükselmelidir.
Açıklama katmanını araç zehirlenmesine karşı savunmak
Araç açıklamaları modeli yönlendirdiği için, dağıttığınız kodla aynı denetimlere sahip olmayı hak ediyor. Üç alışkanlık, maruz kalmaların çoğunu kapsar.
- Bağlandığınız sunucuları sabitleyin ve inceleyin. Bilinen sunuculardan oluşan özel bir kümeye bağlanan bir ajan, kayıt defterinin sunduğu herhangi bir şeyi yükleyen bir ajandan daha küçük bir hedeftir. Yeni bir sunucuyu, çünkü öyle olduğu için yeni bir bağımlılık gibi ele alın.
- Her yazıda bir insan bulundurun. Bir sevkiyatçıyı rezerve etmeden, iptal etmeden veya değiştirmeden önceki bir onay adımı, sessizce yapılan bir talimatı kullanıcının reddedebileceği görünür bir isteğe dönüştürür. En yüksek getiriyi sağlayan en ucuz kontroldür.
- API'de doğrulayın, istemde değil. Sunucu, modelin mantıklı bir çağrı oluşturduğuna güvenmek yerine, aldığı her parametreyi hesabın gerçek izinlerine ve rezervasyonun gerçek durumuna karşı yeniden kontrol etmelidir. Model önerir, API karar verir.
Tek bir taşıyıcının atlayabilmesi için bir pazar yeri sunucusunun neyi zorunlu kılması gerekir?
Tek taşıyıcılı bir sunucu yalnızca kendi ağında hareket eder, bu nedenle etki alanı bir operatörle sınırlıdır. Bir pazar yeri sunucusu ise birçok kullanıcı adına birçok taşıyıcıda teklif verir ve rezervasyon yapar, bu da güvenlik görevini iki şekilde değiştirir.
Öncelikle, kapsam kullanıcı bazında ve taşıyıcı bazında olmalı, sunucu bazında değil. Bir temsilcinin bir taşıyıcı ile rezervasyon yapmasına izin veren bir jeton, sessizce başka bir taşıyıcıya ulaşmamalı ve bir müşterinin temsilcisi asla başka bir müşterinin belgelerini görmemelidir. İkinci olarak, denetim izi daha önemlidir, çünkü bir temsilci bir pazar yeri üzerinden rezervasyon yaptığında, her yazım işlemi için "hangi kullanıcı, hangi jeton, hangi taşıyıcı, ne zaman" sorularını yanıtlamanız gerekir. Bu kaydı, herkese fişi çekmek yerine dar bir şekilde iptal etmemize olanak tanıdığı için, bir sonradan düşünülmüş bir şey değil, ürünün bir parçası olarak ele alıyoruz.
Rezervasyonunuzu yayınlamadan önce pratik bir kontrol listesi
- Araçları okuma ve yazma olarak ayırın ve bölünmeyi hem temsilcinin hem de ekibinizin görebileceği bir yere yazın.
- Alıntı yapma ve referans araçlarını düşük sürtünmeli tutun ki günlük değeri devam etsin.
- Her yazma işlemini, kapsamı belirlenmiş, kısa ömürlü, iptal edilebilir bir OAuth 2.1 belirteci (PKCE ile birlikte) ile güvence altına alın.
- Rezervasyon, iptal, alıcı ve adres değişikliklerinde onay adımı gereklidir.
- API'deki her parametreyi gerçek izinlere ve gerçek sevkiyat durumuna karşı yeniden doğrulayın.
- Yazma araçlarını asla kimliği doğrulanmamış HTTP üzerinden sunmayın ve yazma yeteneğine sahip sunucuları varsayılan olarak yerel stdio'ya ayarlayın.
- Ajanınızın bağlandığı sunucuları sabitleyin ve yeni kodları inceler gibi yenilerini gözden geçirin.
- Her yazmayı kullanıcı, belirteç, taşıyıcı ve zamanla günlüğe kaydedin ve ihtiyacınız olmadan önce geri çağırmayı prova edin.
Bunların hiçbiri yapay zekaya özgü değil. Bunlar, bir talimatın kaynaklanabileceği yeni yere yöneltilmiş, nakliye ve ödemelerin zaten kullandığı kontrollerdir. Aracı, yeni bir kural seti değil, yeni bir çağrandır.
Sıkça Sorulan Sorular
Yapay zeka aracısının navlun rezervasyonu yapmasına izin vermek güvenli midir?
Evet, onay adımıyla kimliği doğrulanmış ve yetkilendirilmiş bir çağrının arkasında rezervasyon yapıldığında ve sunucu modelden gelen bilgilere güvenmek yerine her parametreyi yeniden kontrol ettiğinde. Güvensiz sürüm, insan müdahalesi olmayan açık bir yazma aracıdır. Rezervasyonları para hareketini içeren diğer işlemler gibi ele alın ve aracı da kimliği doğrulanmış başka bir arayan olacaktır.
Neden basit bir API anahtarı yerine OAuth 2.1 kullanılmalı?
Statik bir anahtar uzun ömürlü, geniş kapsamlı ve onu paylaşan herkesi rahatsız etmeden iptal edilmesi zor olma eğilimindedir. OAuth 2.1, kapsamlı, kısa ömürlü, iptal edilebilir jetonlar sunar ve yetkilendirme akışında PKCE gerektirir. Yerel bir stdio sunucusu için bir anahtar kabul edilebilir, ancak HTTP üzerinden erişilebilen ve yazabilen her şey OAuth modelini kullanmalıdır.
MCP'de araç zehirlenmesi nedir?
Araç zehirlenmesi, aracının neyi çağıracağına karar vermek için okuduğu bir sunucunun araç tanımının, bir anahtarı sızdırmak veya bir sevkiyatı yönlendirmek gibi zararlı eylemlere modeli yönlendiren gizli talimatlar içermesidir. Tanım davranışları etkilediği için onu kod gibi savunursunuz: güvenilir sunucuları sabitleyin, yazma işlemlerinde bir insan bulundurun ve API'de doğrulayın.
Bir yük MCP sunucusu stdio olarak mı yoksa barındırılan HTTP olarak mı çalıştırılmalı?
Salt okunur bir yardımcı sunucu, barındırılan HTTP üzerinden kurulabilir. Rezervasyon veya belge araçları olan bir sunucu, varsayılan olarak yerel stdio'ya ayarlanmalı ve yalnızca kapsanan OAuth kurulduktan sonra barındırılan HTTP'ye geçmelidir, çünkü kimlik doğrulama olmadan açık bir yazma uç noktasına, URL'yi bulan herkes tarafından erişilebilir.
Bu, bu serinin açtığı döngüyü kapatıyor. Daha önceki bölümleri okumadıysanız, protokol primer bir kargo API'sinin bir araç setine nasıl dönüştüğünü açıklıyor ve Yıkım gönderilen sunucuların bu çizgileri pratikte nereye çektiğini gösteriyor.