Beveiliging

Bereik: beveiligingsmodel voor persoonlijke assistenten

• Ondersteund: één gebruikers-/vertrouwensgrens per Gateway (bij voorkeur één OS-gebruiker/host/VPS per grens).
• Niet ondersteund: één gedeelde Gateway/agent die wordt gebruikt door gebruikers die elkaar niet vertrouwen of kwaadwillend zijn.
• Isolatie van kwaadwillende gebruikers vereist afzonderlijke Gateways (en idealiter afzonderlijke OS-gebruikers/hosts).
• Als meerdere niet-vertrouwde gebruikers berichten kunnen sturen naar één agent met ingeschakelde tools, delen ze de gedelegeerde toolbevoegdheden van die agent.
• Als iemand de status/configuratie van de Gateway-host kan wijzigen (~/.openclaw, inclusief openclaw.json), beschouw diegene dan als een vertrouwde operator.
• Binnen één Gateway is toegang als geauthenticeerde operator een vertrouwde control-plane-rol, geen tenantrol per gebruiker.
• sessionKey (sessie-ID's, labels) is een routeringsselector, geen autorisatietoken.

Meerdere gebruikers of organisaties hosten? Voer per tenant één geïsoleerde Gateway-cel uit in plaats van een Gateway te delen. Zie Multitenanthosting.

Neem voordat je externe toegang, DM-beleid, reverse proxy of openbare blootstelling wijzigt het draaiboek voor Gateway-blootstelling door als checklist vooraf en voor terugdraaien.

openclaw security audit

Voer dit uit na elke configuratiewijziging of voordat je netwerkoppervlakken blootstelt:

openclaw security auditopenclaw security audit --deep    # probeert een live Gateway-controle uit te voerenopenclaw security audit --fix     # veilige herstelmaatregelen toepassenopenclaw security audit --json

--fix is bewust beperkt: het zet open groepsbeleid om in toelatingslijsten, herstelt logging.redactSensitive: "tools", verscherpt de machtigingen voor status-, configuratie- en include-bestanden (600-bestanden, 700-mappen) en gebruikt op Windows ACL-resets in plaats van POSIX chmod.

Wat de audit controleert (op hoofdlijnen)

• Inkomende toegang - DM-/groepsbeleid, toelatingslijsten: kunnen onbekenden de bot activeren?
• Impactbereik van tools - tools met verhoogde rechten + open ruimten: kan promptinjectie leiden tot shell-, bestands- of netwerkacties?
• Afwijkingen in het exec-bestandssysteem - bestandssysteemtools die wijzigingen aanbrengen zijn geweigerd, terwijl exec/process zonder sandboxbeperkingen beschikbaar blijven.
• Afwijkingen in exec-goedkeuringen - security="full", autoAllowSkills, toelatingslijsten voor interpreters zonder strictInlineEval. Alleen security="full" is een brede waarschuwing over de beveiligingshouding, geen bewijs van een bug - dit is de gekozen standaard voor vertrouwde persoonlijke-assistentconfiguraties; verscherp deze alleen wanneer je dreigingsmodel goedkeuring of toelatingslijsten als beveiligingsmaatregel vereist.
• Netwerkblootstelling - Gateway-binding/-authenticatie, Tailscale Serve/Funnel, zwakke/korte authenticatietokens.
• Blootstelling van browserbesturing - externe Nodes, relaypoorten, externe CDP-eindpunten.
• Lokale schijfhygiëne - machtigingen, symbolische koppelingen, configuratie-includes, paden naar gesynchroniseerde mappen.
• Plugins - laden zonder expliciete toelatingslijst.
• Beleidsafwijkingen - Docker-instellingen voor de sandbox zijn geconfigureerd terwijl de sandboxmodus uitstaat; gateway.nodes.commands.deny-vermeldingen die effectief lijken, maar alleen overeenkomen met exacte opdracht-ID's (bijvoorbeeld system.run) en niet met shelltekst in de payload; gevaarlijke gateway.nodes.commands.allow-vermeldingen; globale tools.profile="minimal" die per agent wordt overschreven; tools van Plugins die bereikbaar zijn onder een permissief beleid.
• Afwijkingen in runtimeverwachtingen - aannemen dat impliciete exec nog steeds sandbox betekent terwijl tools.exec.host nu standaard auto gebruikt, of tools.exec.host="sandbox" instellen terwijl de sandboxmodus uitstaat.
• Modelhygiëne - waarschuwt voor verouderde geconfigureerde modellen (lichte waarschuwing, geen harde blokkering).

Elke bevinding heeft een gestructureerde checkId (bijvoorbeeld gateway.bind_no_auth, tools.exec.security_full_configured). Voorvoegsels: fs.* (machtigingen), gateway.* (binding/authenticatie/Tailscale/Control UI/vertrouwde proxy), hooks.*/browser.*/sandbox.*/tools.exec.* (versterking per oppervlak), plugins.*/skills.* (toeleveringsketen), security.exposure.* (toegangsbeleid x impactbereik van tools). Volledige catalogus met ernst en ondersteuning voor automatisch herstel: Controles van de beveiligingsaudit. Zie ook Formele verificatie.

Prioriteitsvolgorde bij het beoordelen van bevindingen

1. Alles wat 'open' is + ingeschakelde tools: beperk eerst DM's/groepen (koppeling/toelatingslijsten) en verscherp daarna het toolbeleid/de sandbox.
2. Openbare netwerkblootstelling (LAN-binding, Funnel, ontbrekende authenticatie): onmiddellijk oplossen.
3. Externe blootstelling van browserbesturing: behandel dit als operatortoegang (alleen tailnet, koppel Nodes bewust, geen openbare blootstelling).
4. Machtigingen: status/configuratie/inloggegevens/authenticatie mogen niet leesbaar zijn voor de groep of iedereen.
5. Plugins: laad alleen wat je expliciet vertrouwt.
6. Modelkeuze: geef voor elke bot met tools de voorkeur aan moderne modellen die zijn versterkt voor het volgen van instructies.

Versterkte basisconfiguratie in 60 seconden

{  gateway: {    mode: "local",    bind: "loopback",    auth: { mode: "token", token: "replace-with-long-random-token" },  },  session: {    dmScope: "per-channel-peer",  },  tools: {    profile: "messaging",    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],    fs: { workspaceOnly: true },    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },  channels: {    whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },  },}

Houdt de Gateway uitsluitend lokaal, isoleert DM's en schakelt control-plane-/runtimetools standaard uit. Schakel van daaruit selectief tools opnieuw in per vertrouwde agent.

Ingebouwde basisregel voor via chat aangestuurde agentbeurten: afzenders die niet de eigenaar zijn, kunnen de tools cron en gateway niet gebruiken, ongeacht de configuratie.

Controles per aanvrager en promptcontext

tools.toolsBySender, eigenaarschap van de afzender en toolinventarissen die alleen voor de eigenaar zijn, worden geëvalueerd aan de hand van de oorspronkelijke aanvrager van de huidige beurt. Ze authenticeren of saneren geen andere inhoud in die modelprompt, waaronder geciteerde tekst, eerdere geschiedenis uit een gedeelde ruimte, doorgestuurde inhoud, opgehaalde inhoud, bijlagen, toolresultaten of andere promptinvoer. Inhoud van iemand anders kan daarom een door de eigenaar gestarte beurt beïnvloeden wanneer die inhoud in de context van die beurt is opgenomen.

Beschouw deze controles als gelaagde beveiliging die de directe mogelijkheden van een aanvrager beperkt, niet als isolatie voor vijandige multitenancy. Gebruik contextVisibility om ondersteunde, door het kanaal aangeleverde context te filteren, beperk tools en plaats de agent in een sandbox, en gebruik afzonderlijke Gateways en idealiter afzonderlijke OS-gebruikers of hosts wanneer deelnemers elkaar kwaadwillend bejegenen.

Matrix van vertrouwensgrenzen

Beknopt model voor het beoordelen van risicomeldingen:

Door het ontwerp geen kwetsbaarheden

Vertrouwen in Gateway en Node

Beschouw Gateway en Node als één vertrouwensdomein van de operator met verschillende rollen:

• Gateway: besturingsvlak en beleidsoppervlak (gateway.auth, toolbeleid, routering).
• Node: extern uitvoeringsoppervlak dat aan die Gateway is gekoppeld (opdrachten, apparaatacties, hostlokale mogelijkheden).
• Een aanroeper die bij de Gateway is geauthenticeerd, wordt binnen het bereik van de Gateway vertrouwd; na koppeling worden node-acties vertrouwd als operatoracties op die node. Zie Operatorbereiken.
• Directe loopback-backendclients die met het gedeelde gatewaytoken/-wachtwoord zijn geauthenticeerd, kunnen interne RPC's van het besturingsvlak uitvoeren zonder een gebruikersapparaatidentiteit te presenteren. Dit omzeilt geen externe of browserkoppeling: netwerkclients, nodeclients, apparaattokenclients en expliciete apparaatidentiteiten blijven onderworpen aan koppeling en afdwinging van bereikupgrades.
• Uitvoeringsgoedkeuringen (toelatingslijst + vragen) zijn vangrails voor de intentie van de operator, geen vijandige isolatie tussen meerdere tenants. Ze binden de exacte aanvraagcontext en, naar beste vermogen, directe lokale bestandsoperanden; ze modelleren niet semantisch elk laadpad van runtimes/interpreters. Gebruik sandboxing en hostisolatie voor sterke grenzen.
• Standaard voor één vertrouwde operator: hostuitvoering op gateway/node is toegestaan zonder goedkeuringsprompts (security="full", ask="off"). Dat is een bewuste UX-keuze en op zichzelf geen kwetsbaarheid.

Voor isolatie van vijandige gebruikers moet je vertrouwensgrenzen per OS-gebruiker/host scheiden en afzonderlijke gateways uitvoeren.

Dreigingsmodel

Je AI-assistent kan willekeurige shellopdrachten uitvoeren, bestanden lezen/schrijven, toegang krijgen tot netwerkservices en berichten naar iedereen verzenden (als toegang tot een kanaal is verleend). Mensen die de assistent berichten sturen, kunnen proberen deze tot schadelijke handelingen te verleiden, via social engineering toegang tot je gegevens te verkrijgen of details over de infrastructuur te achterhalen.

De meeste fouten zijn hier geen exotische exploits, maar gevallen waarin „iemand de bot een bericht stuurde en de bot deed wat er werd gevraagd”. De benadering van OpenClaw, in deze volgorde:

1. Eerst identiteit — bepaal wie met de bot kan praten (DM-koppeling/toelatingslijsten/expliciet „open”).
2. Daarna bereik — bepaal waar de bot kan handelen (groepstoelatingslijsten + vermeldingsvereisten, tools, sandboxing, apparaatmachtigingen).
3. Als laatste het model — ga ervan uit dat het model kan worden gemanipuleerd; ontwerp het systeem zo dat manipulatie een beperkte impact heeft.

DM-toegang: koppeling, toelatingslijst, open, uitgeschakeld

Elk kanaal dat DM's ondersteunt, biedt dmPolicy (of *.dm.policy), waarmee inkomende DM's worden tegengehouden voordat het bericht wordt verwerkt:

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

Details + bestanden op schijf: Koppeling

Beschouw dmPolicy="open" en groupPolicy="open" als instellingen voor noodgevallen; geef de voorkeur aan koppeling + toelatingslijsten, tenzij je elk lid van de ruimte volledig vertrouwt.

Toelatingslijsten (twee lagen)

• DM-toelatingslijst (allowFrom / channels.discord.allowFrom / channels.slack.allowFrom; verouderd: channels.discord.dm.allowFrom, channels.slack.dm.allowFrom): wie de bot een DM kan sturen. Wanneer dmPolicy="pairing", schrijven goedkeuringen naar ~/.openclaw/credentials/<channel>-allowFrom.json (standaardaccount) of <channel>-<accountId>-allowFrom.json (niet-standaardaccounts), samengevoegd met toelatingslijsten uit de configuratie.
• Groepstoelatingslijst (kanaalspecifiek): welke groepen/kanalen/guilds de bot überhaupt accepteert.
  • channels.whatsapp.groups, channels.telegram.groups, channels.imessage.groups: standaarden per groep, zoals requireMention; wanneer ingesteld, fungeren deze ook als groepstoelatingslijst (neem "*" op om het gedrag waarbij alles is toegestaan te behouden). Pas activeringen door vermeldingen aan met agents.entries.*.groupChat.mentionPatterns (bijvoorbeeld ["@openclaw", "@mybot"]), zodat requireMention reageert op je eigen botnamen.
  • groupPolicy="allowlist" + groupAllowFrom: beperk wie de bot binnen een groepssessie kan activeren (WhatsApp/Telegram/Signal/iMessage/Microsoft Teams).
  • channels.discord.guilds / channels.slack.channels: toelatingslijsten per oppervlak + standaardinstellingen voor vermeldingen.
  • Controlevolgorde: eerst groupPolicy/groepstoelatingslijsten, daarna activering via vermelding/antwoord. Antwoorden op een botbericht (impliciete vermelding) omzeilt groupAllowFrom niet.

Details: Configuratie en Groepen

Isolatie van DM-sessies (modus voor meerdere gebruikers)

OpenClaw routeert standaard alle DM's naar de hoofdsessie om continuïteit tussen apparaten te bieden. Als meerdere mensen de bot een DM kunnen sturen (open DM's of een toelatingslijst met meerdere personen), isoleer dan de DM-sessies:

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

Waarden voor session.dmScope:

Lokale onboarding via de CLI behoudt een expliciete session.dmScope en laat deze anders oningesteld, zodat de standaardwaarde "main" van toepassing is: alle directe berichten via verschillende kanalen delen de doorlopende hoofdsessie van de agent (de standaard voor een persoonlijke agent). Stel voor gedeelde inboxen of inboxen met meerdere gebruikers session.dmScope: "per-channel-peer" in; openclaw security audit raadt isolatie aan wanneer DM-verkeer van meerdere gebruikers wordt gedetecteerd.

Dit is een grens voor berichtcontext, geen grens voor hostbeheer. Als gebruikers onderling vijandig zijn en dezelfde Gateway-host/configuratie delen, voer dan afzonderlijke gateways per vertrouwensgrens uit.

Als dezelfde persoon via meerdere kanalen contact met je opneemt, gebruik je session.identityLinks om die DM-sessies samen te voegen tot één canonieke identiteit. Zie Sessiebeheer en Configuratie.

Contextzichtbaarheid versus activeringsautorisatie

Twee afzonderlijke concepten:

• Activeringsautorisatie: wie de agent kan activeren (dmPolicy, groupPolicy, toelatingslijsten, vermeldingsvereisten).
• Contextzichtbaarheid: welke aanvullende context het model bereikt (antwoordtekst, geciteerde tekst, threadgeschiedenis, doorgestuurde metadata).

contextVisibility beheert het tweede:

• "all" (standaard): aanvullende context wordt behouden zoals deze is ontvangen.
• "allowlist": aanvullende context wordt gefilterd tot afzenders die volgens de actieve toelatingslijstcontroles zijn toegestaan.
• "allowlist_quote": zoals allowlist, maar één expliciet geciteerd antwoord blijft behouden.

Stel dit per kanaal of per ruimte/gesprek in — zie Groepen. Meldingen die alleen aantonen dat „het model geciteerde/historische tekst kan zien van afzenders die niet op de toelatingslijst staan”, zijn bevindingen voor aanvullende beveiliging die met contextVisibility kunnen worden aangepakt, en zijn op zichzelf geen omzeiling van authenticatie of sandboxing; voor een melding met beveiligingsimpact moet nog steeds een aantoonbare omzeiling van een vertrouwensgrens worden gedemonstreerd.

Promptinjectie

Een aanvaller stelt een bericht op dat het model manipuleert om een onveilige handeling uit te voeren („negeer je instructies”, „dump je bestandssysteem”, „volg deze link en voer opdrachten uit”). Promptinjectie wordt niet opgelost door alleen vangrails in de systeemprompt — dat zijn zachte richtlijnen; harde afdwinging komt van toolbeleid, uitvoeringsgoedkeuringen, sandboxing en kanaaltoelatingslijsten (die operators nog steeds bewust kunnen uitschakelen).

Voor promptinjectie zijn geen openbare DM's vereist: zelfs als alleen jij de bot berichten kunt sturen, kan alle niet-vertrouwde inhoud die de bot leest (resultaten van zoeken/ophalen op het web, browserpagina's, e-mails, documenten, bijlagen, geplakte logboeken/code) vijandige instructies bevatten. De inhoud zelf vormt een aanvalsoppervlak, niet alleen de afzender.

Waarschuwingssignalen die als niet-vertrouwd moeten worden behandeld:

• „Lees dit bestand/deze URL en doe precies wat erin staat.”
• „Negeer je systeemprompt of veiligheidsregels.”
• „Onthul je verborgen instructies of tooluitvoer.”
• „Plak de volledige inhoud van ~/.openclaw of je logboeken.”

Wat in de praktijk helpt:

• Houd inkomende DM's vergrendeld (koppeling/toelatingslijsten); geef in groepen de voorkeur aan activering via vermeldingen; vermijd bots die altijd actief zijn in openbare ruimtes.
• Behandel links, bijlagen en geplakte instructies standaard als vijandig.
• Voer gevoelige tooluitvoering uit in een sandbox; houd geheimen buiten het bestandssysteem dat voor de agent bereikbaar is. Sandboxing is optioneel: als de sandboxmodus is uitgeschakeld, wordt impliciete host=auto naar de gatewayhost herleid, terwijl expliciete host=sandbox nog steeds gesloten faalt (geen sandboxruntime beschikbaar). Stel host=gateway in om dat gedrag expliciet in de configuratie vast te leggen.
• Beperk tools met een hoog risico (exec, browser, web_fetch, web_search) tot vertrouwde agents of expliciete toelatingslijsten.
• Als je interpreters op de toelatingslijst zet (python, node, ruby, perl, php, lua, osascript), schakel dan tools.exec.strictInlineEval in, zodat inline-evaluatievormen (-c, -e en vergelijkbare vormen) nog steeds expliciete goedkeuring vereisen. In de toelatingslijstmodus vereist elk heredoc-segment (<<) altijd beoordeling door een reviewer of expliciete goedkeuring, ongeacht de aanhalingstekens — een toegestane opdracht kan een heredoc-body niet gebruiken om beoordeling volgens de toelatingslijst te omzeilen.
• Beperk de impact door een alleen-lezen leesagent of een leesagent zonder tools te gebruiken om niet-vertrouwde inhoud samen te vatten en de samenvatting vervolgens aan je hoofdagent door te geven.
• Bij Gmail-hooks isoleert de ingebouwde sessie per bericht de gesprekscontext, maar verwijdert deze niet de tool- of werkruimtemachtigingen van de doelagent. Routeer niet-vertrouwde e-mail naar een speciale leesagent, pas sandbox- en toolbeperkingen per agent toe en beperk elke overdracht naar de hoofdagent met tools.agentToAgent. Zie Gmail-integratie.
• Houd web_search / web_fetch / browser uitgeschakeld voor agents met ingeschakelde tools, tenzij ze nodig zijn.
• Stel voor OpenResponses-URL-invoer (input_file / input_image) een strikte gateway.http.endpoints.responses.files.urlAllowlist / images.urlAllowlist in en houd maxUrlParts laag (lege toelatingslijsten gelden als niet ingesteld). Gebruik files.allowUrl: false / images.allowUrl: false om het ophalen van URL's volledig uit te schakelen.
• Houd geheimen buiten prompts; geef ze in plaats daarvan door via omgevingsvariabelen/configuratie op de gatewayhost.

Modelkeuze is belangrijk. Weerstand tegen promptinjectie is niet uniform tussen modelniveaus: kleinere/goedkopere modellen zijn bij vijandige prompts vatbaarder voor misbruik van tools en het kapen van instructies.

• Gebruik het nieuwste model van het beste niveau voor elke bot die tools kan uitvoeren of toegang heeft tot bestanden/netwerken.
• Gebruik geen oudere/zwakkere/kleinere niveaus voor agents die tools kunnen gebruiken of voor niet-vertrouwde inboxen.
• Als je een kleiner model moet gebruiken, beperk dan de impact: alleen-lezen-tools, sterke sandboxing, minimale bestandssysteemtoegang en strikte toelatingslijsten. Schakel sandboxing in voor alle sessies en schakel web_search/web_fetch/browser uit, tenzij invoer strikt wordt beheerd.
• Voor persoonlijke assistenten die alleen chatten, met vertrouwde invoer en zonder tools, zijn kleinere modellen doorgaans prima.

Externe inhoud en omhulling van niet-vertrouwde invoer

OpenResponses input_file-tekst wordt nog steeds als niet-vertrouwde externe inhoud geïnjecteerd, hoewel de Gateway deze lokaal decodeert: het blok bevat <<&lt;EXTERNAL_UNTRUSTED_CONTENT ...&gt;>>-grensmarkeringen plus Source: External-metadata (dit pad laat de langere SECURITY NOTICE:-banner weg die elders wordt gebruikt). Dezelfde op markeringen gebaseerde omhulling wordt toegepast wanneer mediaherkenning tekst uit bijgevoegde documenten extraheert voordat deze aan de mediaprompt wordt toegevoegd.

OpenClaw verwijdert ook veelvoorkomende speciale token-literals van chatsjablonen voor zelfgehoste LLM's (Qwen/ChatML, Llama, Gemma, Mistral, Phi, GPT-OSS-rol-/beurttokens) uit omhulde externe inhoud en metadata voordat deze het model bereiken. Zelfgehoste OpenAI-compatibele backends (vLLM, SGLang, TGI, LM Studio, aangepaste Hugging Face-tokenizerstacks) tokeniseren letterlijke tekenreeksen zoals <|im_start|> of <|start_header_id|> soms als structurele chatsjabloontokens in gebruikersinhoud; zonder deze opschoning zou niet-vertrouwde tekst in een opgehaalde pagina, e-mailtekst of uitvoer van een tool voor bestandsinhoud een synthetische assistant/system-rolgrens kunnen vervalsen. Opschoning vindt plaats in de laag die externe inhoud omhult en wordt dus uniform toegepast op ophaal-/leestools en inkomende kanaalinhoud. Gehoste providers (OpenAI, Anthropic) passen al hun eigen opschoning aan de aanvraagzijde toe; houd omhulling van externe inhoud ingeschakeld en geef waar beschikbaar de voorkeur aan backendinstellingen die speciale tokens splitsen/escapen.

Uitgaande modelantwoorden hebben een afzonderlijk opschoningsmechanisme dat gelekte <tool_call>, <function_calls>, <system-reminder>, <previous_response> en vergelijkbare interne hulpstructuren bij de uiteindelijke kanaalbezorgingsgrens uit voor gebruikers zichtbare antwoorden verwijdert.

Dit vervangt dmPolicy, toelatingslijsten, uitvoeringsgoedkeuringen, sandboxing of contextVisibility niet: het dicht één specifieke omzeiling op tokenizerniveau.

Omzeilingsvlaggen (uitgeschakeld houden in productie)

• hooks.mappings[].allowUnsafeExternalContent
• hooks.gmail.allowUnsafeExternalContent
• Cron-payloadveld allowUnsafeExternalContent

Schakel deze alleen tijdelijk in voor strikt afgebakende foutopsporing; is er een ingeschakeld, isoleer die agent dan (sandbox + minimale tools + afzonderlijke sessienaamruimte).

Hook-payloads zijn niet-vertrouwde inhoud, zelfs wanneer ze worden aangeleverd door systemen die je beheert (e-mail-/document-/webinhoud kan promptinjectie bevatten). Zwakke modelniveaus vergroten dit risico: geef voor door hooks aangestuurde automatisering de voorkeur aan sterke moderne modelniveaus, houd het toolbeleid strikt (tools.profile: "messaging" of strenger) en gebruik waar mogelijk sandboxing.

Redenering en uitgebreide uitvoer in groepen

/reasoning, /verbose en /trace kunnen interne redeneringen, tooluitvoer of plug-indiagnostiek blootleggen die niet voor een openbaar kanaal zijn bedoeld; ze kunnen toolargumenten, URL's, plug-indiagnostiek en door het model bekeken gegevens bevatten. Houd ze uitgeschakeld in openbare ruimtes; schakel ze alleen in vertrouwde privéberichten of strikt beheerde ruimtes in.

Autorisatie van opdrachten

Slash-opdrachten en richtlijnen worden alleen uitgevoerd voor geautoriseerde afzenders, bepaald op basis van kanaaltoelatingslijsten/koppeling plus commands.useAccessGroups (zie Configuratie en Slash-opdrachten). Als een kanaaltoelatingslijst leeg is of "*" bevat, zijn opdrachten voor dat kanaal feitelijk openbaar.

/exec is uitsluitend een gemak voor geautoriseerde operators binnen de sessie: het schrijft geen configuratie en wijzigt geen andere sessies.

Tools voor het besturingsvlak

Twee ingebouwde tools blijven gevoelig voor het besturingsvlak:

• gateway leest configuratie met config.schema.lookup / config.get. Deze kan geen configuratie schrijven, OpenClaw bijwerken of de Gateway opnieuw starten.
• cron maakt geplande taken die blijven draaien nadat de oorspronkelijke chat/taak is beëindigd.

De tool gateway blijft uitsluitend voor de eigenaar, omdat het lezen van configuratie geheimen en de hosttopologie kan blootleggen. Agents vragen blijvende configuratie- of levenscycluswijzigingen aan via de delegatietool openclaw; OpenClaw zet deze om in getypeerde bewerkingen en vereist menselijke goedkeuring voordat ze worden toegepast. Zie OpenClaw-installatieagent.

Weiger deze standaard voor elke agent/elk oppervlak dat niet-vertrouwde inhoud verwerkt:

{  tools: {    deny: ["gateway", "cron", "sessions_spawn", "sessions_send"],  },}

commands.restart=false schakelt /restart en externe SIGUSR1-herstartverzoeken uit. De agenttool gateway heeft geen herstartactie.

Node-uitvoering (system.run)

Als een macOS-node is gekoppeld, kan de Gateway daarop system.run aanroepen: dit is uitvoering van externe code op die Mac.

• Vereist nodekoppeling (goedkeuring + token). Koppeling stelt de identiteit/het vertrouwen van de node vast en geeft een token uit; het is geen goedkeuringsmechanisme per opdracht.
• De Gateway past een grof globaal beleid voor nodeopdrachten toe via gateway.nodes.commands.allow / gateway.nodes.commands.deny. De weigeringslijst vergelijkt alleen exacte namen van nodeopdrachten (bijvoorbeeld system.run), niet shelltekst in een opdrachtpayload; een node die opnieuw verbinding maakt en een andere opdrachtenlijst aankondigt, vormt op zichzelf geen kwetsbaarheid als het globale Gateway-beleid en de eigen uitvoeringsgoedkeuringen van de node de grens nog steeds handhaven.
• Het system.run-beleid per node is het eigen bestand met uitvoeringsgoedkeuringen van de node (exec.approvals.node.*), dat op de Mac wordt beheerd via Settings -> Exec approvals (security + ask + allowlist); dit kan strenger of minder streng zijn dan het globale beleid voor opdracht-ID's van de Gateway.
• Een node die security="full" en ask="off" uitvoert, volgt het standaardmodel voor vertrouwde operators: verwacht gedrag, geen bug, tenzij je implementatie een strikter beleid vereist.
• De goedkeuringsmodus bindt de exacte aanvraagcontext en, waar mogelijk, één concreet lokaal script-/bestandsoperand. Als OpenClaw niet precies één rechtstreeks lokaal bestand voor een interpreter-/runtimeopdracht kan identificeren, wordt uitvoering op basis van goedkeuring geweigerd in plaats van volledige semantische dekking te beloven.
• Voor host=node slaan uitvoeringen op basis van goedkeuring ook een canoniek voorbereid systemRunPlan op; later goedgekeurd doorsturen gebruikt dat opgeslagen plan opnieuw en Gateway-validatie weigert wijzigingen door de aanroeper aan de opdracht-/werkmap-/sessiecontext nadat de goedkeuringsaanvraag is aangemaakt.
• Om externe uitvoering volledig uit te schakelen: stel security in op deny en verwijder de nodekoppeling voor die Mac.

Dynamische Skills (watcher / externe nodes)

OpenClaw kan de lijst met Skills tijdens een sessie vernieuwen: de Skills-watcher werkt de momentopname bij tijdens de volgende agentbeurt wanneer SKILL.md verandert, en door verbinding te maken met een macOS-node kunnen Skills die alleen voor macOS zijn bedoeld in aanmerking komen (op basis van het detecteren van binaire bestanden). Behandel Skills-mappen als vertrouwde code en beperk wie ze kan wijzigen.

Plugins

Plugins draaien in hetzelfde proces als de Gateway: behandel ze als vertrouwde code.

• Installeer alleen uit bronnen die je vertrouwt; geef de voorkeur aan expliciete plugins.allow-toelatingslijsten; controleer de Pluginconfiguratie voordat je deze inschakelt; start de Gateway opnieuw na Pluginwijzigingen.
• Bij het installeren/bijwerken van Plugins wordt uitvoerbare code uitgevoerd:
  • Het installatiepad is de map per Plugin onder de actieve hoofdmap voor Plugininstallaties.
  • ClawHub-pakketten en de gebundelde/officiële catalogus van OpenClaw zijn vertrouwde bronnen. Bij een nieuwe willekeurige npm-, npm-pack:-, git-, lokaal pad-/archief- of marktplaatsbron verschijnt vóór installatie een waarschuwing; niet-interactieve installaties vereisen --force nadat je die bron hebt beoordeeld en vertrouwd. --force bevestigt de herkomst en staat overschrijven toe; het omzeilt security.installPolicy of overige veiligheidscontroles bij installatie niet. Updates gebruiken de reeds geselecteerde bron opnieuw.
  • OpenClaw voert tijdens installatie/bijwerking geen ingebouwde lokale blokkering van gevaarlijke code uit. Gebruik security.installPolicy voor lokale, door operators beheerde beslissingen over toestaan/blokkeren en openclaw security audit --deep voor diagnostische scans.
  • Bij npm- en git-installaties van Plugins wordt alleen tijdens de expliciete installatie-/bijwerkprocedure convergentie van pakketbeheerafhankelijkheden uitgevoerd. Lokale paden en archieven worden behandeld als zelfstandige pakketten; OpenClaw kopieert/verwijst ernaar zonder npm install uit te voeren.
  • Geef de voorkeur aan vastgezette exacte versies (@scope/pkg@1.2.3) en inspecteer de uitgepakte code voordat je deze inschakelt.
  • --dangerously-force-unsafe-install is verouderd en verandert het installatie-/bijwerkgedrag niet meer.
  • Met security.installPolicy kunnen operators een vertrouwde lokale opdracht uitvoeren om hostspecifieke beslissingen te nemen over het toestaan/blokkeren van Skills- en Plugininstallaties. Deze wordt uitgevoerd nadat het bronmateriaal is klaargezet maar voordat de installatie doorgaat, geldt ook voor ClawHub-Skills en wordt niet omzeild door verouderde onveilige vlaggen.

Details: Plugins

Sandboxing

Speciale documentatie: Sandboxing

Twee complementaire benaderingen:

• Volledige Gateway in Docker (containergrens): Docker
• Toolsandbox (agents.defaults.sandbox; host-Gateway + door de sandbox geïsoleerde tools; Docker is de standaardbackend): Sandboxing

Toegang tot de agentwerkruimte binnen de sandbox (agents.defaults.sandbox.workspaceAccess):

• "none" (standaard): tools zien een sandboxwerkruimte onder ~/.openclaw/sandboxes; de agentwerkruimte is niet toegankelijk.
• "ro": koppelt de agentwerkruimte als alleen-lezen aan /agent (schakelt write/edit/apply_patch uit).
• "rw": koppelt de agentwerkruimte als lezen/schrijven aan /workspace.

Aanvullende sandbox.docker.binds worden gevalideerd aan de hand van genormaliseerde, gecanonicaliseerde bronpaden. Een weigeringslijst voor geblokkeerde paden omvat /etc, /private/etc, /proc, /sys, /dev, /root, /boot en mappen die doorgaans de Docker-socket bevatten of ernaar verwijzen (/run, /var/run en docker.sock daaronder), plus subpaden voor referenties in HOME (.aws, .cargo, .config, .docker, .gnupg, .netrc, .npm, .ssh). Trucs met bovenliggende symbolische koppelingen en canonieke aliassen voor de thuismap worden via bestaande voorouders opgelost en opnieuw gecontroleerd, zodat ze nog steeds standaard worden geweigerd als ze naar een geblokkeerde hoofdmap verwijzen.

Beveiliging voor delegatie aan subagents

Als je sessietools toestaat, behandel gedelegeerde subagentuitvoeringen dan als een afzonderlijke grensbeslissing:

• Weiger sessions_spawn tenzij de agent delegatie echt nodig heeft.
• Beperk agents.defaults.subagents.allowAgents en eventuele agents.entries.*.subagents.allowAgents-overrides per agent tot bekende, veilige doelagenten.
• Roep voor workflows die in de sandbox moeten blijven sessions_spawn aan met sandbox: "require" (standaard is "inherit"); "require" breekt onmiddellijk af wanneer de runtime van het doelkind niet in een sandbox draait.

Alleen-lezenmodus

Bouw een alleen-lezenprofiel door agents.defaults.sandbox.workspaceAccess: "ro" (of "none" voor geen toegang tot de werkruimte) te combineren met lijsten voor het toestaan/weigeren van tools die write, edit, apply_patch, exec, process, enzovoort blokkeren.

• tools.exec.applyPatch.workspaceOnly: true (standaard): voorkomt dat apply_patch buiten de werkruimtemap schrijft of verwijdert, zelfs als sandboxing is uitgeschakeld. Stel false alleen in als je bewust wilt dat apply_patch bestanden buiten de werkruimte benadert.
• tools.fs.workspaceOnly: true (optioneel): beperkt paden voor read/write/edit/apply_patch en automatisch geladen native promptafbeeldingen tot de werkruimtemap.
• Houd bestandssysteemhoofdmappen beperkt: vermijd brede hoofdmappen zoals je thuismap voor agent-/sandboxwerkruimten, omdat bestandssysteemtools hierdoor toegang kunnen krijgen tot gevoelige lokale bestanden (bijvoorbeeld status/configuratie onder ~/.openclaw).

Toegangsprofielen per agent (multi-agent)

Elke agent kan een eigen sandbox- en toolbeleid hebben: volledige toegang, alleen-lezen of geen toegang. Zie Sandbox en tools voor meerdere agents voor de voorrangsregels.

Veelvoorkomende patronen: persoonlijke agent (volledige toegang, geen sandbox), gezins-/werkagent (sandbox + alleen-lezentools), openbare agent (sandbox + geen bestandssysteem-/shelltools).

Volledige toegang (geen sandbox)

{  agents: {    list: [      { id: "personal", workspace: "~/.openclaw/workspace-personal", sandbox: { mode: "off" } },    ],  },}

Alleen-lezentools + alleen-lezenwerkruimte

{  agents: {    list: [      {        id: "family",        workspace: "~/.openclaw/workspace-family",        sandbox: { mode: "all", scope: "agent", workspaceAccess: "ro" },        tools: {          allow: ["read"],          deny: ["write", "edit", "apply_patch", "exec", "process", "browser"],        },      },    ],  },}

Geen toegang tot bestandssysteem/shell (berichten via providers toegestaan)

{  agents: {    list: [      {        id: "public",        workspace: "~/.openclaw/workspace-public",        sandbox: { mode: "all", scope: "agent", workspaceAccess: "none" },        tools: {          // Sessietools kunnen transcriptgegevens onthullen. Het standaardbereik is huidig + gestart;          // leesbewerkingen omvatten ook groepen van dezelfde agent die via omgevingsbewustzijn van groepen worden gevolgd.          // Gebruik visibility: "self" om die gevolgde sessies uit te sluiten.          sessions: { visibility: "tree" }, // self | tree | agent | all          allow: [            "sessions_list",            "sessions_history",            "sessions_send",            "sessions_spawn",            "session_status",            "discord",            "slack",            "telegram",            "whatsapp",          ],          deny: [            "apply_patch",            "browser",            "canvas",            "cron",            "edit",            "exec",            "gateway",            "image",            "nodes",            "process",            "read",            "write",          ],        },      },    ],  },}

Risico's van browserbesturing

Als je browserbesturing inschakelt, geef je het model toegang tot een echte browser. Als dat profiel al aangemelde sessies bevat, kan het model toegang krijgen tot die accounts en gegevens; behandel browserprofielen als gevoelige status.

• Gebruik bij voorkeur een afzonderlijk profiel voor de agent (het standaardprofiel openclaw); vermijd je persoonlijke profiel voor dagelijks gebruik.
• Houd browserbesturing op de host uitgeschakeld voor agents in een sandbox, tenzij je ze vertrouwt.
• De zelfstandige loopback-API voor browserbesturing accepteert alleen authenticatie met een gedeeld geheim (bearer-authenticatie met een Gateway-token of Gateway-wachtwoord); deze gebruikt geen identiteitheaders van een vertrouwde proxy of Tailscale Serve.
• Behandel browserdownloads als niet-vertrouwde invoer; gebruik bij voorkeur een geïsoleerde downloadmap.
• Schakel browsersynchronisatie/wachtwoordbeheerders indien mogelijk uit in het agentprofiel.
• Voor externe Gateways staat 'browserbesturing' gelijk aan 'operatortoegang' tot alles wat dat profiel kan bereiken.
• Houd Gateway- en Node-hosts uitsluitend toegankelijk via het tailnet; stel poorten voor browserbesturing niet beschikbaar aan het LAN of openbare internet.
• Schakel browserproxyrouting uit wanneer dit niet nodig is (gateway.nodes.browser.mode="off").
• De modus voor bestaande sessies van Chrome MCP is niet 'veiliger': deze kan namens jou handelen in alles wat het Chrome-profiel op die host kan bereiken.
• Voer een Node-host uit op de browsermachine en laat de Gateway browseracties proxyen wanneer de Gateway zich op afstand van de browser bevindt (zie Browsertool); behandel het koppelen van Nodes als beheerderstoegang, houd de Gateway en Node-host op hetzelfde tailnet en stel relay-/besturingspoorten niet beschikbaar via het LAN, openbare internet of Tailscale Funnel.

Browser-SSRF-beleid (standaard strikt)

Privé-/interne bestemmingen blijven geblokkeerd, tenzij je ze expliciet toestaat.

• Standaard: browser.ssrfPolicy.dangerouslyAllowPrivateNetwork is niet ingesteld, waardoor privé-, interne en voor speciaal gebruik bestemde bestemmingen geblokkeerd blijven. De verouderde alias allowPrivateNetwork wordt nog steeds geaccepteerd.
• Expliciet toestaan: stel dangerouslyAllowPrivateNetwork: true in om deze bestemmingen toe te staan.
• Gebruik in de strikte modus hostnameAllowlist (patronen zoals *.example.com) en allowedHostnames (uitzonderingen voor exacte hosts, inclusief anderszins geblokkeerde namen zoals localhost) voor expliciete uitzonderingen.
• Directe navigatieverzoeken worden vooraf gecontroleerd. Tijdens de actie en een beperkte respijtperiode na de actie onderscheppen beveiligde Playwright-interacties (klikken, klikken op coördinaten, aanwijzen, slepen, scrollen, selecteren, indrukken, typen, formulieren invullen en evalueren) door beleid geweigerde documentladingen op het hoogste niveau en in subframes voordat bytes van het HTTP-verzoek worden verzonden. Daarna wordt de uiteindelijke http(s)-URL naar beste vermogen opnieuw gecontroleerd.
• Voor elke nieuwe beheerde Chrome-start schakelt OpenClaw naar beste vermogen netwerkvoorspelling uit, waarmee het waargenomen speculatieve vooraf verbinden van Chromium voor die geweigerde ladingen wordt onderdrukt. Dit is beveiliging in de diepte, geen beleidsgrens: een browser die opnieuw wordt gebruikt na een herstart van de besturingsservice en andere browserbackends delen deze hardening mogelijk niet. Paginaroutering blijft onderschepping op verzoekniveau, geen netwerkfirewall: omleidingsstappen, het eerste verzoek van een pop-up, Service Worker-verkeer, paginacode die na het beperkte beveiligingsvenster wordt uitgevoerd en sommige achtergrond-/subresourcepaden kunnen dit omzeilen. Controles van de uiteindelijke URL blijven een detectie-/quarantaineverdediging; volledige preventie vereist uitgaande isolatie aan de kant van de eigenaar of een proxy die het beleid afdwingt.

{  browser: {    ssrfPolicy: {      dangerouslyAllowPrivateNetwork: false,      hostnameAllowlist: ["*.example.com", "example.com"],      allowedHostnames: ["localhost"],    },  },}

Netwerkblootstelling

Binding, poort, firewall

De Gateway multiplexeert WebSocket + HTTP op één poort (standaard 18789; configuratie/vlaggen/omgeving: gateway.port, --port, OPENCLAW_GATEWAY_PORT). Dat HTTP-oppervlak omvat de Control UI (SPA-assets, standaardbasispad /) en de canvashost (/__openclaw__/canvas en /__openclaw__/a2ui: willekeurige HTML/JS; behandel dit als niet-vertrouwde inhoud wanneer het in een normale browser wordt geladen; stel het niet beschikbaar aan niet-vertrouwde netwerken/gebruikers en deel geen origin met weboppervlakken met hogere rechten).

gateway.bind bepaalt waar de Gateway luistert:

• "loopback" (standaard): alleen lokale clients kunnen verbinding maken.
• "lan", "tailnet", "custom": vergroten het aanvalsoppervlak. Gebruik dit alleen met Gateway-authenticatie (gedeeld token/wachtwoord of een correct geconfigureerde vertrouwde proxy) en een echte firewall.

Vuistregels: geef de voorkeur aan Tailscale Serve boven LAN-bindings (Serve houdt de Gateway op loopback en Tailscale regelt de toegang); als je aan het LAN moet binden, beperk de poort met een firewall tot een strikte toelatingslijst van bron-IP-adressen in plaats van de poort breed door te sturen; stel de Gateway nooit zonder authenticatie beschikbaar op 0.0.0.0.

Docker-poortpublicatie met UFW

Gepubliceerde containerpoorten (-p HOST:CONTAINER of Compose ports:) worden gerouteerd via de forwardingketens van Docker, niet alleen via de INPUT-regels van de host. Dwing regels af in DOCKER-USER (geëvalueerd vóór de eigen acceptatieregels van Docker); de meeste moderne distributies gebruiken de iptables-nft-frontend, die deze regels nog steeds toepast op de nftables-backend.

# /etc/ufw/after.rules (voeg toe als een afzonderlijke *filter-sectie)*filter:DOCKER-USER - [0:0]-A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j RETURN-A DOCKER-USER -s 127.0.0.0/8 -j RETURN-A DOCKER-USER -s 10.0.0.0/8 -j RETURN-A DOCKER-USER -s 172.16.0.0/12 -j RETURN-A DOCKER-USER -s 192.168.0.0/16 -j RETURN-A DOCKER-USER -s 100.64.0.0/10 -j RETURN-A DOCKER-USER -p tcp --dport 80 -j RETURN-A DOCKER-USER -p tcp --dport 443 -j RETURN-A DOCKER-USER -m conntrack --ctstate NEW -j DROP-A DOCKER-USER -j RETURNCOMMIT

IPv6 heeft afzonderlijke tabellen; voeg een overeenkomstig beleid toe in /etc/ufw/after6.rules als Docker IPv6 is ingeschakeld. Vermijd hardgecodeerde interfacenamen (eth0), omdat deze per VPS-image verschillen (ens3, enp*, enzovoort) en een niet-overeenkomende naam je weigeringsregel ongemerkt kan overslaan.

ufw reloadiptables -S DOCKER-USERip6tables -S DOCKER-USERnmap -sT -p 1-65535 <public-ip> --open

De verwachte externe poorten mogen alleen de poorten zijn die je bewust beschikbaar stelt (voor de meeste configuraties: SSH + reverse-proxypoorten).

mDNS-/Bonjour-detectie

Wanneer de meegeleverde bonjour-Plugin is ingeschakeld, zendt de Gateway zijn aanwezigheid via mDNS uit (_openclaw-gw._tcp, poort 5353) voor het detecteren van lokale apparaten. De volledige modus bevat TXT-records die operationele details blootleggen: cliPath (bestandssysteempad dat gebruikersnaam en installatielocatie onthult), sshPort (maakt SSH-beschikbaarheid bekend), displayName/lanHost (hostnaaminformatie). Het uitzenden van infrastructuurdetails maakt verkenning op het LAN eenvoudiger.

• Houd Bonjour uitgeschakeld tenzij LAN-detectie nodig is; het start automatisch op macOS-hosts en moet elders expliciet worden ingeschakeld. Rechtstreekse Gateway-URL's, Tailnet, SSH of wide-area DNS-SD vermijden lokale multicast.

• Minimale modus (standaard wanneer Bonjour is ingeschakeld, aanbevolen voor blootgestelde Gateways) laat gevoelige velden weg:

  { discovery: { mdns: { mode: "minimal" } } }

• Uit onderdrukt lokale detectie terwijl de Plugin ingeschakeld blijft:

  { discovery: { mdns: { mode: "off" } } }

• Volledige modus (expliciet inschakelen) bevat cliPath + sshPort:

  { discovery: { mdns: { mode: "full" } } }

• Of stel OPENCLAW_DISABLE_BONJOUR=1 in om mDNS zonder configuratiewijzigingen uit te schakelen.

In de minimale modus zendt de Gateway role, gatewayPort, transport uit, maar laat cliPath/sshPort weg; apps die het CLI-pad nodig hebben, kunnen dit in plaats daarvan ophalen via de geauthenticeerde WebSocket-verbinding.

Gateway-WebSocket-authenticatie

Gateway-authenticatie is standaard vereist: als er geen geldig authenticatiepad is geconfigureerd, weigert de Gateway WebSocket-verbindingen (gesloten bij fouten). Onboarding genereert standaard een token (zelfs voor loopback), zodat lokale clients zich moeten authenticeren.

{ gateway: { auth: { mode: "token", token: "your-token" } } }

openclaw doctor --generate-gateway-token kan er een voor je genereren.

Zet externe TLS vast met gateway.remote.tlsFingerprint wanneer je wss:// gebruikt. Onversleutelde ws:// wordt geaccepteerd voor loopback, letterlijke privé-IP-adressen, .local en Tailnet-*.ts.net-gateway-URL's; stel voor andere vertrouwde privé-DNS-namen OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 in op het clientproces als noodoplossing (alleen procesomgeving, geen openclaw.json-sleutel). Mobiele koppeling en handmatige/gescande Android-gatewayroutes zijn strenger: onversleuteld verkeer is alleen toegestaan voor loopback, terwijl privé-LAN, link-local, .local en hostnamen zonder punt TLS moeten gebruiken, tenzij je expliciet kiest voor het vertrouwde onversleutelde pad voor privénetwerken.

Apparaatkoppeling wordt automatisch goedgekeurd voor directe lokale loopbackverbindingen (plus een beperkt zelfverbindingspad binnen de backend/container voor vertrouwde helperflows met een gedeeld geheim); Tailnet- en LAN-verbindingen, inclusief verbindingen op dezelfde host naar een Tailnet-adres, worden als extern behandeld en moeten nog steeds worden goedgekeurd. Een omgezet tailnet-adres of custom-adres anders dan 127.0.0.1 of 0.0.0.0 voegt een afzonderlijke 127.0.0.1-listener toe; alleen verbindingen met die lokale listener krijgen loopbacksemantiek. Bewijs uit doorgestuurde headers bij een loopbackverzoek sluit loopbacklokaliteit uit; automatische goedkeuring van metadata-upgrades is strikt afgebakend. Zie Gateway-koppeling.

Authenticatiemodi:

• "token": gedeeld bearertoken (aanbevolen voor de meeste configuraties).
• "password": stel dit bij voorkeur in via OPENCLAW_GATEWAY_PASSWORD.
• "trusted-proxy": vertrouw op een identiteitsbewuste reverse proxy om gebruikers te authenticeren en identiteit via headers door te geven. Zie Authenticatie met vertrouwde proxy.

Controlelijst voor rotatie (token/wachtwoord): genereer/stel een nieuw geheim in (gateway.auth.token of OPENCLAW_GATEWAY_PASSWORD); herstart de Gateway (of de macOS-app als deze de Gateway beheert); werk externe clients bij (gateway.remote.token/.password); controleer of de oude referenties niet meer werken.

Identiteitsheaders van Tailscale Serve

Wanneer gateway.auth.allowTailscale gelijk is aan true (standaard voor Serve), accepteert OpenClaw de Tailscale Serve-identiteitsheader tailscale-user-login voor authenticatie van de Control UI/WebSocket. De identiteit wordt geverifieerd door het x-forwarded-for-adres via de lokale Tailscale-daemon (tailscale whois) om te zetten en met de header te vergelijken. Dit wordt alleen geactiveerd voor loopbackverzoeken die x-forwarded-for, x-forwarded-proto en x-forwarded-host bevatten zoals door Tailscale ingevoegd. Voor deze asynchrone controle worden mislukte pogingen voor dezelfde {scope, ip} geserialiseerd voordat de limietregelaar de mislukking registreert, zodat gelijktijdige ongeldige nieuwe pogingen vanaf één Serve-client de tweede poging onmiddellijk kunnen blokkeren.

HTTP-API-eindpunten (/v1/*, /tools/invoke, /api/channels/*) gebruiken geen authenticatie via Tailscale-identiteitsheaders; ze volgen de geconfigureerde HTTP-authenticatiemodus van de gateway.

HTTP-bearerauthenticatie van de Gateway biedt in feite volledige of geen operatortoegang. Referenties die /v1/chat/completions, /v1/responses, pluginroutes zoals /api/v1/admin/rpc of /api/channels/* kunnen aanroepen, zijn operatorgeheimen met volledige toegang voor die gateway: bearerauthenticatie met een gedeeld geheim herstelt alle standaardoperatorbereiken (operator.admin, operator.approvals, operator.pairing, operator.read, operator.talk.secrets, operator.write) en eigenaarssemantiek voor agentbeurten, en beperktere x-openclaw-scopes-waarden beperken dat pad met gedeeld geheim niet. Semantiek voor bereik per verzoek is alleen van toepassing wanneer het verzoek afkomstig is van een modus met identiteit (authenticatie via vertrouwde proxy) of expliciet niet-geauthenticeerde privétoegang; in die modi valt het weglaten van x-openclaw-scopes terug op de normale set standaardoperatorbereiken, en headers op eigenaarsniveau zoals x-openclaw-model vereisen operator.admin wanneer de bereiken zijn beperkt. /tools/invoke en HTTP-eindpunten voor sessiegeschiedenis volgen dezelfde regel voor gedeelde geheimen. Deel deze referenties niet met niet-vertrouwde aanroepers; gebruik bij voorkeur afzonderlijke gateways per vertrouwensgrens.

Serve-authenticatie zonder token veronderstelt dat de gatewayhost zelf wordt vertrouwd; dit biedt geen bescherming tegen vijandige processen op dezelfde host. Als niet-vertrouwde lokale code op de gatewayhost kan worden uitgevoerd, schakel dan allowTailscale uit en vereis expliciete authenticatie met een gedeeld geheim (token of password).

Stuur deze headers niet door vanuit je eigen reverse proxy. Als je TLS beëindigt of een proxy vóór de gateway plaatst, schakel dan allowTailscale uit en gebruik in plaats daarvan authenticatie met een gedeeld geheim of Authenticatie met vertrouwde proxy.

Zie Tailscale en Weboverzicht.

Configuratie van reverse proxy

Stel gateway.trustedProxies in voor correcte verwerking van doorgestuurde client-IP-adressen achter nginx/Caddy/Traefik/etc. Wanneer de Gateway proxyheaders detecteert vanaf een adres dat niet in trustedProxies staat, behandelt deze de verbinding niet als lokaal; als gatewayauthenticatie is uitgeschakeld, wordt die verbinding geweigerd. Dit voorkomt dat proxyverbindingen van localhost lijken te komen en automatisch worden vertrouwd.

trustedProxies wordt ook gebruikt door gateway.auth.mode: "trusted-proxy", dat strenger is: standaard wordt toegang via proxies met een loopbackbron veilig geweigerd. Reverse proxy's op dezelfde host via loopback kunnen trustedProxies gebruiken voor detectie van lokale clients en verwerking van doorgestuurde IP-adressen, maar kunnen alleen voldoen aan de authenticatiemodus trusted-proxy wanneer gateway.auth.trustedProxy.allowLoopback = true; gebruik anders token-/wachtwoordauthenticatie.

gateway:  trustedProxies:    - "10.0.0.1" # IP-adres van reverse proxy  allowRealIpFallback: false # standaard false; alleen inschakelen als je proxy geen X-Forwarded-For kan leveren  auth:    mode: password    password: ${OPENCLAW_GATEWAY_PASSWORD}

Wanneer trustedProxies is ingesteld, gebruikt de Gateway X-Forwarded-For om het client-IP-adres te bepalen; X-Real-IP wordt genegeerd tenzij gateway.allowRealIpFallback: true expliciet is ingesteld. Zorg dat je proxy X-Forwarded-For/X-Real-IP overschrijft in plaats van er waarden aan toe te voegen:

# goedproxy_set_header X-Forwarded-For $remote_addr;proxy_set_header X-Real-IP $remote_addr; # fout: behoudt/voegt niet-vertrouwde, door de client aangeleverde waarden toeproxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Vertrouwde proxyheaders zorgen er niet voor dat apparaatkoppeling van nodes automatisch wordt vertrouwd; gateway.nodes.pairing.autoApproveCidrs is een afzonderlijk operatorbeleid dat standaard is uitgeschakeld, en paden met vertrouwde proxyheaders vanuit een loopbackbron blijven uitgesloten van automatische nodegoedkeuring, zelfs wanneer authenticatie via een vertrouwde loopbackproxy is ingeschakeld (omdat lokale aanroepers die headers kunnen vervalsen).

Opmerkingen over HSTS en oorsprong

• De gateway van OpenClaw is primair bedoeld voor lokaal/loopbackgebruik. Als je TLS bij een reverse proxy beëindigt, stel je HSTS daar in.
• Als de gateway zelf HTTPS beëindigt, voegt gateway.http.securityHeaders.strictTransportSecurity de HSTS-header toe aan antwoorden van OpenClaw.
• Voor implementaties van de Control UI buiten loopback is standaard gateway.controlUi.allowedOrigins vereist; allowedOrigins: ["*"] is een expliciet beleid dat alles toestaat, geen geharde standaardinstelling. Vermijd dit buiten streng gecontroleerde lokale tests.
• Mislukte browserauthenticatie vanaf loopback blijft onderworpen aan snelheidsbeperking, zelfs wanneer de algemene loopbackvrijstelling is ingeschakeld, maar de blokkeringssleutel wordt per genormaliseerde Origin-waarde afgebakend in plaats van één gedeelde localhostgroep.
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true schakelt de terugvalmodus voor oorsprong via de Host-header in; behandel dit als een gevaarlijk, door de operator geselecteerd beleid.
• Beschouw DNS-rebinding en het gedrag van proxyhostheaders als aandachtspunten voor het beveiligen van de implementatie; houd trustedProxies strikt en stel de gateway niet rechtstreeks bloot aan het openbare internet.
• Gedetailleerde implementatierichtlijnen: Authenticatie met vertrouwde proxy.

Control UI via HTTP

De Control UI heeft een beveiligde context (HTTPS of localhost) nodig om een apparaatidentiteit te genereren.

• gateway.controlUi.allowInsecureAuth: lokale compatibiliteitsschakelaar. Staat op localhost authenticatie van de Control UI zonder apparaatidentiteit toe wanneer de pagina via onbeveiligde HTTP wordt geladen. Omzeilt koppelingscontroles niet en versoepelt de vereisten voor apparaatidentiteit op afstand (buiten localhost) niet. Gebruik bij voorkeur HTTPS (Tailscale Serve) of open de UI op 127.0.0.1.
• gateway.controlUi.dangerouslyDisableDeviceAuth: buiten gebruik gestelde noodinvoer. Oudere configuraties behouden geauthenticeerde Control UI-toegang uitsluitend voor koppeling om herstel mogelijk te maken, totdat een browser die opnieuw via HTTPS of localhost is geopend de begrensde, expliciete migratie voor zelfkoppeling voltooit; voeg dit niet toe aan de huidige configuratie.
• Los van deze vlaggen kan een geslaagde gateway.auth.mode: "trusted-proxy" operator-sessies van de Control UI zonder apparaatidentiteit toelaten. Dit is bewust gedrag van de authenticatiemodus, geen allowInsecureAuth-snelkoppeling, en geldt niet voor Control UI-sessies met de noderol.

openclaw security audit waarschuwt wanneer allowInsecureAuth is ingeschakeld.

Onveilige/gevaarlijke vlaggen

openclaw security audit rapporteert config.insecure_or_dangerous_flags voor elke ingeschakelde bekende onveilige/gevaarlijke foutopsporingsschakelaar (één bevinding per vlag). Laat deze in productie uitgeschakeld. Als auditonderdrukkingen zijn geconfigureerd, blijft security.audit.suppressions.active in de actieve uitvoer staan, zelfs wanneer overeenkomende bevindingen naar suppressedFindings worden verplaatst.

Vertrouwen in implementatie en host

• Volledige schijfversleuteling op de Gateway-host; gebruik bij voorkeur een speciaal OS-gebruikersaccount voor de Gateway als de host wordt gedeeld.
• Vergrendeling van afhankelijkheden voor gepubliceerde pakketten: broncodecheck-outs gebruiken pnpm-lock.yaml; het gepubliceerde npm-pakket openclaw en npm-pluginpakketten van OpenClaw bevatten npm-shrinkwrap.json, zodat installaties de beoordeelde transitieve afhankelijkheidsgraaf van de release gebruiken in plaats van tijdens de installatie een nieuwe graaf op te lossen. Dit vormt een grens voor versterking van de toeleveringsketen en reproduceerbaarheid van releases, geen sandbox — zie npm-shrinkwrap.
• Veilige bestandsbewerkingen: OpenClaw gebruikt @openclaw/fs-safe voor tot de hoofdmap begrensde bestandstoegang, atomaire schrijfbewerkingen, archiefextractie, tijdelijke werkruimten en helpers voor geheime bestanden. De optionele POSIX Python-helper staat standaard uit; stel OPENCLAW_FS_SAFE_PYTHON_MODE=auto of require alleen in als je de extra versterking van fd-relatieve wijzigingen wilt en een Python-runtime kunt ondersteunen. Details: Veilige bestandsbewerkingen.
• Risico van een gedeelde Slack-werkruimte: als iedereen in Slack berichten naar de bot kan sturen, is het belangrijkste risico gedelegeerde bevoegdheid voor tools — elke toegestane afzender kan binnen het beleid van de agent toolaanroepen activeren (exec, browser-, netwerk- en bestandstools), prompt- of inhoudsinjectie door één afzender kan gedeelde status, apparaten en uitvoer beïnvloeden, en als de gedeelde agent toegang heeft tot gevoelige aanmeldgegevens of bestanden, kan elke toegestane afzender mogelijk via toolgebruik exfiltratie aansturen. Gebruik voor teamwerkstromen afzonderlijke agents/Gateways met minimale tools; houd agents met persoonsgegevens privé.
• Bedrijfsgedeelde agent (aanvaardbaar patroon): geschikt wanneer iedereen die de agent gebruikt binnen dezelfde vertrouwensgrens valt (bijvoorbeeld één bedrijfsteam) en de agent strikt tot bedrijfsdoeleinden is beperkt. Voer deze uit op een speciale machine/VM/container, gebruik een speciaal OS-gebruikersaccount en speciale browser/profiel/accounts, en meld die runtime niet aan bij persoonlijke Apple-/Google-accounts of persoonlijke wachtwoordbeheerder-/browserprofielen. Door persoonlijke en bedrijfsidentiteiten in dezelfde runtime te combineren, verdwijnt de scheiding en neemt het risico op blootstelling van persoonsgegevens toe.

Geheimen op schijf

Ga ervan uit dat alles onder ~/.openclaw/ (of $OPENCLAW_STATE_DIR/) geheimen of privégegevens kan bevatten:

Overzicht van credentialopslag

Ook nuttig voor beslissingen over back-ups:

• WhatsApp: ~/.openclaw/credentials/whatsapp/<accountId>/creds.json
• Telegram-bottoken: configuratie/omgeving of channels.telegram.tokenFile (alleen regulier bestand; symbolische koppelingen worden geweigerd)
• Discord-bottoken: configuratie/omgeving of SecretRef (env/file/exec-providers)
• Slack-tokens: configuratie/omgeving (channels.slack.*)
• Koppelingslijsten met toegestane items: ~/.openclaw/credentials/<channel>-allowFrom.json (standaardaccount) / <channel>-<accountId>-allowFrom.json (niet-standaardaccounts)
• Modelauthenticatieprofielen: ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite (auth_profile_store)
• MCP OAuth-sessies: ~/.openclaw/state/openclaw.sqlite (mcp_oauth_stores)
• Import van verouderde OAuth-gegevens: ~/.openclaw/credentials/oauth.json

Versterking: houd de machtigingen strikt (700 voor mappen, 600 voor bestanden); gebruik volledige schijfversleuteling op de Gateway-host; geef de voorkeur aan een afzonderlijk OS-gebruikersaccount als de host wordt gedeeld.

Bestandsmachtigingen

• ~/.openclaw/openclaw.json: 600 (alleen lezen/schrijven door de gebruiker)
• ~/.openclaw: 700 (alleen de gebruiker)

openclaw doctor kan waarschuwen en aanbieden deze aan te scherpen.

Werkruimtebestanden .env

OpenClaw laadt werkruimtelokale .env-bestanden voor agents en tools, maar staat nooit toe dat deze stilzwijgend de runtime-instellingen van de Gateway overschrijven:

• Omgevingsvariabelen met providercredentials worden geblokkeerd in niet-vertrouwde .env-bestanden van de werkruimte, bijvoorbeeld GEMINI_API_KEY, GOOGLE_API_KEY, XAI_API_KEY, MISTRAL_API_KEY, GROQ_API_KEY, DEEPSEEK_API_KEY, PERPLEXITY_API_KEY, BRAVE_API_KEY, TAVILY_API_KEY, EXA_API_KEY, FIRECRAWL_API_KEY en providerauthenticatiesleutels die door geïnstalleerde vertrouwde plugins zijn gedeclareerd. Plaats providercredentials in plaats daarvan in de procesomgeving van de Gateway, ~/.openclaw/.env ($OPENCLAW_STATE_DIR/.env), het configuratieblok env of een optionele import vanuit de login-shell.
• Elke sleutel die begint met OPENCLAW_ wordt geblokkeerd in niet-vertrouwde .env-bestanden van de werkruimte. Hiermee wordt de volledige runtime-naamruimte gereserveerd, zodat een toekomstige OPENCLAW_*-instelling standaard fail-closed is in plaats van stilzwijgend te kunnen worden overgenomen uit ingecheckte of door een aanvaller aangeleverde .env-inhoud.
• Instellingen voor eindpuntroutering van kanalen en providers worden eveneens geblokkeerd voor overschrijvingen vanuit .env-bestanden van de werkruimte (bijvoorbeeld MATRIX_HOMESERVER, MATTERMOST_URL, IRC_HOST, SYNOLOGY_CHAT_INCOMING_URL, AZURE_SPEECH_ENDPOINT en andere sleutels die eindigen op _ENDPOINT), zodat een gekloonde werkruimte het verkeer van meegeleverde connectors niet via een lokale eindpuntconfiguratie kan omleiden. Deze moeten afkomstig zijn uit de procesomgeving van de Gateway, de globale runtime-dotenv, expliciete configuratie of env.shellEnv.
• Vertrouwde proces-/OS-omgevingsvariabelen, de globale runtime-dotenv, configuratie env en ingeschakelde import vanuit de login-shell blijven van toepassing; dit beperkt alleen het laden van .env-bestanden uit de werkruimte.

.env-bestanden van de werkruimte staan vaak naast agentcode, worden per ongeluk vastgelegd of door tools geschreven; het blokkeren van providercredentials voorkomt dat een gekloonde werkruimte door een aanvaller beheerde provideraccounts kan gebruiken ter vervanging.

Logboeken en transcripties

OpenClaw slaat sessietranscripties op schijf op onder ~/.openclaw/agents/<agentId>/sessions/*.jsonl voor sessiecontinuïteit en optionele geheugenindexering; elk proces en elke gebruiker met toegang tot het bestandssysteem kan ze lezen. Beschouw schijftoegang als de vertrouwensgrens en beperk de machtigingen voor ~/.openclaw; voer agents uit onder afzonderlijke OS-gebruikers of op afzonderlijke hosts voor sterkere isolatie.

Gateway-logboeken kunnen toolsamenvattingen, fouten en URL's bevatten; sessietranscripties kunnen geplakte geheimen, bestandsinhoud, opdrachtuitvoer en links bevatten.

• Houd redactie van logboeken/transcripties ingeschakeld (logging.redactSensitive: "tools", standaard).
• Voeg via logging.redactPatterns aangepaste patronen voor je omgeving toe (tokens, hostnamen, interne URL's).
• Gebruik bij het delen van diagnostische gegevens bij voorkeur openclaw status --all (plakbaar, geheimen geredigeerd) in plaats van onbewerkte logboeken.
• Verwijder oude sessietranscripties en logbestanden als je ze niet langdurig hoeft te bewaren.

Details: Logboekregistratie

Veilige basisconfiguratie (kopiëren/plakken)

{  gateway: {    mode: "local",    bind: "loopback",    port: 18789,    auth: { mode: "token", token: "your-long-random-token" },  },  channels: {    whatsapp: {      dmPolicy: "pairing",      groups: { "*": { requireMention: true } },    },  },}

Houdt de Gateway privé, vereist koppeling voor privéberichten en voorkomt permanent actieve groepsbots. Voeg voor veiligere tooluitvoering ook een sandbox toe en weiger gevaarlijke tools voor elke agent die niet de eigenaar is (zie 'Toegangsprofielen per agent' hierboven).

Afzonderlijke nummers (WhatsApp, Signal, Telegram)

Overweeg voor kanalen op basis van telefoonnummers de assistent op een ander nummer dan je persoonlijke nummer uit te voeren, zodat persoonlijke gesprekken privé blijven en het botnummer automatisering binnen zijn eigen grenzen afhandelt.

Reactie op incidenten

Inperken

1. Stop het: stop de macOS-app (als deze toezicht houdt op de Gateway) of beëindig je openclaw gateway-proces.
2. Sluit de blootstelling af: stel gateway.bind: "loopback" in (of schakel Tailscale Funnel/Serve uit) totdat je begrijpt wat er is gebeurd.
3. Blokkeer toegang: zet riskante privéberichten/groepen op dmPolicy: "disabled" / vereis vermeldingen en verwijder alle "*"-vermeldingen die alles toestaan.

Roteren (ga uit van compromittering als geheimen zijn gelekt)

1. Roteer de Gateway-authenticatie (gateway.auth.token / OPENCLAW_GATEWAY_PASSWORD) en start opnieuw.
2. Roteer geheimen van externe clients (gateway.remote.token / .password) op elke machine die de Gateway kan aanroepen.
3. Roteer provider-/API-credentials (WhatsApp-credentials, Slack-/Discord-tokens, model-/API-sleutels in auth-profiles.json en versleutelde waarden in geheime payloads wanneer die worden gebruikt).

Controleren

1. Controleer Gateway-logboeken met openclaw logs (of openclaw --profile <profile> logs voor een benoemd profiel). Het standaardpad is /tmp/openclaw/openclaw-YYYY-MM-DD.log; benoemde profielen gebruiken /tmp/openclaw/openclaw-<profile>-YYYY-MM-DD.log, tenzij logging.file dit overschrijft.
2. Controleer de relevante transcriptie(s): ~/.openclaw/agents/<agentId>/sessions/*.jsonl.
3. Controleer recente configuratiewijzigingen die de toegang kunnen hebben verruimd: gateway.bind, gateway.auth, beleid voor privéberichten/groepen, tools.elevated, wijzigingen aan plugins.
4. Voer openclaw security audit --deep opnieuw uit en bevestig dat kritieke bevindingen zijn opgelost.

Verzamelen voor een rapport

• Tijdstempel, OS van de Gateway-host + OpenClaw-versie.
• De sessietranscriptie(s) + een kort logboekfragment (na redactie).
• Wat de aanvaller heeft verzonden en wat de agent heeft gedaan.
• Of de Gateway buiten loopback toegankelijk was (LAN/Tailscale Funnel/Serve).

Scannen op geheimen

CI voert de pre-commit-hook detect-private-key uit over de repository. Als deze mislukt, verwijder of roteer dan het vastgelegde sleutelmateriaal en reproduceer het probleem vervolgens lokaal:

pre-commit run --all-files detect-private-key

Beveiligingsproblemen melden

Een kwetsbaarheid in OpenClaw gevonden? Meld deze op verantwoorde wijze:

1. E-mail: security@openclaw.ai
2. Publiceer niets voordat het probleem is opgelost.
3. We zullen je vermelden (tenzij je liever anoniem blijft).