Berechtigungen und MCP-Tool-Stufen

Jede SupaCloud-Agentsitzung erhält eine Mindestoberfläche und kann optional über ein Agentprofil erweitert werden. Wenn du verstehst, wie Edition, Berechtigungen und MCP-Capability-Stufen zusammenwirken, kannst du besser nachvollziehen, was ein Agent tun kann (und was nicht) — und warum.

Die zwei Schranken

Bevor ein Agent handeln kann, müssen zwei unabhängige Schranken dies erlauben.

Schranke 1 — Deployment-Edition. Die SupaCloud-Instanz läuft entweder in der Community- oder in der Enterprise-Edition. Die Edition ist eine prozessglobale, fail-closed-Eigenschaft: Enterprise-Funktionen (einschließlich SSO, erweiterter Seat-Typen und bestimmter Berechtigungs-Overrides) sind auf einer Community-Instanz schlicht nicht verfügbar — unabhängig davon, was ein einzelner Workspace oder ein Agentprofil anfordert. Ein Seat kann niemals eine editionsgesperrte Funktion freischalten.

Schranke 2 — MCP-Capability-Allowlist. Jedes MCP-Tool gehört einer Stufe an. Eine Task-Sitzung hat nur Zugriff auf die Tools, die das Agentprofil (oder das Workspace-Standardprofil) explizit erlaubt. Die beiden Schranken sind unabhängig — die Edition erweitert die MCP-Allowlist nicht automatisch.

MCP-Tool-Stufen

Die 49 MCP-Tools sind auf fünf Allowlist-Stufen aufgeteilt:

Baseline (supacloud.*)

Immer aktiver Grundstock für jede authentifizierte Agentsitzung — bedingungslos gewährt, unabhängig von der Allowlist. Umfasst Subtask-Delegation, lesenden Speicherzugriff, Ergebnistelemetrie und memory.propose_review.

Read-Stufe (supacloud.read.*)

Situationsbewusstsein durch Lesezugriffe: Workspace-Informationen, Projekt- und Task-Listen, Runner-Status, Zeitpläne, Ressourcen, Apps und Workflows. Nur Metadaten — keine Secrets, keine Verbindungszeichenketten.

Ops-Stufe (supacloud.ops.*)

Operative Auslöser: einen Workflow-Run starten, Zeitpläne verwalten, einen Repo-Sync anstoßen. script.run ist ein Ops-Stufen-Tool, das aufgrund seines indirekten Ressourcen- und Secret-Zugriffs eine zusätzliche explizite Freigabe (supacloud.script.run) erfordert.

Scaffold-Stufe (supacloud.scaffold.*)

Proposals erstellen und Scaffold-Tasks starten. Ermöglicht agentengesteuerte Planungs-Workflows, die Arbeitsvorschläge erstellen und untergeordnete Tasks aufspannen, ohne vollständige Ops- oder Deploy-Berechtigungen zu benötigen.

Deploy-Stufe (supacloud.deploy.*)

Deployment-Aktionen: eine App deployen oder das Deployment rückgängig machen, App-Migrationen anwenden. Erfordert supacloud.deploy.* in der Profil-Allowlist plus der Task-Akteur muss Owner oder Admin des Workspaces sein — beide Prüfungen müssen bestehen.

supacloud.full gewährt alle fünf Stufen auf einmal.

Baseline ist immer aktiv

Der N+4-Grundstock wird bedingungslos gewährt — ein Task mit einer leeren Allowlist erhält trotzdem Delegation, Speicherzugriff und Telemetrie. Der Grundstock war früher hinter supacloud.* gesperrt; diese Schranke wurde entfernt (ADR 0033).

Tasks ohne Profil und Workspace-Standardprofile

Ein Task ohne Agentprofil fällt auf eine lesende Oberfläche zurück (supacloud.read.* zuzüglich des bedingungslosen Grundstocks). Ops- und Deploy-Stufen bleiben fail-closed.

Workspace-Administratoren können ein Workspace-Standard-Agentprofil — das mit is_workspace_default gekennzeichnete Profil — unter Einstellungen → Agentprofile festlegen: ein Profil öffnen und Als Workspace-Standard festlegen wählen (ein Workspace hat höchstens eines, das Festlegen eines Profils hebt den bisherigen Standard auf). Wenn gesetzt, erben alle profilelosen Tasks in diesem Workspace dessen Allowlist anstelle des fest codierten Nur-Lesen-Fallbacks.

Ratenlimits

Die Capability-Stufen tragen abgestufte Ratenlimits, die auf mehreren Ebenen gelten:

Stufe	Pro Task	Pro Workspace / Tag	Pro Profil / Stunde
Read	50 Aufrufe	—	—
Ops	10 Aufrufe	100 Aufrufe	30 Aufrufe
Scaffold	10 Aufrufe	10 Proposals + 3 Task-Spawns	10 Proposals + 3 Task-Spawns
Deploy	5 Aufrufe	20 Aufrufe	10 Aufrufe

Die Workspace- und Profil-Obergrenzen schützen davor, dass Delegationsketten die Pro-Task-Budgets über viele Kindtasks hinweg vervielfachen. Die Zähler werden aus audit_events abgeleitet — sie überleben Server-Neustarts.

Bestätigung auf der Deploy-Stufe

app.deploy und app.migration.apply verwenden eine zustandslose zweistufige Bestätigung, um versehentliche Ausführungen zu verhindern. Der erste Aufruf (ohne Token) gibt ein signiertes confirmation_token und eine changes_summary zurück. Der Agent muss erneut aufrufen und dabei dieses Token übergeben, um fortzufahren. Das Token ist HMAC-signiert mit einem serverseitigen Secret (SUPACLOUD_MCP_CONFIRMATION_SECRET); fehlt das Secret, schlagen die Tools fail-closed.

Berechtigungspriorität

Wenn sowohl Edition als auch MCP-Allowlists eine Aktion erlauben, gilt weiterhin die eigene Berechtigungsauflösung des Workspaces:

Benutzer-Override → Seat-Typ → Workspace-Override → Organisationsplan → Standard

Ein vom der Organisation gewährter Seat-Typ kann daher einschränken oder erweitern, was ein Agent über Workspace-Info-Lesezugriffe auf Workspace-Ebene sieht — er kann den Agenten jedoch nicht über das hinaus erheben, was die Deployment-Edition erlaubt.

Tipp

Eine vollständige Auflistung aller MCP-Tool-Namen und ihrer Parameter findest du in der MCP-Referenz für Entwickler unter die MCP-Tool-Referenz. Wie Workspaces und Organisationen zusammenpassen, erfährst du unter Workspaces und Organisationen.