Cloudflare hat die Zugriffssteuerung für Workers präziser gemacht: Nutzer, Gruppen, API-Tokens und damit auch KI-Agenten oder CI/CD-Prozesse können auf einen einzelnen Worker begrenzt werden. Für Unternehmen ist das mehr als eine Komfortfunktion. Statt einem automatisierten Prozess Rechte auf alle Anwendungen eines Kontos zu geben, lässt sich sein technischer Aktionsradius auf genau die Anwendung reduzieren, die er bearbeiten soll. Das senkt nicht das Risiko eines fehlerhaften Deployments innerhalb dieses Workers, begrenzt aber den möglichen Schaden auf weniger Ressourcen.
Was Cloudflare konkret eingeführt hat
Bestätigt ist: Die neuen Worker-Rechte stehen laut Cloudflare allen Kunden zur Verfügung. Eine Richtlinie kombiniert eine Rolle mit einem Scope. Dieser Scope kann die gesamte Developer Platform, ein Produkt oder eine einzelne Ressource umfassen. Für einen Agenten oder eine Deployment-Pipeline ist die engste sinnvolle Variante daher meist: eine definierte Rolle für genau einen Worker. Die Zuweisung ist im Dashboard, über die API oder per Terraform möglich; mehrere Personen können über Benutzergruppen dieselbe Richtlinie erben.
- Metadata Read-Only: Einstellungen sowie Metriken, Logs und Traces sehen, aber keinen Quellcode. Geeignet für Diagnose- und Observability-Agenten.
- Content Read-Only: Worker-Code lesen, ohne ihn zu verändern oder bereitzustellen. Geeignet für Code-Review oder Fehleranalyse.
- Editor: Inhalte und Einstellungen ändern sowie deployen, aber Ressourcen weder anlegen noch löschen. Geeignet für eng begrenzte CI/CD-Workflows.
- Admin: vollständige Verwaltung einschließlich Anlegen, Umbenennen, Löschen und Rechtevergabe. Nur für klar benannte Administratoren oder kontrollierte Notfallzugriffe.
Entscheidungsrahmen für Agenten und Automationen
Aus GNS-Sicht sollte nicht der technische Akteur, sondern die konkrete Aufgabe die Rolle bestimmen. Ein Incident-Agent, der Logs auswertet, braucht keinen Codezugriff. Ein Review-Agent braucht Code, aber kein Deployment. Eine Pipeline benötigt Editor nur für den Worker, den sie tatsächlich ausliefert. Admin sollte nicht zum Standard werden, nur weil eine Integration mit engeren Rechten zunächst fehlschlägt. Die bessere Reaktion ist, die verweigerte Operation zu identifizieren und die Richtlinie gezielt zu korrigieren.
- Aufgabe notieren: Welche API-Operationen muss der Agent oder Workflow wirklich ausführen?
- Datenzugriff trennen: Reichen Metriken und Logs, wird Quellcode benötigt oder sind Schreiboperationen erforderlich?
- Scope minimieren: Ein Token pro Workflow und Worker statt eines gemeinsam genutzten Kontotokens.
- Löschrechte isolieren: Admin nur für menschlich kontrollierte Vorgänge oder einen separat abgesicherten Notfallprozess.
- Gültigkeit und Besitzer festlegen: Verantwortliche Stelle, Ablaufdatum, Rotation und Widerruf dokumentieren.
- Negativ testen: Nachweisen, dass der Akteur fremde Worker, Löschfunktionen und nicht benötigte Kontodaten tatsächlich nicht erreicht.
Diese Empfehlung ist eine operative Ableitung, keine Aussage Cloudflares über eine universell richtige Konfiguration. Ob ein Token pro Anwendung, Umgebung oder Pipeline sinnvoll ist, hängt von der eigenen Release-Architektur ab. Als Grundregel gilt jedoch: Ein kompromittiertes Token sollte möglichst wenige produktive Ressourcen und Funktionen erreichen. Getrennte Tokens verbessern außerdem die Zuordnung in Logs und erleichtern Rotation, Abschaltung und Ursachenanalyse.
Zwei Ausnahmen, die im Rollout leicht übersehen werden
Erstens sind Routes und Custom Domains separat geschützt. Wer eine Route anlegen, ändern oder entfernen will, benötigt neben Editor für den Worker zusätzlich die Berechtigung Workers Routes für die betreffende Zone. Ein bestehender Routing-Bezug lässt sich dagegen weiter nutzen, wenn ein Deployment ihn nicht verändert. Das ermöglicht einer Pipeline, neue Worker-Versionen auszurollen, ohne ihr zugleich Zugriff auf Domains, Datenbanken oder Storage zu geben.
Zweitens besitzen Durable Objects keine eigenständigen Rollen. Ihr Zugriff folgt dem Worker, der sie implementiert. Metadata Read-Only umfasst Metriken, Logs und Traces, nicht aber die gespeicherten Inhalte. Der Zugriff über Durable Objects Data Studio erfordert laut Cloudflare Editor, weil dort Daten direkt abgefragt und verändert werden können. Diese Vererbung gehört in jede Rechteprüfung: Wer nur auf den sichtbaren Worker-Code schaut, kann die Reichweite eines Editor-Zugriffs unterschätzen.
Ein kontrollierter Rollout in sechs Schritten
Beginnen sollte die Umstellung mit einer Inventur bestehender Mitgliederrechte und API-Tokens. Cloudflare lässt ältere Rollen vorerst weiterlaufen und nennt kein Abschaltdatum. Dadurch besteht kein Zwang zu einer überhasteten Migration, wohl aber die Chance, breite Altberechtigungen schrittweise zu ersetzen. Priorität haben produktive Tokens, gemeinsam genutzte Credentials und Automationen mit Änderungsrechten.
- Alle Worker, Umgebungen, Pipelines, Agenten und menschlichen Zugriffe erfassen.
- Für jeden Zugriff Soll-Rolle, Worker-Scope, Besitzer und geschäftlichen Zweck festlegen.
- Mit einem nicht kritischen Worker beginnen und erlaubte sowie verbotene Operationen prüfen.
- Produktive Tokens einzeln ersetzen; alte und neue Berechtigung nur so kurz wie nötig parallel halten.
- Fehler, Deployments, Token-Nutzung und verweigerte Zugriffe überwachen; keine pauschalen Rechteerweiterungen vornehmen.
- Nach Stabilisierung breite Altrollen entfernen und die Überprüfung in den regulären Access-Review aufnehmen.
Sinnvolle Betriebskennzahlen sind weniger die Zahl neu angelegter Rollen als der Anteil ressourcenspezifischer Tokens, die Zahl gemeinsam genutzter Credentials, das Alter aktiver Tokens und die Zeit bis zum Widerruf eines nicht mehr benötigten Zugangs. Für CI/CD kommen fehlgeschlagene Deployments wegen zu enger Rechte und erfolgreiche Versuche auf nicht erlaubte Ressourcen hinzu. Ein guter Rollout reduziert breite Zugriffe, ohne Release-Zeiten oder Störungsbehebung unkontrolliert zu verschlechtern.
Kosten, Nutzen und verbleibendes Risiko
Die technische Funktion kann den Schadensradius begrenzen, erzeugt aber mehr Richtlinien, Tokens und Verantwortlichkeiten. Das erhöht zunächst den Verwaltungsaufwand. Dieser Aufwand lohnt sich besonders bei mehreren produktiven Workers, externen Teams und automatisierten Akteuren. Kleine Umgebungen profitieren ebenfalls, sollten jedoch ein einfaches Namens-, Eigentümer- und Rotationsschema wählen. Ressourcenscope ersetzt weder Code-Review noch Tests, Secret-Management, Vier-Augen-Freigaben oder eine Rückfallstrategie.
Noch nicht verfügbar ist die gleiche Granularität für alle genannten Plattformprodukte. Cloudflare kündigt an, das Modell auf D1, R2 und KV auszuweiten. Bis diese Unterstützung tatsächlich bereitsteht, dürfen Verantwortliche daraus keine bestehenden Einzelressourcen-Rechte ableiten. Für heutige Architekturentscheidungen ist deshalb getrennt zu dokumentieren, welche Komponenten bereits granular eingeschränkt sind und wo weiterhin breitere Produkt- oder Kontorechte gelten.
Fazit: Rechte an Aufgaben und Ressourcen koppeln
Cloudflares neue Worker-Rollen schaffen eine brauchbare Grundlage für Least Privilege bei KI-Agenten, Entwicklerteams und CI/CD. Der größte praktische Gewinn entsteht, wenn Unternehmen Rolle und Ressourcenscope gemeinsam planen: Beobachten ohne Code, Lesen ohne Änderung, Deployen ohne Löschen und Administration nur dort, wo sie nachweislich nötig ist. Wer zusätzlich Route-Rechte, Durable Objects, Token-Lebenszyklus und Negativtests berücksichtigt, macht aus einer Produktfunktion ein belastbares Betriebsmodell.