Wer darf freigeben
Fachlich: Zwei Fragen, die gern verwechselt werden - wer darf die Server verwalten, und wer darf eine gehaltene Aktion entscheiden. Das sind zwei Achsen. Wer den MCP benutzt und freigibt, muss dafür keine Server anlegen können; wer die Werkzeuge pflegt, entscheidet deswegen nicht über jede Zahlung.
Die Freigabepolitik gilt in Schichten#
Wer entscheiden darf, hängt nicht an der Regel. Beim Halten löst tokyn.trail von oben nach unten auf und nimmt die erste Schicht, die etwas sagt:
| Schicht | Eingestellt unter | Wofür |
|---|---|---|
| 1. Regel | Regel-Editor auf der Serverseite | „Zahlungen über 5.000 € gehen an die Geschäftsführung" |
| 2. Server | Serverseite | „Für den Buchhaltungsserver entscheidet Team Finanzen" |
| 3. Arbeitsbereich | Einstellungen → Freigaben | Der Normalfall für alles, was nichts Eigenes sagt |
| 4. Voreinstellung | eingebaut | Rolle approver, eine Freigabe, keine Begründungspflicht, Frist 240 Minuten, danach abgelehnt |
Der praktische Grund für die Schichten: Holds entstehen auch ganz ohne Regel - unter Enforce hält tokyn.trail fail-closed, was keine Regel trifft, und ein neues oder geändertes Werkzeug ist immer freigabepflichtig. Hinge das Freigaberecht an der Regel, müssten Sie für den Normalfall erst eine schreiben.
Was in einer Politik steht#
| Feld | Bedeutung |
|---|---|
approvers | eine Rolle oder konkrete Personen |
min_approvals | 2 = Vier-Augen; derselbe Mensch zählt nicht doppelt |
reason_required | Begründungspflicht beim Entscheiden |
timeout_minutes | Frist, Default 240, Minimum 1 |
Der Kreis wird beim Halten festgeschrieben#
Die aufgelöste Politik hängt an der gehaltenen Aktion, nicht an der Regel - sie steht als approverPolicy im action_held-Ereignis der Hash-Chain und als Spalte approver_policy im Oversight-Report. Ändern Sie die Politik später oder löschen Sie die Regel, bleibt der Beleg, was er war. Andernfalls behauptete die Kette „ein Berechtigter hat entschieden", ohne sagen zu können, wer das war.
Geprüft wird beim Entscheiden - auf jedem Kanal gleich: Inbox, E-Mail-Link, SMS und Slack laufen durch dieselbe Prüfung. Ausgenommen sind Widget-Entscheidungen aus einem Kundenportal: Dort sind die Entscheider keine Mitglieder, ihre Berechtigung ist das Widget-Token.
Dürfen Owner und Admins alles freigeben?#
Standardmäßig ja: Rang entscheidet mit, ein Admin kann jeden Hold freigeben. Unter Einstellungen → Freigaben lässt sich das abschalten. Dann entscheidet nur der benannte Kreis - auch der Owner nicht. Nehmen Sie den Schalter heraus, wenn „nicht jeder soll von jedem freigeben können" bei Ihnen eine Anforderung ist und keine Frage der Höflichkeit.
Rollen#
| Rolle | Verwaltet | Gibt frei |
|---|---|---|
owner | alles, zusätzlich Löschung des Arbeitsbereichs | ja, solange der Admin-Schalter an ist |
admin | Server, Freigaben, Mitglieder, API-Schlüssel, Abrechnung, Marke, Kanäle | ja, solange der Admin-Schalter an ist |
operator | nur Server, Werkzeuge und Regeln | nur, wenn eine Politik ihn ausdrücklich nennt |
approver | nichts | ja, wenn die Politik ihn nennt |
viewer | nichts | nein |
operator ist die Stufe zwischen Admin und Approver: Wer die MCP-Server pflegen soll, braucht dafür nicht die API-Schlüssel und die Abrechnung dazu. Eine Rolle mit wenig Vertrauen ist das trotzdem nicht - wer Regeln schreiben darf, kann ein Werkzeug auch auf Allow stellen und die Freigabe damit ganz umgehen. Der Unterschied zum Admin liegt in der Reichweite über den Server hinaus, nicht in der Governance auf ihm.
In der Freigabe-Hierarchie ist der Operator kein Vorgesetzter des Approvers, sondern ein zweites Blatt unter dem Admin: „Approver entscheidet" schließt ihn nicht ein. Server pflegen und Freigaben entscheiden sind zwei Achsen - als Freigabe-Ziel ist die Rolle aber wählbar, wenn Sie es ausdrücklich so wollen.