MCP, kararlı bir “Enterprise-Managed Authorization” spesifikasyonu yayınladı; OAuth client-credentials taslağı ve iki açık öneri dahil olmak üzere diğer makineden makineye (machine-to-machine) kimlik taslakları ise henüz tamamlanmadı. Model Context Protocol ile otonom ajanlar çalıştırmaya çalışanlar için bu, mevcut protokolün bir insan kullanıcıyı doğrulayabileceği ancak gözetimsiz bir sürecin iddia ettiği kişi olduğunu kanıtlayacak hazır bir yöntem sunmadığı anlamına geliyor.
Yol haritası neden önemli
Model Context Protocol (MCP) yol haritası, ajan kimliği ve güvenliğini en önemli öncelikleri arasında listeliyor. Yayınlanması planlanan dört madde vardı: insan odaklı bir tarayıcı akışı, servisler için bir OAuth client-credentials akışı, DPoP tabanlı bir token bağlama (token binding) ve bir iş yükü kimliği federasyonu (workload-identity federation) mekanizması. Bunlardan sadece ilki —Enterprise-Managed Authorization— kararlı statüye ulaştı.
Kararlı spesifikasyon gerçekte ne yapar
Enterprise-Managed Authorization, BT yöneticilerinin her bağlantıyı her çalışanın onaylaması yerine, sunucu erişimini tek bir konsoldan vermesine olanak tanır. Akış, bir tarayıcı yönlendirmesi ve kullanıcı girişi kullanır; böylece bir dizüstü bilgisayar başındaki kişi kimlik doğrulaması yapabilir ve ardından sunucu o kullanıcının oturumuna güvenir.
Kısıtlama barizdir: Süreç, klavye başında bir insana ihtiyaç duyar. Gece boyunca çalışan, veri işleyen veya uyarılara yanıt veren bir ajanın, bir giriş düğmesine tıklayacak kimsesi yoktur. Sonuç olarak, gözetimsiz ajanlara bağımlı olan herhangi bir dağıtım, MCP'nin şu anda garanti ettiği tek spesifikasyonu kullanamaz.
Taslak seçenekler ve dezavantajları
İki taslak uzantı, ajanlara kendi kimliklerini vermeyi amaçlıyor:
- SEP-1932 (DPoP) – tokenları bir açık-gizli anahtar çiftine bağlayarak çalınan tokenları işe yaramaz hale getirir.
- SEP-1933 (Workload Identity Federation) – ajanların bulut platformlarında halihazırda tanımlanmış kimlikleri devralmasına olanak tanır.
Her ikisi de açık pull request olarak duruyor; hiçbiri resmi spesifikasyona dahil edilmedi. Bu süre zarfında, belgelenmiş diğer tek seçenek, önceden kaydedilmiş sırlar (secrets) gerektiren bir OAuth client-credentials akışıdır. Bu sırları bir ajanın okuyabileceği bir yerde saklamak, klasik bir saldırı yüzeyi oluşturur: Eğer sır sızarsa, herhangi bir saldırgan ajanın kimliğine bürünebilir.
Bugün üretim ortamı için pratik adımlar
Protokol henüz yerel bir ajan kimliği sağlamadığı için ekipler, kimlik yönetimini MCP dışına taşıyarak ajanları yine de güvence altına alabilirler:
- İş yükü katmanında doğrulanabilir kimlikler oluşturun. SPIRE gibi sistemler, ana makinenin güven köküne (trust root) bağlı kısa ömürlü sertifikalar oluşturarak statik sırları ortadan kaldırır.
- Kimlik bilgilerini bir ağ geçidinde (gateway) sonlandırın. Bir ön uç (front-end) servisi API anahtarını veya token'ı tutar ve istekleri ajan adına ileterek sırrı çalışma zamanı (runtime) ortamının dışında tutar.
- Token içeriğine göre değil, doğrulanmış kimliğe göre yetkilendirme yapın. Kimlik doğrulamayı (kim çağırıyor) yetkilendirmeden (ne yapabilirler) ayırın; böylece kimlik doğrulama yöntemi değişse bile politika uygulanabilir.
Sırada ne var?
İki açık pull request —DPoP binding ve workload-identity federation— MCP bünyesinde gerçek bir makineden makineye kimlik standardına giden tek yoldur. Topluluk bunları birleştirirse, ajanlar sırları ifşa etmeden bir gizli anahtara sahip olduklarını kanıtlayabilecek veya bulut tarafından verilen kimlikleri devralabileceklerdir. O zamana kadar, her türlü üretim dağıtımı harici kimlik çerçevelerine güvenmek veya statik kimlik bilgilerinin riskini kabul etmek zorundadır.
Sonuç açık: MCP şu anda bir isteğin arkasındaki kişiyi doğrulayabilir, ancak isteği yapan yazılımı henüz doğrulamıyor. Güvenli otonom ajanlara ihtiyaç duyan ekipler, spesifikasyonun yayınlanmasını beklememeli; kimliği bugün iş yükü katmanında inşa etmeli ve bekleyen DPoP ve federasyon önerilerini takip etmelidirler.