Workspace-Rollen und Berechtigungen: die fünfstufige Leiter

Ein Workspace beginnt mit einer Person und einem Guthaben, und Berechtigungen sind kein Thema. Dann kommt für eine Kampagne ein freier Editor dazu, ein Backend-Dienst braucht einen Schlüssel, und jemand aus der Buchhaltung will sehen, was das alles kostet. Ab diesem Punkt ist „alle sind Admin“ keine Abkürzung mehr, sondern ein Risiko – denn bei eroq gibt jedes Mitglied Credits aus demselben gemeinsamen Guthaben aus.

Deshalb sind die Rollen zuerst eine Leiter und erst danach ein Raster aus Häkchen. Fünf Stufen, fünfzehn benannte Berechtigungen, eine Regel dafür, wer auf wen einwirken darf – und wenn eine Stufe nicht genau zu jemandem passt, ein persönlicher Schalter für jede Berechtigung. Hier ist das ganze Modell, plus das eine Verhalten, das beim ersten Mal alle überrascht: was mit einem API-Schlüssel passiert, wenn du die Person herabstufst, die ihn erstellt hat.

Die fünf Stufen

Jede Stufe hat alle Berechtigungen der Stufe darunter, plus ihre eigenen. Das ist das ganze mentale Modell; der Rest sind Details.

Inhaber. Alles, inklusive der zwei Berechtigungen, die sonst niemand hat – den Workspace an jemand anderen übertragen und ihn komplett löschen. Der Inhaber ist das Konto, das den Workspace erstellt hat.

Admin. Leitet den Laden. Personen, Abrechnung, Workspace-Einstellungen, API-Schlüssel, Webhooks, Generierung, Veröffentlichen, Bibliothek und Nutzung. Alles außer Übertragen und Löschen.

Entwickler. Baut auf der API. Erstellt und widerruft API-Schlüssel, verwaltet Webhook-Endpunkte, generiert mit vollem Rate-Limit, veröffentlicht, liest die Bibliothek und das Nutzungsprotokoll. Keine Abrechnung, keine Einladungen, keine Einstellungen. Das ist die Stufe für die Person, die die API integriert und niemals den Plan ändern können soll.

Creator. Arbeitet im Studio. Generiert, veröffentlicht in der Community-Galerie, liest Bibliothek und Nutzung. Keine Schlüssel, keine Webhooks, keine Einstellungen, keine Abrechnung. Standardmäßig bekommt ein Creator außerdem die Hälfte des Minuten-Rate-Limits des Workspace – genug, um den ganzen Tag im Tool „Video“ zu arbeiten, aber nicht genug, um eine Produktionspipeline auszuhungern, die auf demselben Plan läuft.

Betrachter. Sieht die Bibliothek der Kreationen und das Nutzungsprotokoll. Kann keinen einzigen Credit ausgeben. Das ist die Stufe für Kunden, Stakeholder oder die Person, die immer nur prüfen muss, was erstellt wurde und was es gekostet hat.

Die Berechtigungen selbst sind benannt, nicht stillschweigend mitgemeint – Generieren, Veröffentlichen, Bibliothek ansehen, Nutzung ansehen, die vier Speicher-Berechtigungen (durchsuchen, hochladen, löschen, Einstellungen), API-Schlüssel, Webhooks, Workspace-Einstellungen, Personen verwalten, Abrechnung & Pläne, Inhaberschaft übertragen, Workspace löschen. Die Matrix im Tab „Mitglieder“ unter /dashboard/workspace wird aus denselben Daten erzeugt, die der Server durchsetzt. Was du dort siehst, passiert also wirklich bei einem Request.

Wenn eine Stufe nicht passt: eine Berechtigung anhaken

Eine Leiter ist der richtige Standard und die falsche endgültige Antwort. Der Editor, der veröffentlichen, aber nie einen Credit ausgeben soll; der Auftragnehmer, der einen Monat lang API-Schlüssel braucht, aber nie die Abrechnung sehen darf; die Person aus der Buchhaltung, die das Guthaben aufladen soll und sonst nichts – keiner davon ist eine Stufe.

Deshalb ist jede Berechtigung auch eine Checkbox. Öffne den Zugriff eines Mitglieds im Tab „Mitglieder“, und die Rolle ist der Ausgangspunkt: Jedes Kästchen ist aus ihr vorausgefüllt, und du hakst darüber hinaus jedes einzelne an oder ab. Ein Betrachter mit angehaktem Generieren kann Credits ausgeben; ein Entwickler ohne Häkchen bei API-Schlüssel kann keinen erstellen. Die Mitgliederliste zeigt ein kleines Tag angepasst neben allen, deren Zugriff von ihrer Rolle abweicht, und wenn du mit der Maus darüberfährst, siehst du genau, was hinzugefügt oder entfernt wurde.

Drei Regeln verhindern, dass daraus ein Chaos wird:

1. Du kannst nur vergeben, was du selbst hast. Ein Entwickler kann einem Creator Webhooks anhaken, weil Entwickler Webhooks haben; Abrechnung & Pläne kann er niemandem anhaken, weil er die Berechtigung selbst nicht hat. Abhaken ist bei allen unter dir immer erlaubt.
2. Kästchen ändern nie den Rang. Ein Creator mit angehaktem Personen verwalten kann Personen unter Creator einladen und bearbeiten – und nur unter Creator. Die Leiter entscheidet weiterhin, wer über wem steht.
3. Übertragen und Löschen haben kein Kästchen. Sie gehören dem Inhaber, Punkt.

Das alles geht auch schon, bevor die Person da ist. Das Einladungsformular hat dasselbe Raster eingeklappt unter der Rollenauswahl: Lade jemanden als Betrachter mit angehaktem Generieren ein, und genau das hat die Person ab ihrer allerersten Anmeldung – kein Zeitfenster, in dem ein Neuzugang mehr oder weniger hat, als du wolltest.

Ein Rollenwechsel behält die Kästchen, die noch etwas bedeuten: Beförderst du einen angepassten Betrachter zum Creator, verschwindet das Häkchen bei Generieren, das jetzt in der Rolle steckt, einfach; ein Häkchen bei Abrechnung, das er hatte, bleibt. Und ein API-Schlüssel folgt denselben Regeln wie alles andere – hake ein Kästchen an oder ab, und der Schlüssel übernimmt das innerhalb von dreißig Sekunden, genau wie bei einem Rollenwechsel.

Warum der Inhaber keine Rolle ist, die du vergeben kannst

Der Inhaber ist nicht in der Mitgliedschaftszeile gespeichert. Er ist eine Eigenschaft des Workspace selbst – das Konto, das ihn erstellt hat – und wird beim Lesen des Workspace auf die oberste Stufe gehoben.

Das klingt nach einem Implementierungsdetail. Es hat drei Folgen, auf die du dich verlassen kannst:

1. Es gibt immer genau einen Inhaber. Nicht „meistens einen“. Das Schema kann gar keine zwei darstellen.
2. Du kannst nicht versehentlich einen erschaffen. Ein Admin, der Rollen verteilt, sieht „Inhaber“ nie in der Auswahl, weil es keine vergebbare Rolle ist.
3. Den Workspace zu übertragen ist ein bewusster Schritt, getrennt vom Befördern. Ein Firmenkonto zu übergeben ist nicht dieselbe Geste, wie einer Kollegin Zugriff auf die Abrechnung zu geben, und das Modell weigert sich, beides zu vermischen.

Die praktische Konsequenz: Wenn du einen Workspace für eine Firma einrichtest, erstelle ihn mit einem Konto, das die Firma kontrolliert – nicht mit einem privaten Login, das du in achtzehn Monaten löschen willst.

Du kannst nur Personen verwalten, die unter dir stehen

Die zweite Regel: Du darfst nur auf ein Mitglied einwirken, wenn dein Rang strikt höher ist als seiner, und du darfst nie eine Rolle vergeben, die gleich hoch oder höher ist als deine eigene.

Lies das zweimal, denn beide Hälften zählen:

• Zwei Admins können sich nie gegenseitig herabstufen, entfernen oder aussperren. Gleiche Ränge berühren sich nicht. Muss ein Admin gehen, erledigt das der Inhaber.
• Ein Entwickler kann weder sich selbst noch jemand anderen zum Admin befördern, weil Admin nicht unter Entwickler steht.
• Die Rollenauswahl im Einladungsformular zeigt nur die Stufen, die du vergeben darfst. Ein Admin sieht Admin, Entwickler, Creator, Betrachter. Ein Entwickler sieht gar nichts zum Einladen, weil Einladungen zur Berechtigung „Personen verwalten“ gehören.

Mit einer flachen Admin-Ebene wird ein Workspace bei einer Meinungsverschiedenheit von dem gekapert, der am schnellsten klickt. Eine Leiter macht das unmöglich statt nur unwahrscheinlich.

Ein API-Schlüssel erbt die Rolle seines Halters

Das ist der Teil, den du verinnerlichen solltest. Ein Schlüssel ist keine eigene Identität mit eigenen Berechtigungen. Er trägt den Rang des Mitglieds, das ihn hält, und dieser Rang wird bei jedem Aufruf neu geprüft.

Stufe einen Entwickler zum Betrachter herab, und seine Schlüssel hören auf zu generieren – sofort, ohne dass du die Schlüssel anfasst:

curl -X POST https://eroq.ai/v1/videos/generations \
  -H "Authorization: Bearer $EROQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "eroq-motion-one",
    "prompt": "A courier crosses a wet avenue under a broken streetlight, headlights smearing behind her. Tracking shot, 35mm film, neon noir palette, tense tempo.",
    "seconds": 5,
    "aspect": "9:16"
  }'

{
  "error": {
    "message": "This workspace role cannot spend credits. Ask an admin for Creator access or above.",
    "type": "permission_error",
    "code": "role_forbidden"
  }
}

Beachte, was nicht passiert ist: Nichts wurde abgebucht, und der Schlüssel kann weiterhin lesen. Die Schlüssel eines herabgestuften Mitglieds können immer noch Kreationen auflisten und die Nutzung lesen, weil das Betrachter-Berechtigungen sind. Nur die Berechtigungen, die du entzogen hast, funktionieren nicht mehr.

Fürs Offboarding ist das schon die ganze Prozedur. Ein einziger Rollenwechsel entzieht die Generierung über alle Schlüssel hinweg, die diese Person je erstellt hat – ohne Bestandsaufnahme, welche Schlüssel es gibt oder welcher Dienst sie nutzt. Ändere zuerst die Rolle und widerrufe die Schlüssel dann in aller Ruhe. Rollenwechsel greifen bei neuen Requests innerhalb von Sekunden.

Die Prüfung sitzt auf dem Server außerdem an genau einer Stelle – in dem Moment, in dem Credits bewegt werden sollen –, sodass ein neuer Generierungs-Endpunkt sie nicht vergessen kann.

Zwei Regler zusätzlich zur Rolle

Rollen entscheiden über das Was. Zwei Regler pro Mitglied entscheiden über das Wie viel, und ein Admin stellt beide im Tab „Mitglieder“ ein:

Ein Anteil an den Minuten-Rate-Limits, in Prozent. Der Anteil der Rolle ist die Obergrenze – Creator startet bei der Hälfte –, und eine individuelle Einstellung kann ihn nur weiter verengen, nie über das hinaus erweitern, was die Rolle erlaubt.

Eine monatliche Credit-Obergrenze. Ein hartes Limit dafür, was dieses Mitglied in einem Kalendermonat aus dem gemeinsamen Guthaben ausgeben kann, zurückgesetzt am 1. des Monats. Erstattungen werden dagegen verrechnet, sodass ein Render, der fehlgeschlagen ist und sich selbst erstattet hat, nicht heimlich jemandes Kontingent auffrisst. Wer die Obergrenze erreicht, bekommt eine klare Ablehnung mit der konkreten Zahl, keinen rätselhaften Abrechnungsfehler.

Keiner der Regler ist Pflicht – lass beide leer, und ein Mitglied bekommt einfach, was seine Rolle hergibt. Wie man sie dimensioniert, ist ein eigenes Thema; die Logik hinter pauschalen Credits steht in Credit-Preise für KI-APIs.

Eine vernünftige Standardzuordnung

• Backend-Dienst oder Integration → Entwickler, mit einem Schlüssel pro Pipeline.
• Freier Editor oder Auftragnehmer → Creator, mit einer monatlichen Obergrenze passend zum Auftrag.
• Producer oder Account Manager, der Ausgaben freigibt → Admin.
• Kunde, Stakeholder, Prüfer → Betrachter.
• Das Konto, dem die Arbeit rechtlich gehört → Inhaber, und sonst niemand.

Noch eine Einschränkung, die du einplanen solltest, bevor du irgendjemanden einlädst: wie viele Plätze dein Plan hat. Kostenlose Workspaces haben einen, jeder Einzelplan hat genau zwei, und echte Teams arbeiten in der Business-Stufe. Die Übersicht der Plätze steht auf /pricing und wird auf /faq noch einmal beantwortet.

Häufige Fragen

Können sich zwei Admins bei eroq gegenseitig entfernen?

Nein. Ein Mitglied kann nur auf jemanden einwirken, der strikt unter ihm steht, gleiche Ränge sind füreinander also unantastbar. Einen Admin zu entfernen oder herabzustufen ist Aufgabe des Inhabers.

Was passiert mit API-Schlüsseln, wenn ich ein Teammitglied herabstufe?

Sie funktionieren weiter für alles, was die neue Rolle noch erlaubt, und hören mit dem Rest auf. Nach einer Herabstufung zum Betrachter können die Schlüssel noch die Bibliothek und die Nutzung lesen, während jeder Generierungsaufruf mit 403 role_forbidden antwortet, ohne einen Credit abzubuchen.

Ist „Inhaber“ eine Rolle, die ich jemand anderem geben kann?

Nicht als Rolle. Der Inhaber ist das Konto, das den Workspace erstellt hat, deshalb taucht er nie in der Rollenauswahl auf. Ihn zu wechseln heißt, den Workspace selbst zu übertragen – eine separate Aktion, die nur der Inhaber ausführen kann.

Richte die Leiter ein, bevor die zweite Person dazukommt – öffne den Tab „Mitglieder“ unter /dashboard/workspace.