Pairing und DM-Zugriffskontrolle

Die meisten Zugriffsfehler beginnen nicht mit einem dramatischen Angriff. Sie beginnen mit einem hilfreichen Impuls. Du willst noch einer Person erlauben, dem Bot direkt zu schreiben. Dann noch einer. Dann nimmt jemand an, dass DM-Freigabe auch Gruppen-Zugriff, Command-Ownership oder sicheren Zugriff auf jedes Tool-gestützte Workflow bedeutet. Genau dann wird aus einem sauberen Assistenten schnell eine öffentliche Lobby mit Shell-Zugang.

OpenClaw hat dafür ein besseres Modell. Pairing gibt dir einen expliziten Freigabeschritt. DM-Policies legen fest, wie streng Direktzugriff sein soll. Zugriffsgruppen lassen dich vertrauenswürdige Senderlisten wiederverwenden, ohne IDs in der ganzen Config zu verteilen. Gruppenregeln bleiben absichtlich separat.

Die offizielle Pairing-Doku und die Groups-Doku sind die zwei wichtigsten Referenzen, die du dafür zusammen lesen solltest. Die eine erklärt, wer durch die Eingangstür kommt. Die andere erklärt, was zusätzlich noch gelten muss, sobald jemand im Gebäude ist.

Wofür Pairing eigentlich da ist

In OpenClaw ist Pairing der explizite Freigabeschritt. Die Doku nutzt ihn an zwei Stellen: für DM-Pairing bei eingehendem Direktzugriff und für Node-Pairing bei Geräten, die dem Gateway-Netzwerk beitreten.

Für diesen Artikel ist der DM-Teil entscheidend. Wenn ein Kanal dmPolicy: "pairing" nutzt, bekommt ein unbekannter Sender nicht sofort normale Bot-Verarbeitung. Er erhält einen kurzen Code, und der Operator entscheidet, ob diese Person hereindarf.

Stell dir das wie einen Summer am Empfang vor. Der Besucher kann melden, dass er da ist. Er läuft noch nicht frei durchs Büro.

• Pairing-Codes sind kurz und zeitlich begrenzt
• offene Anfragen laufen ab, statt ewig liegenzubleiben
• Freigabe ist explizit und nicht versehentlich
• das System bleibt standardmäßig privat, bis du es bewusst öffnest

Open, pairing und allowlist sind nicht dieselbe Policy

Genau hier werden viele unsauber. Sie sehen drei Modi und machen daraus nur eine vage Skala von "offener" zu "geschlossener". Die echten Unterschiede zählen.

• dmPolicy: "open" bedeutet nur dann wirklich öffentliche Direktnachrichten, wenn die effektive DM-Allowlist "*" enthält. Ohne diesen Wildcard ist open nicht heimlich universeller Zugriff.
• dmPolicy: "pairing" bedeutet, dass unbekannte Sender erst freigegeben werden müssen.
• dmPolicy: "allowlist" bedeutet, dass nur vorher definierte Sender hereindürfen, meist über konkrete IDs oder accessGroup:<name>-Referenzen.

Pairing ist für viele persönliche Setups der vernünftige Mittelweg. Weniger lästig als jede Person vorher hart zu verdrahten, aber deutlich weniger riskant als öffentlichen Direktzugriff zu erlauben.

Warum die erste Freigabe wichtiger ist als die späteren

Die Pairing-Doku nennt ein Detail, das leicht untergeht. Wenn noch kein Command-Owner existiert, kann die erste freigegebene DM-Pairing-Anfrage commands.ownerAllowFrom auf diesen Sender bootstrappen.

Das ist für ein frisches Setup praktisch, bedeutet aber auch: Die allererste Freigabe ist nicht nur ein weiterer Gastlisteneintrag. Sie kann festlegen, wer zum vertrauenswürdigen Command-Owner für privilegierte Aktionen und Freigabe-Prompts wird.

Sobald bereits ein Owner existiert, geben spätere Pairing-Freigaben nur DM-Zugriff. Sie erzeugen nicht still weitere Owner. So soll es sein.

DM-Zugriff ist keine Gruppen-Befugnis

Genau dieser Denkfehler sorgt oft für Verwirrung. Der Pairing-Allowlist-Store ist für DMs da. Gruppen-Autorisierung ist eine eigene Schicht.

Die Groups-Doku macht die Trennung ziemlich klar:

• DM-Zugriff wird über allowFrom gesteuert
• Gruppen-Zugriff wird über groupPolicy, groups und groupAllowFrom gesteuert
• Antwortverhalten wird über Mention-Gating wie requireMention geregelt

Anders gesagt: Jemandem zu erlauben, dem Bot direkt zu schreiben, ist nicht dasselbe wie ihm Steuerung in einem Slack-Channel, einer Telegram-Gruppe oder einem Discord-Server zu geben. Das Gebäudebild passt auch hier: Ein Besucherausweis für die Lobby ist kein Generalschlüssel für alle Räume darüber.

Zugriffsgruppen verhindern Senderlisten-Spaghetti

Pairing dreht sich um Freigabe. Zugriffsgruppen drehen sich um Wiederverwendung.

Die offizielle Doku beschreibt Zugriffsgruppen als benannte Senderlisten, die per accessGroup:<name> in Allowlists referenziert werden. Das hilft dann, wenn dieselben vertrauenswürdigen Menschen über mehrere Kanäle hinweg zugelassen sein sollen oder wenn dieselbe Menge sowohl für DMs als auch für Gruppen-Sender-Autorisierung gelten soll.

Ohne Zugriffsgruppen kopierst du IDs überall hinein. Das wirkt überschaubar, bis sich das Team ändert, ein Contractor geht oder du einen Kanal vergisst. Dann existiert deine Policy nur noch auf dem Papier.

{
  accessGroups: {
    operators: {
      type: "message.senders",
      members: {
        telegram: ["987654321"],
        slack: ["U01234567"],
      },
    },
  },
  channels: {
    telegram: {
      dmPolicy: "pairing",
      allowFrom: ["accessGroup:operators"],
      groupPolicy: "allowlist",
      groupAllowFrom: ["accessGroup:operators"],
      groups: {
        "-1001234567890": { requireMention: true },
      },
    },
  },
}

Die konkreten IDs sehen bei dir natürlich anders aus. Das nützliche Muster ist die Trennung: eine wiederverwendbare vertrauenswürdige Sendergruppe, eine DM-Policy, eine Gruppen-Policy und explizites Mention-Verhalten in geteilten Räumen.

Wo Menschen Zugriff versehentlich überdehnen

Die meisten Überdehnungen entstehen nicht durch einen spektakulären Bug, sondern durch verschwommene Vertrauensgrenzen.

1. Jemand paart ein paar Direktnachrichten-Sender.
2. Diese Sender werden dann als allgemeine Vertrauensklasse für alles behandelt.
3. Gruppen-Allowlists werden aus Bequemlichkeit passend mit aufgeweitet.
4. Ein geteilter Raum hat jetzt mehr Trigger-Befugnis als jemals beabsichtigt war.

Das OpenClaw-Sicherheitsmodell ist an dieser Stelle erfreulich direkt. Ein gemeinsames Gateway ist eine Personal-Assistant-Vertrauensgrenze, keine feindliche Multi-Tenant-Festung. Wenn mehrere einander nicht voll vertrauende Menschen denselben tool-fähigen Agenten ansprechen können, teilen sie sich effektiv auch dessen delegierte Befugnisse.

Wenn deine echte Situation also gemischtes Vertrauen ist, spiele nicht mit einem einzigen großen Shared Gateway. Trenne die Grenze mit getrennten Agenten, getrennten Gateways oder wenigstens getrennten Workspaces und strengerer Tool-Haltung.

Wie Pairing mit Routing und Gruppen zusammenspielt

Routing und Zugriffskontrolle sind enge Verwandte, aber nicht dieselbe Aufgabe.

Kanal-Routing entscheidet, welcher Agent und welche Session die Nachricht bekommen. Direktnachrichten laufen standardmäßig oft in die Main-Session. Gruppen behalten eigene Session-Keys. Das ist für Kontext-Management nützlich, trifft aber keine Zugriffsentscheidung für dich.

Ein sauberes Grundmodell sieht so aus:

• Pairing und Allowlists entscheiden, wer hereindarf
• Routing entscheidet, welcher Agent oder welche Session die Nachricht verarbeitet
• Gruppenregeln entscheiden, wer in geteilten Räumen triggern darf
• Mention-Gating entscheidet, wann der Bot sichtbar antworten soll

Sobald du diese Ebenen trennst, wird OpenClaw viel leichter verständlich. Wenn du sie vermischst, debugst du Policy-Fehler plötzlich so, als wären es Routing-Bugs. Das frisst unnötig Abende.

Ein vernünftiges Startmuster

Für die meisten privaten oder kleinen Team-Setups ist das eine starke Voreinstellung:

• nutze dmPolicy: "pairing" für Direktnachrichten
• definiere eine kleine wiederverwendbare operators-Zugriffsgruppe
• halte groupPolicy: "allowlist" in geteilten Räumen bei
• verlange Mentions in Gruppen, solange es keinen klaren Grund für Always-on gibt
• behandle den ersten freigegebenen Owner als bewusste Entscheidung und nicht als beiläufige Admin-Aufräumarbeit

Langweilig? Ja. Wirksam? Ebenfalls ja. Zugriffskontrolle darf sich ein wenig langweilig anfühlen. Genau dann macht sie ihren Job meistens gut.

Die Kurzfassung

• Pairing ist der explizite Freigabeschritt für DM-Zugriff und kein allgemeiner Vertrauens-Shortcut
• Der erste freigegebene DM-Sender kann Command-Ownership bootstrappen, wenn noch kein Owner existiert
• DM-Zugriff und Gruppen-Steuerung sind absichtlich getrennt
• Zugriffsgruppen halten vertrauenswürdige Senderlisten wiederverwendbar und weniger fehleranfällig
• Wenn Nutzer nicht dieselbe Vertrauensgrenze teilen, trenne Gateway oder Agent-Oberfläche, statt darauf zu hoffen, dass Config allein das Problem löst

Das Ziel ist simpel: Die richtigen Menschen sollen den Bot direkt erreichen können, ohne dass diese Bequemlichkeit später als vager, vererbter Zugriff überall sonst wieder auftaucht.