PalveronPalveronDocs
Benutzerhandbuch

Rollen & Berechtigungen

Die fünf Berechtigungsstufen in Palveron — wer sieht was, wer ändert was.

Palveron hat fünf Berechtigungsstufen. Jede Stufe ist eine echte Obermenge der niedrigeren — bis auf platform_admin, das Palveron-Mitarbeitern vorbehalten und nicht vom Kunden vergebbar ist.

Die fünf Stufen

StufeWerVergeben durch
platform_adminPalveron-Support-PersonalPalveron (im Dashboard nicht zuweisbar)
ownerEigentümer der KundenorganisationProjekt-Erstellung; per Support übertragbar
adminPlattform-Admins in der KundenorganisationOwner oder Admin
editorCompliance Officer, MLOps, Security-EngineersAdmin
viewer (Standard)Alle anderenImplizit beim Einladen des Nutzers

Die fünf Stufen sind dasselbe, was useAccess().isAdmin(), canEdit() und canView() im Frontend auswerten, sodass Sidebar und Seitenaktionen entsprechend filtern — Nutzer sehen nur, womit sie auch handeln können.

Berechtigungs-Matrix

Fähigkeitplatform_adminowneradmineditorviewer
Projekt & Billing
Projekte anlegen
Billing / Verträge verwalten
Eigentum übertragen
Projekt löschen
Team & Zugriff
Mitglieder einladen
Rollen zuweisen
Identity Provider verbinden
Agenten
Agenten registrieren / freigeben
Pausieren / fortsetzen / aussetzen
Widerrufen (terminal)
Emergency Stop
Policies
Policies anlegen / bearbeiten
Policies aktivieren / deprecaten
Compliance
Annex-IV-PDF exportieren
FRIA abschließen
Vorfälle melden
Monitoring
Command Center einsehen
Traces durchsuchen
Nutzeraktionen auf Traces erfassen (WARN_PROCEEDED, JUSTIFIED)
Integrationen
Slack / Teams / ServiceNow / Jira verbinden
Blockchain-Wallet konfigurieren
System
Admin-Panel einsehen
Projekt-API-Key rotieren
NGE / Sensitivity-Preset konfigurieren

Rollen-Mapping aus externen Systemen

Wenn Sie einen Identity Provider verbinden (Entra ID, Google Workspace, Okta), mappt Palveron IdP-Gruppen auf diese Stufen — siehe IdP konfigurieren. Das Mapping ist Einbahn: Änderungen im IdP propagieren nach Palveron, aber Palveron schreibt nicht zurück.

Wie die Rollen zusammenspielen

Ein typischer Ablauf in einem Unternehmen:

  1. Der Owner oder ein Admin legt das Projekt an, verdrahtet die Stripe-Abrechnung und verbindet den Identity Provider.
  2. Ein Admin lädt einen Compliance Officer (editor) und einen Developer (viewer) ein.
  3. Der Editor registriert einen neuen Agenten im Wizard, klassifiziert ihn nach EU AI Act und legt die Policies an.
  4. Nach Abschluss des Wizards generiert die Plattform einen Agent-API-Key. Der Editor reicht den Key (oder die Integrations-URL) an den Developer weiter.
  5. Der Viewer-Developer integriert den Key in seine Anwendung — er kann den Key kopieren, Traces durchsuchen (zur Fehlersuche) und den Playground nutzen, aber keine Policies oder Agent-Zustände ändern.
  6. Wenn eine Policy „Freigabe erforderlich" auslöst, erhält ein Editor (oder höher) eine Slack-/Teams-Benachrichtigung und genehmigt oder lehnt ab. Die Entscheidung wird auf Flare verankert.

Connection-Status — Das grün-/gelb-/rote Badge auf der Agenten-Seite macht die Übergabe zwischen Editor (registriert) und Developer (technisch angebunden) auf einen Blick sichtbar.

Die Dashboard-Sidebar respektiert die Berechtigungs-Matrix: Ein viewer sieht niemals Menüeinträge für Billing, Team, Integrationen oder Einstellungen — sie sind versteckt, nicht nur deaktiviert. Das hält die UI fokussiert und verhindert versehentliche Klicks auf Aktionen, die der Nutzer nicht ausführen kann.

Rollen zuweisen

Rollen werden von einem owner oder admin unter Team zugewiesen. Wenn ein Identity Provider verbunden ist, werden IdP-Gruppen automatisch gemappt (siehe IdP konfigurieren).

On this page