OpenClaw: tillåtelselistor, parning och säkra gruppomnämnanden

OpenClaws användbara funktioner är precis varför säkerhetsmodellen spelar roll. Gatewayen kan koppla meddelandekanaler till en agent som kan köra skalkommandon, läsa och skriva filer, styra en webbläsare och skicka meddelanden. Ett enkelt men allvarligt felfall är att en obetrodd eller komprometterad avsändare når en agent med för breda behörigheter. Kontrollerna nedan minskar den exponeringen tillsammans med sedvanlig säkerhet för värd, beroenden, autentiseringsuppgifter och nätverk.

OpenClaws egen ordning är den rätta (säkerhetsdokumentation):

1. Identitet först — vem som får prata med boten (DM-parning / tillåtelselistor / uttryckligen öppen åtkomst).
2. Omfattning sedan — var den får agera (grupper, verktyg, sandlåda, enhetsbehörigheter).
3. Modell sist — anta att modellen kan manipuleras och begränsa skadeområdet.

Den här artikeln utgår från att du redan har installerat gatewayen (installation av en personlig gateway).

dmPolicy="open" och groupPolicy="open" är inställningar för undantagsfall. Föredra parning och tillåtelselistor om du inte litar fullständigt på varje deltagare som kan nå boten. Öppna DM till en bot med verktyg blir en offentligt åtkomlig fjärrkontroll.

Varje godkänd avsändare kan bli en väg in till allt som agenten kan läsa: mejl, filer, webbläsarsessioner och kunddata i verktyg. Godkänn personer som du skulle godkänna SSH-nycklar: sparsamt, med möjlighet att återkalla åtkomsten och med ett angivet skäl.

Tillitsmodellen i ett stycke

OpenClaw dokumenterar en tillitsmodell för en personlig assistent: en betrodd operatör per gateway. Den utgör inte en säkerhetsgräns mellan sinsemellan fientliga användare. Om användare som inte litar på varandra kan skicka meddelanden till en agent med verktyg delar de agentens delegerade befogenheter. Använd separata gateways, och helst separata OS-användare eller värdar, när tillitsgränserna skiljer sig.

Autentiserad åtkomst till gatewayen ger operatörsbehörighet. sessionKey väljer dirigeringsväg och är inte en auktoriseringstoken. Utgå inte från att en delad personlig gateway ger säker isolering mellan användare.

DM-åtkomst: pairing, allowlist, open, disabled

Varje kanal som stöder DM har en DM-policy. Namnen varierar något mellan kanalerna; se den aktuella dokumentationen:

Godkänn medvetet:

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

Detaljer: parning.

Praktisk regel för personligt bruk: behåll pairing eller en strikt allowlist. Godkänn bara dina egna konton och på sin höjd ett fåtal andra operatörer som ingår i samma tillitsgräns.

Två lager av tillåtelselistor

1. DM-tillåtelselista (allowFrom / kanalspecifika motsvarigheter)

Vem som får DM:a boten. I nuvarande OpenClaw lagras väntande och godkända avsändarposter i ~/.openclaw/state/openclaw.sqlite, ordnade efter kanal och konto. Äldre JSON-filer med autentiseringsuppgifter är indata för migrering, inte den nuvarande auktoriseringskällan (dokumentation om parningstillstånd). Behandla SQLite-filen som känsligt auktoriseringstillstånd och säkerhetskopiera den på samma konsekventa sätt som övrigt gatewaytillstånd.

2. Grupptillåtelselista

Vilka grupper/kanaler/guilds boten över huvud taget accepterar — plus vem som får utlösa den inuti en grupp (groupPolicy="allowlist" + groupAllowFrom på stödda kanaler).

Kontrollordningen spelar roll: först grupppolicy och tillåtelselistor, därefter aktivering genom omnämnande eller svar. Att svara på ett botmeddelande kringgår inte groupAllowFrom.

Exempelform (anpassa stabila avsändar-ID:n och agentnamn till det aktuella kanalschemat):

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

Anpassa omnämnandemönstren så att requireMention matchar dina botnamn, inte en allmän sträng som vem som helst kan råka skriva.

Gruppomnämnanden är en säkerhetskontroll

I hektiska grupper kommer en alltid-lyssnande agent att:

• Slösa tokens på brus
• Agera på promptinjektion som döljs i skämt, inklistrade loggar eller länkade sidor
• Läcka kontext mellan personer som delar ett rum men inte en tillitsgräns

Kräv omnämnande eller motsvarande aktivering, om inte rummet är en särskild agentkanal med en låst medlemslista.

Även med krav på omnämnande kan obetrott innehåll som boten hämtar, exempelvis webbsidor, bilagor och mejl, innehålla instruktioner. Systemprompter löser inte promptinjektion. De verksamma kontrollerna är verktygspolicy, godkännanden, sandlåda och vem som över huvud taget får prata med boten.

Promptinjektion kräver inte offentliga DM. Även om bara du kan skicka meddelanden till boten kan illvillig text nå den via verktygsresultat när den läser den öppna webben eller delade inkorgar.

Sessionsisolering för DM från flera personer

Standardbeteendet kan dirigera DM till en huvudsession för kontinuitet. Om fler än en person kan skicka DM till boten ska sessionerna isoleras:

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

Utan isolering kan en persons kontext läcka in i en annans tur. Det är både ett integritetsfel och en förstärkare av promptinjektion.

Nätverksexponering

Innan du firar fjärrchatt:

• Föredra gateway.bind: "loopback" för personliga installationer
• Kräv autentiseringstoken för all åtkomst till gatewayen som inte sker via loopback
• Behandla Tailscale Serve/Funnel och omvända proxyservrar som exponeringshändelser. Följ rutinen för nätverksexponering om du använder någon av dem
• Publicera aldrig Control UI (:18789) eller modellportar på internet utan autentisering

Kör:

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

Prioriteringsordningen i dokumentationen är att först låsa öppna DM och grupper med verktyg, därefter offentlig nätverksexponering, fjärråtkomst för webbläsarstyrning, filbehörigheter och till sist insticksprogram.

Härdad baslinje (startpunkt)

OpenClaw publicerar ett kompakt härdat exempel med lokal bindning, tokenautentisering, en meddelandeinriktad verktygsprofil, spärrlistor för grupperna automation/runtime/fs, nekad exec med ask: "always", avstängda förhöjda verktyg samt parning och krav på omnämnande för WhatsApp. Överför avsikten från den aktuella säkerhetssidan till din konfiguration i stället för att behålla en inklistrad kopia som blir inaktuell. Kör sedan granskningen igen.

Standardinställningarna för en betrodd ensam operatör kan tillåta kommandokörning på värden utan bekräftelsefrågor (security="full", ask="off"). Det är ett avsiktligt användarflöde för en personlig assistent, inte ett skäl att behålla inställningen när fler får tillgång till kanalerna. Skärp policyn när hotmodellen omfattar andras meddelanden.

Kvartalsvisa granskningsfrågor

Varje kvartal (eller efter varje kanalexpansion):

1. Vem står på varje tillåtelselista, och varför?
2. Vilka grupper har fortfarande boten, och kräver de fortfarande omnämnande?
3. Har någon aktiverat open DM-/grupppolicy ”tillfälligt”?
4. Har exec- och webbläsarverktygen större åtkomst än förra kvartalets hotmodell medger?
5. Har openclaw security audit körts sedan senaste konfigurationsändringen?

Skriv ner svaren. En säkerhetsnivå som bara finns i någons huvud överlever inte den första semestern.

Discord / Slack / Teams-anteckningar (samma principer)

Kanalernas gränssnitt skiljer sig, men säkerhetsfrågorna är desamma:

• Vilka guilds/workspaces/teams är tillåtelselistade?
• Vilka användare får DM:a?
• Måste boten @omnämnas i kanaler?
• Lagras bot-tokens endast på gatewayvärden?

För Discord och Slack dokumenterar OpenClaw separata tillåtelselistor per yta (guilds, channels och relaterade nycklar; kontrollera det aktuella schemat). Tillämpa samma princip om stängt som standard som i exemplen för WhatsApp och Telegram. En offentlig Slack-arbetsyta med en öppen agent och exec-verktyg väntar bara på att en nyfiken kollega ska utlösa en incident.

Arbetsplatschatt innehåller ofta personuppgifter om anställda och kunder. Att koppla OpenClaw till Slack/Teams är en behandlingsaktivitet: känn till den rättsliga grunden, vem som kan kalla på boten och vilka verktygsutdata som behålls i ~/.openclaw.

Konkreta felfall (mönster, inte folklore)

Så här kan incidenterna se ut:

Glömd öppen DM-policy

En bottoken läcker till ett offentligt kodarkiv eller en vän delar användarnamnet. Främlingar skickar prompter i stil med ”sammanfatta min ~/Documents”. Med verktygen aktiverade kan modellen försöka göra det.

Grupp utan omnämnande

Boten reagerar på varje tråd. Någon klistrar in en skadlig README. Agenten hämtar och följer den.

Delad familje-WhatsApp

Tonåringar och konsulter delar en grupp som kan @-nämna boten. Sammanhang från olika sessioner blandas. Ett skämt blir en begäran om ett skalkommando.

Fjärrgränssnitt utan autentisering

:18789 exponeras i det lokala nätverket ”så att telefonen kan nå den”. Användare på gästnätverket får då tillgång till kontrollplanet.

Varje scenario förebyggs med parning och tillåtelselistor, regler för omnämnanden, sessionsisolering, nätverksbindning och autentisering, inte med en strängare systemprompt.

Återkallelse och avslut av åtkomst

Ta fram en kort åtgärdsrutin:

1. Ta bort identiteten från allowFrom eller återkalla dess parningspost med det aktuella CLI:t eller gränssnittet. Kontrollera med verktyg som stöds att den kanoniska SQLite-auktoriseringsposten är borta, utan att redigera databasen direkt.
2. Rotera kanal-bot-tokens om personen någonsin sett dem.
3. Granska sessionerna i ~/.openclaw efter kvarvarande känsliga uppgifter.
4. Kör om openclaw security audit.
5. Om personen hade nodparning kopplar du bort enheten.

Behandla detta som att återkalla en SSH-nyckel, inte som att sluta följa en bot.

Operatörschecklista

• DM-policy är pairing eller strikt allowlist
• allowFrom innehåller endast betrodda identiteter
• Grupper kräver omnämnande; grupptillåtelselistor satta
• dmScope isolerad om flera DM-avsändare finns
• Gatewayen är bunden till loopback, eller tillåter endast autentiserad fjärråtkomst
• openclaw security audit utan allvarliga anmärkningar
• Högriskverktyg är avstängda tills identiteten är låst
• Tillståndskatalogen kan inte läsas av alla användare
• Avslutsrutiner dokumenterade för dina kanaler

Återkalla parningar och poster i tillåtelselistor när ett telefonnummer, en Slack-användare eller ett konsultuppdrag upphör. Glömda poster i tillåtelselistan är fortsatt öppna inbjudningar. Exportera eller radera sessionshistorik som innehåller andras personuppgifter när den rättsliga grunden upphör.

Tillåtelselistor och parning är inte byråkrati. De är skillnaden mellan en personlig gateway och ett oautentiserat agent-API kopplat till ditt skal. Konfigurera dem före skills, heartbeat och bekvämlighetsautomatiseringar. Nästa artikel behandlar skills, heartbeat och godkännandekontroller.