--- read_when: - Functies toevoegen die toegang of automatisering uitbreiden summary: Beveiligingsoverwegingen en dreigingsmodel voor het draaien van een AI-Gateway met shelltoegang title: Beveiliging x-i18n: generated_at: "2026-05-11T20:32:27Z" model: gpt-5.5 provider: openai source_hash: dc25981e46229a6fabe72d70222953e84fcb6a0b19792e9849c4e05de7c266bb source_path: gateway/security/index.md workflow: 16 --- **Vertrouwensmodel voor persoonlijke assistent.** Deze richtlijn gaat uit van één vertrouwde operatorgrens per gateway (single-user, persoonlijke-assistentmodel). OpenClaw is **geen** vijandige multi-tenant beveiligingsgrens voor meerdere vijandige gebruikers die één agent of gateway delen. Als je werking met gemengd vertrouwen of vijandige gebruikers nodig hebt, splits dan vertrouwensgrenzen (aparte gateway + inloggegevens, idealiter aparte OS-gebruikers of hosts). ## Eerst de scope: beveiligingsmodel voor persoonlijke assistent OpenClaw-beveiligingsrichtlijnen gaan uit van een **persoonlijke assistent**-implementatie: één vertrouwde operatorgrens, mogelijk veel agents. - Ondersteunde beveiligingshouding: één gebruiker/vertrouwensgrens per gateway (bij voorkeur één OS-gebruiker/host/VPS per grens). - Geen ondersteunde beveiligingsgrens: één gedeelde gateway/agent die wordt gebruikt door onderling onvertrouwde of vijandige gebruikers. - Als isolatie voor vijandige gebruikers vereist is, splits dan per vertrouwensgrens (aparte gateway + inloggegevens, en idealiter aparte OS-gebruikers/hosts). - Als meerdere onvertrouwde gebruikers één agent met tools kunnen berichten, behandel hen dan alsof ze dezelfde gedelegeerde toolbevoegdheid voor die agent delen. Deze pagina legt hardening **binnen dat model** uit. Ze claimt geen vijandige multi-tenant-isolatie op één gedeelde gateway. ## Snelle controle: `openclaw security audit` Zie ook: [Formele verificatie (beveiligingsmodellen)](/nl/security/formal-verification) Voer dit regelmatig uit (vooral na het wijzigen van configuratie of het blootstellen van netwerkoppervlakken): ```bash openclaw security audit openclaw security audit --deep openclaw security audit --fix openclaw security audit --json ``` `security audit --fix` blijft bewust beperkt: het zet gangbare open groepsbeleid om naar allowlists, herstelt `logging.redactSensitive: "tools"`, scherpt machtigingen voor state/config/include-bestanden aan, en gebruikt Windows ACL-resets in plaats van POSIX `chmod` wanneer het op Windows draait. Het markeert veelvoorkomende valkuilen (blootstelling van Gateway-authenticatie, blootstelling van browserbesturing, verhoogde allowlists, bestandssysteemmachtigingen, permissieve exec-goedkeuringen en open-channel toolblootstelling). OpenClaw is zowel een product als een experiment: je koppelt frontier-modelgedrag aan echte berichtenoppervlakken en echte tools. **Er bestaat geen "perfect beveiligde" setup.** Het doel is om bewust om te gaan met: - wie met je bot kan praten - waar de bot mag handelen - wat de bot kan aanraken Begin met de kleinste toegang die nog werkt, en breid die daarna uit naarmate je vertrouwen groeit. ### Implementatie- en hostvertrouwen OpenClaw gaat ervan uit dat de host- en configuratiegrens vertrouwd zijn: - Als iemand Gateway-hoststatus/configuratie (`~/.openclaw`, inclusief `openclaw.json`) kan wijzigen, behandel die persoon dan als een vertrouwde operator. - Eén Gateway draaien voor meerdere onderling onvertrouwde/vijandige operators is **geen aanbevolen setup**. - Voor teams met gemengd vertrouwen: splits vertrouwensgrenzen met aparte gateways (of minimaal aparte OS-gebruikers/hosts). - Aanbevolen standaard: één gebruiker per machine/host (of VPS), één gateway voor die gebruiker, en één of meer agents in die gateway. - Binnen één Gateway-instantie is geauthenticeerde operatortoegang een vertrouwde control-plane-rol, geen per-user tenant-rol. - Sessie-identifiers (`sessionKey`, sessie-ID's, labels) zijn routingselectoren, geen autorisatietokens. - Als meerdere mensen één agent met tools kunnen berichten, kan ieder van hen dezelfde machtigingenset sturen. Per-user sessie-/geheugenisolatie helpt privacy, maar maakt van een gedeelde agent geen hostautorisatie per gebruiker. ### Beveiligde bestandsbewerkingen OpenClaw gebruikt `@openclaw/fs-safe` voor root-begrensde bestandstoegang, atomische writes, archiefextractie, tijdelijke workspaces en helpers voor geheime bestanden. OpenClaw zet de optionele POSIX Python-helper van fs-safe standaard **uit**; stel `OPENCLAW_FS_SAFE_PYTHON_MODE=auto` of `require` alleen in wanneer je de extra fd-relatieve mutatiehardening wilt en een Python-runtime kunt ondersteunen. Details: [Beveiligde bestandsbewerkingen](/nl/gateway/security/secure-file-operations). ### Gedeelde Slack-workspace: echt risico Als "iedereen in Slack de bot kan berichten", is het kernrisico gedelegeerde toolbevoegdheid: - elke toegestane afzender kan toolcalls (`exec`, browser, netwerk-/bestandstools) binnen het beleid van de agent uitlokken; - prompt-/contentinjectie van één afzender kan acties veroorzaken die gedeelde state, apparaten of uitvoer beïnvloeden; - als één gedeelde agent gevoelige inloggegevens/bestanden heeft, kan elke toegestane afzender mogelijk exfiltratie via toolgebruik aansturen. Gebruik aparte agents/gateways met minimale tools voor teamworkflows; houd agents met persoonlijke data privé. ### Bedrijfsgedeelde agent: acceptabel patroon Dit is acceptabel wanneer iedereen die die agent gebruikt zich binnen dezelfde vertrouwensgrens bevindt (bijvoorbeeld één bedrijfsteam) en de agent strikt zakelijk afgebakend is. - draai deze op een dedicated machine/VM/container; - gebruik een dedicated OS-gebruiker + dedicated browser/profiel/accounts voor die runtime; - meld die runtime niet aan bij persoonlijke Apple-/Google-accounts of persoonlijke wachtwoordmanager-/browserprofielen. Als je persoonlijke en bedrijfsidentiteiten op dezelfde runtime mengt, laat je de scheiding vervallen en vergroot je het risico op blootstelling van persoonlijke data. ## Vertrouwensconcept voor Gateway en node Behandel Gateway en node als één operatorvertrouwensdomein, met verschillende rollen: - **Gateway** is de control plane en het beleidsoppervlak (`gateway.auth`, toolbeleid, routing). - **Node** is een extern uitvoeringsoppervlak gekoppeld aan die Gateway (commando's, apparaat acties, host-local mogelijkheden). - Een caller die bij de Gateway is geauthenticeerd, wordt binnen Gateway-scope vertrouwd. Na koppeling zijn node-acties vertrouwde operatoracties op die node. - Operatorscope-niveaus en controles tijdens goedkeuring worden samengevat in [Operatorscopes](/nl/gateway/operator-scopes). - Directe loopback-backendclients die zijn geauthenticeerd met het gedeelde gateway token/wachtwoord kunnen interne control-plane-RPC's uitvoeren zonder een gebruikers- apparaatidentiteit te presenteren. Dit is geen omzeiling van remote of browser pairing: netwerk- clients, node-clients, device-tokenclients en expliciete apparaatidentiteiten blijven door pairing en scope-upgrade-afdwinging gaan. - `sessionKey` is routing-/contextselectie, geen per-user auth. - Exec-goedkeuringen (allowlist + vragen) zijn guardrails voor operatorintentie, geen vijandige multi-tenant-isolatie. - De productstandaard van OpenClaw voor vertrouwde single-operator-setups is dat host-exec op `gateway`/`node` zonder goedkeuringsprompts is toegestaan (`security="full"`, `ask="off"` tenzij je dit aanscherpt). Die standaard is bewuste UX, op zichzelf geen kwetsbaarheid. - Exec-goedkeuringen binden exacte requestcontext en best-effort directe lokale bestandsoperanden; ze modelleren niet semantisch elk runtime-/interpreter-loaderpad. Gebruik sandboxing en hostisolatie voor sterke grenzen. Als je isolatie voor vijandige gebruikers nodig hebt, splits vertrouwensgrenzen per OS-gebruiker/host en draai aparte gateways. ## Matrix van vertrouwensgrenzen Gebruik dit als snel model bij risicotriage: | Grens of controle | Wat het betekent | Veelvoorkomende misinterpretatie | | --------------------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------- | | `gateway.auth` (token/wachtwoord/trusted-proxy/device auth) | Authenticeert callers naar gateway-API's | "Heeft per-message signatures op elk frame nodig om veilig te zijn" | | `sessionKey` | Routingsleutel voor context-/sessieselectie | "Sessiesleutel is een gebruikersauthenticatiegrens" | | Prompt-/contentguardrails | Verminderen risico op modelmisbruik | "Promptinjectie alleen bewijst auth-omzeiling" | | `canvas.eval` / browser evaluate | Bewuste operatormogelijkheid wanneer ingeschakeld | "Elke JS-eval-primitive is automatisch een kwetsbaarheid in dit vertrouwensmodel" | | Lokale TUI `!` shell | Expliciet door operator getriggerde lokale uitvoering | "Handig local shell-commando is remote injection" | | Node-pairing en node-commando's | Remote uitvoering op operatorniveau op gekoppelde apparaten | "Remote apparaatbesturing moet standaard als onvertrouwde gebruikerstoegang worden behandeld" | | `gateway.nodes.pairing.autoApproveCidrs` | Opt-in inschrijfbeleid voor nodes op vertrouwd netwerk | "Een standaard uitgeschakelde allowlist is een automatische pairing-kwetsbaarheid" | ## Geen kwetsbaarheden by design Deze patronen worden vaak gerapporteerd en worden meestal zonder actie gesloten tenzij een echte grensomzeiling wordt aangetoond: - Alleen-promptinjectieketens zonder beleids-, auth- of sandboxomzeiling. - Claims die uitgaan van vijandige multi-tenant-werking op één gedeelde host of configuratie. - Claims die normale operator-read-path-toegang (bijvoorbeeld `sessions.list` / `sessions.preview` / `chat.history`) classificeren als IDOR in een gedeelde-gateway-setup. - Bevindingen voor localhost-only implementaties (bijvoorbeeld HSTS op een loopback-only gateway). - Bevindingen over Discord inbound webhook signatures voor inbound paden die niet in deze repo bestaan. - Rapporten die node-pairingmetadata behandelen als een verborgen tweede per-command goedkeuringslaag voor `system.run`, terwijl de echte uitvoeringsgrens nog steeds het globale node-commandobeleid van de gateway plus de eigen exec- goedkeuringen van de node is. - Rapporten die geconfigureerde `gateway.nodes.pairing.autoApproveCidrs` op zichzelf als een kwetsbaarheid behandelen. Deze instelling is standaard uitgeschakeld, vereist expliciete CIDR/IP-vermeldingen, geldt alleen voor eerste `role: node`-pairing met geen aangevraagde scopes, en keurt operator/browser/Control UI, WebChat, rolupgrades, scope-upgrades, metadatawijzigingen, public-key-wijzigingen, of same-host loopback trusted-proxy header-paden niet automatisch goed, tenzij loopback trusted-proxy auth expliciet was ingeschakeld. - Bevindingen over "ontbrekende per-user autorisatie" die `sessionKey` als een auth-token behandelen. ## Hardened baseline in 60 seconden Gebruik eerst deze baseline, en schakel daarna selectief tools opnieuw in per vertrouwde agent: ```json5 { 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 } } }, }, } ``` Dit houdt de Gateway alleen lokaal, isoleert DM's en schakelt control-plane-/runtime-tools standaard uit. ## Snelle regel voor gedeelde inbox Als meer dan één persoon je bot kan DM'en: - Stel `session.dmScope: "per-channel-peer"` in (of `"per-account-channel-peer"` voor multi-account channels). - Houd `dmPolicy: "pairing"` of strikte allowlists aan. - Combineer gedeelde DM's nooit met brede tooltoegang. - Dit hardent coöperatieve/gedeelde inboxen, maar is niet ontworpen als vijandige co-tenant-isolatie wanneer gebruikers host-/config-schrijftoegang delen. ## Model voor contextzichtbaarheid OpenClaw scheidt twee concepten: - **Triggerautorisatie**: wie de agent kan triggeren (`dmPolicy`, `groupPolicy`, allowlists, mention gates). - **Contextzichtbaarheid**: welke aanvullende context in modelinput wordt geïnjecteerd (antwoordtekst, geciteerde tekst, threadgeschiedenis, doorgestuurde metadata). Allowlists regelen triggers en commandoautorisatie. De instelling `contextVisibility` bepaalt hoe aanvullende context (geciteerde antwoorden, thread-roots, opgehaalde geschiedenis) wordt gefilterd: - `contextVisibility: "all"` (standaard) behoudt aanvullende context zoals ontvangen. - `contextVisibility: "allowlist"` filtert aanvullende context naar afzenders die zijn toegestaan door de actieve allowlist-controles. - `contextVisibility: "allowlist_quote"` gedraagt zich als `allowlist`, maar behoudt nog steeds een expliciet geciteerd antwoord. Stel `contextVisibility` in per kanaal of per ruimte/gesprek. Zie [Groepschats](/nl/channels/groups#context-visibility-and-allowlists) voor configuratiedetails. Richtlijnen voor triage van meldingen: - Claims die alleen aantonen dat "het model geciteerde of historische tekst van niet-geallowliste afzenders kan zien" zijn hardeningsbevindingen die met `contextVisibility` kunnen worden aangepakt, geen zelfstandige omzeilingen van auth- of sandboxgrenzen. - Om beveiligingsimpact te hebben, hebben rapporten nog steeds een aangetoonde omzeiling van een vertrouwensgrens nodig (auth, beleid, sandbox, goedkeuring of een andere gedocumenteerde grens). ## Wat de audit controleert (op hoog niveau) - **Inkomende toegang** (DM-beleid, groepsbeleid, allowlists): kunnen vreemden de bot activeren? - **Blast radius van tools** (verhoogde tools + open ruimtes): kan promptinjectie veranderen in shell-/bestand-/netwerkacties? - **Drift in exec-bestandssysteem**: worden muterende bestandssysteemtools geweigerd terwijl `exec`/`process` beschikbaar blijven zonder sandbox-bestandssysteembeperkingen? - **Drift in exec-goedkeuring** (`security=full`, `autoAllowSkills`, interpreter-allowlists zonder `strictInlineEval`): doen host-exec-guardrails nog steeds wat je denkt dat ze doen? - `security="full"` is een brede houdingswaarschuwing, geen bewijs van een bug. Het is de gekozen standaard voor vertrouwde personal-assistant-configuraties; verscherp dit alleen wanneer je dreigingsmodel goedkeurings- of allowlist-guardrails nodig heeft. - **Netwerkblootstelling** (Gateway bind/auth, Tailscale Serve/Funnel, zwakke/korte auth-tokens). - **Blootstelling van browserbesturing** (externe nodes, relay-poorten, externe CDP-eindpunten). - **Hygiëne van lokale schijf** (machtigingen, symlinks, config-includes, paden naar "gesynchroniseerde map"). - **Plugins** (plugins laden zonder expliciete allowlist). - **Beleidsdrift/misconfiguratie** (sandbox-dockerinstellingen geconfigureerd maar sandboxmodus uit; ineffectieve `gateway.nodes.denyCommands`-patronen omdat matching alleen op exacte commandonaam gebeurt (bijvoorbeeld `system.run`) en shelltekst niet inspecteert; gevaarlijke `gateway.nodes.allowCommands`-vermeldingen; globale `tools.profile="minimal"` overschreven door profielen per agent; tools die eigendom zijn van plugins bereikbaar onder permissief toolbeleid). - **Drift in runtimeverwachtingen** (bijvoorbeeld aannemen dat impliciete exec nog steeds `sandbox` betekent wanneer `tools.exec.host` nu standaard `auto` is, of expliciet `tools.exec.host="sandbox"` instellen terwijl sandboxmodus uit staat). - **Modelhygiëne** (waarschuw wanneer geconfigureerde modellen verouderd lijken; geen harde blokkade). Als je `--deep` uitvoert, probeert OpenClaw ook een best-effort live Gateway-probe. ## Overzicht van opslag van referenties Gebruik dit bij het auditen van toegang of beslissen waarvan je een back-up maakt: - **WhatsApp**: `~/.openclaw/credentials/whatsapp//creds.json` - **Telegram-bottoken**: config/env of `channels.telegram.tokenFile` (alleen regulier bestand; symlinks geweigerd) - **Discord-bottoken**: config/env of SecretRef (env/file/exec-providers) - **Slack-tokens**: config/env (`channels.slack.*`) - **Pairing-allowlists**: - `~/.openclaw/credentials/-allowFrom.json` (standaardaccount) - `~/.openclaw/credentials/--allowFrom.json` (niet-standaardaccounts) - **Model-auth-profielen**: `~/.openclaw/agents//agent/auth-profiles.json` - **Codex-runtime-status**: `~/.openclaw/agents//agent/codex-home/` - **Bestandsgebaseerde secrets-payload (optioneel)**: `~/.openclaw/secrets.json` - **Legacy OAuth-import**: `~/.openclaw/credentials/oauth.json` ## Checklist voor beveiligingsaudit Wanneer de audit bevindingen afdrukt, behandel dit als prioriteitsvolgorde: 1. **Alles wat "open" is + tools ingeschakeld**: vergrendel eerst DM's/groepen (pairing/allowlists) en verscherp daarna toolbeleid/sandboxing. 2. **Publieke netwerkblootstelling** (LAN-bind, Funnel, ontbrekende auth): onmiddellijk oplossen. 3. **Externe blootstelling van browserbesturing**: behandel dit als operatortoegang (alleen tailnet, pair nodes bewust, vermijd publieke blootstelling). 4. **Machtigingen**: zorg dat status/config/referenties/auth niet leesbaar zijn voor groep/wereld. 5. **Plugins**: laad alleen wat je expliciet vertrouwt. 6. **Modelkeuze**: geef de voorkeur aan moderne, instructiegeharde modellen voor elke bot met tools. ## Woordenlijst voor beveiligingsaudit Elke auditbevinding wordt geïdentificeerd door een gestructureerde `checkId` (bijvoorbeeld `gateway.bind_no_auth` of `tools.exec.security_full_configured`). Veelvoorkomende kritieke ernstklassen: - `fs.*` - bestandssysteemmachtigingen op status, config, referenties, auth-profielen. - `gateway.*` - bindmodus, auth, Tailscale, Control UI, vertrouwde-proxyconfiguratie. - `hooks.*`, `browser.*`, `sandbox.*`, `tools.exec.*` - hardening per oppervlak. - `plugins.*`, `skills.*` - bevindingen over plugin-/skill-toeleveringsketen en scans. - `security.exposure.*` - doorsnijdende controles waar toegangsbeleid de blast radius van tools raakt. Zie de volledige catalogus met ernstniveaus, fix-sleutels en ondersteuning voor auto-fix op [Controles voor beveiligingsaudit](/nl/gateway/security/audit-checks). ## Control UI via HTTP De Control UI heeft een **beveiligde context** (HTTPS of localhost) nodig om apparaatidentiteit te genereren. `gateway.controlUi.allowInsecureAuth` is een lokale compatibiliteitsschakelaar: - Op localhost staat dit Control UI-auth toe zonder apparaatidentiteit wanneer de pagina via niet-beveiligde HTTP wordt geladen. - Het omzeilt pairing-controles niet. - Het versoepelt vereisten voor apparaatidentiteit op afstand (niet-localhost) niet. Geef de voorkeur aan HTTPS (Tailscale Serve) of open de UI op `127.0.0.1`. Alleen voor break-glass-scenario's schakelt `gateway.controlUi.dangerouslyDisableDeviceAuth` controles op apparaatidentiteit volledig uit. Dit is een ernstige beveiligingsdowngrade; laat dit uit tenzij je actief debugt en snel kunt terugdraaien. Los van die gevaarlijke flags kunnen succesvolle `gateway.auth.mode: "trusted-proxy"`- sessies **operator** Control UI-sessies toelaten zonder apparaatidentiteit. Dat is bedoeld auth-modusgedrag, geen `allowInsecureAuth`-shortcut, en het geldt nog steeds niet voor Control UI-sessies met node-rol. `openclaw security audit` waarschuwt wanneer deze instelling is ingeschakeld. ## Samenvatting van onveilige of gevaarlijke flags `openclaw security audit` meldt `config.insecure_or_dangerous_flags` wanneer bekende onveilige/gevaarlijke debugschakelaars zijn ingeschakeld. Laat deze uitgeschakeld in productie. - `gateway.controlUi.allowInsecureAuth=true` - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` - `gateway.controlUi.dangerouslyDisableDeviceAuth=true` - `hooks.gmail.allowUnsafeExternalContent=true` - `hooks.mappings[].allowUnsafeExternalContent=true` - `tools.exec.applyPatch.workspaceOnly=false` - `plugins.entries.acpx.config.permissionMode=approve-all` Control UI en browser: - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback` - `gateway.controlUi.dangerouslyDisableDeviceAuth` - `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` Kanaal-naammatching (gebundelde kanalen en plugin-kanalen; ook beschikbaar per `accounts.` waar van toepassing): - `channels.discord.dangerouslyAllowNameMatching` - `channels.slack.dangerouslyAllowNameMatching` - `channels.googlechat.dangerouslyAllowNameMatching` - `channels.msteams.dangerouslyAllowNameMatching` - `channels.synology-chat.dangerouslyAllowNameMatching` (plugin-kanaal) - `channels.synology-chat.dangerouslyAllowInheritedWebhookPath` (plugin-kanaal) - `channels.zalouser.dangerouslyAllowNameMatching` (plugin-kanaal) - `channels.irc.dangerouslyAllowNameMatching` (plugin-kanaal) - `channels.mattermost.dangerouslyAllowNameMatching` (plugin-kanaal) Netwerkblootstelling: - `channels.telegram.network.dangerouslyAllowPrivateNetwork` (ook per account) Sandbox Docker (standaarden + per agent): - `agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets` - `agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources` - `agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin` ## Reverse-proxyconfiguratie Als je de Gateway achter een reverse proxy draait (nginx, Caddy, Traefik, enz.), configureer `gateway.trustedProxies` voor correcte verwerking van doorgestuurde client-IP's. Wanneer de Gateway proxyheaders detecteert vanaf een adres dat **niet** in `trustedProxies` staat, behandelt hij verbindingen **niet** als lokale clients. Als gateway-auth is uitgeschakeld, worden die verbindingen geweigerd. Dit voorkomt authenticatie-omzeiling waarbij geproxiede verbindingen anders vanaf localhost zouden lijken te komen en automatisch vertrouwen zouden krijgen. `gateway.trustedProxies` voedt ook `gateway.auth.mode: "trusted-proxy"`, maar die auth-modus is strenger: - trusted-proxy-auth **faalt standaard gesloten bij loopback-bronproxy's** - same-host loopback reverse proxies kunnen `gateway.trustedProxies` gebruiken voor lokale-clientdetectie en verwerking van doorgestuurde IP's - same-host loopback reverse proxies kunnen alleen voldoen aan `gateway.auth.mode: "trusted-proxy"` wanneer `gateway.auth.trustedProxy.allowLoopback = true`; gebruik anders token-/wachtwoordauth ```yaml gateway: trustedProxies: - "10.0.0.1" # reverse proxy IP # Optional. Default false. # Only enable if your proxy cannot provide X-Forwarded-For. allowRealIpFallback: false auth: mode: password password: ${OPENCLAW_GATEWAY_PASSWORD} ``` Wanneer `trustedProxies` is geconfigureerd, gebruikt de Gateway `X-Forwarded-For` om het client-IP te bepalen. `X-Real-IP` wordt standaard genegeerd tenzij `gateway.allowRealIpFallback: true` expliciet is ingesteld. Vertrouwde proxyheaders maken node-apparaatpairing niet automatisch vertrouwd. `gateway.nodes.pairing.autoApproveCidrs` is een afzonderlijk, standaard uitgeschakeld operatorbeleid. Zelfs wanneer dit is ingeschakeld, worden headerpaden van vertrouwde proxy's met loopback-bron uitgesloten van automatische node-goedkeuring, omdat lokale aanroepers die headers kunnen vervalsen, ook wanneer loopback trusted-proxy-auth expliciet is ingeschakeld. Goed reverse-proxygedrag (inkomende forwardingheaders overschrijven): ```nginx proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; ``` Slecht reverse-proxygedrag (niet-vertrouwde forwardingheaders toevoegen/behouden): ```nginx proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ``` ## HSTS- en origin-opmerkingen - OpenClaw-gateway is eerst lokaal/local loopback. Als je TLS op een reverse proxy beëindigt, stel HSTS daar in op het proxy-gerichte HTTPS-domein. - Als de gateway zelf HTTPS beëindigt, kun je `gateway.http.securityHeaders.strictTransportSecurity` instellen om de HSTS-header uit OpenClaw-antwoorden te verzenden. - Gedetailleerde implementatierichtlijnen staan in [Trusted Proxy Auth](/nl/gateway/trusted-proxy-auth#tls-termination-and-hsts). - Voor niet-loopback Control UI-implementaties is `gateway.controlUi.allowedOrigins` standaard vereist. - `gateway.controlUi.allowedOrigins: ["*"]` is een expliciet alles-toestaanbeleid voor browser-origins, geen geharde standaard. Vermijd dit buiten strikt gecontroleerde lokale tests. - Auth-fouten voor browser-origin op loopback blijven rate-limited, zelfs wanneer de algemene loopback-vrijstelling is ingeschakeld, maar de lockout-sleutel is gescoped per genormaliseerde `Origin`-waarde in plaats van een gedeelde localhost-bucket. - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` schakelt Host-header-origin-fallbackmodus in; behandel dit als gevaarlijk door de operator gekozen beleid. - Behandel DNS-rebinding en proxy-hostheadergedrag als aandachtspunten voor implementatiehardening; houd `trustedProxies` strak en vermijd directe blootstelling van de gateway aan het publieke internet. ## Lokale sessielogs staan op schijf OpenClaw slaat sessietranscripten op schijf op onder `~/.openclaw/agents//sessions/*.jsonl`. Dit is vereist voor sessiecontinuiteit en (optioneel) indexering van sessiegeheugen, maar het betekent ook dat **elk proces/elke gebruiker met bestandssysteemtoegang die logs kan lezen**. Behandel schijftoegang als de vertrouwensgrens en vergrendel de rechten op `~/.openclaw` (zie de auditsectie hieronder). Als je sterkere isolatie tussen agents nodig hebt, voer ze dan uit onder aparte OS-gebruikers of op aparte hosts. ## Node-uitvoering (system.run) Als een macOS-node is gekoppeld, kan de Gateway `system.run` op die node aanroepen. Dit is **uitvoering van externe code** op de Mac: - Vereist nodekoppeling (goedkeuring + token). - Gateway-nodekoppeling is geen goedkeuringsoppervlak per opdracht. Het stelt node-identiteit/vertrouwen en tokenuitgifte vast. - De Gateway past een grofmazig globaal node-opdrachtbeleid toe via `gateway.nodes.allowCommands` / `denyCommands`. - Beheerd op de Mac via **Settings → Exec approvals** (beveiliging + vragen + allowlist). - Het `system.run`-beleid per node is het eigen exec-goedkeuringsbestand van de node (`exec.approvals.node.*`), dat strenger of minder streng kan zijn dan het globale opdracht-ID-beleid van de Gateway. - Een node die draait met `security="full"` en `ask="off"` volgt het standaardmodel voor vertrouwde operators. Behandel dat als verwacht gedrag tenzij je deployment expliciet een strakkere goedkeurings- of allowlist-houding vereist. - Goedkeuringsmodus bindt de exacte aanvraagcontext en, waar mogelijk, een concreet lokaal script-/bestandoperand. Als OpenClaw niet precies een direct 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 runs op basis van goedkeuring ook een canoniek voorbereide `systemRunPlan` op; latere goedgekeurde forwards hergebruiken dat opgeslagen plan, en gateway- validatie weigert wijzigingen door de aanroeper aan opdracht/cwd/sessiecontext nadat de goedkeuringsaanvraag is aangemaakt. - Als je geen externe uitvoering wilt, zet beveiliging dan op **weigeren** en verwijder nodekoppeling voor die Mac. Dit onderscheid is belangrijk voor triage: - Een opnieuw verbindende gekoppelde node die een andere opdrachtenlijst adverteert, is op zichzelf geen kwetsbaarheid als het globale Gateway-beleid en de lokale exec-goedkeuringen van de node nog steeds de feitelijke uitvoeringsgrens afdwingen. - Rapporten die nodekoppelingsmetadata behandelen als een tweede verborgen goedkeuringslaag per opdracht zijn meestal verwarring over beleid/UX, geen omzeiling van een beveiligingsgrens. ## Dynamische Skills (watcher / externe nodes) OpenClaw kan de Skills-lijst tijdens een sessie verversen: - **Skills-watcher**: wijzigingen in `SKILL.md` kunnen de Skills-snapshot bij de volgende agentbeurt bijwerken. - **Externe nodes**: het verbinden van een macOS-node kan macOS-only Skills geschikt maken (op basis van bin-probing). Behandel Skills-mappen als **vertrouwde code** en beperk wie ze kan wijzigen. ## Het dreigingsmodel Je AI-assistent kan: - Willekeurige shellopdrachten uitvoeren - Bestanden lezen/schrijven - Toegang krijgen tot netwerkservices - Berichten naar iedereen sturen (als je hem WhatsApp-toegang geeft) Mensen die je berichten sturen, kunnen: - Proberen je AI te misleiden om slechte dingen te doen - Toegang tot je gegevens social-engineeren - Naar infrastructuurdetails peilen ## Kernconcept: toegangscontrole vóór intelligentie De meeste mislukkingen hier zijn geen geavanceerde exploits - het zijn gevallen van "iemand stuurde de bot een bericht en de bot deed wat werd gevraagd." De houding van OpenClaw: - **Eerst identiteit:** bepaal wie met de bot mag praten (DM-koppeling / allowlists / expliciet "open"). - **Daarna bereik:** bepaal waar de bot mag handelen (groeps-allowlists + mention-gating, tools, sandboxing, apparaatrechten). - **Als laatste model:** neem aan dat het model kan worden gemanipuleerd; ontwerp zo dat manipulatie een beperkte impact heeft. ## Model voor opdracht-autorisatie Slash-commando's en directives worden alleen gehonoreerd voor **geautoriseerde afzenders**. Autorisatie wordt afgeleid van kanaal-allowlists/koppeling plus `commands.useAccessGroups` (zie [Configuratie](/nl/gateway/configuration) en [Slash-commando's](/nl/tools/slash-commands)). Als een kanaal-allowlist leeg is of `"*"` bevat, staan opdrachten feitelijk open voor dat kanaal. `/exec` is alleen een sessiegerichte voorziening voor geautoriseerde operators. Het schrijft **geen** configuratie en wijzigt geen andere sessies. ## Risico van control-plane-tools Twee ingebouwde tools kunnen blijvende control-plane-wijzigingen maken: - `gateway` kan configuratie inspecteren met `config.schema.lookup` / `config.get`, en kan blijvende wijzigingen aanbrengen met `config.apply`, `config.patch` en `update.run`. - `cron` kan geplande taken maken die blijven draaien nadat de oorspronkelijke chat/taak is geeindigd. De owner-only runtime-tool `gateway` weigert nog steeds `tools.exec.ask` of `tools.exec.security` te herschrijven; legacy `tools.bash.*`-aliassen worden genormaliseerd naar dezelfde beschermde exec-paden voordat er wordt geschreven. Door agents aangestuurde bewerkingen met `gateway config.apply` en `gateway config.patch` zijn standaard fail-closed: alleen een smalle set prompt-, model- en mention-gating- paden is door agents instelbaar. Nieuwe gevoelige configuratiebomen zijn daarom beschermd tenzij ze bewust aan de allowlist worden toegevoegd. Weiger deze standaard voor elke agent/elk oppervlak dat onvertrouwde inhoud verwerkt: ```json5 { tools: { deny: ["gateway", "cron", "sessions_spawn", "sessions_send"], }, } ``` `commands.restart=false` blokkeert alleen herstartacties. Het schakelt `gateway`-configuratie-/updateacties niet uit. ## Plugins Plugins draaien **in-process** met de Gateway. Behandel ze als vertrouwde code: - Installeer alleen plugins uit bronnen die je vertrouwt. - Geef de voorkeur aan expliciete `plugins.allow`-allowlists. - Controleer pluginconfiguratie voordat je deze inschakelt. - Herstart de Gateway na pluginwijzigingen. - Als je plugins installeert of bijwerkt (`openclaw plugins install `, `openclaw plugins update `), behandel dat dan alsof je onvertrouwde code uitvoert: - Het installatiepad is de map per plugin onder de actieve plugin-installatieroot. - OpenClaw voert vóór installatie/update een ingebouwde scan op gevaarlijke code uit. `critical`-bevindingen blokkeren standaard. - npm- en git-plugininstallaties voeren convergentie van package-manager-afhankelijkheden alleen uit tijdens de expliciete installatie-/updateflow. Lokale paden en archieven worden behandeld als op zichzelf staande pluginpakketten; OpenClaw kopieert/verwijst ernaar zonder `npm install` uit te voeren. - Geef de voorkeur aan vastgepinde, exacte versies (`@scope/pkg@1.2.3`) en inspecteer de uitgepakte code op schijf voordat je deze inschakelt. - `--dangerously-force-unsafe-install` is alleen een break-glass-optie voor false positives van de ingebouwde scan bij plugin-installatie-/updateflows. Het omzeilt geen beleidsblokkades van plugin-`before_install`-hooks en omzeilt geen scanfouten. - Door Gateway ondersteunde installaties van Skills-afhankelijkheden volgen dezelfde gevaarlijk/verdacht-splitsing: ingebouwde `critical`-bevindingen blokkeren tenzij de aanroeper expliciet `dangerouslyForceUnsafeInstall` instelt, terwijl verdachte bevindingen nog steeds alleen waarschuwen. `openclaw skills install` blijft de aparte ClawHub-download-/installatieflow voor Skills. Details: [Plugins](/nl/tools/plugin) ## DM-toegangsmodel: koppeling, allowlist, open, uitgeschakeld Alle huidige DM-geschikte kanalen ondersteunen een DM-beleid (`dmPolicy` of `*.dm.policy`) dat inkomende DM's afschermt **voordat** het bericht wordt verwerkt: - `pairing` (standaard): onbekende afzenders ontvangen een korte koppelingscode en de bot negeert hun bericht totdat dit is goedgekeurd. Codes verlopen na 1 uur; herhaalde DM's verzenden pas opnieuw een code wanneer een nieuwe aanvraag is aangemaakt. Openstaande aanvragen zijn standaard beperkt tot **3 per kanaal**. - `allowlist`: onbekende afzenders worden geblokkeerd (geen koppelingshandshake). - `open`: sta iedereen toe een DM te sturen (publiek). **Vereist** dat de kanaal-allowlist `"*"` bevat (expliciete opt-in). - `disabled`: negeer inkomende DM's volledig. Goedkeuren via CLI: ```bash openclaw pairing list openclaw pairing approve ``` Details + bestanden op schijf: [Koppeling](/nl/channels/pairing) ## Isolatie van DM-sessies (multi-usermodus) Standaard routeert OpenClaw **alle DM's naar de hoofdsessie** zodat je assistent continuiteit heeft over apparaten en kanalen heen. Als **meerdere mensen** de bot kunnen DM'en (open DM's of een allowlist met meerdere personen), overweeg dan DM-sessies te isoleren: ```json5 { session: { dmScope: "per-channel-peer" }, } ``` Dit voorkomt contextlekkage tussen gebruikers terwijl groepschats geisoleerd blijven. Dit is een grens voor berichtcontext, geen host-admin-grens. Als gebruikers onderling vijandig zijn en dezelfde Gateway-host/config delen, draai dan in plaats daarvan aparte gateways per vertrouwensgrens. ### Veilige DM-modus (aanbevolen) Behandel het fragment hierboven als **veilige DM-modus**: - Standaard: `session.dmScope: "main"` (alle DM's delen een sessie voor continuiteit). - Standaard bij lokale CLI-onboarding: schrijft `session.dmScope: "per-channel-peer"` wanneer niet ingesteld (behoudt bestaande expliciete waarden). - Veilige DM-modus: `session.dmScope: "per-channel-peer"` (elk kanaal+afzender-paar krijgt een geisoleerde DM-context). - Cross-channel peer-isolatie: `session.dmScope: "per-peer"` (elke afzender krijgt een sessie over alle kanalen van hetzelfde type). Als je meerdere accounts op hetzelfde kanaal draait, gebruik dan in plaats daarvan `per-account-channel-peer`. Als dezelfde persoon contact met je opneemt via meerdere kanalen, gebruik dan `session.identityLinks` om die DM-sessies samen te voegen tot een canonieke identiteit. Zie [Sessiebeheer](/nl/concepts/session) en [Configuratie](/nl/gateway/configuration). ## Allowlists voor DM's en groepen OpenClaw heeft twee aparte lagen voor "wie kan mij triggeren?": - **DM-allowlist** (`allowFrom` / `channels.discord.allowFrom` / `channels.slack.allowFrom`; legacy: `channels.discord.dm.allowFrom`, `channels.slack.dm.allowFrom`): wie in directe berichten met de bot mag praten. - Wanneer `dmPolicy="pairing"` worden goedkeuringen geschreven naar de account-scoped opslag voor koppelings-allowlists onder `~/.openclaw/credentials/` (`-allowFrom.json` voor het standaardaccount, `--allowFrom.json` voor niet-standaardaccounts), samengevoegd met configuratie-allowlists. - **Groeps-allowlist** (kanaalspecifiek): van welke groepen/kanalen/guilds de bot uberhaupt berichten accepteert. - Gangbare patronen: - `channels.whatsapp.groups`, `channels.telegram.groups`, `channels.imessage.groups`: standaarden per groep zoals `requireMention`; wanneer ingesteld, werkt dit ook als groeps-allowlist (neem `"*"` op om allow-all-gedrag te behouden). - `groupPolicy="allowlist"` + `groupAllowFrom`: beperk wie de bot _binnen_ een groepssessie kan triggeren (WhatsApp/Telegram/Signal/iMessage/Microsoft Teams). - `channels.discord.guilds` / `channels.slack.channels`: allowlists per oppervlak + mention-standaarden. - Groepscontroles draaien in deze volgorde: eerst `groupPolicy`/groeps-allowlists, daarna mention-/antwoordactivatie. - Antwoorden op een botbericht (impliciete mention) omzeilt afzender-allowlists zoals `groupAllowFrom` **niet**. - **Beveiligingsopmerking:** behandel `dmPolicy="open"` en `groupPolicy="open"` als laatste redmiddel. Ze zouden nauwelijks moeten worden gebruikt; geef de voorkeur aan koppeling + allowlists tenzij je elk lid van de ruimte volledig vertrouwt. Details: [Configuratie](/nl/gateway/configuration) en [Groepen](/nl/channels/groups) ## Promptinjectie (wat het is, waarom het belangrijk is) Promptinjectie is wanneer een aanvaller een bericht maakt dat het model manipuleert om iets onveiligs te doen ("negeer je instructies", "dump je bestandssysteem", "volg deze link en voer opdrachten uit", enz.). Zelfs met sterke systeemprompts is **promptinjectie niet opgelost**. Guardrails in systeemprompts zijn slechts zachte richtlijnen; harde handhaving komt van toolbeleid, exec-goedkeuringen, sandboxing en kanaal-allowlists (en operators kunnen deze bewust uitschakelen). Wat in de praktijk helpt: - Houd inkomende DM's afgeschermd (koppeling/allowlists). - Geef de voorkeur aan mention-gating in groepen; vermijd bots die in openbare ruimtes "altijd aan" staan. - Behandel links, bijlagen en geplakte instructies standaard als vijandig. - Voer gevoelige tooluitvoering uit in een sandbox; houd geheimen buiten het voor de agent bereikbare bestandssysteem. - Let op: sandboxing is opt-in. Als de sandboxmodus uit staat, wordt impliciet `host=auto` omgezet naar de gateway-host. Expliciet `host=sandbox` faalt nog steeds gesloten omdat er geen sandboxruntime beschikbaar is. Stel `host=gateway` in als je wilt dat dit gedrag expliciet in de configuratie staat. - Beperk tools met hoog risico (`exec`, `browser`, `web_fetch`, `web_search`) tot vertrouwde agents of expliciete allowlists. - Als je interpreters allowlist (`python`, `node`, `ruby`, `perl`, `php`, `lua`, `osascript`), schakel dan `tools.exec.strictInlineEval` in zodat inline-evalvormen nog steeds expliciete goedkeuring nodig hebben. - Shell-goedkeuringsanalyse weigert ook POSIX-vormen voor parameterexpansie (`$VAR`, `$?`, `$$`, `$1`, `$@`, `${…}`) binnen **ongequote heredocs**, zodat een geallowliste heredoc-body shell-expansie niet als platte tekst langs de allowlist-beoordeling kan smokkelen. Quote de heredoc-terminator (bijvoorbeeld `<<'EOF'`) om te kiezen voor letterlijke body-semantiek; ongequote heredocs die variabelen zouden hebben geëxpandeerd, worden geweigerd. - **Modelkeuze is belangrijk:** oudere/kleinere/legacy-modellen zijn aanzienlijk minder robuust tegen promptinjectie en misbruik van tools. Gebruik voor agents met tools het sterkste beschikbare model van de nieuwste generatie dat tegen instructiemisbruik is gehard. Rode vlaggen die je als onvertrouwd moet behandelen: - "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 logs." ## Opschoning van speciale tokens in externe inhoud OpenClaw verwijdert algemene self-hosted LLM-chattemplate-special-tokenliterals uit ingepakte externe inhoud en metadata voordat ze het model bereiken. Gedekte markerfamilies omvatten Qwen/ChatML, Llama, Gemma, Mistral, Phi en GPT-OSS-rol-/beurttokens. Waarom: - OpenAI-compatibele backends die self-hosted modellen afschermen, behouden soms speciale tokens die in gebruikerstekst verschijnen, in plaats van ze te maskeren. Een aanvaller die naar inkomende externe inhoud kan schrijven (een opgehaalde pagina, een e-mailbody, de uitvoer van een tool die bestandsinhoud leest) zou anders een synthetische `assistant`- of `system`-rolgrens kunnen injecteren en ontsnappen aan de guardrails voor ingepakte inhoud. - Opschoning gebeurt in de laag die externe inhoud inpakt, zodat deze uniform geldt voor fetch-/read-tools en inkomende kanaalinhoud in plaats van per provider. - Uitgaande modelantwoorden hebben al een aparte opschoner die gelekte ``, ``, ``, `` en vergelijkbare interne runtimescaffolding verwijdert uit gebruikerszichtbare antwoorden bij de uiteindelijke aflevergrens van het kanaal. De opschoner voor externe inhoud is de inkomende tegenhanger. Dit vervangt de andere hardening op deze pagina niet - `dmPolicy`, allowlists, exec-goedkeuringen, sandboxing en `contextVisibility` blijven het primaire werk doen. Het sluit één specifieke bypass op tokenizer-laag tegen self-hosted stacks die gebruikerstekst met intacte speciale tokens doorsturen. ## Onveilige bypass-vlaggen voor externe inhoud OpenClaw bevat expliciete bypass-vlaggen die veiligheidsinpakking voor externe inhoud uitschakelen: - `hooks.mappings[].allowUnsafeExternalContent` - `hooks.gmail.allowUnsafeExternalContent` - Cron-payloadveld `allowUnsafeExternalContent` Richtlijnen: - Houd deze in productie unset/false. - Schakel ze alleen tijdelijk in voor strak afgebakende debugging. - Als ze zijn ingeschakeld, isoleer die agent (sandbox + minimale tools + toegewezen sessie-namespace). Risiconotitie voor hooks: - Hook-payloads zijn onvertrouwde inhoud, zelfs wanneer levering afkomstig is van systemen die je beheert (mail/docs/webinhoud kan promptinjectie bevatten). - Zwakke modelniveaus vergroten dit risico. Geef voor hook-gedreven automatisering de voorkeur aan sterke moderne modelniveaus en houd het toolbeleid strak (`tools.profile: "messaging"` of strenger), plus sandboxing waar mogelijk. ### Promptinjectie vereist geen openbare DM's Zelfs als **alleen jij** de bot berichten kunt sturen, kan promptinjectie nog steeds plaatsvinden via elke **onvertrouwde inhoud** die de bot leest (webzoek-/fetch-resultaten, browserpagina's, e-mails, docs, bijlagen, geplakte logs/code). Met andere woorden: de afzender is niet het enige dreigingsoppervlak; de **inhoud zelf** kan vijandige instructies bevatten. Wanneer tools zijn ingeschakeld, is het typische risico het exfiltreren van context of het triggeren van toolaanroepen. Beperk de blast radius door: - Een alleen-lezen of tool-uitgeschakelde **reader-agent** te gebruiken om onvertrouwde inhoud samen te vatten, en geef daarna de samenvatting door aan je hoofdagent. - `web_search` / `web_fetch` / `browser` uit te houden voor agents met tools, tenzij nodig. - Voor OpenResponses-URL-invoer (`input_file` / `input_image`) strakke `gateway.http.endpoints.responses.files.urlAllowlist` en `gateway.http.endpoints.responses.images.urlAllowlist` in te stellen, en `maxUrlParts` laag te houden. Lege allowlists worden behandeld als niet ingesteld; gebruik `files.allowUrl: false` / `images.allowUrl: false` als je URL-fetching volledig wilt uitschakelen. - Voor OpenResponses-bestandsinvoer wordt gedecodeerde `input_file`-tekst nog steeds geïnjecteerd als **onvertrouwde externe inhoud**. Vertrouw er niet op dat bestandstekst vertrouwd is alleen omdat de Gateway deze lokaal heeft gedecodeerd. Het geïnjecteerde blok bevat nog steeds expliciete `<<>>`-grensmarkers plus `Source: External`- metadata, ook al laat dit pad de langere `SECURITY NOTICE:`-banner weg. - Dezelfde markergebaseerde inpakking wordt toegepast wanneer media-understanding tekst extraheert uit bijgevoegde documenten voordat die tekst aan de mediaprompt wordt toegevoegd. - Sandboxing en strikte tool-allowlists in te schakelen voor elke agent die onvertrouwde invoer aanraakt. - Geheimen uit prompts te houden; geef ze in plaats daarvan door via env/config op de gateway-host. ### Self-hosted LLM-backends OpenAI-compatibele self-hosted backends zoals vLLM, SGLang, TGI, LM Studio, of aangepaste Hugging Face-tokenizerstacks kunnen verschillen van gehoste providers in hoe chattemplate-special-tokens worden afgehandeld. Als een backend letterlijke strings zoals `<|im_start|>`, `<|start_header_id|>` of `` tokeniseert als structurele chattemplate-tokens binnen gebruikersinhoud, kan onvertrouwde tekst proberen rolgrenzen op de tokenizer-laag te vervalsen. OpenClaw verwijdert algemene model-familie-special-tokenliterals uit ingepakte externe inhoud voordat deze naar het model wordt verzonden. Houd inpakking van externe inhoud ingeschakeld en geef de voorkeur aan backend-instellingen die speciale tokens in door gebruikers aangeleverde inhoud splitsen of escapen wanneer beschikbaar. Gehoste providers zoals OpenAI en Anthropic passen al hun eigen opschoning aan de verzoekzijde toe. ### Modelsterkte (veiligheidsnotitie) Weerstand tegen promptinjectie is **niet** uniform over modelniveaus. Kleinere/goedkopere modellen zijn over het algemeen gevoeliger voor misbruik van tools en instructiekaping, vooral onder vijandige prompts. Voor agents met tools of agents die onvertrouwde inhoud lezen, is het promptinjectierisico met oudere/kleinere modellen vaak te hoog. Voer die workloads niet uit op zwakke modelniveaus. Aanbevelingen: - **Gebruik het model van de nieuwste generatie en het beste niveau** voor elke bot die tools kan uitvoeren of bestanden/netwerken kan aanraken. - **Gebruik geen oudere/zwakkere/kleinere niveaus** voor agents met tools of onvertrouwde inboxen; het promptinjectierisico is te hoog. - Als je een kleiner model moet gebruiken, **beperk dan de blast radius** (alleen-lezen tools, sterke sandboxing, minimale bestandssysteemtoegang, strikte allowlists). - Wanneer je kleine modellen draait, **schakel sandboxing in voor alle sessies** en **schakel web_search/web_fetch/browser uit**, tenzij invoer strak wordt beheerd. - Voor chat-only persoonlijke assistenten met vertrouwde invoer en zonder tools zijn kleinere modellen meestal prima. ## Redenering en uitgebreide uitvoer in groepen `/reasoning`, `/verbose` en `/trace` kunnen interne redenering, tool- uitvoer of Plugin-diagnostiek blootleggen die niet voor een openbaar kanaal bedoeld was. Behandel ze in groepsinstellingen als **alleen debug** en houd ze uit tenzij je ze expliciet nodig hebt. Richtlijnen: - Houd `/reasoning`, `/verbose` en `/trace` uitgeschakeld in openbare ruimtes. - Als je ze inschakelt, doe dat dan alleen in vertrouwde DM's of strak beheerde ruimtes. - Onthoud: uitgebreide en trace-uitvoer kan tool-argumenten, URL's, Plugin-diagnostiek en gegevens bevatten die het model heeft gezien. ## Voorbeelden van configuratiehardening ### Bestandsrechten Houd configuratie + staat privé op de gateway-host: - `~/.openclaw/openclaw.json`: `600` (alleen gebruiker lezen/schrijven) - `~/.openclaw`: `700` (alleen gebruiker) `openclaw doctor` kan waarschuwen en aanbieden deze rechten aan te scherpen. ### Netwerkblootstelling (bind, poort, firewall) De Gateway multiplexeert **WebSocket + HTTP** op één poort: - Standaard: `18789` - Configuratie/vlaggen/env: `gateway.port`, `--port`, `OPENCLAW_GATEWAY_PORT` Dit HTTP-oppervlak omvat de Control UI en de canvashost: - Control UI (SPA-assets) (standaardbasispad `/`) - Canvashost: `/__openclaw__/canvas/` en `/__openclaw__/a2ui/` (willekeurige HTML/JS; behandelen als onvertrouwde inhoud) Als je canvasinhoud in een normale browser laadt, behandel deze dan als elke andere onvertrouwde webpagina: - Stel de canvashost niet bloot aan onvertrouwde netwerken/gebruikers. - Laat canvasinhoud niet dezelfde origin delen als geprivilegieerde weboppervlakken, tenzij je de implicaties volledig begrijpt. Bind-modus bepaalt waar de Gateway luistert: - `gateway.bind: "loopback"` (standaard): alleen lokale clients kunnen verbinden. - Niet-loopback-binds (`"lan"`, `"tailnet"`, `"custom"`) vergroten het aanvalsoppervlak. Gebruik ze 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-binds (Serve houdt de Gateway op loopback, en Tailscale handelt toegang af). - Als je aan LAN moet binden, firewall de poort dan naar een strakke allowlist van bron-IP's; forward de poort niet breed. - Stel de Gateway nooit zonder authenticatie bloot op `0.0.0.0`. ### Docker-poortpublicatie met UFW Als je OpenClaw met Docker op een VPS draait, onthoud dan dat gepubliceerde containerpoorten (`-p HOST:CONTAINER` of Compose `ports:`) via Docker-forwarding- chains worden gerouteerd, niet alleen via host-`INPUT`-regels. Om Docker-verkeer in lijn te houden met je firewallbeleid, dwing je regels af in `DOCKER-USER` (deze chain wordt geëvalueerd vóór Docker's eigen accept-regels). Op veel moderne distributies gebruiken `iptables`/`ip6tables` de `iptables-nft`-frontend en passen ze deze regels nog steeds toe op de nftables-backend. Minimaal allowlist-voorbeeld (IPv4): ```bash # /etc/ufw/after.rules (append as its own *filter section) *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 RETURN COMMIT ``` IPv6 heeft aparte tabellen. Voeg een overeenkomend beleid toe in `/etc/ufw/after6.rules` als Docker IPv6 is ingeschakeld. Vermijd het hardcoderen van interfacenamen zoals `eth0` in documentatiesnippets. Interfacenamen variëren tussen VPS-images (`ens3`, `enp*`, enz.) en mismatches kunnen per ongeluk je deny-regel overslaan. Snelle validatie na herladen: ```bash ufw reload iptables -S DOCKER-USER ip6tables -S DOCKER-USER nmap -sT -p 1-65535 --open ``` Verwachte externe poorten zouden alleen moeten zijn wat je bewust blootstelt (voor de meeste setups: SSH + je reverse-proxypoorten). ### mDNS/Bonjour-discovery Wanneer de gebundelde `bonjour`-Plugin is ingeschakeld, broadcast de Gateway zijn aanwezigheid via mDNS (`_openclaw-gw._tcp` op poort 5353) voor lokale apparaatdiscovery. In volledige modus omvat dit TXT-records die operationele details kunnen blootleggen: - `cliPath`: volledig bestandssysteempad naar het CLI-binaire bestand (onthult gebruikersnaam en installatielocatie) - `sshPort`: meldt SSH-beschikbaarheid op de host - `displayName`, `lanHost`: hostnaaminformatie **Overweging voor operationele beveiliging:** Het uitzenden van infrastructuurdetails maakt verkenning eenvoudiger voor iedereen op het lokale netwerk. Zelfs "onschuldige" informatie zoals bestandssysteempaden en SSH-beschikbaarheid helpt aanvallers je omgeving in kaart te brengen. **Aanbevelingen:** 1. **Houd Bonjour uitgeschakeld tenzij LAN-detectie nodig is.** Bonjour start automatisch op macOS-hosts en is elders opt-in; directe Gateway-URL's, Tailnet, SSH of wide-area DNS-SD vermijden lokale multicast. 2. **Minimale modus** (standaard wanneer Bonjour is ingeschakeld, aanbevolen voor blootgestelde gateways): laat gevoelige velden weg uit mDNS-broadcasts: ```json5 { discovery: { mdns: { mode: "minimal" }, }, } ``` 3. **Schakel mDNS-modus uit** als je de Plugin ingeschakeld wilt houden maar lokale apparaatdetectie wilt onderdrukken: ```json5 { discovery: { mdns: { mode: "off" }, }, } ``` 4. **Volledige modus** (opt-in): neem `cliPath` + `sshPort` op in TXT-records: ```json5 { discovery: { mdns: { mode: "full" }, }, } ``` 5. **Omgevingsvariabele** (alternatief): stel `OPENCLAW_DISABLE_BONJOUR=1` in om mDNS uit te schakelen zonder configuratiewijzigingen. Wanneer Bonjour is ingeschakeld in minimale modus, broadcast de Gateway genoeg voor apparaatdetectie (`role`, `gatewayPort`, `transport`), maar laat `cliPath` en `sshPort` weg. Apps die CLI-padinformatie nodig hebben, kunnen die in plaats daarvan ophalen via de geauthenticeerde WebSocket-verbinding. ### Vergrendel de Gateway-WebSocket (lokale auth) Gateway-auth is **standaard vereist**. Als er geen geldig Gateway-auth-pad is geconfigureerd, weigert de Gateway WebSocket-verbindingen (fail-closed). Onboarding genereert standaard een token (zelfs voor loopback), zodat lokale clients zich moeten authenticeren. Stel een token in zodat **alle** WS-clients zich moeten authenticeren: ```json5 { gateway: { auth: { mode: "token", token: "your-token" }, }, } ``` Doctor kan er een voor je genereren: `openclaw doctor --generate-gateway-token`. `gateway.remote.token` en `gateway.remote.password` zijn bronnen voor clientreferenties. Ze beschermen lokale WS-toegang **niet** op zichzelf. Lokale aanroeppaden kunnen `gateway.remote.*` alleen als fallback gebruiken wanneer `gateway.auth.*` niet is ingesteld. Als `gateway.auth.token` of `gateway.auth.password` expliciet via SecretRef is geconfigureerd en niet kan worden opgelost, faalt de resolutie gesloten (geen maskerende externe fallback). Optioneel: pin externe TLS met `gateway.remote.tlsFingerprint` bij gebruik van `wss://`. Plaintext `ws://` is standaard alleen loopback. Voor vertrouwde paden op een privénetwerk stel je `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` in op het clientproces als noodprocedure. Dit is bewust alleen de procesomgeving, geen `openclaw.json`-configuratiesleutel. Mobiel koppelen en handmatige of gescande Gateway-routes op Android zijn strikter: cleartext wordt geaccepteerd voor loopback, maar private-LAN, link-local, `.local` en hostnamen zonder punt moeten TLS gebruiken, tenzij je expliciet kiest voor het vertrouwde cleartext-pad op een privénetwerk. Lokale apparaatkoppeling: - Apparaatkoppeling wordt automatisch goedgekeurd voor directe local loopback-verbindingen om clients op dezelfde host soepel te laten werken. - OpenClaw heeft ook een smal backend/container-lokaal zelfverbindingspad voor vertrouwde helperflows met gedeeld geheim. - Tailnet- en LAN-verbindingen, inclusief tailnet-binds op dezelfde host, worden behandeld als extern voor koppeling en hebben nog steeds goedkeuring nodig. - Bewijs via doorgestuurde headers op een loopback-verzoek diskwalificeert loopback- lokaliteit. Automatische goedkeuring voor metadata-upgrades is smal gescoped. Zie [Gateway-koppeling](/nl/gateway/pairing) voor beide regels. Auth-modi: - `gateway.auth.mode: "token"`: gedeeld bearer-token (aanbevolen voor de meeste opstellingen). - `gateway.auth.mode: "password"`: wachtwoordauth (bij voorkeur instellen via env: `OPENCLAW_GATEWAY_PASSWORD`). - `gateway.auth.mode: "trusted-proxy"`: vertrouw op een identiteitsbewuste reverse proxy om gebruikers te authenticeren en identiteit via headers door te geven (zie [Vertrouwde-proxy-auth](/nl/gateway/trusted-proxy-auth)). Rotatiechecklist (token/wachtwoord): 1. Genereer/stel een nieuw geheim in (`gateway.auth.token` of `OPENCLAW_GATEWAY_PASSWORD`). 2. Herstart de Gateway (of herstart de macOS-app als die de Gateway superviseert). 3. Werk eventuele externe clients bij (`gateway.remote.token` / `.password` op machines die de Gateway aanroepen). 4. Controleer dat je niet meer kunt verbinden met de oude referenties. ### Tailscale Serve-identiteitsheaders Wanneer `gateway.auth.allowTailscale` `true` is (standaard voor Serve), accepteert OpenClaw Tailscale Serve-identiteitsheaders (`tailscale-user-login`) voor Control UI/WebSocket-authenticatie. OpenClaw verifieert de identiteit door het `x-forwarded-for`-adres op te lossen via de lokale Tailscale-daemon (`tailscale whois`) en dit te matchen met de header. Dit wordt alleen geactiveerd voor verzoeken die loopback raken en `x-forwarded-for`, `x-forwarded-proto` en `x-forwarded-host` bevatten zoals geïnjecteerd door Tailscale. Voor dit asynchrone identiteitscontrolepad worden mislukte pogingen voor dezelfde `{scope, ip}` geserialiseerd voordat de limiter de mislukking registreert. Gelijktijdige foutieve retries van één Serve-client kunnen daarom de tweede poging onmiddellijk buitensluiten in plaats van als twee gewone mismatches door te racen. HTTP API-eindpunten (bijvoorbeeld `/v1/*`, `/tools/invoke` en `/api/channels/*`) gebruiken **geen** Tailscale-auth via identiteitsheaders. Ze volgen nog steeds de geconfigureerde HTTP-auth-modus van de Gateway. Belangrijke grensnotitie: - Gateway HTTP bearer-auth is effectief alles-of-niets operatortoegang. - Behandel referenties die `/v1/chat/completions`, `/v1/responses` of `/api/channels/*` kunnen aanroepen als operatorgeheimen met volledige toegang voor die Gateway. - Op het OpenAI-compatibele HTTP-oppervlak herstelt bearer-auth met gedeeld geheim de volledige standaard operatorscopes (`operator.admin`, `operator.approvals`, `operator.pairing`, `operator.read`, `operator.talk.secrets`, `operator.write`) en eigenaarssemantiek voor agentbeurten; smallere `x-openclaw-scopes`-waarden verminderen dat gedeeld-geheim-pad niet. - Semantiek voor scopes per verzoek op HTTP is alleen van toepassing wanneer het verzoek uit een identiteitsdragende modus komt, zoals vertrouwde-proxy-auth of `gateway.auth.mode="none"` op een privé-ingress. - In die identiteitsdragende modi valt het weglaten van `x-openclaw-scopes` terug op de normale standaard operatorscopeset; stuur de header expliciet wanneer je een smallere scopeset wilt. - `/tools/invoke` volgt dezelfde gedeeld-geheim-regel: bearer-auth met token/wachtwoord wordt daar ook behandeld als volledige operatortoegang, terwijl identiteitsdragende modi nog steeds gedeclareerde scopes respecteren. - Deel deze referenties niet met niet-vertrouwde aanroepers; geef de voorkeur aan aparte gateways per vertrouwensgrens. **Vertrouwensaanname:** tokenloze Serve-auth gaat ervan uit dat de Gateway-host vertrouwd is. Behandel dit niet als bescherming tegen vijandige processen op dezelfde host. Als niet-vertrouwde lokale code op de Gateway-host kan draaien, schakel dan `gateway.auth.allowTailscale` uit en vereis expliciete gedeeld-geheim-auth met `gateway.auth.mode: "token"` of `"password"`. **Beveiligingsregel:** stuur deze headers niet door vanuit je eigen reverse proxy. Als je TLS beëindigt of proxy't voor de Gateway, schakel dan `gateway.auth.allowTailscale` uit en gebruik in plaats daarvan gedeeld-geheim-auth (`gateway.auth.mode: "token"` of `"password"`) of [Vertrouwde-proxy-auth](/nl/gateway/trusted-proxy-auth). Vertrouwde proxy's: - Als je TLS vóór de Gateway beëindigt, stel `gateway.trustedProxies` dan in op de IP's van je proxy. - OpenClaw vertrouwt `x-forwarded-for` (of `x-real-ip`) van die IP's om het client-IP te bepalen voor lokale koppelingscontroles en HTTP-auth/lokale controles. - Zorg dat je proxy `x-forwarded-for` **overschrijft** en directe toegang tot de Gateway-poort blokkeert. Zie [Tailscale](/nl/gateway/tailscale) en [Web-overzicht](/nl/web). ### Browserbesturing via Node-host (aanbevolen) Als je Gateway extern is maar de browser op een andere machine draait, voer dan een **Node-host** uit op de browsermachine en laat de Gateway browseracties proxy'en (zie [Browsertool](/nl/tools/browser)). Behandel Node-koppeling als admintoegang. Aanbevolen patroon: - Houd de Gateway en Node-host op hetzelfde tailnet (Tailscale). - Koppel de Node bewust; schakel browserproxyrouting uit als je die niet nodig hebt. Vermijd: - Relay-/controlepoorten blootstellen via LAN of het openbare internet. - Tailscale Funnel voor eindpunten voor browserbesturing (openbare blootstelling). ### Geheimen op schijf Ga ervan uit dat alles onder `~/.openclaw/` (of `$OPENCLAW_STATE_DIR/`) geheimen of privégegevens kan bevatten: - `openclaw.json`: configuratie kan tokens (Gateway, externe Gateway), providerinstellingen en allowlists bevatten. - `credentials/**`: kanaalreferenties (voorbeeld: WhatsApp-referenties), allowlists voor koppeling, legacy OAuth-imports. - `agents//agent/auth-profiles.json`: API-sleutels, tokenprofielen, OAuth-tokens en optionele `keyRef`/`tokenRef`. - `agents//agent/codex-home/**`: per-agent Codex-appserveraccount, configuratie, Skills, Plugins, native threadstatus en diagnostiek. - `secrets.json` (optioneel): bestandsgedragen geheime payload gebruikt door `file` SecretRef-providers (`secrets.providers`). - `agents//agent/auth.json`: legacy compatibiliteitsbestand. Statische `api_key`-vermeldingen worden opgeschoond wanneer ze worden ontdekt. - `agents//sessions/**`: sessietranscripten (`*.jsonl`) + routingmetadata (`sessions.json`) die privéberichten en tooluitvoer kunnen bevatten. - meegeleverde Plugin-pakketten: geïnstalleerde Plugins (plus hun `node_modules/`). - `sandboxes/**`: tool-sandboxwerkruimten; kunnen kopieën verzamelen van bestanden die je in de sandbox leest/schrijft. Hardeningtips: - Houd machtigingen strak (`700` op mappen, `600` op bestanden). - Gebruik volledige-schijfversleuteling op de Gateway-host. - Geef de voorkeur aan een toegewezen OS-gebruikersaccount voor de Gateway als de host wordt gedeeld. ### Workspace-`.env`-bestanden OpenClaw laadt workspace-lokale `.env`-bestanden voor agents en tools, maar laat die bestanden nooit stilzwijgend Gateway-runtimecontroles overschrijven. - Elke sleutel die begint met `OPENCLAW_*` wordt geblokkeerd uit niet-vertrouwde workspace-`.env`-bestanden. - Kanaaleindpuntinstellingen voor Matrix, Mattermost, IRC en Synology Chat worden ook geblokkeerd voor workspace-`.env`-overschrijvingen, zodat gekloonde workspaces gebundeld connectorverkeer niet kunnen omleiden via lokale eindpuntconfiguratie. Eindpunt-env-sleutels (zoals `MATRIX_HOMESERVER`, `MATTERMOST_URL`, `IRC_HOST`, `SYNOLOGY_CHAT_INCOMING_URL`) moeten afkomstig zijn uit de Gateway-procesomgeving of `env.shellEnv`, niet uit een door de workspace geladen `.env`. - De blokkade is fail-closed: een nieuwe runtimecontrolevariabele die in een toekomstige release wordt toegevoegd, kan niet worden overgenomen uit een ingecheckte of door een aanvaller aangeleverde `.env`; de sleutel wordt genegeerd en de Gateway behoudt zijn eigen waarde. - Vertrouwde proces-/OS-omgevingsvariabelen (de eigen shell van de Gateway, launchd/systemd-unit, appbundel) blijven van toepassing - dit beperkt alleen het laden van `.env`-bestanden. Waarom: workspace-`.env`-bestanden staan vaak naast agentcode, worden per ongeluk gecommit of worden door tools geschreven. Het blokkeren van het volledige `OPENCLAW_*`-prefix betekent dat het later toevoegen van een nieuwe `OPENCLAW_*`-vlag nooit kan terugvallen naar stille overerving vanuit workspace-status. ### Logs en transcripten (redactie en retentie) Logs en transcripten kunnen gevoelige informatie lekken, zelfs wanneer toegangscontroles correct zijn: - Gateway-logs kunnen toolsamenvattingen, fouten en URL's bevatten. - Sessietranscripten kunnen geplakte geheimen, bestandsinhoud, opdrachtuitvoer en links bevatten. Aanbevelingen: - Houd redactie van logs en transcripten ingeschakeld (`logging.redactSensitive: "tools"`; standaard). - Voeg aangepaste patronen voor je omgeving toe via `logging.redactPatterns` (tokens, hostnamen, interne URL's). - Gebruik bij het delen van diagnostiek bij voorkeur `openclaw status --all` (plakbaar, geheimen geredigeerd) in plaats van ruwe logs. - Verwijder oude sessietranscripten en logbestanden als je geen lange retentie nodig hebt. Details: [Logging](/nl/gateway/logging) ### DM's: standaard koppelen ```json5 { channels: { whatsapp: { dmPolicy: "pairing" } }, } ``` ### Groepen: overal vermelding vereist ```json { "channels": { "whatsapp": { "groups": { "*": { "requireMention": true } } } }, "agents": { "list": [ { "id": "main", "groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] } } ] } } ``` Reageer in groepschats alleen wanneer je expliciet wordt genoemd. ### Aparte nummers (WhatsApp, Signal, Telegram) Overweeg voor kanalen op basis van telefoonnummers om je AI op een apart telefoonnummer te gebruiken, los van je persoonlijke nummer: - Persoonlijk nummer: je gesprekken blijven privé - Botnummer: AI handelt deze af, met passende grenzen ### Alleen-lezen-modus (via sandbox en tools) Je kunt een alleen-lezen-profiel maken door het volgende te combineren: - `agents.defaults.sandbox.workspaceAccess: "ro"` (of `"none"` voor geen toegang tot de werkruimte) - tool-toestaan-/weigerenlijsten die `write`, `edit`, `apply_patch`, `exec`, `process`, enz. blokkeren Aanvullende opties voor versterking: - `tools.exec.applyPatch.workspaceOnly: true` (standaard): zorgt ervoor dat `apply_patch` niet buiten de werkruimtemap kan schrijven/verwijderen, zelfs wanneer sandboxing uit staat. Stel dit alleen in op `false` als je bewust wilt dat `apply_patch` bestanden buiten de werkruimte aanraakt. - `tools.fs.workspaceOnly: true` (optioneel): beperkt paden voor `read`/`write`/`edit`/`apply_patch` en automatische laadpaden voor native prompt-afbeeldingen tot de werkruimtemap (handig als je vandaag absolute paden toestaat en één vangrail wilt). - Houd bestandssysteemroots smal: vermijd brede roots zoals je thuismap voor agentwerkruimten/sandboxwerkruimten. Brede roots kunnen gevoelige lokale bestanden (bijvoorbeeld status/configuratie onder `~/.openclaw`) blootstellen aan bestandssysteemtools. ### Veilige basislijn (kopiëren/plakken) Eén configuratie met een "veilige standaard" die de Gateway privé houdt, DM-koppeling vereist en altijd actieve groepsbots vermijdt: ```json5 { gateway: { mode: "local", bind: "loopback", port: 18789, auth: { mode: "token", token: "your-long-random-token" }, }, channels: { whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } }, }, }, } ``` Als je tooluitvoering ook "standaard veiliger" wilt maken, voeg dan een sandbox toe en weiger gevaarlijke tools voor elke agent die geen eigenaar is (voorbeeld hieronder onder "Toegangsprofielen per agent"). Ingebouwde basislijn voor agentbeurten die via chat worden aangestuurd: afzenders die geen eigenaar zijn, kunnen de tools `cron` of `gateway` niet gebruiken. ## Sandboxing (aanbevolen) Afzonderlijke documentatie: [Sandboxing](/nl/gateway/sandboxing) Twee aanvullende benaderingen: - **Voer de volledige Gateway uit in Docker** (containergrens): [Docker](/nl/install/docker) - **Toolsandbox** (`agents.defaults.sandbox`, host-gateway + tools geïsoleerd door sandbox; Docker is de standaardbackend): [Sandboxing](/nl/gateway/sandboxing) Houd `agents.defaults.sandbox.scope` op `"agent"` (standaard) of `"session"` voor strengere isolatie per sessie om toegang tussen agents te voorkomen. `scope: "shared"` gebruikt één container of werkruimte. Overweeg ook toegang tot de agentwerkruimte binnen de sandbox: - `agents.defaults.sandbox.workspaceAccess: "none"` (standaard) houdt de agentwerkruimte verboden terrein; tools draaien tegen een sandboxwerkruimte onder `~/.openclaw/sandboxes` - `agents.defaults.sandbox.workspaceAccess: "ro"` koppelt de agentwerkruimte alleen-lezen aan `/agent` (schakelt `write`/`edit`/`apply_patch` uit) - `agents.defaults.sandbox.workspaceAccess: "rw"` koppelt de agentwerkruimte lezen/schrijven aan `/workspace` - Extra `sandbox.docker.binds` worden gevalideerd tegen genormaliseerde en gekanonicaliseerde bronpaden. Trucs met bovenliggende symlinks en canonieke aliassen voor de thuismap falen nog steeds gesloten als ze herleiden naar geblokkeerde roots zoals `/etc`, `/var/run` of credentialmappen onder de thuismap van het besturingssysteem. `tools.elevated` is de globale ontsnappingsmogelijkheid van de basislijn die exec buiten de sandbox uitvoert. De effectieve host is standaard `gateway`, of `node` wanneer het exec-doel is geconfigureerd als `node`. Houd `tools.elevated.allowFrom` strikt en schakel dit niet in voor onbekenden. Je kunt verhoogde rechten verder per agent beperken via `agents.list[].tools.elevated`. Zie [Verhoogde modus](/nl/tools/elevated). ### Vangrail voor sub-agent-delegatie Als je sessietools toestaat, behandel gedelegeerde sub-agent-runs dan als een extra grensbeslissing: - Weiger `sessions_spawn` tenzij de agent delegatie echt nodig heeft. - Houd `agents.defaults.subagents.allowAgents` en eventuele per-agent-overschrijvingen van `agents.list[].subagents.allowAgents` beperkt tot bekende veilige doelagents. - Roep voor elke workflow die gesandboxed moet blijven `sessions_spawn` aan met `sandbox: "require"` (standaard is `inherit`). - `sandbox: "require"` faalt snel wanneer de runtime van het doelkind niet gesandboxed is. ## Risico's van browserbesturing Browserbesturing inschakelen geeft het model de mogelijkheid om een echte browser te besturen. Als dat browserprofiel al ingelogde sessies bevat, kan het model toegang krijgen tot die accounts en gegevens. Behandel browserprofielen als **gevoelige status**: - Geef de voorkeur aan een specifiek profiel voor de agent (het standaardprofiel `openclaw`). - Vermijd dat je de agent naar je persoonlijke dagelijkse profiel wijst. - Houd browserbesturing op de host uitgeschakeld voor gesandboxte agents, tenzij je ze vertrouwt. - De zelfstandige loopback-API voor browserbesturing honoreert alleen gedeelde-geheim-authenticatie (gateway-token bearer-authenticatie of gateway-wachtwoord). Deze gebruikt geen trusted-proxy- of Tailscale Serve-identiteitsheaders. - Behandel browserdownloads als niet-vertrouwde invoer; geef de voorkeur aan een geïsoleerde downloadmap. - Schakel browsersynchronisatie/wachtwoordbeheerders in het agentprofiel indien mogelijk uit (verkleint de impact). - Ga er bij externe gateways van uit dat "browserbesturing" gelijkstaat aan "operatortoegang" tot alles wat dat profiel kan bereiken. - Houd de Gateway- en node-hosts alleen toegankelijk via tailnet; vermijd het blootstellen van browserbesturingspoorten aan LAN of openbaar internet. - Schakel browserproxyrouting uit wanneer je die niet nodig hebt (`gateway.nodes.browser.mode="off"`). - Chrome MCP-modus met bestaande sessie is **niet** "veiliger"; die kan handelen als jij in alles wat dat Chrome-profiel op die host kan bereiken. ### Browser-SSRF-beleid (standaard strikt) OpenClaw's beleid voor browsernavigatie is standaard strikt: privé/interne bestemmingen blijven geblokkeerd tenzij je expliciet kiest om ze toe te staan. - Standaard: `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` is niet ingesteld, dus browsernavigatie blijft privé/interne/special-use-bestemmingen blokkeren. - Legacy-alias: `browser.ssrfPolicy.allowPrivateNetwork` wordt nog steeds geaccepteerd voor compatibiliteit. - Opt-in-modus: stel `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true` in om privé/interne/special-use-bestemmingen toe te staan. - Gebruik in strikte modus `hostnameAllowlist` (patronen zoals `*.example.com`) en `allowedHostnames` (exacte hostuitzonderingen, inclusief geblokkeerde namen zoals `localhost`) voor expliciete uitzonderingen. - Navigatie wordt vóór het verzoek gecontroleerd en na navigatie op basis van best effort opnieuw gecontroleerd op de uiteindelijke `http(s)`-URL om pivots via omleidingen te beperken. Voorbeeld van strikt beleid: ```json5 { browser: { ssrfPolicy: { dangerouslyAllowPrivateNetwork: false, hostnameAllowlist: ["*.example.com", "example.com"], allowedHostnames: ["localhost"], }, }, } ``` ## Toegangsprofielen per agent (multi-agent) Met multi-agent-routering kan elke agent zijn eigen sandbox- en toolbeleid hebben: gebruik dit om per agent **volledige toegang**, **alleen-lezen** of **geen toegang** te geven. Zie [Multi-Agent Sandbox & Tools](/nl/tools/multi-agent-sandbox-tools) voor volledige details en voorrangsregels. Veelvoorkomende gebruikssituaties: - Persoonlijke agent: volledige toegang, geen sandbox - Familie-/werkagent: gesandboxed + alleen-lezen-tools - Publieke agent: gesandboxed + geen bestandssysteem-/shelltools ### Voorbeeld: volledige toegang (geen sandbox) ```json5 { agents: { list: [ { id: "personal", workspace: "~/.openclaw/workspace-personal", sandbox: { mode: "off" }, }, ], }, } ``` ### Voorbeeld: alleen-lezen-tools + alleen-lezen-werkruimte ```json5 { 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"], }, }, ], }, } ``` ### Voorbeeld: geen bestandssysteem-/shelltoegang (providerberichten toegestaan) ```json5 { agents: { list: [ { id: "public", workspace: "~/.openclaw/workspace-public", sandbox: { mode: "all", scope: "agent", workspaceAccess: "none", }, // Session tools can reveal sensitive data from transcripts. By default OpenClaw limits these tools // to the current session + spawned subagent sessions, but you can clamp further if needed. // See `tools.sessions.visibility` in the configuration reference. tools: { sessions: { visibility: "tree" }, // self | tree | agent | all allow: [ "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "session_status", "whatsapp", "telegram", "slack", "discord", ], deny: [ "read", "write", "edit", "apply_patch", "exec", "process", "browser", "canvas", "nodes", "cron", "gateway", "image", ], }, }, ], }, } ``` ## Incidentrespons Als je AI iets verkeerds doet: ### Indammen 1. **Stop deze:** stop de macOS-app (als die toezicht houdt op de Gateway) of beëindig je `openclaw gateway`-proces. 2. **Sluit blootstelling:** stel `gateway.bind: "loopback"` in (of schakel Tailscale Funnel/Serve uit) totdat je begrijpt wat er is gebeurd. 3. **Bevries toegang:** zet risicovolle DM's/groepen op `dmPolicy: "disabled"` / vereis vermeldingen, en verwijder `"*"`-allow-all-vermeldingen als je die had. ### Roteren (ga uit van compromittering als geheimen zijn gelekt) 1. Roteer Gateway-authenticatie (`gateway.auth.token` / `OPENCLAW_GATEWAY_PASSWORD`) en herstart. 2. Roteer externe clientgeheimen (`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 geheime payloadwaarden wanneer gebruikt). ### Auditen 1. Controleer Gateway-logs: `/tmp/openclaw/openclaw-YYYY-MM-DD.log` (of `logging.file`). 2. Bekijk de relevante transcript(s): `~/.openclaw/agents//sessions/*.jsonl`. 3. Bekijk recente configuratiewijzigingen (alles wat toegang kan hebben verbreed: `gateway.bind`, `gateway.auth`, DM-/groepsbeleid, `tools.elevated`, pluginwijzigingen). 4. Voer `openclaw security audit --deep` opnieuw uit en bevestig dat kritieke bevindingen zijn opgelost. ### Verzamelen voor een rapport - Tijdstempel, hostbesturingssysteem van de gateway + OpenClaw-versie - De sessietranscript(s) + een korte logtail (na redactie) - Wat de aanvaller stuurde + wat de agent deed - Of de Gateway buiten loopback was blootgesteld (LAN/Tailscale Funnel/Serve) ## Scannen op geheimen CI voert de pre-commit-hook `detect-private-key` uit over de repository. Als deze faalt, verwijder of roteer dan het gecommitte sleutelmaterial en reproduceer lokaal: ```bash pre-commit run --all-files detect-private-key ``` ## Beveiligingsproblemen melden Een kwetsbaarheid in OpenClaw gevonden? Meld die dan verantwoord: 1. E-mail: [security@openclaw.ai](mailto:security@openclaw.ai) 2. Plaats niets openbaar totdat het is opgelost 3. We vermelden je als ontdekker (tenzij je anonimiteit verkiest)