Am 22. August 2026 hat Cloudflare die feingranulare OAuth-Zustimmung für Wrangler und für den MCP-Server seiner API aktiviert. Bisher hieß das Autorisieren des Werkzeugs, alle angeforderten Berechtigungen auf einen Schlag anzunehmen; nun lässt sich nur ein Teil gewähren, was das Kommandozeilen-Tooling näher an das Prinzip der geringsten Rechte rückt.
Was die optionale Zustimmung ändert
Das klassische OAuth-Modell war alles oder nichts: Der Zustimmungsdialog listete die von einem Client verlangten Scopes auf, ohne andere Wahl als alles anzunehmen oder alles abzulehnen. Die Neuerung unterscheidet zwischen erforderlichen Scopes, vorausgewählt und nicht abwählbar, und optionalen Scopes, die man vor dem Bestätigen ablehnen kann. Das ausgestellte Token trägt dann nur die tatsächlich gewährten Berechtigungen.
In der Praxis zeigt der Autorisierungsdialog jetzt eine Schaltfläche „Edit permissions“, die die Liste der optionalen Scopes öffnet. Das Abwählen eines Scopes verkleinert die Reichweite des Tokens entsprechend. Braucht ein Befehl später eine abgelehnte Berechtigung, fügt eine erneute Autorisierung des Clients sie hinzu.
| Angeforderter Scope | Einstufung | Was er erlaubt |
|---|---|---|
user-details.read | Erforderlich | Kontoprofil lesen |
zone.read | Erforderlich | Zonenkonfiguration lesen |
workers-scripts.write | Optional | Workers bereitstellen |
workers-kv-storage.write | Optional | In KV-Namespaces schreiben |
Zur Vorsicht: Anwendungen, die diese Tokens nutzen, müssen mit Teilgewährungen umgehen. Nach dem Austausch sind die im Token tatsächlich vorhandenen Scopes zu prüfen, statt anzunehmen, dass alles Angeforderte gewährt wurde.
Wie ein Scope optional wird
Die Einstufung erfolgt auf Seite des OAuth-Client-Entwicklers, im Cloudflare-Dashboard: Jeder konfigurierte Scope lässt sich als erforderlich oder optional markieren. Standardmäßig bleiben alle erforderlich, was das bestehende Verhalten bewahrt. Die Einstufung erforderlich/optional wird nur gegen die in einem konkreten Autorisierungsvorgang wirklich angeforderten Scopes ausgewertet, nicht gegen die gesamte Konfiguration; wird kein optionaler Scope angefordert, bleibt der Zustimmungsdialog unverändert. Die Funktion steht ab Wrangler 4.116 bereit.
# Ré-autoriser Wrangler en n'accordant qu'un sous-ensemble de scopes
npx wrangler logout
npx wrangler login
# → l'écran de consentement propose « Edit permissions »
# décochez les scopes optionnels dont le workflow n'a pas besoin
# Si une commande échoue faute de permission, ré-autoriser pour ajouter le scope
npx wrangler login # cochez cette fois le scope manquantWarum das Agenten und MCP betrifft
Der Nutzen reicht über den Entwickler hinaus, der wrangler deploy ausführt. Cloudflare nennt ausdrücklich MCP-Server, die Agenten Werkzeuge bereitstellen. Ein solcher Server neigt dazu, ein breites Berechtigungsset anzufordern, da ein Agent theoretisch alle nutzen könnte; in der Praxis will kaum jemand, dass ein Agent so weitreichenden Zugriff hat. Optionale Scopes erlauben, dem Agenten nur das Nötigste zu gewähren, ohne dass der Server-Autor eine eigene Oberfläche zur Berechtigungsauswahl bauen muss.
Ein Token, das nur in Workers schreiben darf, kann weder einen Cache leeren noch eine DNS-Zone lesen.
Diese Logik passt zu einer größeren Verschiebung bei der Zugriffsdelegation an Agenten: den Wirkungsradius eines kompromittierten Tokens verkleinern und im Moment der Zustimmung lesbar machen, was ein automatisiertes Werkzeug tun kann. Sie verlängert Fragen, die der Aufstieg des MCP-Protokolls bereits aufgeworfen hat.
Was bleibt
Die Änderung ist leise, aber strukturell: Sie überführt die Autorisierung von Wrangler und MCP-Server von einem binären Modell in eine anpassbare Gewährung. Für Teams ist es die Gelegenheit, die an Integrationen und Agenten vergebenen Tokens zu prüfen und nur zu gewähren, was ein Workflow wirklich braucht. Die Einführungskosten sind auf Nutzerseite null; der Aufwand liegt bei den Client-Autoren, die ihre Scopes einstufen und Teilgewährungen sauber behandeln müssen.
Der richtige Standard für ein Agenten-Token ist das kleinste Berechtigungsset, das die Aufgabe dennoch abschließen lässt, mit erneuter Autorisierung, wenn sich der Bedarf ändert. Ich sehe zu viele Automatisierungs-Tokens, die „sicherheitshalber“ zugeschnitten sind, mit Schreibrechten, die niemand nutzt und die im Leckfall nur die Angriffsfläche vergrößern. Die Ablehnung eines Scopes bei der Zustimmung trivial zu machen, ist genau das Detail, das eine gute Praxis vom Reden ins tatsächliche Tun bringt — Simon Janvier
