Cloudflare'ın MCP step-up yetkilendirmesini test etmek: agent erişim kontrolünde ne değişiyor

Cloudflare, API MCP Server'a step-up yetkilendirme ekliyor

19 Ekim 2026'da Cloudflare, API MCP Server'ının artık step-up yetkilendirmeyi desteklediğini duyurdu: bir agent'ı yalnızca ihtiyaç duyduğu scope'larla bağlayın, ardından bir tool çağrısı daha fazlasını gerektirdiğinde talep üzerine ek izinleri onaylayın. Özel bir MCP client geliştirip canlı servise 128 istek gönderen bir geliştirici, mekanizmayı Google'ın uzun süredir var olan artımlı yetkilendirmesiyle (incremental authorization) karşılaştıran uygulamalı bir incelemeyi dev.to'da yayımladı. Bulgular, kapsamlı (scoped) API'lerle konuşan agent'lar geliştiren herkes için önemli.

Temel sonuç şu: step-up yetkilendirme, erişim vermenin yeni bir yolu değil. Yetkilendirme adımının kendisi sıradan bir OAuth authorization-code akışı. Yeni olan, sunucunun istemciye bir iznin eksik olduğunu bildirmesi için tanımlanmış bir yol — bu, hangi tool'ların çağrılacağını geliştirici değil bir yapay zeka agent'ı seçtiği için önemli; çünkü bir client, önceden hangi scope'lara ihtiyaç duyacağını bilemez.

Aralarında 382 kayıt bulunan iki scope listesi

dev.to analizine göre Cloudflare'ın MCP uç noktası birbirinden farklı iki scopes_supported listesi yayımlıyor. Protected Resource Metadata (RFC 9728) iki scope belirtiyor — user:read ve account:read — ve bunlar temel işlevsellik için gereken minimum olarak tanımlanıyor. Authorization Server Metadata (RFC 8414) ise dns.write, zone.write ve workers-r2.read gibi öğeler dahil 384 scope listeliyor.

Bu boşluk, özelliğin var olma nedeni. Step-up olmadan, ilk kez bağlanan bir client önceden 384 scope arasından seçim yapmak zorunda. Çok az isterse işlemler başarısız olur; çok isterse agent gereğinden fazla yetkiyle kalır. İki scope ile başlamak, ancak bir görev ihtiyacı ortaya çıkardığında daha fazlası verilebiliyorsa pratiktir.

Arka planda standart OAuth

Akışı başlatan hata — WWW-Authenticate başlığında insufficient_scope içeren bir 403 — 2012'de RFC 6750'de tanımlanmıştı. MCP belirtiminin eklediği şey ise çevresindeki prosedür: challenge'ı ayrıştır, son kez istenen scope'larla challenge'da belirtilen scope'ların birleşimini oluştur, normal authorization-code akışıyla yeniden yetkilendir ve özgün isteği tekrar dene.

Dev.to yazarı, Google'ın artımlı yetkilendirmesiyle karşılaştırma yaparken ayrımı üç eksende çiziyor: daha fazla erişim gerektiğini kim fark ediyor (Google'ın modelinde uygulama, MCP'de sunucu), eksik scope nasıl bildiriliyor (Google'da örtük olarak, MCP'de bir challenge ile açıkça) ve daha önce verilen scope'ları kim hatırlıyor — Google tarafında include_granted_scopes=true olduğunda yetkilendirme sunucusu, MCP'de ise client.

Özellik, değişiklik günlüğünün ima ettiğinden daha yeni değil. Step-up akışı zaten 2025-11-25 tarihli MCP belirtiminde vardı ve 2025-06-18'den önce yoktu. 2026-07-28 revizyonu tek bir önemli şeyi değiştirdi: scope birleşimini oluşturma sorumluluğunu sunucudan istemciye taşıdı.

Canlı testler ne buldu

Cloudflare'ın değişiklik günlüğü, daha önce verilmiş scope'ların korunduğunu söylüyordu ama kimin koruduğunu belirtmiyordu. Canlı test bu belirsizliği iki yönden çözdü. Cloudflare'ın yetkilendirme sunucusu, daha önce verilmiş scope'ları temel setin — iki metadata scope'u artı offline_access — ötesinde yeni yetkilendirmelere taşımıyor; bu, Google'ın davranışının tam tersi ve MCP client'larının birleşimi gerçekten kendilerinin sürdürmesi gerektiği anlamına geliyor. Yine de sunucu, 403 challenge'ları oluştururken bir token'a verilmiş scope'ları yansıtmıştı; 2026-07-28 belirtiminin uzaklaştığı bir yaklaşım.

Kapsam da tutarsızdı. Aynı sunucuda, bazı eksik yetkili işlemler düzgün bir 403 challenge döndürürken diğerleri boş bir listeyle HTTP 200 döndürdü. Zone'ları listeleme ve Workers script'lerini listeleme, ilgili scope'lar verilmeden önce boş döndü, verildikten sonra dolu döndü (üç zone, on iki script). D1 veritabanlarını listeleme, yetkilendirmeden önce bir challenge, sonrasında beş öğe döndürdü. Yazar bu açığı Cloudflare'a bildirdi ve aynı gün düzeltildi.

Bu değişiklik, kademeli bir dağıtımın üçüncü adımıydı: Wrangler ve API MCP Server, 22 Ağustos 2026'da isteğe bağlı scope'lar ve bir Edit Permissions onay seçeneği kazandı; 1 Ekim'de gönderilen workers-oauth-provider v1 ise sunucu geliştiricileri için tek satırlık bir insufficientScope() yardımcı işlevi içeriyordu.

Neden önemli

Boş liste başarısızlık modu sessiz tehlikedir. Challenge yolu çalıştığında bir agent en düşük ayrıcalıklarla başlayıp kullanıcı onayıyla yetkilerini yükseltebilir. Çalışmadığında ise agent bir izin sorunu bildirmez — kaynağın var olmadığını bildirir. Yazarın örneğinde bir agent ona zone olmadığını söyledi; oysa üç zone vardı. Agent geliştiricileri için pratik dersler şunlar: verilen scope'ları sunucunun yapacağını varsaymak yerine istemci tarafında takip etmek ve kapsamlı API'lerden gelen boş sonuçlara şüpheyle yaklaşmak. MCP sunucusu geliştiricileri için ders ise challenge'ları tutarlı biçimde üretmek; çünkü başka bir doğrulama yolu olmayan bir model için sessiz boşluk, yokluktan ayırt edilemez.