Zugriffsgruppen & Broadcast-Gruppen

Die meisten Berechtigungsprobleme beginnen nicht mit böser Absicht. Sie beginnen mit Bequemlichkeit. Eine schnelle Allowlist wird zu drei. Drei werden zu zehn. Einen Monat später weiß niemand mehr genau, wer was sehen darf, wer was auslösen darf oder warum ein interner Status im falschen Raum gelandet ist.

Genau diese Lücke sollen Zugriffsgruppen schließen. In OpenClaw geben sie dir eine wiederverwendbare Möglichkeit, festzulegen, wer zu einer Vertrauensgrenze gehört, statt dieselbe Entscheidung an zwanzig Stellen hart zu verdrahten.

Broadcast-Gruppen lösen ein anderes Problem. Sie entscheiden nicht, wer überhaupt Zugriff bekommt. Sie steuern die gezielte Verteilung, nachdem eine Nachricht oder ein Ereignis bereits zulässig ist. Erst Berechtigung, dann Verteilung. Wer diese beiden Aufgaben vermischt, baut sich früher oder später ein schlampiges Setup.

Was Zugriffsgruppen eigentlich lösen

Die offizielle Doku beschreibt Zugriffsgruppen als wiederverwendbare Mitgliederlisten für Zugriffskontrolle, die über accessGroup:<name> in Allowlists referenziert werden. Klingt trocken, bringt aber praktisch viel: Du hörst auf, dieselben Personen, Rollen oder Räume in jeder einzelnen Regel neu aufzulisten.

Wenn du schon einmal fünf getrennte Allowlists gepflegt hast, die eigentlich dasselbe bedeuten sollten, kennst du den Schmerz. Eine Person kommt ins Team. Eine andere geht. Irgendwo wird eine Liste vergessen. Plötzlich existiert die Policy nur noch in der Theorie.

Zugriffsgruppen geben dir eine benannte Quelle der Wahrheit. Ein Raum, eine Route oder eine Funktion verweist auf die Gruppe, statt jedes Mal alle Mitglieder neu zu definieren. Wichtig ist nur: Eine Zugriffsgruppe gewährt nicht von selbst Zugriff. Sie wirkt erst dort, wo eine Allowlist sie tatsächlich referenziert.

• private Operator-Räume können dieselbe Vertrauensgruppe teilen
• sensible Admin-Aktionen können dieselbe freigegebene Mitgliedschaft wiederverwenden
• Kanaloberflächen bleiben konsistent, wenn sich das Team ändert
• Audits werden leichter, weil die Absicht sichtbar ist

Das ist derselbe Grund, warum gute Teams rollenbasierte Zugriffe nutzen statt Namenslisten an jeder Ecke. Wiederverwendung ist nicht nur sauberer. Sie ist sicherer.

Broadcast-Gruppen lösen Verteilung, nicht Vertrauen

Hier stolpern viele. Eine Broadcast-Gruppe ist kein magischer Berechtigungs-Shortcut. Sie ist eine Zustellkarte.

Die aktuelle OpenClaw-Doku beschreibt Broadcasts als explizite Ziellisten pro Quell-Peer. Auf Deutsch: Ein zulässiger Quellraum kann an eine definierte Menge von Zielräumen weiterreichen. Diese Bauweise ist absichtlich explizit, weil Nachrichtenvervielfältigung sehr schnell gefährlich werden kann.

Dazu kommt eine wichtige Einschränkung in der aktuellen Doku: Broadcast-Gruppen sind als experimentell markiert und gelten derzeit nur für den WhatsApp-Webkanal. Das ist also keine universelle Lösung für jede Oberfläche in OpenClaw.

Stell dir ein Museum vor. Zugriffsgruppen entscheiden, wer durch die Mitarbeitertür darf. Broadcast-Gruppen entscheiden, welche internen Räume den Funkruf hören sollen, sobald jemand drinnen ein Problem meldet. Verwandt, ja. Dasselbe, nein.

Gerade diese Trennung macht ein Setup sauber. Du kannst sagen:

• nur vertrauenswürdige Operatoren dürfen einen Workflow auslösen
• nur bestimmte Räume dürfen die resultierenden Updates sehen
• nicht jeder vertrauenswürdige Raum braucht jeden Broadcast

Sobald du Zugriff und Fan-out als getrennte Schichten siehst, wird die Architektur deutlich klarer.

Warum versehentliches Oversharing meistens passiert

Oversharing braucht selten einen dramatischen Bug. Meist reichen breite Gruppen, unscharfe Namen oder eine Broadcast-Liste, die aus Gewohnheit statt aus Absicht gewachsen ist.

Das typische Fehlerbild sieht so aus:

1. ein Team baut eine breite Vertrauensgruppe
2. diese Gruppe wird in Bereichen mit unterschiedlicher Sensibilität wiederverwendet
3. eine Broadcast-Zuordnung zeigt von einer Quelle auf zu viele Ziele
4. ein internes oder privates Detail landet dort, wo es nicht hingehört

Das ist ein bisschen so, als würdest du einen einzigen E-Mail-Verteiler für Kunden, Freelancer, Geschäftsleitung und Incident-Responder nutzen, weil getrennte Listen lästig wirken. Klingt effizient, bis das falsche Update beim falschen Publikum landet.

Was die lokale Quellprüfung bestätigt

Aktuelle lokale OpenClaw-Build-Artefakte bestätigen diese Trennung zwischen Berechtigung und Verteilung. Das Runtime-Schema zeigt broadcast als eigenen Konfigurationsblock mit dokumentierten Ziellisten und Zustellreihenfolge. Der lokale Channel-Runtime-Code zeigt zusätzlich Gruppen-Zugriffskontrollen wie groupAllowFrom und Group-Policy-Handling. Anders gesagt: Das Produkt selbst behandelt Raumzugriff und Nachrichten-Fan-out als getrennte Regler. Deine Architektur sollte das auch tun.

Designmuster 1: eine Vertrauensgrenze pro Aufgabe

Gib Gruppen Namen, die beschreiben, warum die Mitglieder zusammengehören, nicht nur, wo sie zufällig arbeiten.

• ops-core für Menschen, die Deployment- und Incident-Updates sehen dürfen
• support-leads für Menschen, die kundennahe Workflows auslösen dürfen
• finance-private für Räume oder Mitglieder mit sensiblen Zahlen

Das klingt langweilig. Gut so. Langweiliges Berechtigungsdesign ist meistens das gesunde.

Vermeide Namen wie main-team oder trusted, wenn die Grenze unscharf ist. Unscharfe Namen erzeugen später unscharfe Entscheidungen.

Designmuster 2: Broadcast-Ziele absichtlich knapp halten

Die Broadcast-Doku setzt bewusst auf explizite Zuordnung pro Quelle. Das ist klug. Fan-out sollte sich absichtlich anfühlen, fast ein wenig unbequem, wenn du neue Ziele hinzufügst. Genau diese Reibung schützt dich.

Wenn ein Quellraum an drei Ziele broadcastet, sollte jemand alle drei ohne Ausreden begründen können. Wenn das nicht geht, ist die Liste zu breit.

{
  accessGroups: {
    opsCore: ["telegram:-100111:7", "slack:team-ops"],
    supportLeads: ["discord:guild:lead-room"]
  },
  broadcast: {
    "telegram:-100111:9": [
      "telegram:-100111:7",
      "slack:C045OPS"
    ]
  }
}

Es geht hier nicht um die Syntax. Es geht darum, dass Quelle und jedes Ziel bewusst benannt sind. Nichts daran passiert zufällig.

Designmuster 3: Operator-Sichtbarkeit von Kunden-Sichtbarkeit trennen

Ein nützliches Muster aus der Praxis ist, dass ein interner Raum Arbeit auslösen oder überwachen darf, während ein anderer öffentlicher Raum nur eine kürzere und sicherere Version des Ergebnisses sieht. Zugriffsgruppen definieren, wer den Workflow berühren darf. Broadcast-Gruppen definieren, wohin Status reisen darf.

So bleibt eine wichtige Wahrheit erhalten: Die Menschen, die ein System bedienen dürfen, sind nicht automatisch dieselbe Zielgruppe, die jedes Rohdetail aus diesem System sehen sollte.

Designmuster 4: Gruppen immer mit Routing-Änderungen mitprüfen

Kanal Routing und Gruppendesign sind enge Verwandte. Wenn du Routing änderst, einen neuen Raumtyp hinzufügst oder einem Agenten eine neue operative Oberfläche gibst, prüfe die Gruppen direkt mit. Sonst liegt sauberes Routing auf alten Vertrauensgrenzen.

Eine starke Gewohnheit ist, immer diese drei Fragen zusammen zu prüfen:

• wer darf Arbeit auslösen
• wer darf Ergebnisse sehen
• welche Räume erhalten automatischen Fan-out

Dieses kleine Audit fängt erstaunlich viel Unsinn ab, bevor daraus öffentlicher Unsinn wird.

Wann Broadcast-Gruppen helfen und wann nicht

Broadcast-Gruppen helfen, wenn dieselbe Quellnachricht wirklich kontrolliert in mehrere Ziele gehen soll. Gute Beispiele sind:

• Alerts, die sowohl einen Operator-Topic als auch einen Backup-Raum erreichen sollen
• ein Quell-Thread, der zusätzlich einen eng gefassten Monitoring-Kanal speist
• Workflows, bei denen der Input in einem Raum ankommt, die Prüfung aber woanders erfolgt

Sie helfen nicht, wenn du nur normale Antworten im selben Raum brauchst oder Fan-out als Ersatz für unklare Routing-Regeln nutzt. Das ist keine Verteilung. Das ist Architekturschuld mit falschem Schnurrbart.

Die praktische Faustregel

Nutze Zugriffsgruppen, um Vertrauen einmal sauber zu definieren und dann wiederzuverwenden. Nutze Broadcast-Gruppen nur dann, wenn sich Information von einer freigegebenen Quelle aus bewusst an wenige andere Orte verteilen soll.

Wenn du dir nur einen Satz merkst, dann diesen: Berechtigungsgrenzen sollten klein und klar benannt sein. Broadcast-Listen sollten kurz und begründbar sein. So bleibt OpenClaw nützlich, ohne zu einer Gossip-Maschine mit Webhooks zu werden.