Sikkerhed i OpenClaw med tilladelseslister, parring og gruppeomtaler

OpenClaws nyttige funktioner er netop grunden til, at sikkerhedsmodellen betyder noget. Gatewayen kan forbinde beskedtjenester med en agent, der kan køre shellkommandoer, læse og skrive filer, styre en browser og sende beskeder. En enkel, men alvorlig fejlvej er, at en afsender, du ikke har tillid til, eller en kompromitteret afsender når en agent med for vide rettigheder. Kontrollerne nedenfor reducerer denne risiko sammen med almindelig sikkerhed for værter, afhængigheder, legitimationsoplysninger og netværk.

OpenClaws egen rækkefølge er den rigtige (sikkerhedsdokumentation):

1. Identitet først — hvem der kan tale med botten (parring af direkte beskeder, tilladelseslister eller udtrykkeligt åben adgang).
2. Omfang dernæst — hvor den kan handle (grupper, værktøjer, sandkasse og enhedsrettigheder).
3. Model sidst — antag, at modellen kan manipuleres; begræns skadeomfanget.

Denne artikel antager, at du allerede har installeret gatewayen (personlig gateway-setup).

dmPolicy="open" og groupPolicy="open" er indstillinger, du kun bør bruge som sidste udvej. Foretræk parring og tilladelseslister, medmindre du har fuld tillid til alle deltagere, der kan nå botten. Åbne direkte beskeder til en bot med værktøjer er en offentlig fjernstyringsflade.

Hver godkendt afsender kan blive en vej ind til det, agenten kan læse: e-mail, filer, browsersessioner og kundedata i værktøjer. Godkend personer, som du ville godkende SSH-nøgler: sparsomt, så adgangen kan tilbagekaldes, og med en navngiven begrundelse.

Tillidsmodellen i ét afsnit

OpenClaw dokumenterer en tillidsmodel for en personlig assistent: én betroet operatørgrænse pr. gateway. Det er ikke en sikkerhedsgrænse for flere indbyrdes fjendtlige brugere. Hvis brugere, der ikke har tillid til hinanden, kan skrive til én agent med værktøjer, deler de agentens delegerede beføjelser. Adskil gateways og helst også OS-brugere eller værter, når tillidsgrænserne er forskellige.

Autentificeret adgang til gatewayen er adgang på operatørniveau. sessionKey vælger routing; den er ikke en autorisationstoken. Skab ikke en falsk forestilling om brugeradskillelse i en delt personlig gateway.

Adgang til direkte beskeder: parring, tilladelsesliste, åben eller deaktiveret

Hver kanal, der understøtter direkte beskeder, har en politik for dem (navnene varierer lidt fra kanal til kanal; se den aktuelle dokumentation):

Godkend bevidst:

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

Detaljer: pairing.

Praktisk regel til personlig brug: Behold pairing eller en streng allowlist. Godkend kun dine egne konti og højst nogle få andre operatører, der deler den samme tillidsgrænse.

To lag af tilladelseslister

1. Tilladelsesliste til direkte beskeder (allowFrom og kanalspecifikke varianter)

Hvem der må sende direkte beskeder til botten. Den aktuelle OpenClaw-version gemmer rækker med afventende og godkendte afsendere i ~/.openclaw/state/openclaw.sqlite, hvor kanal og konto bruges som nøgle. Ældre JSON-filer med legitimationsoplysninger er kun input til migrering fra tidligere versioner, ikke den aktuelle autorisationskilde (dokumentation om parringsdata). Behandl SQLite-filen som følsomme autorisationsdata, og sikkerhedskopiér den sammen med gatewayens øvrige tilstand.

2. Tilladelsesliste til grupper

Hvilke grupper, kanaler eller servere botten overhovedet accepterer, og hvem der må udløse den i en gruppe (groupPolicy="allowlist" og groupAllowFrom på understøttede kanaler).

Kontrollernes rækkefølge betyder noget: Først gælder gruppepolitikken og tilladelseslisterne, derefter aktivering gennem omtale eller svar. Et svar på en botbesked omgår ikke groupAllowFrom.

Eksempel på formen (fra OpenClaws dokumentation; tilpas den til den enkelte kanal):

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

Tilpas mønstrene for omtaler, så requireMention matcher dine botnavne, ikke en generisk tekst, som alle kan skrive ved et uheld.

Gruppeomtaler er en sikkerhedskontrol

I travle grupper vil en agent, der altid lytter:

• Brænde tokens på støj
• Handle på promptinjektion skjult i vittigheder, indsatte loguddrag eller sider, der linkes til
• Lække kontekst mellem mennesker, der deler et rum, men ikke en tillidsgrænse

Kræv en omtale eller tilsvarende aktivering, medmindre rummet er en dedikeret agentkanal med en låst medlemsliste.

Selv med krav om omtale kan indhold, du ikke har tillid til, som botten henter fra websider, vedhæftede filer eller e-mails, indeholde instruktioner. Systemprompts løser ikke promptinjektion. De håndhævende kontroller er værktøjspolitik, godkendelser, sandkasser og regler for, hvem der overhovedet kan tale med botten.

Promptinjektion kræver ikke åbne direkte beskeder. Selv hvis kun du kan skrive til botten, kan ondsindet tekst stadig nå den gennem værktøjsresultater fra det åbne internet eller delte indbakker.

Sessionsadskillelse ved direkte beskeder fra flere personer

Standardadfærden kan sende direkte beskeder ind i en hovedsession for at bevare kontinuitet. Hvis mere end én person kan sende direkte beskeder til botten, skal sessionerne adskilles:

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

Uden adskillelse kan én persons kontekst sive ind i en andens samtale. Det er både en databeskyttelsesfejl og en forstærker af promptinjektion.

Netværkseksponering

Før du tager fjernchat i brug:

• Foretræk gateway.bind: "loopback" ved personlige installationer
• Kræv autentifikationstokens til gatewayen ved enhver adgang uden for loopback
• Behandl Tailscale Serve/Funnel og reverse proxyer som ændringer i eksponeringen; gennemgå driftsvejledningen til eksponering, hvis du bruger en af dem
• Udstil aldrig Control UI (:18789) eller modelporte på det offentlige internet uden autentifikation

Kør:

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

Prioriteringen i dokumentationen er: Begræns først åbne direkte beskeder og grupper med værktøjer, derefter offentlig netværkseksponering, fjernstyring af browseren, filtilladelser og til sidst plugins.

Hærdet grundkonfiguration

OpenClaw offentliggør et kompakt hærdet eksempel: lokal binding, tokenautentifikation, en værktøjsprofil til beskeder, afvisningslister til grupperne automation/runtime/fs, afvist exec med ask: "always", deaktiverede forhøjede værktøjer samt WhatsApp-lignende parring og krav om omtale. Overfør hensigten til din konfiguration fra den aktuelle sikkerhedsside i stedet for at bevare et forældet eksempel, og kør derefter revisionen igen.

Standarder til én betroet operatør kan tillade kommandoer på værten uden at spørge (security="full", ask="off"). Det er et bevidst brugeroplevelsesvalg til en personlig assistent, ikke et bevis for, at indstillingen bør bevares, når flere får adgang til kanalerne. Stram reglerne, når trusselsmodellen omfatter andres beskeder.

Spørgsmål til den kvartalsvise gennemgang

Hvert kvartal (eller efter enhver kanaludvidelse):

1. Hvem står på hver tilladelsesliste, og hvorfor?
2. Hvilke grupper har stadig botten, og kræver de stadig en omtale?
3. Har nogen aktiveret open som politik for direkte beskeder eller grupper »midlertidigt«?
4. Har exec og browserværktøjerne fået bredere adgang end sidste kvartals trusselsmodel tillod?
5. Er openclaw security audit blevet kørt siden sidste konfigurationsændring?

Skriv svarene ned. En sikkerhedspraksis, der kun eksisterer i nogens hoved, svigter, så snart den ansvarlige er på ferie.

Discord / Slack / Teams-noter (samme principper)

Kanalernes brugerflader er forskellige; sikkerhedsspørgsmålene er de samme:

• Hvilke servere, arbejdsområder eller teams står på tilladelseslisten?
• Hvilke brugere må sende direkte beskeder?
• Skal botten omtales med @ i kanaler?
• Gemmes bot-tokens kun på gatewayværten?

For Discord og Slack dokumenterer OpenClaw tilladelseslister for de enkelte flader (guilds, channels og relaterede nøgler; kontrollér det aktuelle skema). Brug samme princip om lukket adgang som standard som i eksemplerne til WhatsApp og Telegram. Et offentligt Slack-arbejdsområde med en åben agent og exec-værktøjer indebærer en reel risiko for en sikkerhedshændelse.

Chats på arbejdspladsen indeholder ofte personoplysninger om medarbejdere og kunder. Når OpenClaw forbindes med Slack eller Teams, behandles disse data: Kend behandlingsgrundlaget, hvem der kan tilkalde botten, og hvilke værktøjsresultater der opbevares i ~/.openclaw.

Konkrete fejlscenarier (mønstre, ikke vandrehistorier)

Sådan kan hændelserne se ud:

Glemt åben politik for direkte beskeder

Et token til botten lækker til et offentligt versionslager, eller en ven deler botnavnet. Fremmede sender instruktioner som »opsummér min mappe ~/Documents«. Med aktiverede værktøjer kan modellen forsøge at efterkomme dem.

Gruppe uden krav om omtale

Botten reagerer på hver tråd. Nogen indsætter en ondsindet README-fil. Agenten henter og følger den.

Delt familie-WhatsApp

Teenagere og eksterne samarbejdspartnere deler en gruppe, der kan omtale botten. Kontinuitet i sessionen blander kontekster. En vittighed bliver til en anmodning om en shellkommando.

Fjernbrugerflade uden autentifikation

:18789 bindes til lokalnettet »så telefonen kan nå den«. Brugere på gæstenetværket får adgang til kontrolplanet.

Hvert scenarie forebygges med parring, tilladelseslister, regler for omtaler, sessionsadskillelse samt binding og autentifikation, ikke med en strengere systemprompt.

Tilbagekaldelse og fjernelse af adgang

Lav en kort driftsvejledning:

1. Fjern identiteten fra allowFrom, eller tilbagekald dens parringspost via den aktuelle kommandolinje eller brugergrænseflade. Kontrollér med understøttede værktøjer, at den kanoniske SQLite-række med autorisation er væk; redigér ikke databasen direkte.
2. Roter kanal-bot-tokens, hvis personen nogensinde så dem.
3. Gennemgå sessionerne i ~/.openclaw for følsomme rester.
4. Genkør openclaw security audit.
5. Hvis de havde en parret node, skal du ophæve parringen af enheden.

Behandl dette som tilbagekaldelse af en SSH-nøgle, ikke som at holde op med at følge en bot.

Tjekliste til operatøren

• Politikken for direkte beskeder er pairing eller en streng allowlist
• allowFrom indeholder kun betroede identiteter
• Grupper kræver omtale; gruppetilladelseslister er konfigureret
• dmScope isoleret, hvis flere personer kan sende direkte beskeder
• Gatewayen bruger loopback eller kun autentificeret fjernadgang
• Fund fra openclaw security audit er håndteret til et acceptabelt risikoniveau
• Værktøjer med høj risiko er deaktiveret, indtil identiteten er låst
• Rettighederne til tilstandsmappen tillader ikke læsning for alle
• Trin til fjernelse af adgang er dokumenteret for dine kanaler

Tilbagekald parringer og poster på tilladelseslister, når et telefonnummer, en Slack-bruger eller et samarbejde med en ekstern part ikke længere er aktuelt. Glemte poster på tilladelseslister er stående invitationer. Eksportér eller slet sessionhistorik, der indeholder andres personoplysninger, når behandlingsgrundlaget ophører.

Tilladelseslister og parring er ikke bureaukrati. De er forskellen mellem en personlig gateway og et uautentificeret agent-API med adgang til din shell. Konfigurér dem før skills, heartbeat og bekvemmelighedsautomatiseringer, som dækkes i skills, heartbeat og godkendelser.