PathruleRollen und Berechtigungen
Die Rollen in einer Pathrule-Organisation, wie ein Workspace mit der ganzen Organisation geteilt oder privat gehalten wird und wie die Datenbank jeden Lese- und Schreibzugriff einheitlich durchsetzt, ob über die Webkonsole, die CLI, VS Code oder MCP.
Auf dieser Seite
Pathrule beginnt als Werkzeug für Einzelne und wächst zu einem Teamprodukt. Sobald du Kolleginnen und Kollegen einlädst, stellt sich die Frage, wer was sehen und ändern darf. Diese Seite beschreibt die Rollen, die du vergibst, wie sich der Zugriff von der Organisation auf den Workspace eingrenzen lässt und wo die Prüfung tatsächlich stattfindet.
Kurz gesagt: Rollen werden auf Organisationsebene vergeben, der Zugriff lässt sich pro Workspace einschränken, und jeder Lese- und Schreibzugriff auf einen Pathrule Cloud-Workspace wird von der Datenbank gegen deinen angemeldeten Benutzer geprüft. Diese Prüfung gilt gleichermaßen, ob die Anfrage aus der Webkonsole unter app.pathrule.io, der Pathrule CLI, der VS Code-Erweiterung oder dem MCP-Server kommt, mit dem ein KI-Client spricht.
Ein lokaler Workspace, der mit --local angelegt wurde, hat kein Konto und liegt auf einem einzigen Rechner. Für ihn gelten deshalb keine Rollen, bis du ihn in die Cloud verschiebst.
Die vier Rollen
Rollen werden pro Person auf Organisationsebene vergeben. Ein Owner oder Admin lädt eine Kollegin oder einen Kollegen per E-Mail ein und wählt die Rolle, standardmäßig Editor; mit dem Annehmen der Einladung tritt die Person der Organisation bei. Einladen kannst du unter Members in der Webkonsole oder im Terminal:
pathrule invite colleague@example.com --role viewer
| Rolle | Darf |
|---|---|
| Owner | Die Organisation verwalten und die Eigentümerschaft steuern. Die Organisation muss immer einen Owner behalten. |
| Admin | Mitgliedschaften und zulässige Rollen verwalten sowie Workspaces administrieren. |
| Editor | Inhalte (Memories, Regeln, Skills) in den Workspaces lesen und schreiben, auf die die Person Zugriff hat. Die Standardrolle für den Arbeitsalltag. |
| Viewer | Inhalte in den Workspaces lesen, auf die die Person Zugriff hat. Kein Schreiben. |
Daraus ergeben sich einige Schutzmechanismen:
- Änderungen an der Eigentümerschaft erfordern Owner-Rechte, und die Organisation muss einen Owner behalten.
- Änderungen an Eigentümerschaft und Mitgliedschaft werden auf dem Server geprüft, einschließlich der Vorgabe, dass ein Owner erhalten bleiben muss.
Änderungen an Mitgliedschaften setzen eine aktuelle, berechtigte Session voraus. Für sensible Aktionen wie das Archivieren oder Löschen eines Workspace ist zusätzlich eine frische Authentifizierung nötig.
Seats und Pläne
Jede Person in der Organisation belegt einen Seat, unabhängig von ihrer Rolle.
- Solo und Pro sind für eine Person gedacht. Sie bieten keine Einladungen; um mit anderen zusammenzuarbeiten, wechselst du zu Team.
- Team wird pro Seat abgerechnet, mindestens zwei, der Owner eingeschlossen. Wer mehr Personen einladen will, als Seats bezahlt sind, braucht einen weiteren Seat; gibt es weniger Seats als Mitglieder, behalten alle ihren Zugriff, und neue Einladungen warten.
- Seats für Enterprise werden mit dem Vertrieb vereinbart.
Seats und Rechnungen findest du unter Billing in der Webkonsole; pathrule billing öffnet diesen Bereich aus dem Terminal. Siehe Pathrule Web.
Workspace-Zugriff: organisationsweit oder privat
Die Rolle legt fest, was eine Person tun darf. Der Zugriffsmodus eines Workspace legt fest, wer ihn überhaupt erreicht. Jeder Workspace hat einen von zwei Modi.
- Organisationsweit. Jedes Mitglied der Organisation hat Zugriff, mit seiner Rolle in der Organisation.
- Privat. Nur Personen, die ausdrücklich zum Workspace hinzugefügt wurden, haben Zugriff. Die Mitgliedschaft in der Organisation allein reicht nicht.
Owner und Admins stellen den Modus in den Einstellungen der Webkonsole unter Workspace, Access um. Wird ein Workspace privat, haben nur noch seine ausdrücklich hinzugefügten Workspace-Mitglieder Zugriff. Prüfe, wer Zugriff braucht, und füge diese Personen hinzu; die Mitgliedschaft in der Organisation allein gewährt keinen Zugriff mehr. Innerhalb eines privaten Workspace bestimmt die Workspace-Rolle einer Person, was sie dort tun darf. So kannst du jemandem dort andere Rechte geben als an anderer Stelle.
Zugriffsverlust zerstört nichts
Änderungen an Berechtigungen vernichten nie Arbeit und blenden sie nur selten aus.
- Verlierst du Schreibrechte (etwa beim Wechsel von Editor zu Viewer), verschwindet nichts. Du kannst weiterhin alles lesen, was du vorher lesen konntest; Schreibzugriffe von dir oder von einem Assistenten, der in deinem Namen arbeitet, werden abgelehnt.
- Verlierst du den Zugriff auf einen Workspace (Entfernung aus einem privaten Workspace oder aus der Organisation), verschwinden erst dann seine Inhalte aus deiner Sicht. Die Inhalte bleiben beim Team.
Dieselbe Grenze gilt auch für den Assistenten. Versucht ein KI-Client dort zu schreiben, wo ein Mitglied nicht schreiben darf, liefert der MCP-Tool-Aufruf ein eindeutiges Permission-denied-Ergebnis, das der Assistent dir verständlich weitergeben kann, statt stillschweigend zu scheitern oder scheinbar erfolgreich zu sein. Der Kontext, den ein Assistent erhält, und die Anweisungsdateien, die Pathrule für ihn schreibt, stammen ausschließlich aus Workspaces, die das jeweilige Mitglied lesen darf.
Wo die Prüfung stattfindet
Nichts davon wird in der Anwendung durchgesetzt, die du gerade benutzt. Jeder Lese- und Schreibzugriff auf einen Cloud-Workspace durchläuft eine Zugriffsprüfung in der Datenbank, die anhand deines angemeldeten Benutzers, deiner Mitgliedschaft in der Organisation und des Zugriffsmodus des Workspace aufgelöst wird. Die Zugriffsprüfungen sind Teil der Datenbankoperationen auf dem Server und nicht bloß ein ausgeblendeter Button in der Oberfläche.
- Eine Prüfung für alle Oberflächen. Die Webkonsole, die Pathrule CLI, die VS Code-Erweiterung, der lokale MCP-Server und Remote MCP laufen alle durch dieselbe datenbankseitige Zugriffskontrolle. Eine Änderung aus dem Terminal und ein Schreibzugriff eines KI-Clients unterliegen denselben Regeln.
- Kein gemeinsamer Admin-Schlüssel. Jede Oberfläche verwendet ein kurzlebiges Token pro Benutzer, nie einen gemeinsamen Service-Schlüssel, der die Daten eines anderen Teams öffnen könnte. Ein kompromittierter Client erreicht immer nur, was der betreffende Benutzer ohnehin erreichen kann.
- Auflösung auf dem Server. Mitgliedschaften und Workspace-Rollen werden auf dem Server ermittelt und nicht ungeprüft vom Client übernommen. Eine manipulierte Anfrage kann sich also keinen Zugriff verschaffen, der ihr nicht gewährt wurde.
Das vollständige Bild davon, wie der Zugriff auf die Cloud abgesichert ist, findest du in der Sicherheitsübersicht.
Selbst gehostet
Enterprise selbst gehostet nutzt dasselbe Rollen- und Berechtigungsmodell in deinem eigenen Cloudflare-Konto. Rollen und Zugriffsmodi der Workspaces verhalten sich genauso; der Unterschied ist, dass Daten und Datenbank in deinem Konto liegen. Single Sign-on über deinen eigenen Identity Provider wird im Rahmen der Enterprise-Vereinbarung eingerichtet und auf dieselben Organisationsrollen abgebildet, die hier beschrieben sind. Wie dieses Deployment funktioniert, erfährst du unter Enterprise selbst gehostet.