सुरक्षा

पहले दायरा: व्यक्तिगत सहायक सुरक्षा मॉडल

OpenClaw सुरक्षा मार्गदर्शन व्यक्तिगत सहायक deployment मानता है: एक विश्वसनीय ऑपरेटर सीमा, संभावित रूप से कई agents.

• समर्थित सुरक्षा मुद्रा: प्रति Gateway एक user/trust boundary (प्राथमिकता से प्रति boundary एक OS user/host/VPS).
• समर्थित सुरक्षा सीमा नहीं: परस्पर अविश्वसनीय या प्रतिकूल उपयोगकर्ताओं द्वारा उपयोग किया गया एक साझा Gateway/agent.
• यदि प्रतिकूल-उपयोगकर्ता अलगाव आवश्यक है, तो trust boundary के अनुसार विभाजित करें (अलग Gateway + credentials, और आदर्श रूप से अलग OS users/hosts).
• यदि कई अविश्वसनीय उपयोगकर्ता एक tool-enabled agent को message कर सकते हैं, तो मानें कि वे उस agent के लिए समान delegated tool authority साझा कर रहे हैं।

यह पृष्ठ उस मॉडल के भीतर hardening समझाता है। यह एक साझा Gateway पर hostile multi-tenant isolation का दावा नहीं करता।

Remote access, DM policy, reverse proxy, या public exposure बदलने से पहले, Gateway exposure runbook को pre-flight और rollback checklist की तरह उपयोग करें।

त्वरित जांच: openclaw security audit

यह भी देखें: औपचारिक सत्यापन (सुरक्षा मॉडल)

इसे नियमित रूप से चलाएं (विशेष रूप से config बदलने या network surfaces expose करने के बाद):

openclaw security auditopenclaw security audit --deepopenclaw security audit --fixopenclaw security audit --json

security audit --fix जानबूझकर सीमित रहता है: यह सामान्य open group policies को allowlists में बदलता है, logging.redactSensitive: "tools" बहाल करता है, state/config/include-file permissions कसता है, और Windows पर चलते समय POSIX chmod के बजाय Windows ACL resets का उपयोग करता है।

यह सामान्य footguns को flag करता है (Gateway auth exposure, browser control exposure, elevated allowlists, filesystem permissions, permissive exec approvals, और open-channel tool exposure).

OpenClaw एक product और एक experiment दोनों है: आप frontier-model behavior को वास्तविक messaging surfaces और वास्तविक tools से जोड़ रहे हैं। कोई "पूरी तरह सुरक्षित" setup नहीं है। लक्ष्य इन बातों पर सोच-समझकर निर्णय लेना है:

• कौन आपके bot से बात कर सकता है
• bot को कहां act करने की अनुमति है
• bot क्या touch कर सकता है

सबसे छोटे access से शुरू करें जो अभी भी काम करता है, फिर confidence बढ़ने पर उसे widen करें।

Published package dependency lock

OpenClaw source checkouts pnpm-lock.yaml उपयोग करते हैं। प्रकाशित openclaw npm package और OpenClaw-owned npm plugin packages में npm-shrinkwrap.json, npm का publishable dependency lockfile, शामिल होता है, ताकि package installs install time पर fresh graph resolve करने के बजाय release से reviewed transitive dependency graph का उपयोग करें।

Shrinkwrap supply-chain hardening और release reproducibility boundary है, sandbox नहीं। Plain-English model, maintainer commands, और package inspection checks के लिए, npm shrinkwrap देखें।

Deployment और host trust

OpenClaw मानता है कि host और config boundary trusted हैं:

• यदि कोई Gateway host state/config (~/.openclaw, जिसमें openclaw.json शामिल है) modify कर सकता है, तो उसे trusted operator मानें।
• कई परस्पर अविश्वसनीय/प्रतिकूल operators के लिए एक Gateway चलाना recommended setup नहीं है।
• Mixed-trust teams के लिए, अलग gateways के साथ trust boundaries विभाजित करें (या कम से कम अलग OS users/hosts).
• Recommended default: प्रति machine/host (या VPS) एक user, उस user के लिए एक Gateway, और उस Gateway में एक या अधिक agents.
• एक Gateway instance के भीतर, authenticated operator access एक trusted control-plane role है, per-user tenant role नहीं।
• Session identifiers (sessionKey, session IDs, labels) routing selectors हैं, authorization tokens नहीं।
• यदि कई लोग एक tool-enabled agent को message कर सकते हैं, तो उनमें से हर कोई उसी permission set को steer कर सकता है। Per-user session/memory isolation privacy में मदद करता है, लेकिन साझा agent को per-user host authorization में परिवर्तित नहीं करता।

Secure file operations

OpenClaw root-bounded file access, atomic writes, archive extraction, temp workspaces, और secret-file helpers के लिए @openclaw/fs-safe उपयोग करता है। OpenClaw fs-safe के optional POSIX Python helper को default रूप से off रखता है; OPENCLAW_FS_SAFE_PYTHON_MODE=auto या require केवल तब set करें जब आप extra fd-relative mutation hardening चाहते हों और Python runtime support कर सकते हों।

विवरण: Secure file operations.

Shared Slack workspace: वास्तविक जोखिम

यदि "Slack में हर कोई bot को message कर सकता है," तो मुख्य जोखिम delegated tool authority है:

• कोई भी allowed sender agent की policy के भीतर tool calls (exec, browser, network/file tools) induce कर सकता है;
• एक sender से prompt/content injection shared state, devices, या outputs को प्रभावित करने वाली actions करवा सकता है;
• यदि एक shared agent के पास sensitive credentials/files हैं, तो कोई भी allowed sender संभावित रूप से tool usage के माध्यम से exfiltration drive कर सकता है।

Team workflows के लिए minimal tools वाले अलग agents/gateways उपयोग करें; personal-data agents को private रखें।

Company-shared agent: स्वीकार्य pattern

यह तब स्वीकार्य है जब उस agent का उपयोग करने वाला हर व्यक्ति समान trust boundary में हो (उदाहरण के लिए एक company team) और agent strictly business-scoped हो।

• उसे dedicated machine/VM/container पर चलाएं;
• उस runtime के लिए dedicated OS user + dedicated browser/profile/accounts उपयोग करें;
• उस runtime को personal Apple/Google accounts या personal password-manager/browser profiles में sign in न करें।

यदि आप एक ही runtime पर personal और company identities मिलाते हैं, तो separation collapse हो जाता है और personal-data exposure risk बढ़ जाता है।

Gateway और Node trust concept

Gateway और Node को अलग roles के साथ एक operator trust domain मानें:

• Gateway control plane और policy surface है (gateway.auth, tool policy, routing).
• Node उस Gateway से paired remote execution surface है (commands, device actions, host-local capabilities).
• Gateway पर authenticated caller Gateway scope पर trusted होता है। Pairing के बाद, Node actions उस Node पर trusted operator actions होती हैं।
• Operator scope levels और approval-time checks का सार Operator scopes में दिया गया है।
• Shared gateway token/password से authenticated direct loopback backend clients user device identity प्रस्तुत किए बिना internal control-plane RPCs कर सकते हैं। यह remote या browser pairing bypass नहीं है: network clients, Node clients, device-token clients, और explicit device identities अभी भी pairing और scope-upgrade enforcement से गुजरते हैं।
• sessionKey routing/context selection है, per-user auth नहीं।
• Exec approvals (allowlist + ask) operator intent के लिए guardrails हैं, hostile multi-tenant isolation नहीं।
• Trusted single-operator setups के लिए OpenClaw का product default यह है कि gateway/node पर host exec approval prompts के बिना allowed है (security="full", ask="off" जब तक आप इसे tighten न करें). वह default intentional UX है, अपने-आप में vulnerability नहीं।
• Exec approvals exact request context और best-effort direct local file operands से bind होते हैं; वे हर runtime/interpreter loader path को semantically model नहीं करते। Strong boundaries के लिए sandboxing और host isolation उपयोग करें।

यदि आपको hostile-user isolation चाहिए, तो OS user/host के अनुसार trust boundaries विभाजित करें और अलग gateways चलाएं।

Trust boundary matrix

Risk triage करते समय इसे quick model की तरह उपयोग करें:

Design के अनुसार vulnerabilities नहीं

60 सेकंड में hardened baseline

पहले इस baseline का उपयोग करें, फिर trusted agent के अनुसार tools को selectively re-enable करें:

{  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 } } },  },}

यह Gateway को local-only रखता है, DMs को isolate करता है, और control-plane/runtime tools को default रूप से disable करता है।

Shared inbox quick rule

यदि एक से अधिक व्यक्ति आपके bot को DM कर सकते हैं:

• session.dmScope: "per-channel-peer" सेट करें (या बहु-खाता चैनलों के लिए "per-account-channel-peer").
• dmPolicy: "pairing" या सख्त अनुमति-सूचियाँ रखें.
• साझा निजी संदेशों को व्यापक टूल पहुंच के साथ कभी न मिलाएँ.
• यह सहयोगी/साझा इनबॉक्स को कठोर बनाता है, लेकिन जब उपयोगकर्ता होस्ट/config लिखने की पहुंच साझा करते हैं, तब इसे शत्रुतापूर्ण सह-किरायेदार अलगाव के रूप में डिजाइन नहीं किया गया है.

संदर्भ दृश्यता मॉडल

OpenClaw दो अवधारणाओं को अलग करता है:

• ट्रिगर प्राधिकरण: एजेंट को कौन ट्रिगर कर सकता है (dmPolicy, groupPolicy, अनुमति-सूचियाँ, उल्लेख गेट).
• संदर्भ दृश्यता: मॉडल इनपुट में कौन-सा पूरक संदर्भ इंजेक्ट किया जाता है (जवाब का मुख्य भाग, उद्धृत पाठ, थ्रेड इतिहास, अग्रेषित मेटाडेटा).

अनुमति-सूचियाँ ट्रिगर और कमांड प्राधिकरण को नियंत्रित करती हैं. contextVisibility सेटिंग यह नियंत्रित करती है कि पूरक संदर्भ (उद्धृत जवाब, थ्रेड रूट, प्राप्त इतिहास) कैसे फिल्टर किया जाता है:

• contextVisibility: "all" (डिफॉल्ट) पूरक संदर्भ को प्राप्त रूप में रखता है.
• contextVisibility: "allowlist" पूरक संदर्भ को सक्रिय अनुमति-सूची जांचों द्वारा अनुमत प्रेषकों तक फिल्टर करता है.
• contextVisibility: "allowlist_quote" allowlist जैसा व्यवहार करता है, लेकिन फिर भी एक स्पष्ट उद्धृत जवाब रखता है.

contextVisibility को प्रति चैनल या प्रति रूम/बातचीत सेट करें. सेटअप विवरण के लिए समूह चैट देखें.

सलाहकारी ट्रायज मार्गदर्शन:

• ऐसे दावे जो केवल यह दिखाते हैं कि "मॉडल गैर-अनुमति-सूचीबद्ध प्रेषकों से उद्धृत या ऐतिहासिक पाठ देख सकता है", contextVisibility से संबोधित किए जा सकने वाले हार्डनिंग निष्कर्ष हैं, अपने आप में auth या sandbox सीमा बाइपास नहीं.
• सुरक्षा-प्रभावी होने के लिए, रिपोर्टों में फिर भी किसी विश्वास-सीमा बाइपास (auth, नीति, sandbox, अनुमोदन, या कोई अन्य दस्तावेजीकृत सीमा) का प्रदर्शित प्रमाण चाहिए.

ऑडिट क्या जांचता है (उच्च स्तर)

• इनबाउंड पहुंच (निजी संदेश नीतियाँ, समूह नीतियाँ, अनुमति-सूचियाँ): क्या अजनबी बॉट को ट्रिगर कर सकते हैं?
• टूल ब्लास्ट रेडियस (उन्नत टूल + खुले रूम): क्या प्रॉम्प्ट इंजेक्शन shell/file/network कार्रवाइयों में बदल सकता है?
• Exec फाइलसिस्टम ड्रिफ्ट: क्या परिवर्तित करने वाले फाइलसिस्टम टूल अस्वीकृत हैं जबकि exec/process sandbox फाइलसिस्टम बाधाओं के बिना उपलब्ध रहते हैं?
• Exec अनुमोदन ड्रिफ्ट (security=full, autoAllowSkills, strictInlineEval के बिना इंटरप्रेटर अनुमति-सूचियाँ): क्या होस्ट-exec गार्डरेल अब भी वही कर रहे हैं जो आप समझते हैं?
  • security="full" एक व्यापक मुद्रा चेतावनी है, किसी बग का प्रमाण नहीं. यह भरोसेमंद निजी-सहायक सेटअप के लिए चुना गया डिफॉल्ट है; इसे केवल तब सख्त करें जब आपके थ्रेट मॉडल को अनुमोदन या अनुमति-सूची गार्डरेल चाहिए.
• नेटवर्क एक्सपोजर (Gateway bind/auth, Tailscale Serve/Funnel, कमजोर/छोटे auth टोकन).
• ब्राउजर नियंत्रण एक्सपोजर (रिमोट नोड, रिले पोर्ट, रिमोट CDP एंडपॉइंट).
• स्थानीय डिस्क स्वच्छता (अनुमतियाँ, symlinks, config includes, "सिंक किया गया फोल्डर" पाथ).
• Plugins (Plugins स्पष्ट अनुमति-सूची के बिना लोड होते हैं).
• नीति ड्रिफ्ट/गलत कॉन्फिगरेशन (sandbox docker सेटिंग्स कॉन्फिगर की गईं लेकिन sandbox मोड बंद है; अप्रभावी gateway.nodes.denyCommands पैटर्न क्योंकि मिलान केवल सटीक कमांड-नाम पर होता है (उदाहरण के लिए system.run) और shell पाठ की जांच नहीं करता; खतरनाक gateway.nodes.allowCommands प्रविष्टियाँ; वैश्विक tools.profile="minimal" प्रति-एजेंट प्रोफाइल द्वारा ओवरराइड; Plugin-स्वामित्व वाले टूल उदार टूल नीति के तहत पहुंच योग्य).
• रनटाइम अपेक्षा ड्रिफ्ट (उदाहरण के लिए यह मानना कि implicit exec अब भी sandbox का अर्थ रखता है जब tools.exec.host अब auto पर डिफॉल्ट होता है, या sandbox मोड बंद रहते हुए स्पष्ट रूप से tools.exec.host="sandbox" सेट करना).
• मॉडल स्वच्छता (जब कॉन्फिगर किए गए मॉडल पुराने लगें तो चेतावनी; कठोर अवरोध नहीं).

यदि आप --deep चलाते हैं, तो OpenClaw सर्वश्रेष्ठ-प्रयास लाइव Gateway जांच भी करने की कोशिश करता है.

क्रेडेंशियल संग्रहण मानचित्र

पहुंच का ऑडिट करते समय या क्या बैकअप लेना है तय करते समय इसका उपयोग करें:

• WhatsApp: ~/.openclaw/credentials/whatsapp/<accountId>/creds.json
• Telegram बॉट टोकन: config/env या channels.telegram.tokenFile (केवल नियमित फाइल; symlinks अस्वीकृत)
• Discord बॉट टोकन: config/env या SecretRef (env/file/exec प्रदाता)
• Slack टोकन: config/env (channels.slack.*)
• पेयरिंग अनुमति-सूचियाँ:
  • ~/.openclaw/credentials/<channel>-allowFrom.json (डिफॉल्ट खाता)
  • ~/.openclaw/credentials/<channel>-<accountId>-allowFrom.json (गैर-डिफॉल्ट खाते)
• मॉडल auth प्रोफाइल: ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
• Codex रनटाइम स्थिति (डिफॉल्ट): ~/.openclaw/agents/<agentId>/agent/codex-home/
• साझा Codex रनटाइम स्थिति (ऑप्ट-इन): $CODEX_HOME या ~/.codex जब plugins.entries.codex.config.appServer.homeScope "user" हो. यह मोड नेटिव Codex खाते, config, plugins, और थ्रेड स्टोर का उपयोग करता है; इसे केवल owner-नियंत्रित स्थानीय Gateway के लिए सक्षम करें. Codex harness देखें.
• फाइल-समर्थित सीक्रेट्स पेलोड (वैकल्पिक): ~/.openclaw/secrets.json
• लेगेसी OAuth इंपोर्ट: ~/.openclaw/credentials/oauth.json

सुरक्षा ऑडिट चेकलिस्ट

जब ऑडिट निष्कर्ष प्रिंट करता है, तो इसे प्राथमिकता क्रम मानें:

1. कुछ भी "open" + टूल सक्षम: पहले निजी संदेश/समूह लॉक डाउन करें (पेयरिंग/अनुमति-सूचियाँ), फिर टूल नीति/sandboxing सख्त करें.
2. सार्वजनिक नेटवर्क एक्सपोजर (LAN bind, Funnel, गायब auth): तुरंत ठीक करें.
3. ब्राउजर नियंत्रण रिमोट एक्सपोजर: इसे ऑपरेटर पहुंच जैसा मानें (केवल tailnet, नोड को जानबूझकर पेयर करें, सार्वजनिक एक्सपोजर से बचें).
4. अनुमतियाँ: सुनिश्चित करें कि state/config/credentials/auth group/world-readable नहीं हैं.
5. Plugins: केवल वही लोड करें जिन पर आप स्पष्ट रूप से भरोसा करते हैं.
6. मॉडल चयन: टूल वाले किसी भी बॉट के लिए आधुनिक, निर्देश-कठोर मॉडल प्राथमिकता दें.

सुरक्षा ऑडिट शब्दावली

हर ऑडिट निष्कर्ष एक संरचित checkId से कुंजीबद्ध होता है (उदाहरण के लिए gateway.bind_no_auth या tools.exec.security_full_configured). सामान्य गंभीरता वर्ग:

• fs.* - state, config, credentials, auth profiles पर फाइलसिस्टम अनुमतियाँ.
• gateway.* - bind मोड, auth, Tailscale, Control UI, trusted-proxy सेटअप.
• hooks.*, browser.*, sandbox.*, tools.exec.* - प्रति-सतह हार्डनिंग.
• plugins.*, skills.* - Plugin/skill सप्लाई चेन और स्कैन निष्कर्ष.
• security.exposure.* - क्रॉस-कटिंग जांचें जहां पहुंच नीति टूल ब्लास्ट रेडियस से मिलती है.

गंभीरता स्तर, fix keys, और auto-fix समर्थन के साथ पूरा कैटलॉग सुरक्षा ऑडिट जांच पर देखें.

HTTP पर Control UI

Control UI को डिवाइस पहचान जनरेट करने के लिए सुरक्षित संदर्भ (HTTPS या localhost) चाहिए. gateway.controlUi.allowInsecureAuth एक स्थानीय संगतता टॉगल है:

• localhost पर, यह पेज को गैर-सुरक्षित HTTP पर लोड किए जाने पर डिवाइस पहचान के बिना Control UI auth की अनुमति देता है.
• यह पेयरिंग जांचों को बाइपास नहीं करता.
• यह रिमोट (गैर-localhost) डिवाइस पहचान आवश्यकताओं को शिथिल नहीं करता.

HTTPS (Tailscale Serve) को प्राथमिकता दें या UI को 127.0.0.1 पर खोलें.

केवल break-glass परिदृश्यों के लिए, gateway.controlUi.dangerouslyDisableDeviceAuth डिवाइस पहचान जांचों को पूरी तरह अक्षम करता है. यह गंभीर सुरक्षा डाउनग्रेड है; इसे बंद रखें जब तक आप सक्रिय रूप से डीबग नहीं कर रहे हों और जल्दी वापस ला सकें.

इन खतरनाक flags से अलग, सफल gateway.auth.mode: "trusted-proxy" डिवाइस पहचान के बिना ऑपरेटर Control UI सत्रों को प्रवेश दे सकता है. यह जानबूझकर auth-mode व्यवहार है, allowInsecureAuth शॉर्टकट नहीं, और यह फिर भी node-role Control UI सत्रों तक विस्तारित नहीं होता.

openclaw security audit इस सेटिंग के सक्षम होने पर चेतावनी देता है.

असुरक्षित या खतरनाक flags सारांश

ज्ञात असुरक्षित/खतरनाक डीबग स्विच सक्षम होने पर openclaw security audit config.insecure_or_dangerous_flags उठाता है. इन्हें उत्पादन में unset रखें. हर सक्षम flag अपने अलग निष्कर्ष के रूप में रिपोर्ट होता है. यदि ऑडिट suppressions कॉन्फिगर हैं, तो security.audit.suppressions.active सक्रिय ऑडिट आउटपुट में बना रहता है, भले ही मेल खाते निष्कर्ष suppressedFindings में चले जाएँ.

रिवर्स प्रॉक्सी कॉन्फिगरेशन

यदि आप Gateway को रिवर्स प्रॉक्सी (nginx, Caddy, Traefik, आदि) के पीछे चलाते हैं, तो उचित forwarded-client IP हैंडलिंग के लिए gateway.trustedProxies कॉन्फिगर करें.

जब Gateway किसी ऐसे पते से प्रॉक्सी हेडर पहचानता है जो trustedProxies में नहीं है, तो वह कनेक्शनों को स्थानीय क्लाइंट नहीं मानेगा. यदि gateway auth अक्षम है, तो वे कनेक्शन अस्वीकृत कर दिए जाते हैं. यह authentication bypass को रोकता है, जहां proxied कनेक्शन अन्यथा localhost से आते हुए दिखते और स्वचालित trust प्राप्त करते.

gateway.trustedProxies gateway.auth.mode: "trusted-proxy" को भी फीड करता है, लेकिन वह auth मोड अधिक सख्त है:

• trusted-proxy auth डिफॉल्ट रूप से loopback-source proxies पर fails closed
• same-host local loopback रिवर्स प्रॉक्सी स्थानीय-क्लाइंट पहचान और forwarded IP हैंडलिंग के लिए gateway.trustedProxies का उपयोग कर सकते हैं
• same-host local loopback रिवर्स प्रॉक्सी gateway.auth.mode: "trusted-proxy" को केवल तब संतुष्ट कर सकते हैं जब gateway.auth.trustedProxy.allowLoopback = true; अन्यथा token/password auth का उपयोग करें

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}

जब trustedProxies कॉन्फिगर होता है, Gateway क्लाइंट IP निर्धारित करने के लिए X-Forwarded-For का उपयोग करता है. X-Real-IP डिफॉल्ट रूप से अनदेखा किया जाता है, जब तक gateway.allowRealIpFallback: true स्पष्ट रूप से सेट न हो.

Trusted proxy हेडर node device pairing को स्वचालित रूप से trusted नहीं बनाते. gateway.nodes.pairing.autoApproveCidrs एक अलग, डिफॉल्ट रूप से अक्षम ऑपरेटर नीति है. सक्षम होने पर भी, loopback-source trusted-proxy header paths node auto-approval से बाहर रखे जाते हैं क्योंकि स्थानीय कॉलर उन हेडर को forge कर सकते हैं, तब भी जब loopback trusted-proxy auth स्पष्ट रूप से सक्षम हो.

अच्छा रिवर्स प्रॉक्सी व्यवहार (incoming forwarding headers को overwrite करें):

proxy_set_header X-Forwarded-For $remote_addr;proxy_set_header X-Real-IP $remote_addr;

खराब रिवर्स प्रॉक्सी व्यवहार (untrusted forwarding headers को append/preserve करें):

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

HSTS और origin नोट्स

• OpenClaw gateway पहले local/loopback है। यदि आप TLS को reverse proxy पर terminate करते हैं, तो proxy-facing HTTPS domain पर वहीं HSTS सेट करें।
• यदि gateway स्वयं HTTPS terminate करता है, तो आप OpenClaw responses से HSTS header emit करने के लिए gateway.http.securityHeaders.strictTransportSecurity सेट कर सकते हैं।
• विस्तृत deployment guidance Trusted Proxy Auth में है।
• non-loopback Control UI deployments के लिए, gateway.controlUi.allowedOrigins default रूप से आवश्यक है।
• gateway.controlUi.allowedOrigins: ["*"] एक स्पष्ट allow-all browser-origin policy है, hardened default नहीं। tightly controlled local testing के बाहर इससे बचें।
• loopback पर browser-origin auth failures अभी भी rate-limited होते हैं, भले ही सामान्य loopback exemption enabled हो, लेकिन lockout key एक shared localhost bucket के बजाय प्रत्येक normalized Origin value तक scoped होती है।
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true Host-header origin fallback mode enable करता है; इसे dangerous operator-selected policy मानें।
• DNS rebinding और proxy-host header behavior को deployment hardening concerns मानें; trustedProxies को tight रखें और gateway को सीधे public internet पर expose करने से बचें।

Local session logs disk पर रहते हैं

OpenClaw session transcripts को disk पर ~/.openclaw/agents/<agentId>/sessions/*.jsonl के अंतर्गत store करता है। यह session continuity और (वैकल्पिक रूप से) session memory indexing के लिए आवश्यक है, लेकिन इसका अर्थ यह भी है कि filesystem access वाला कोई भी process/user उन logs को पढ़ सकता है। disk access को trust boundary मानें और ~/.openclaw पर permissions lock down करें (नीचे audit section देखें)। यदि आपको agents के बीच मजबूत isolation चाहिए, तो उन्हें अलग OS users या अलग hosts के अंतर्गत चलाएँ।

Node execution (system.run)

यदि कोई macOS Node paired है, तो Gateway उस Node पर system.run invoke कर सकता है। यह Mac पर remote code execution है:

• Node pairing (approval + token) आवश्यक है।
• Gateway Node pairing per-command approval surface नहीं है। यह Node identity/trust और token issuance स्थापित करता है।
• Gateway gateway.nodes.allowCommands / denyCommands के माध्यम से coarse global Node command policy लागू करता है।
• Mac पर Settings → Exec approvals (security + ask + allowlist) के माध्यम से नियंत्रित।
• per-node system.run policy Node की अपनी exec approvals file (exec.approvals.node.*) है, जो gateway की global command-ID policy से अधिक strict या अधिक loose हो सकती है।
• security="full" और ask="off" के साथ चल रहा Node default trusted-operator model का पालन कर रहा है। जब तक आपका deployment स्पष्ट रूप से tighter approval या allowlist stance की मांग न करे, इसे expected behavior मानें।
• Approval mode exact request context और, जहाँ संभव हो, एक concrete local script/file operand bind करता है। यदि OpenClaw किसी interpreter/runtime command के लिए ठीक एक direct local file identify नहीं कर सकता, तो approval-backed execution को full semantic coverage का वादा करने के बजाय deny किया जाता है।
• host=node के लिए, approval-backed runs एक canonical prepared systemRunPlan भी store करते हैं; बाद के approved forwards उसी stored plan को reuse करते हैं, और gateway validation approval request बनने के बाद command/cwd/session context में caller edits को reject करता है।
• यदि आप remote execution नहीं चाहते, तो security को deny पर सेट करें और उस Mac के लिए Node pairing हटाएँ।

यह अंतर triage के लिए मायने रखता है:

• यदि reconnecting paired Node अलग command list advertise करता है, तो यह अपने आप में vulnerability नहीं है, बशर्ते Gateway global policy और Node की local exec approvals अभी भी actual execution boundary enforce करें।
• Node pairing metadata को second hidden per-command approval layer मानने वाली reports आमतौर पर policy/UX confusion होती हैं, security boundary bypass नहीं।

Dynamic skills (watcher / remote nodes)

OpenClaw mid-session skills list refresh कर सकता है:

• Skills watcher: SKILL.md में changes अगले agent turn पर skills snapshot update कर सकते हैं।
• Remote nodes: macOS Node connect करने से macOS-only skills eligible हो सकते हैं (bin probing के आधार पर)।

skill folders को trusted code मानें और उन्हें modify कर सकने वालों को restrict करें।

Threat model

आपका AI assistant कर सकता है:

• arbitrary shell commands execute करना
• files read/write करना
• network services access करना
• किसी को भी messages भेजना (यदि आप उसे WhatsApp access देते हैं)

जो लोग आपको message करते हैं, वे कर सकते हैं:

• आपके AI को bad things करने के लिए trick करने की कोशिश
• आपके data तक access के लिए social engineering
• infrastructure details के लिए probe करना

Core concept: intelligence से पहले access control

यहाँ अधिकांश failures fancy exploits नहीं होते - वे "किसी ने bot को message किया और bot ने वही कर दिया जो उससे कहा गया।" होते हैं।

OpenClaw का stance:

• Identity first: तय करें कि bot से कौन बात कर सकता है (DM pairing / allowlists / explicit "open")।
• Scope next: तय करें कि bot कहाँ act कर सकता है (group allowlists + mention gating, tools, sandboxing, device permissions)।
• Model last: मानें कि model manipulate किया जा सकता है; design ऐसा करें कि manipulation का blast radius limited हो।

Command authorization model

Slash commands और directives केवल authorized senders के लिए honored होते हैं। Authorization channel allowlists/pairing plus commands.useAccessGroups से derive होता है (Configuration और Slash commands देखें)। यदि कोई channel allowlist empty है या उसमें "*" शामिल है, तो उस channel के लिए commands effectively open हैं।

/exec authorized operators के लिए session-only convenience है। यह config write नहीं करता या दूसरे sessions change नहीं करता।

Control plane tools risk

दो built-in tools persistent control-plane changes कर सकते हैं:

• gateway config.schema.lookup / config.get के साथ config inspect कर सकता है, और config.apply, config.patch, तथा update.run के साथ persistent changes कर सकता है।
• cron scheduled jobs बना सकता है जो original chat/task समाप्त होने के बाद भी चलते रहते हैं।

agent-facing gateway runtime tool अभी भी tools.exec.ask या tools.exec.security rewrite करने से मना करता है; legacy tools.bash.* aliases को write से पहले उसी protected exec paths में normalize किया जाता है। Agent-driven gateway config.apply और gateway config.patch edits default रूप से fail-closed हैं: केवल low-risk runtime tuning, mention-gating, और visible-reply paths का narrow set agent-tunable है। Global model defaults और prompt overlays operator-controlled रहते हैं। इसलिए new sensitive config trees protected रहती हैं, जब तक उन्हें जानबूझकर allowlist में add न किया जाए।

किसी भी agent/surface के लिए जो untrusted content handle करता है, इन्हें default रूप से deny करें:

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

commands.restart=false केवल restart actions block करता है। यह gateway config/update actions disable नहीं करता।

Plugins

Plugins Gateway के साथ in-process चलते हैं। उन्हें trusted code मानें:

• केवल उन sources से plugins install करें जिन पर आप trust करते हैं।
• explicit plugins.allow allowlists को prefer करें।
• enable करने से पहले plugin config review करें।
• plugin changes के बाद Gateway restart करें।
• यदि आप plugins install या update करते हैं (openclaw plugins install <package>, openclaw plugins update <id>), तो इसे untrusted code चलाने जैसा मानें:
  • install path active plugin install root के अंतर्गत per-plugin directory है।
  • OpenClaw install/update के दौरान built-in local dangerous-code blocking नहीं चलाता। operator-owned local allow/block decisions के लिए security.installPolicy और diagnostic scanning के लिए openclaw security audit --deep use करें।
  • npm और git plugin installs केवल explicit install/update flow के दौरान package-manager dependency convergence चलाते हैं। Local paths और archives को self-contained plugin packages माना जाता है; OpenClaw उन्हें npm install चलाए बिना copy/reference करता है।
  • pinned, exact versions (@scope/pkg@1.2.3) prefer करें, और enable करने से पहले disk पर unpacked code inspect करें।
  • --dangerously-force-unsafe-install deprecated है और अब plugin install/update behavior change नहीं करता।
  • जब operators को skill और plugin installs के लिए host-specific allow/block decisions लेने हेतु trusted local command चाहिए, तो security.installPolicy configure करें। यह policy source material staged होने के बाद लेकिन installation continue होने से पहले चलती है, ClawHub skills पर भी apply होती है, और deprecated unsafe flags से bypass नहीं होती।

Details: Plugins

DM access model: pairing, allowlist, open, disabled

सभी current DM-capable channels DM policy (dmPolicy या *.dm.policy) support करते हैं जो message processed होने से पहले inbound DMs gate करती है:

• pairing (default): unknown senders को short pairing code मिलता है और bot approved होने तक उनका message ignore करता है। Codes 1 hour के बाद expire होते हैं; repeated DMs new request created होने तक code resend नहीं करेंगे। Pending requests default रूप से 3 per channel तक capped हैं।
• allowlist: unknown senders blocked होते हैं (कोई pairing handshake नहीं)।
• open: किसी को भी DM करने दें (public)। channel allowlist में "*" शामिल होना आवश्यक है (explicit opt-in)।
• disabled: inbound DMs को पूरी तरह ignore करें।

CLI के माध्यम से approve करें:

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

Details + disk पर files: Pairing

DM session isolation (multi-user mode)

Default रूप से, OpenClaw सभी DMs को main session में route करता है ताकि आपके assistant के पास devices और channels में continuity रहे। यदि कई लोग bot को DM कर सकते हैं (open DMs या multi-person allowlist), तो DM sessions isolate करने पर विचार करें:

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

यह group chats को isolated रखते हुए cross-user context leakage रोकता है।

यह messaging-context boundary है, host-admin boundary नहीं। यदि users mutually adversarial हैं और वही Gateway host/config share करते हैं, तो प्रति trust boundary अलग gateways चलाएँ।

Secure DM mode (recommended)

ऊपर दिए snippet को secure DM mode मानें:

• Default: session.dmScope: "main" (continuity के लिए सभी DMs एक session share करते हैं)।
• Local CLI onboarding default: unset होने पर session.dmScope: "per-channel-peer" लिखता है (existing explicit values रखता है)।
• Secure DM mode: session.dmScope: "per-channel-peer" (प्रत्येक channel+sender pair को isolated DM context मिलता है)।
• Cross-channel peer isolation: session.dmScope: "per-peer" (प्रत्येक sender को same type के सभी channels में एक session मिलता है)।

यदि आप same channel पर multiple accounts चलाते हैं, तो इसके बजाय per-account-channel-peer use करें। यदि वही व्यक्ति multiple channels पर आपसे contact करता है, तो उन DM sessions को एक canonical identity में collapse करने के लिए session.identityLinks use करें। Session Management और Configuration देखें।

DMs और groups के लिए allowlists

OpenClaw में दो अलग "who can trigger me?" layers हैं:

• DM अनुमति-सूची (allowFrom / channels.discord.allowFrom / channels.slack.allowFrom; पुराना: channels.discord.dm.allowFrom, channels.slack.dm.allowFrom): सीधे संदेशों में bot से बात करने की अनुमति किसे है।
  • जब dmPolicy="pairing" हो, तो अनुमोदन ~/.openclaw/credentials/ के अंतर्गत account-scoped pairing अनुमति-सूची store में लिखे जाते हैं (default account के लिए <channel>-allowFrom.json, non-default accounts के लिए <channel>-<accountId>-allowFrom.json), और config अनुमति-सूचियों के साथ merge किए जाते हैं।
• Group अनुमति-सूची (channel-specific): bot किन groups/channels/guilds से संदेश स्वीकार करेगा।
  • सामान्य patterns:
    • channels.whatsapp.groups, channels.telegram.groups, channels.imessage.groups: per-group defaults जैसे requireMention; set होने पर, यह group अनुमति-सूची की तरह भी काम करता है (allow-all व्यवहार बनाए रखने के लिए "*" शामिल करें)।
    • groupPolicy="allowlist" + groupAllowFrom: किसी group session के अंदर bot को trigger कौन कर सकता है, इसे restrict करें (WhatsApp/Telegram/Signal/iMessage/Microsoft Teams)।
    • channels.discord.guilds / channels.slack.channels: per-surface अनुमति-सूचियाँ + mention defaults।
  • Group checks इस क्रम में चलते हैं: पहले groupPolicy/group अनुमति-सूचियाँ, फिर mention/reply activation।
  • bot message का reply देना (implicit mention) groupAllowFrom जैसी sender अनुमति-सूचियों को bypass नहीं करता।
  • Security note: dmPolicy="open" और groupPolicy="open" को अंतिम उपाय वाली settings मानें। इन्हें बहुत कम इस्तेमाल किया जाना चाहिए; pairing + अनुमति-सूचियों को प्राथमिकता दें, जब तक कि आप room के हर member पर पूरी तरह भरोसा न करते हों।

विवरण: Configuration और Groups

Prompt injection (यह क्या है, यह क्यों मायने रखता है)

Prompt injection तब होता है जब कोई attacker ऐसा message बनाता है जो model को कुछ असुरक्षित करने के लिए manipulate करता है ("ignore your instructions", "dump your filesystem", "follow this link and run commands", आदि)।

मजबूत system prompts के साथ भी, prompt injection हल नहीं हुआ है। System prompt guardrails केवल soft guidance हैं; hard enforcement tool policy, exec approvals, sandboxing, और channel अनुमति-सूचियों से आता है (और operators design के अनुसार इन्हें disable कर सकते हैं)। व्यवहार में ये चीज़ें मदद करती हैं:

• Inbound DMs को locked down रखें (pairing/अनुमति-सूचियाँ)।
• Groups में mention gating को प्राथमिकता दें; public rooms में "always-on" bots से बचें।
• Links, attachments, और paste किए गए instructions को default रूप से hostile मानें।
• Sensitive tool execution को sandbox में run करें; secrets को agent के reachable filesystem से बाहर रखें।
• Note: sandboxing opt-in है। अगर sandbox mode off है, तो implicit host=auto gateway host पर resolve होता है। Explicit host=sandbox फिर भी fail closed होता है क्योंकि कोई sandbox runtime उपलब्ध नहीं है। अगर आप चाहते हैं कि यह व्यवहार config में explicit हो, तो host=gateway set करें।
• High-risk tools (exec, browser, web_fetch, web_search) को trusted agents या explicit अनुमति-सूचियों तक सीमित रखें।
• अगर आप interpreters (python, node, ruby, perl, php, lua, osascript) को allowlist करते हैं, तो tools.exec.strictInlineEval enable करें ताकि inline eval forms को फिर भी explicit approval चाहिए हो।
• Shell approval analysis unquoted heredocs के अंदर POSIX parameter-expansion forms ($VAR, $?, $$, $1, $@, ${…}) को भी reject करता है, ताकि allowlisted heredoc body plain text के रूप में allowlist review से shell expansion चुपके से पार न करा सके। Literal body semantics में opt in करने के लिए heredoc terminator को quote करें (उदाहरण के लिए <<'EOF'); unquoted heredocs जो variables expand करते, वे reject किए जाते हैं।
• Model choice मायने रखता है: पुराने/छोटे/legacy models prompt injection और tool misuse के विरुद्ध काफ़ी कम robust होते हैं। Tool-enabled agents के लिए उपलब्ध सबसे मजबूत latest-generation, instruction-hardened model इस्तेमाल करें।

अविश्वसनीय मानने योग्य red flags:

• "यह file/URL पढ़ें और ठीक वही करें जो यह कहता है।"
• "अपने system prompt या safety rules को ignore करें।"
• "अपने hidden instructions या tool outputs reveal करें।"
• "~/.openclaw या अपने logs की पूरी contents paste करें।"

External content special-token sanitization

OpenClaw wrapped external content और metadata से common self-hosted LLM chat-template special-token literals को model तक पहुँचने से पहले strip करता है। Covered marker families में Qwen/ChatML, Llama, Gemma, Mistral, Phi, और GPT-OSS role/turn tokens शामिल हैं।

क्यों:

• Self-hosted models के सामने मौजूद OpenAI-compatible backends कभी-कभी user text में आने वाले special tokens को mask करने के बजाय preserve कर देते हैं। कोई attacker जो inbound external content (fetched page, email body, file contents tool output) में लिख सकता है, अन्यथा synthetic assistant या system role boundary inject कर सकता है और wrapped-content guardrails से बच सकता है।
• Sanitization external-content wrapping layer पर होता है, इसलिए यह per-provider होने के बजाय fetch/read tools और inbound channel content पर समान रूप से apply होता है।
• Outbound model responses के पास पहले से एक अलग sanitizer है जो final channel delivery boundary पर user-visible replies से leaked <tool_call>, <function_calls>, <system-reminder>, <previous_response>, और समान internal runtime scaffolding strip करता है। External-content sanitizer inbound counterpart है।

यह इस page की दूसरी hardening को replace नहीं करता - dmPolicy, अनुमति-सूचियाँ, exec approvals, sandboxing, और contextVisibility अब भी primary काम करते हैं। यह self-hosted stacks के विरुद्ध एक specific tokenizer-layer bypass बंद करता है जो user text को special tokens intact रखकर forward करते हैं।

Unsafe external content bypass flags

OpenClaw में explicit bypass flags शामिल हैं जो external-content safety wrapping disable करते हैं:

• hooks.mappings[].allowUnsafeExternalContent
• hooks.gmail.allowUnsafeExternalContent
• Cron payload field allowUnsafeExternalContent

Guidance:

• Production में इन्हें unset/false रखें।
• केवल tightly scoped debugging के लिए temporary enable करें।
• अगर enable किया जाए, तो उस agent को isolate करें (sandbox + minimal tools + dedicated session namespace)।

Hooks risk note:

• Hook payloads untrusted content हैं, भले ही delivery आपके control वाले systems से आए (mail/docs/web content prompt injection carry कर सकता है)।
• Weak model tiers यह risk बढ़ाते हैं। Hook-driven automation के लिए strong modern model tiers को प्राथमिकता दें और tool policy tight रखें (tools.profile: "messaging" या stricter), साथ ही जहाँ संभव हो sandboxing भी।

Prompt injection के लिए public DMs आवश्यक नहीं हैं

भले ही bot को message केवल आप कर सकते हों, prompt injection फिर भी किसी भी untrusted content के ज़रिए हो सकता है जिसे bot पढ़ता है (web search/fetch results, browser pages, emails, docs, attachments, pasted logs/code)। दूसरे शब्दों में: sender ही एकमात्र threat surface नहीं है; content itself adversarial instructions carry कर सकता है।

जब tools enabled हों, तो typical risk context exfiltrate करना या tool calls trigger करना होता है। Blast radius घटाएँ:

• Untrusted content summarize करने के लिए read-only या tool-disabled reader agent इस्तेमाल करके, फिर summary अपने main agent को pass करें।
• Tool-enabled agents के लिए web_search / web_fetch / browser off रखें, जब तक जरूरत न हो।
• OpenResponses URL inputs (input_file / input_image) के लिए tight gateway.http.endpoints.responses.files.urlAllowlist और gateway.http.endpoints.responses.images.urlAllowlist set करें, और maxUrlParts low रखें। Empty अनुमति-सूचियाँ unset मानी जाती हैं; अगर आप URL fetching पूरी तरह disable करना चाहते हैं तो files.allowUrl: false / images.allowUrl: false इस्तेमाल करें।
• OpenResponses file inputs के लिए, decoded input_file text फिर भी untrusted external content के रूप में inject होता है। File text trusted है, इस पर सिर्फ इसलिए rely न करें क्योंकि Gateway ने इसे locally decode किया। Injected block में फिर भी explicit <<&lt;EXTERNAL_UNTRUSTED_CONTENT ...&gt;>> boundary markers और Source: External metadata रहता है, भले ही यह path लंबा SECURITY NOTICE: banner omit करता हो।
• यही marker-based wrapping तब apply होता है जब media-understanding attached documents से text extract करता है और उस text को media prompt में append करता है।
• किसी भी untrusted input को touch करने वाले agent के लिए sandboxing और strict tool अनुमति-सूचियाँ enable करें।
• Secrets को prompts से बाहर रखें; इसके बजाय उन्हें gateway host पर env/config के ज़रिए pass करें।

Self-hosted LLM backends

OpenAI-compatible self-hosted backends जैसे vLLM, SGLang, TGI, LM Studio, या custom Hugging Face tokenizer stacks hosted providers से इस मामले में अलग हो सकते हैं कि chat-template special tokens कैसे handle किए जाते हैं। अगर कोई backend literal strings जैसे <|im_start|>, <|start_header_id|>, या <start_of_turn> को user content के अंदर structural chat-template tokens के रूप में tokenize करता है, तो untrusted text tokenizer layer पर role boundaries forge करने की कोशिश कर सकता है।

OpenClaw wrapped external content से common model-family special-token literals को model को dispatch करने से पहले strip करता है। External-content wrapping enabled रखें, और जब available हो, तो ऐसी backend settings को प्राथमिकता दें जो user-provided content में special tokens को split या escape करती हैं। Hosted providers जैसे OpenAI और Anthropic पहले से अपनी request-side sanitization apply करते हैं।

Model strength (security note)

Prompt injection resistance model tiers में uniform नहीं है। Smaller/cheaper models आम तौर पर tool misuse और instruction hijacking के प्रति अधिक susceptible होते हैं, खासकर adversarial prompts के तहत।

Recommendations:

• ऐसे किसी भी bot के लिए latest generation, best-tier model इस्तेमाल करें जो tools run कर सकता है या files/networks touch कर सकता है।
• Tool-enabled agents या untrusted inboxes के लिए older/weaker/smaller tiers इस्तेमाल न करें; prompt-injection risk बहुत high है।
• अगर आपको smaller model इस्तेमाल करना ही है, तो blast radius घटाएँ (read-only tools, strong sandboxing, minimal filesystem access, strict अनुमति-सूचियाँ)।
• Small models run करते समय, सभी sessions के लिए sandboxing enable करें और inputs tightly controlled न हों तो web_search/web_fetch/browser disable करें।
• Trusted input और no tools वाले chat-only personal assistants के लिए smaller models आम तौर पर ठीक होते हैं।

Groups में reasoning और verbose output

/reasoning, /verbose, और /trace internal reasoning, tool output, या plugin diagnostics expose कर सकते हैं जो public channel के लिए अभिप्रेत नहीं था। Group settings में, इन्हें debug only मानें और off रखें जब तक आपको स्पष्ट रूप से इनकी जरूरत न हो।

Guidance:

• Public rooms में /reasoning, /verbose, और /trace disabled रखें।
• अगर आप इन्हें enable करते हैं, तो केवल trusted DMs या tightly controlled rooms में ऐसा करें।
• याद रखें: verbose और trace output में tool args, URLs, plugin diagnostics, और model द्वारा देखा गया data शामिल हो सकता है।

Configuration hardening examples

File permissions

Gateway host पर config + state private रखें:

• ~/.openclaw/openclaw.json: 600 (सिर्फ user read/write)
• ~/.openclaw: 700 (सिर्फ user)

openclaw doctor warning दे सकता है और इन permissions को tighten करने की पेशकश कर सकता है।

Network exposure (bind, port, firewall)

Gateway एक ही port पर WebSocket + HTTP multiplex करता है:

• Default: 18789
• Config/flags/env: gateway.port, --port, OPENCLAW_GATEWAY_PORT

इस HTTP surface में Control UI और canvas host शामिल हैं:

• Control UI (SPA assets) (default base path /)
• Canvas host: /__openclaw__/canvas/ और /__openclaw__/a2ui/ (arbitrary HTML/JS; untrusted content की तरह treat करें)

अगर आप canvas content को normal browser में load करते हैं, तो इसे किसी भी other untrusted web page जैसा मानें:

• Canvas host को untrusted networks/users के सामने expose न करें।
• जब तक आप implications को पूरी तरह न समझते हों, canvas content को privileged web surfaces के same origin के साथ share न कराएँ।

Bind mode control करता है कि Gateway कहाँ listen करता है:

• gateway.bind: "loopback" (default): केवल local clients connect कर सकते हैं।
• Non-loopback binds ("lan", "tailnet", "custom") attack surface बढ़ाते हैं। इन्हें केवल gateway auth (shared token/password या correctly configured trusted proxy) और real firewall के साथ इस्तेमाल करें।

व्यावहारिक नियम:

• LAN बाइंड्स के बजाय Tailscale Serve को प्राथमिकता दें (Serve Gateway को loopback पर रखता है, और Tailscale एक्सेस संभालता है)।
• अगर आपको LAN से बाइंड करना ही पड़े, तो पोर्ट को स्रोत IPs की सख्त allowlist तक firewall करें; इसे व्यापक रूप से port-forward न करें।
• Gateway को कभी भी 0.0.0.0 पर बिना authentication के expose न करें।

UFW के साथ Docker port publishing

अगर आप VPS पर Docker के साथ OpenClaw चलाते हैं, तो याद रखें कि published container ports (-p HOST:CONTAINER या Compose ports:) Docker की forwarding chains के माध्यम से route होते हैं, केवल host INPUT rules से नहीं।

Docker traffic को अपनी firewall policy के साथ aligned रखने के लिए, DOCKER-USER में rules enforce करें (यह chain Docker के अपने accept rules से पहले evaluate होती है)। कई modern distros पर, iptables/ip6tables iptables-nft frontend का उपयोग करते हैं और फिर भी इन rules को nftables backend पर लागू करते हैं।

Minimal allowlist example (IPv4):

# /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 RETURNCOMMIT

IPv6 की अलग tables होती हैं। अगर Docker IPv6 enabled है, तो /etc/ufw/after6.rules में matching policy जोड़ें।

Docs snippets में eth0 जैसे interface names hardcode करने से बचें। Interface names VPS images (ens3, enp*, आदि) में अलग-अलग होते हैं और mismatches अनजाने में आपके deny rule को skip कर सकते हैं।

Reload के बाद quick validation:

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

Expected external ports केवल वही होने चाहिए जिन्हें आप जानबूझकर expose करते हैं (अधिकांश setups के लिए: SSH + आपके reverse proxy ports)।

mDNS/Bonjour discovery

जब bundled bonjour Plugin enabled होता है, तो Gateway local device discovery के लिए mDNS (_openclaw-gw._tcp port 5353 पर) के माध्यम से अपनी presence broadcast करता है। Full mode में, इसमें TXT records शामिल होते हैं जो operational details expose कर सकते हैं:

• cliPath: CLI binary का full filesystem path (username और install location उजागर करता है)
• sshPort: host पर SSH availability advertise करता है
• displayName, lanHost: hostname information

Operational security consideration: Infrastructure details broadcast करने से local network पर मौजूद किसी भी व्यक्ति के लिए reconnaissance आसान हो जाता है। Filesystem paths और SSH availability जैसी “harmless” जानकारी भी attackers को आपका environment map करने में मदद करती है।

Recommendations:

1. जब तक LAN discovery की जरूरत न हो, Bonjour disabled रखें। Bonjour macOS hosts पर auto-start होता है और बाकी जगह opt-in है; direct Gateway URLs, Tailnet, SSH, या wide-area DNS-SD local multicast से बचते हैं।

2. Minimal mode (Bonjour enabled होने पर default, exposed gateways के लिए recommended): mDNS broadcasts से sensitive fields omit करें:

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

3. अगर आप Plugin enabled रखना चाहते हैं लेकिन local device discovery suppress करना चाहते हैं, तो mDNS mode disable करें:

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

4. Full mode (opt-in): TXT records में cliPath + sshPort शामिल करें:

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

5. Environment variable (वैकल्पिक): config changes के बिना mDNS disable करने के लिए OPENCLAW_DISABLE_BONJOUR=1 set करें।

जब Bonjour minimal mode में enabled होता है, तो Gateway device discovery (role, gatewayPort, transport) के लिए पर्याप्त जानकारी broadcast करता है लेकिन cliPath और sshPort omit करता है। जिन apps को CLI path information चाहिए, वे इसे authenticated WebSocket connection के माध्यम से fetch कर सकते हैं।

Gateway WebSocket को lock down करें (local auth)

Gateway auth default रूप से required है। अगर कोई valid gateway auth path configured नहीं है, तो Gateway WebSocket connections refuse करता है (fail-closed)।

Onboarding default रूप से token generate करता है (loopback के लिए भी), इसलिए local clients को authenticate करना होगा।

Token set करें ताकि सभी WS clients को authenticate करना पड़े:

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

Doctor आपके लिए एक generate कर सकता है: openclaw doctor --generate-gateway-token.

वैकल्पिक: wss:// उपयोग करते समय gateway.remote.tlsFingerprint के साथ remote TLS pin करें। Plaintext ws:// loopback, private IP literals, .local, और Tailnet *.ts.net gateway URLs के लिए accepted है। अन्य trusted private-DNS names के लिए, client process पर break-glass के रूप में OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 set करें। यह जानबूझकर केवल process environment है, openclaw.json config key नहीं। Mobile pairing और Android manual या scanned gateway routes ज्यादा strict हैं: cleartext loopback के लिए accepted है, लेकिन private-LAN, link-local, .local, और dotless hostnames को TLS उपयोग करना होगा, जब तक कि आप explicitly trusted private-network cleartext path में opt in न करें।

Local device pairing:

• Same-host clients को smooth रखने के लिए direct local loopback connects के लिए device pairing auto-approved होती है।
• OpenClaw में trusted shared-secret helper flows के लिए narrow backend/container-local self-connect path भी है।
• Tailnet और LAN connects, same-host tailnet binds सहित, pairing के लिए remote माने जाते हैं और फिर भी approval चाहिए।
• Loopback request पर forwarded-header evidence loopback locality को disqualify करता है। Metadata-upgrade auto-approval narrow scope में है। दोनों rules के लिए Gateway pairing देखें।

Auth modes:

• gateway.auth.mode: "token": shared bearer token (अधिकांश setups के लिए recommended)।
• gateway.auth.mode: "password": password auth (env के माध्यम से set करना prefer करें: OPENCLAW_GATEWAY_PASSWORD)।
• gateway.auth.mode: "trusted-proxy": users को authenticate करने और headers के माध्यम से identity pass करने के लिए identity-aware reverse proxy पर trust करें (Trusted Proxy Auth देखें)।

Rotation checklist (token/password):

1. नया secret generate/set करें (gateway.auth.token या OPENCLAW_GATEWAY_PASSWORD)।
2. Gateway restart करें (या अगर macOS app Gateway supervise करता है, तो app restart करें)।
3. किसी भी remote clients को update करें (gateway.remote.token / .password उन machines पर जो Gateway को call करती हैं)।
4. Verify करें कि आप पुराने credentials से अब connect नहीं कर सकते।

Tailscale Serve identity headers

जब gateway.auth.allowTailscale true होता है (Serve के लिए default), OpenClaw Control UI/WebSocket authentication के लिए Tailscale Serve identity headers (tailscale-user-login) accept करता है। OpenClaw local Tailscale daemon (tailscale whois) के माध्यम से x-forwarded-for address resolve करके और उसे header से match करके identity verify करता है। यह केवल उन requests के लिए trigger होता है जो loopback hit करती हैं और Tailscale द्वारा injected x-forwarded-for, x-forwarded-proto, और x-forwarded-host शामिल करती हैं। इस async identity check path के लिए, same {scope, ip} के failed attempts limiter failure record करने से पहले serialized होते हैं। इसलिए एक Serve client से concurrent bad retries दो plain mismatches की तरह race करने के बजाय second attempt को तुरंत lock out कर सकते हैं। HTTP API endpoints (उदाहरण के लिए /v1/*, /tools/invoke, और /api/channels/*) Tailscale identity-header auth का उपयोग नहीं करते। वे फिर भी gateway के configured HTTP auth mode का पालन करते हैं।

Important boundary note:

• Gateway HTTP bearer auth प्रभावी रूप से all-or-nothing operator access है।
• ऐसे credentials जो /v1/chat/completions, /v1/responses, /api/v1/admin/rpc जैसे plugin routes, या /api/channels/* call कर सकते हैं, उन्हें उस gateway के लिए full-access operator secrets मानें।
• OpenAI-compatible HTTP surface पर, shared-secret bearer auth full default operator scopes (operator.admin, operator.approvals, operator.pairing, operator.read, operator.talk.secrets, operator.write) और agent turns के लिए owner semantics restore करता है; narrower x-openclaw-scopes values उस shared-secret path को reduce नहीं करतीं।
• HTTP पर per-request scope semantics केवल तब apply होते हैं जब request trusted proxy auth जैसे identity-bearing mode से आती है, या explicitly no-auth private ingress से।
• उन identity-bearing modes में, x-openclaw-scopes omit करने पर normal operator default scope set पर fallback होता है; जब आप narrower scope set चाहते हैं, तो header explicitly भेजें। x-openclaw-model जैसे owner-level OpenAI-compatible headers को scopes narrowed होने पर operator.admin चाहिए।
• /tools/invoke और HTTP session history endpoints वही shared-secret rule follow करते हैं: token/password bearer auth वहां भी full operator access माना जाता है, जबकि identity-bearing modes declared scopes का सम्मान करते हैं।
• इन credentials को untrusted callers के साथ share न करें; हर trust boundary के लिए separate gateways prefer करें।

Trust assumption: tokenless Serve auth मानता है कि gateway host trusted है। इसे hostile same-host processes के विरुद्ध protection न मानें। अगर untrusted local code gateway host पर run हो सकता है, तो gateway.auth.allowTailscale disable करें और gateway.auth.mode: "token" या "password" के साथ explicit shared-secret auth require करें।

Security rule: अपने reverse proxy से ये headers forward न करें। अगर आप gateway के सामने TLS terminate या proxy करते हैं, तो gateway.auth.allowTailscale disable करें और इसके बजाय shared-secret auth (gateway.auth.mode: "token" या "password") या Trusted Proxy Auth उपयोग करें।

Trusted proxies:

• अगर आप Gateway के सामने TLS terminate करते हैं, तो gateway.trustedProxies को अपने proxy IPs पर set करें।
• OpenClaw उन IPs से आए x-forwarded-for (या x-real-ip) पर trust करेगा ताकि local pairing checks और HTTP auth/local checks के लिए client IP determine की जा सके।
• सुनिश्चित करें कि आपका proxy x-forwarded-for को overwrite करता है और Gateway port तक direct access block करता है।

Tailscale और Web overview देखें।

node host के माध्यम से browser control (recommended)

अगर आपका Gateway remote है लेकिन browser किसी दूसरी machine पर चलता है, तो browser machine पर एक node host चलाएं और Gateway को browser actions proxy करने दें (Browser tool देखें)। Node pairing को admin access की तरह treat करें।

Recommended pattern:

• Gateway और node host को same tailnet (Tailscale) पर रखें।
• Node को intentionally pair करें; अगर आपको browser proxy routing की जरूरत नहीं है, तो उसे disable करें।

Avoid:

• Relay/control ports को LAN या public Internet पर expose करना।
• Browser control endpoints के लिए Tailscale Funnel (public exposure)।

Disk पर secrets

मान लें कि ~/.openclaw/ (या $OPENCLAW_STATE_DIR/) के अंतर्गत कुछ भी secrets या private data contain कर सकता है:

• openclaw.json: कॉन्फ़िगरेशन में टोकन (gateway, remote gateway), provider सेटिंग्स, और allowlists शामिल हो सकते हैं।
• credentials/**: channel credentials (उदाहरण: WhatsApp creds), pairing allowlists, legacy OAuth imports।
• agents/<agentId>/agent/auth-profiles.json: API keys, token profiles, OAuth tokens, और वैकल्पिक keyRef/tokenRef।
• agents/<agentId>/agent/codex-home/**: प्रति-agent Codex app-server account, config, skills, plugins, native thread state, और diagnostics (डिफ़ॉल्ट)।
• $CODEX_HOME/** या ~/.codex/**: जब Codex plugin स्पष्ट रूप से appServer.homeScope: "user" का उपयोग करता है, Gateway native Codex account, config, plugins, और threads को पढ़ और अपडेट कर सकता है। इसे privileged owner access मानें; यह mode केवल local-stdio है और native thread management केवल owner के लिए है।
• secrets.json (वैकल्पिक): file SecretRef providers (secrets.providers) द्वारा उपयोग किया जाने वाला file-backed secret payload।
• agents/<agentId>/agent/auth.json: legacy compatibility file। Static api_key entries खोजे जाने पर scrub कर दी जाती हैं।
• agents/<agentId>/sessions/**: session transcripts (*.jsonl) + routing metadata (sessions.json) जिनमें private messages और tool output हो सकते हैं।
• bundled plugin packages: installed plugins (साथ में उनके node_modules/)।
• sandboxes/**: tool sandbox workspaces; sandbox के अंदर आपके द्वारा पढ़ी/लिखी गई files की copies जमा हो सकती हैं।

Hardening tips:

• permissions कसी हुई रखें (dirs पर 700, files पर 600)।
• gateway host पर full-disk encryption का उपयोग करें।
• यदि host साझा है, तो Gateway के लिए dedicated OS user account को प्राथमिकता दें।

Workspace .env files

OpenClaw agents और tools के लिए workspace-local .env files लोड करता है, लेकिन उन files को कभी भी gateway runtime controls को चुपचाप override करने नहीं देता।

• Provider credential environment variables untrusted workspace .env files से blocked हैं। उदाहरणों में 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, और installed trusted plugins द्वारा घोषित provider auth keys शामिल हैं। Provider credentials को Gateway process environment, ~/.openclaw/.env ($OPENCLAW_STATE_DIR/.env), config env block, या वैकल्पिक login-shell import में रखें।
• OPENCLAW_* से शुरू होने वाली कोई भी key untrusted workspace .env files से blocked है।
• Matrix, Mattermost, IRC, और Synology Chat के लिए channel endpoint settings भी workspace .env overrides से blocked हैं, ताकि cloned workspaces bundled connector traffic को local endpoint config के जरिए redirect न कर सकें। Endpoint env keys (जैसे MATRIX_HOMESERVER, MATTERMOST_URL, IRC_HOST, SYNOLOGY_CHAT_INCOMING_URL) gateway process environment या env.shellEnv से आनी चाहिए, workspace-loaded .env से नहीं।
• block fail-closed है: future release में जोड़ा गया नया runtime-control variable checked-in या attacker-supplied .env से inherit नहीं किया जा सकता; key ignored रहती है और gateway अपना value रखता है।
• Trusted process/OS environment variables, global runtime dotenv, config env, और enabled login-shell import अब भी लागू होते हैं - यह केवल workspace .env file loading को सीमित करता है।

क्यों: workspace .env files अक्सर agent code के पास रहती हैं, गलती से commit हो जाती हैं, या tools द्वारा लिखी जाती हैं। Provider credentials को block करना cloned workspace को attacker-controlled provider accounts substitute करने से रोकता है। पूरे OPENCLAW_* prefix को block करने का मतलब है कि बाद में नया OPENCLAW_* flag जोड़ना कभी भी workspace state से silent inheritance में regress नहीं कर सकता।

Logs and transcripts (redaction and retention)

Logs और transcripts sensitive info leak कर सकते हैं, भले ही access controls सही हों:

• Gateway logs में tool summaries, errors, और URLs शामिल हो सकते हैं।
• Session transcripts में pasted secrets, file contents, command output, और links शामिल हो सकते हैं।

Recommendations:

• log और transcript redaction चालू रखें (logging.redactSensitive: "tools"; default)।
• logging.redactPatterns के जरिए अपने environment के लिए custom patterns जोड़ें (tokens, hostnames, internal URLs)।
• diagnostics share करते समय raw logs के बजाय openclaw status --all (pasteable, secrets redacted) को प्राथमिकता दें।
• यदि आपको long retention की आवश्यकता नहीं है, तो old session transcripts और log files prune करें।

Details: Logging

DMs: pairing by default

{  channels: { whatsapp: { dmPolicy: "pairing" } },}

Groups: require mention everywhere

{  "channels": {    "whatsapp": {      "groups": {        "*": { "requireMention": true }      }    }  },  "agents": {    "list": [      {        "id": "main",        "groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] }      }    ]  }}

group chats में, केवल स्पष्ट रूप से mention किए जाने पर respond करें।

Separate numbers (WhatsApp, Signal, Telegram)

Phone-number-based channels के लिए, अपने AI को अपने personal number से अलग phone number पर चलाने पर विचार करें:

• Personal number: आपकी conversations private रहती हैं
• Bot number: AI इन्हें appropriate boundaries के साथ handle करता है

Read-only mode (via sandbox and tools)

आप इनको combine करके read-only profile बना सकते हैं:

• agents.defaults.sandbox.workspaceAccess: "ro" (या workspace access नहीं चाहिए तो "none")
• tool allow/deny lists जो write, edit, apply_patch, exec, process, आदि को block करती हैं।

Additional hardening options:

• tools.exec.applyPatch.workspaceOnly: true (default): सुनिश्चित करता है कि sandboxing off होने पर भी apply_patch workspace directory के बाहर write/delete नहीं कर सकता। इसे false केवल तभी set करें जब आप जानबूझकर चाहते हों कि apply_patch workspace के बाहर files को छुए।
• tools.fs.workspaceOnly: true (वैकल्पिक): read/write/edit/apply_patch paths और native prompt image auto-load paths को workspace directory तक restrict करता है (यदि आप आज absolute paths allow करते हैं और single guardrail चाहते हैं तो उपयोगी)।
• filesystem roots narrow रखें: agent workspaces/sandbox workspaces के लिए अपने home directory जैसे broad roots से बचें। Broad roots sensitive local files (उदाहरण के लिए ~/.openclaw के तहत state/config) को filesystem tools के सामने expose कर सकते हैं।

Secure baseline (copy/paste)

एक "safe default" config जो Gateway को private रखता है, DM pairing require करता है, और always-on group bots से बचता है:

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

यदि आप tool execution को भी "safer by default" चाहते हैं, तो किसी भी non-owner agent के लिए sandbox + dangerous tools deny जोड़ें (नीचे "Per-agent access profiles" के अंतर्गत example)।

chat-driven agent turns के लिए built-in baseline: non-owner senders cron या gateway tools का उपयोग नहीं कर सकते।

Sandboxing (recommended)

Dedicated doc: Sandboxing

दो complementary approaches:

• पूरा Gateway Docker में चलाएँ (container boundary): Docker
• Tool sandbox (agents.defaults.sandbox, host gateway + sandbox-isolated tools; Docker default backend है): Sandboxing

sandbox के अंदर agent workspace access पर भी विचार करें:

• agents.defaults.sandbox.workspaceAccess: "none" (default) agent workspace को off-limits रखता है; tools ~/.openclaw/sandboxes के तहत sandbox workspace के विरुद्ध run करते हैं
• agents.defaults.sandbox.workspaceAccess: "ro" agent workspace को /agent पर read-only mount करता है (write/edit/apply_patch disable करता है)
• agents.defaults.sandbox.workspaceAccess: "rw" agent workspace को /workspace पर read/write mount करता है
• अतिरिक्त sandbox.docker.binds normalized और canonicalized source paths के विरुद्ध validate किए जाते हैं। Parent-symlink tricks और canonical home aliases अब भी fail closed होते हैं यदि वे /etc, /var/run, या OS home के तहत credential directories जैसे blocked roots में resolve होते हैं।

Sub-agent delegation guardrail

यदि आप session tools allow करते हैं, तो delegated sub-agent runs को एक और boundary decision के रूप में treat करें:

• जब तक agent को सच में delegation की आवश्यकता न हो, sessions_spawn deny करें।
• agents.defaults.subagents.allowAgents और किसी भी per-agent agents.list[].subagents.allowAgents overrides को known-safe target agents तक restricted रखें।
• किसी भी workflow के लिए जिसे sandboxed रहना ही चाहिए, sessions_spawn को sandbox: "require" के साथ call करें (default inherit है)।
• target child runtime sandboxed नहीं होने पर sandbox: "require" fast fail करता है।

Browser control risks

browser control enable करने से model को real browser चलाने की क्षमता मिलती है। यदि उस browser profile में पहले से logged-in sessions हैं, तो model उन accounts और data तक access कर सकता है। Browser profiles को sensitive state मानें:

• agent के लिए dedicated profile को प्राथमिकता दें (default openclaw profile)।
• agent को अपने personal daily-driver profile की ओर point करने से बचें।
• sandboxed agents के लिए host browser control disabled रखें, जब तक आप उन पर trust न करते हों।
• standalone loopback browser control API केवल shared-secret auth (gateway token bearer auth या gateway password) को honor करता है। यह trusted-proxy या Tailscale Serve identity headers consume नहीं करता।
• browser downloads को untrusted input मानें; isolated downloads directory को प्राथमिकता दें।
• संभव हो तो agent profile में browser sync/password managers disable करें (blast radius घटाता है)।
• remote gateways के लिए, मानें कि "browser control" उस profile की पहुंच वाली किसी भी चीज़ के लिए "operator access" के equivalent है।
• Gateway और node hosts को tailnet-only रखें; browser control ports को LAN या public Internet पर expose करने से बचें।
• जब आवश्यकता न हो तो browser proxy routing disable करें (gateway.nodes.browser.mode="off")।
• Chrome MCP existing-session mode "safer" नहीं है; यह उस host Chrome profile की पहुंच वाली किसी भी चीज़ में आपकी तरह act कर सकता है।

Browser SSRF policy (strict by default)

OpenClaw की browser navigation policy default रूप से strict है: private/internal destinations तब तक blocked रहते हैं जब तक आप explicit opt in न करें।

• Default: browser.ssrfPolicy.dangerouslyAllowPrivateNetwork unset है, इसलिए browser navigation private/internal/special-use destinations को blocked रखता है।
• Legacy alias: compatibility के लिए browser.ssrfPolicy.allowPrivateNetwork अब भी accepted है।
• Opt-in mode: private/internal/special-use destinations allow करने के लिए browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true set करें।
• strict mode में, explicit exceptions के लिए hostnameAllowlist (*.example.com जैसे patterns) और allowedHostnames (exact host exceptions, जिसमें localhost जैसे blocked names शामिल हैं) का उपयोग करें।
• redirect-based pivots घटाने के लिए navigation से पहले request check किया जाता है और navigation के बाद final http(s) URL पर best-effort re-check किया जाता है।

Example strict policy:

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

Per-agent access profiles (multi-agent)

multi-agent routing के साथ, प्रत्येक agent की अपनी sandbox + tool policy हो सकती है: प्रति agent full access, read-only, या no access देने के लिए इसका उपयोग करें। पूरी details और precedence rules के लिए Multi-Agent Sandbox & Tools देखें।

Common use cases:

• Personal agent: full access, no sandbox
• Family/work agent: sandboxed + read-only tools
• Public agent: sandboxed + no filesystem/shell tools

Example: full access (no sandbox)

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

उदाहरण: केवल-पढ़ने वाले टूल + केवल-पढ़ने वाला कार्यक्षेत्र

{  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"],        },      },    ],  },}

उदाहरण: कोई फाइलसिस्टम/शेल एक्सेस नहीं (प्रदाता मैसेजिंग अनुमत)

{  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",          ],        },      },    ],  },}

घटना प्रतिक्रिया

यदि आपका AI कुछ गलत करता है:

नियंत्रित करें

1. इसे रोकें: macOS ऐप को रोकें (यदि वह Gateway की निगरानी करता है) या अपनी openclaw gateway प्रक्रिया समाप्त करें।
2. एक्सपोज़र बंद करें: जब तक आप समझ न लें कि क्या हुआ, gateway.bind: "loopback" सेट करें (या Tailscale Funnel/Serve अक्षम करें)।
3. एक्सेस रोकें: जोखिम भरे DM/समूहों को dmPolicy: "disabled" पर स्विच करें / उल्लेख आवश्यक करें, और यदि आपने "*" allow-all प्रविष्टियां रखी थीं तो उन्हें हटा दें।

रोटेट करें (यदि सीक्रेट लीक हुए हों तो समझौता मानें)

1. Gateway auth (gateway.auth.token / OPENCLAW_GATEWAY_PASSWORD) रोटेट करें और रीस्टार्ट करें।
2. Gateway को कॉल कर सकने वाली किसी भी मशीन पर रिमोट क्लाइंट सीक्रेट (gateway.remote.token / .password) रोटेट करें।
3. प्रदाता/API क्रेडेंशियल रोटेट करें (WhatsApp क्रेड्स, Slack/Discord टोकन, auth-profiles.json में मॉडल/API कुंजियां, और उपयोग होने पर एन्क्रिप्टेड सीक्रेट payload मान)।

ऑडिट करें

1. Gateway लॉग जांचें: /tmp/openclaw/openclaw-YYYY-MM-DD.log (या logging.file)।
2. संबंधित transcript की समीक्षा करें: ~/.openclaw/agents/<agentId>/sessions/*.jsonl।
3. हाल के config बदलावों की समीक्षा करें (कुछ भी जिसने एक्सेस बढ़ाया हो: gateway.bind, gateway.auth, dm/group policies, tools.elevated, plugin बदलाव)।
4. openclaw security audit --deep फिर से चलाएं और पुष्टि करें कि महत्वपूर्ण findings हल हो गई हैं।

रिपोर्ट के लिए एकत्र करें

• टाइमस्टैम्प, gateway होस्ट OS + OpenClaw संस्करण
• session transcript(s) + छोटा log tail (redact करने के बाद)
• हमलावर ने क्या भेजा + एजेंट ने क्या किया
• क्या Gateway loopback से आगे एक्सपोज़ था (LAN/Tailscale Funnel/Serve)

सीक्रेट स्कैनिंग

CI repository पर pre-commit detect-private-key hook चलाता है। यदि यह विफल होता है, committed key material हटाएं या रोटेट करें, फिर स्थानीय रूप से पुन: प्रस्तुत करें:

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

सुरक्षा समस्याओं की रिपोर्ट करना

OpenClaw में vulnerability मिली? कृपया जिम्मेदारी से रिपोर्ट करें:

1. ईमेल: security@openclaw.ai
2. ठीक होने तक सार्वजनिक रूप से पोस्ट न करें
3. हम आपको श्रेय देंगे (जब तक आप गुमनाम रहना पसंद न करें)