MCP araç çağrısını çözer, yetkilendirmeyi değil: agent geliştiricilerinin kapatması gereken boşluklar

Her kontrolü geçen bir araç çağrısı

dev.to'da Coryntas tarafından yazılan bir yazı, Model Context Protocol'ün yardımının nerede bittiğini göstermek için bir çalışan ayrılışı (offboarding) iş akışı kullanıyor. İK sistemi, bir çalışanın erişiminin 17:00'de sonlanması gerektiğini kaydediyor. 15:30'da çalışanın yöneticisi, agent'a son toplantının bittiğini ve çalışanı hemen çıkarmasını söylüyor. Agent doğru kimlik yönetimi aracını buluyor, input şemasını karşılayan argümanlar oluşturuyor, MCP sunucusunun kabul ettiği bir token sunuyor ve erişilebilir bir API'ye ulaşıyor. Yazara göre bunların hiçbiri, yöneticinin fiili ayrılış saatini öne çekmeye yetkili olup olmadığını belirlemiyor. Entegrasyon, tam olarak tasarlandığı gibi davranırken gerçekleştirdiği iş aksiyonu zamansız veya yetkisiz olabilir.

MCP'nin araç sınırının gerçekte kapsadığı şey

Yazı, MCP'ye gerçek bir birlikte çalışabilirlik sorununu çözdüğü kredisini veriyor. Sunucular araç tanımlarını isim, açıklama ve input şemalarıyla yayımlıyor; istemciler yetenekleri tools/list ile keşfediyor ve tools/call ile çağırıyor; ve spesifikasyon, hatalı biçimlendirilmiş protokol isteklerini çalıştırma sırasında oluşan hatalardan ayırıyor. Ayrıca güvenlik görevlerini de atıyor: sunucular girdileri doğrulamak, erişim kontrollerini uygulamak, çağrıları rate-limit ile sınırlamak ve çıktıları temizlemek zorunda; istemciler ise araç etkinliğini göstermeli, sonuçları doğrulamalı, timeout uygulamalı, kullanımı kaydetmeli ve hassas işlemler için onay istemeli.

Yazara göre bu kontroller yalnızca aracın var olduğunu, argümanların kabul edilebilir biçimde olduğunu, çağıranın sunucuya ulaşabildiğini ve sonucun beklenen yapıyla eşleştiğini kanıtlıyor. Hangi sistemin fiili saat gibi bir alan üzerinde yetki sahibi olduğunu, yasal bir tutma (legal hold) olup olmadığını veya başka bir iş akışının aynı görevi zaten başlatıp başlatmadığını söyleyemezler.

Transport yetkilendirmesi daha dar bir soruyu yanıtlıyor

MCP'nin yetkilendirme spesifikasyonu HTTP transportlarını kapsıyor: bir istemcinin yetkilendirme sunucusunu nasıl bulduğu, bir access token nasıl edindiği ve onu korunan bir kaynağa nasıl sunduğu. Yazıya göre bu, istemcinin verilen bir kapsam dahilinde istek yapıp yapamayacağını yanıtlıyor, bu belirli offboarding işleminin 15:30'da gerçekleşmesi gerekip gerekmediğini değil.

Yazar, gerçek iş akışlarının en az dört kimlik içerdiğini yazıyor: işi başlatan istek sahibi, hedef sistem üzerinde hareket eden workload kimliği, erişimi değişen subject ve diğerlerinin sahip olmadığı yetkiyi sağlayan onaylayıcı. Bu rolleri tek bir kimlikte birleştirmek denetim kayıtlarını çarpıtır. Yöneticinin token'ıyla hedef sistem, otomatik bir iş akışının gerçekte seçtiği bir hesabı devre dışı bırakan kişi olarak yöneticiyi kaydeder; service account ile günlük teknik aktörü adlandırır ama değişikliği kimin istediğini ve hangi İK kararının bunu yetkilendirdiğini düşürür. OAuth kapsamları aktörün teknik olarak neler isteyebileceğini sınırlar; iş akışı politikası ise hâlâ bu çalışmanın bu anda bu subject üzerinde ne yapabileceğine karar vermelidir. Yazı ayrıca, bir MCP sunucusu aşağı akış (downstream) servislerini çağırırken token passthrough yapılmaması yönündeki resmi güvenlik kılavuzuna atıfta bulunuyor ve ayrı bir downstream kimlik bilgisinin bile kullanımının iş gerekçesini sağlamadığını belirtiyor.

Runtime'ın inceleyebileceği bir çalıştırma zarfı

Yazar, sonuç doğuran bir çağrıdan önce runtime'ın eylemin şu anda neden izinli olduğunun kompakt bir kaydını tutmasını öneriyor: açıkça MCP spesifikasyonunun parçası olmayan, örnek niteliğinde bir çalıştırma zarfı (execution envelope). Alanları arasında istek sahibi, aktör ve subject tanımlayıcıları, yetkili İK olayına bir işaretçi, kullanılan politika sürümü, izin verilen bir aksiyon, execute-after zaman damgası, payload digest'ı içeren bir onay referansı, idempotency anahtarı ve kanıt referansları var. Her alan belirli bir boşluğu kapatıyor. Execute-after değeri, gelecekte geçerli bir aksiyonun hemen yetkili bir aksiyona dönüşmesini engelliyor; digest ise bir onayı tek bir kesin payload'a bağlıyor. Yazar, bu değerleri araç argümanları olarak taşımanın onları daha güvenilir yapmadığı konusunda uyarıyor; runtime bu değerleri yetkili sistemlerden almalı ve modelin veya istek sahibinin kendininkini koymasını engellemelidir.

Onayların süresi dolar ve timeout'lar yalan söyler

Zamanlama argümanı şöyle işliyor: İK 17:00'lik bir çalıştırmayı 15:30'da onaylıyor, ayrılış 16:45'te erteleniyor ve 16:50'de bir yasal tutma geliyor. Önceki onay, önceki bir durumu doğru şekilde tanımlıyordu. Runtime, kararı önemli ölçüde etkileyen gerçekleri pratik olduğu ölçüde çalıştırmaya yakın bir zamanda yeniden doğrulamalıdır; bunlara güncel İK olayı ve fiili saat, istihdam durumu, aktif tutmalar, onay geçerliliği, önerilen payload ve hedef hesabın gözlemlenen durumu dahildir; girdiler değiştiğinde bir onayı geçersiz kılmalı veya daha dar bir inceleme istemelidir. Disable-user aksiyonu için genel bir onay istemi, inceleyen kişi subject'i, zamanlamayı veya bağımlı aksiyonları hiç görmediyse pek bir şey kanıtlamaz.

Son olarak, kimlik sağlayıcısı yanıtı geri dönüş yolunda kaybolan bir yazma işlemi gerçekleştirebilir. Bir timeout başarısızlığı kanıtlamaz ve körleme tekrar denemeler belge aktarımlarını, bildirimleri veya servis masası kayıtlarını ikileyebilir. Yazar, yazma yapabilen entegrasyonların runtime'ın tekrar denemek, incelemek, uzlaştırmak veya durmak arasında seçim yapabilmesi için yeterli çalıştırma bilgisi açığa çıkarması gerektiğini savunuyor.

Neden önemli

Agent entegrasyonları yapan ekipler için MCP angaryayı ortadan kaldırıyor: keşif, çağırma ve transport kimlik doğrulaması. Yargı katmanına ise dokunmuyor. Bir araca erişim yetkisi, eylem yetkisi değildir ve yeşil yanan bir araç çağrısı, hiçbir insanın veya politikanın gerçekte vermediği bir kararı kodlamış olabilir. Yazının tespit ettiği boşluklar — kimlik ayrımından politika sürümlü onaylara, zaman sınırlı çalıştırmaya, yeniden doğrulamaya ve idempotency'ye kadar — hepsi protokolün üzerinde yer alıyor; yani agent'ları üretim sistemlerine bağlayan her kurum, o katmanı kendisi kurmak ve denetlemek zorunda.