OpenClaw: Allowlists, Pairing und sichere Erwähnungen in Gruppen

Gerade wegen der nützlichen Funktionen von OpenClaw ist sein Sicherheitsmodell wichtig. Das Gateway kann Messaging-Kanäle mit einem Agenten verbinden, der Shell-Befehle ausführen, Dateien lesen und schreiben, einen Browser steuern und Nachrichten senden darf. Ein einfacher, aber folgenreicher Fehler besteht darin, dass eine nicht vertrauenswürdige oder kompromittierte Absenderidentität einen Agenten mit zu weitreichenden Berechtigungen erreicht. Die folgenden Kontrollen verringern dieses Risiko zusammen mit der üblichen Absicherung von Host, Abhängigkeiten, Zugangsdaten und Netzwerk.

Die Reihenfolge von OpenClaw selbst ist die richtige (Security-Dokumentation):

1. Zuerst die Identität: Wer darf mit dem Bot sprechen (Pairing für Direktnachrichten / Allowlists / ausdrücklich offener Zugang)?
2. Dann der Handlungsspielraum: Wo darf er handeln (Gruppen, Werkzeuge, Sandbox, Geräteberechtigungen)?
3. Zuletzt das Modell: Gehen Sie davon aus, dass das Modell manipuliert werden kann, und begrenzen Sie den möglichen Schaden.

Dieser Artikel setzt voraus, dass Sie den Gateway bereits installiert haben (persönliches Gateway-Setup).

dmPolicy="open" und groupPolicy="open" sollten nur als letztes Mittel verwendet werden. Bevorzugen Sie Pairing und Allowlists, sofern Sie nicht allen Personen vollständig vertrauen, die den Bot erreichen können. Offene Direktnachrichten an einen Bot mit Werkzeugzugriff bilden eine öffentliche Fernsteuerungsoberfläche.

Jede freigegebene Absenderidentität kann zum Zugangsweg für alles werden, was der Agent lesen darf: E-Mails, Dateien, Browsersitzungen und Kundendaten in Werkzeugen. Gewähren Sie Personen den Zugriff ebenso sparsam und widerrufbar wie bei SSH-Schlüsseln und dokumentieren Sie den Grund.

Vertrauensmodell in einem Absatz

OpenClaw dokumentiert ein Vertrauensmodell für einen persönlichen Assistenten: Pro Gateway gilt eine Grenze mit einer vertrauenswürdigen betreibenden Person. Das Gateway ist keine Sicherheitsgrenze zwischen einander nicht vertrauenden Mandanten. Wenn Personen, die einander nicht vertrauen, denselben Agenten mit Werkzeugzugriff anschreiben können, teilen sie dessen delegierte Berechtigungen. Trennen Sie die Gateways und idealerweise auch Betriebssystemkonten oder Hosts, wenn die Vertrauensgrenzen voneinander abweichen.

Authentifizierter Gateway-Zugang gewährt Berechtigungen auf Betreiberebene. sessionKey steuert die Weiterleitung und ist kein Autorisierungstoken. Behandeln Sie ein gemeinsam genutztes persönliches Gateway nicht fälschlich wie eine mandantengetrennte Umgebung pro Person.

Zugriff per Direktnachricht: Pairing, Allowlist, Open, Disabled

Jeder Kanal mit Direktnachrichten unterstützt eine entsprechende Richtlinie. Die Namen unterscheiden sich je nach Kanal geringfügig; prüfen Sie die aktuelle Dokumentation:

Freigaben bewusst erteilen:

openclaw pairing list <channel>
openclaw pairing approve <channel> <code>

Details: Pairing.

Praktische Regel für den persönlichen Einsatz: Behalten Sie pairing oder eine strikte allowlist bei. Genehmigen Sie nur Ihre eigenen Konten und höchstens eine sehr kleine Gruppe von Personen, die das Gateway innerhalb derselben Vertrauensgrenze mitbetreiben.

Zwei Allowlist-Schichten

1. DM-Allowlist (allowFrom / kanal-spezifische Äquivalente)

Diese Liste legt fest, wer dem Bot Direktnachrichten senden darf. OpenClaw speichert ausstehende und freigegebene Absenderdatensätze derzeit in ~/.openclaw/state/openclaw.sqlite, geordnet nach Kanal und Konto. Ältere JSON-Dateien mit Zugangsdaten dienen nur noch als Eingabe für die Migration und sind nicht die aktuelle Autorisierungsquelle (Dokumentation zum Pairing-Zustand). Behandeln Sie die SQLite-Datei als sensiblen Autorisierungszustand und sichern Sie sie gemeinsam mit dem übrigen Gateway-Zustand.

2. Gruppen-Allowlist

Sie legt fest, welche Gruppen, Kanäle oder Server der Bot überhaupt akzeptiert und wer ihn innerhalb einer Gruppe auslösen darf (groupPolicy="allowlist" + groupAllowFrom auf unterstützten Kanälen).

Die Reihenfolge der Prüfungen ist wichtig: zuerst Gruppenrichtlinie und Allowlists, anschließend die Aktivierung durch Erwähnung oder Antwort. Eine Antwort auf eine Bot-Nachricht umgeht groupAllowFrom nicht.

Beispielstruktur; passen Sie stabile Absender-IDs und die Agentenbezeichnung an das aktuelle Kanalschema an:

{
  channels: {
    whatsapp: {
      dmPolicy: 'allowlist',
      allowFrom: ['+15555550123'],
      groupPolicy: 'allowlist',
      groupAllowFrom: ['+15555550123'],
      groups: { '<approved-group-id>': { requireMention: true } },
    },
  },
  agents: {
    list: [{ id: 'main', groupChat: { mentionPatterns: ['@openclaw'] } }],
  },
}

Passen Sie die Erwähnungsmuster so an, dass requireMention auf Ihre Botnamen reagiert, nicht auf eine allgemeine Zeichenfolge, die jemand versehentlich eingeben könnte.

Erwähnungen in Gruppen sind eine Sicherheitskontrolle

In belebten Gruppen wird ein ständig aktiver Agent:

• Token für belanglose Nachrichten verbrauchen
• auf Prompt-Injection reagieren, die in Witzen, eingefügten Protokollen oder verlinkten Seiten verborgen ist
• Kontext zwischen Personen preisgeben, die zwar denselben Raum, aber nicht dieselbe Vertrauensgrenze teilen

Verlangen Sie eine Erwähnung (oder eine gleichwertige Aktivierung), sofern es sich nicht um einen eigenen Agentenkanal mit gesperrter Mitgliederliste handelt.

Auch wenn eine Erwähnung erforderlich ist, können nicht vertrauenswürdige Inhalte, die der Bot abruft (Webseiten, Anhänge, E-Mails), Anweisungen enthalten. System-Prompts lösen Prompt-Injection nicht. Wirksame Kontrollen sind Werkzeugrichtlinien, Freigaben, Sandboxing und die Beschränkung der Personen, die den Bot überhaupt ansprechen dürfen.

Prompt-Injection setzt keine öffentlichen Direktnachrichten voraus. Selbst wenn nur Sie den Bot anschreiben dürfen, kann böswillig gestalteter Text über das offene Web oder gemeinsam genutzte Postfächer in die Werkzeugergebnisse gelangen.

Getrennte Sitzungen für Direktnachrichten mehrerer Personen

Das Standardverhalten kann Direktnachrichten aus Kontinuitätsgründen in eine Hauptsitzung leiten. Wenn mehr als eine Person dem Bot direkt schreiben kann, trennen Sie die Sitzungen:

{ session: { dmScope: 'per-channel-peer' } }

Ohne diese Trennung kann der Kontext einer Person in die nächste Interaktion einer anderen einfließen. Das ist sowohl ein Datenschutzproblem als auch ein Verstärker für Prompt-Injection.

Erreichbarkeit über das Netzwerk

Bevor Sie den Fernzugriff als Erfolg verbuchen:

• Bevorzugen Sie bei persönlichen Installationen gateway.bind: "loopback".
• Verlangen Sie für jeden Zugriff außerhalb von Loopback ein Gateway-Authentifizierungs-Token.
• Behandeln Sie Tailscale Serve/Funnel und Reverse-Proxys als neue Netzwerkexposition. Arbeiten Sie das Runbook zur Exposition durch, wenn Sie eine solche Lösung verwenden.
• Stellen Sie die Control UI (:18789) oder Modellports niemals ohne Authentifizierung ins öffentliche Internet.

Ausführen:

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix   # narrow safe remediations only

Die Dokumentation empfiehlt für die Triage folgende Reihenfolge: zuerst offene Direktnachrichten und Gruppen mit Werkzeugzugriff schließen, dann die öffentliche Netzwerkexposition, danach entfernte Browsersteuerung, Dateiberechtigungen und schließlich Plugins prüfen.

Gehärtete Baseline (Ausgangspunkt)

OpenClaw veröffentlicht ein kompaktes Beispiel für eine gehärtete Konfiguration: Bindung an eine lokale Adresse, Authentifizierung per Token, ein auf Messaging ausgerichtetes Werkzeugprofil, Sperrlisten für Automatisierungs-, Laufzeit- und Dateisystemgruppen, gesperrte Befehlsausführung mit ask: "always", deaktivierte Werkzeuge mit erhöhten Berechtigungen sowie Pairing nach WhatsApp-Art und erforderliche Erwähnungen. Übernehmen Sie die Absicht aus der aktuellen Sicherheitsseite in Ihre Konfiguration, statt eine eingefügte Konfiguration dauerhaft unverändert zu lassen. Führen Sie das Audit anschließend erneut aus.

Standardeinstellungen für eine einzige vertrauenswürdige betreibende Person können Befehlsausführung auf dem Host ohne Rückfrage zulassen (security="full", ask="off"). Das ist eine bewusste Bedienentscheidung für einen persönlichen Assistenten, aber kein Grund, diese Einstellung beizubehalten, sobald weitere Personen über die Kanäle Zugriff erhalten. Verschärfen Sie die Konfiguration, sobald Ihr Bedrohungsmodell Nachrichten anderer Personen einschließt.

Quartalsfragen zur Überprüfung

Jedes Quartal (oder nach jeder Kanal-Erweiterung):

1. Wer steht auf jeder Allowlist und warum?
2. In welchen Gruppen ist der Bot noch, und ist dort weiterhin eine Erwähnung erforderlich?
3. Hat jemand die Richtlinie für Direktnachrichten oder Gruppen „vorübergehend“ auf open gesetzt?
4. Haben Befehlsausführungs- und Browserwerkzeuge mehr Rechte, als es das Bedrohungsmodell des Vorquartals zulässt?
5. Wurde openclaw security audit seit der letzten Konfigurationsänderung ausgeführt?

Halten Sie die Antworten schriftlich fest. Eine Sicherheitslage, die nur im Kopf einer Person existiert, scheitert am ersten Urlaub.

Hinweise zu Discord / Slack / Teams (gleiche Prinzipien)

Die Kanal-UIs unterscheiden sich; die Sicherheitsfragen nicht:

• Welche Server, Workspaces und Teams stehen auf der Allowlist?
• Welche Personen dürfen Direktnachrichten senden?
• Muss der Bot in Kanälen mit @ erwähnt werden?
• Werden Bot-Tokens nur auf dem Gateway-Host gespeichert?

Für Discord und Slack dokumentiert OpenClaw Allowlists für die einzelnen Oberflächen (guilds, channels und verwandte Schlüssel; prüfen Sie das aktuelle Schema). Wenden Sie denselben Grundsatz „standardmäßig geschlossen“ an wie in den Beispielen für WhatsApp und Telegram. Bei einem öffentlichen Slack-Workspace mit einem offenen Agenten und Werkzeugen zur Befehlsausführung genügt ein neugieriger Kollege für einen Sicherheitsvorfall.

Chats am Arbeitsplatz enthalten oft personenbezogene Daten von Mitarbeitenden und Kunden. Die Verbindung von OpenClaw mit Slack oder Teams ist ein Verarbeitungsvorgang. Klären Sie die Rechtsgrundlage, wer den Bot aufrufen darf und welche Werkzeugausgaben in ~/.openclaw gespeichert werden.

Konkrete Fehlermuster (Muster, keine Folklore)

Typische Vorfälle folgen diesen Mustern:

Vergessene offene Richtlinie für Direktnachrichten

Ein Bot-Token gelangt in ein öffentliches Repository oder ein Freund gibt den Kontonamen weiter. Fremde senden Direktnachrichten wie „Fasse mein Verzeichnis ~/Documents zusammen“. Mit aktivierten Werkzeugen könnte das Modell versuchen, die Anweisung auszuführen.

Gruppe ohne erforderliche Erwähnung

Der Bot reagiert auf jeden Thread. Jemand fügt eine bösartige README ein. Der Agent lädt sie und folgt ihr.

Geteilte Familien-WhatsApp

Jugendliche und Auftragnehmer sind in derselben Gruppe und können den Bot mit @ erwähnen. Die fortlaufende Sitzung vermischt ihre Kontexte. Aus einem Scherz wird eine Aufforderung, einen Shell-Befehl auszuführen.

Remote-UI ohne Auth

:18789 ist im LAN gebunden, „damit das Handy darauf zugreifen kann“. Gäste im WLAN erhalten damit Zugriff auf eine Steuerungsoberfläche.

Pairing und Allowlists, Regeln für Erwähnungen, getrennte Sitzungen sowie Bindung und Authentifizierung verhindern diese Szenarien. Ein strengerer System-Prompt tut das nicht.

Widerruf und Offboarding

Bauen Sie ein kleines Runbook:

1. Entfernen Sie die Identität aus allowFrom oder widerrufen Sie ihren Pairing-Eintrag über die aktuelle CLI beziehungsweise UI. Prüfen Sie mit den unterstützten Werkzeugen, dass der maßgebliche SQLite-Autorisierungsdatensatz entfernt wurde; bearbeiten Sie die Datenbank nicht direkt.
2. Kanal-Bot-Tokens rotieren, falls die Person sie je gesehen hat.
3. Sitzungen unter ~/.openclaw auf sensible Reste prüfen.
4. openclaw security audit erneut ausführen.
5. Heben Sie die Kopplung des Geräts auf, falls ein Node-Pairing bestand.

Behandeln Sie diesen Vorgang wie die Reaktion auf einen kompromittierten SSH-Schlüssel, nicht wie das Entfolgen eines Bots.

Operator-Checkliste

• DM-Policy ist pairing oder strikte allowlist
• allowFrom enthält nur vertrauenswürdige Identitäten
• Gruppen erfordern eine Erwähnung; Gruppen-Allowlists sind eingerichtet
• dmScope trennt Sitzungen, wenn mehrere Personen Direktnachrichten senden dürfen
• Gateway an Loopback gebunden (oder nur authentifiziert aus der Ferne erreichbar)
• openclaw security audit so weit bereinigt, dass keine beunruhigenden Befunde offen sind
• Risikoreiche Werkzeuge sind deaktiviert, bis der Identitätszugriff eingeschränkt ist
• Das Zustandsverzeichnis ist nicht für alle lokalen Personen lesbar
• Offboarding-Schritte für Ihre Kanäle dokumentiert

Widerrufen Sie Pairing- und Allowlist-Einträge, wenn eine Telefonnummer, ein Slack-Konto oder ein Auftragsverhältnis nicht mehr besteht. Vergessene Allowlist-Einträge sind dauerhaft gültige Einladungen. Exportieren oder löschen Sie Sitzungsverläufe mit personenbezogenen Daten anderer Personen, wenn die Rechtsgrundlage entfällt.

Allowlists und Pairing sind keine Bürokratie. Sie unterscheiden ein persönliches Gateway von einer nicht authentifizierten Agenten-API mit Zugriff auf Ihre Shell. Konfigurieren Sie sie vor Skills, Heartbeat und Komfortautomatisierungen. Der nächste Artikel behandelt Skills, Heartbeat und Freigaben.