--- read_when: - ऐसी सुविधाएँ जोड़ना जो पहुँच या स्वचालन को विस्तृत करती हैं summary: शेल एक्सेस वाले एआई Gateway को चलाने के लिए सुरक्षा संबंधी विचार और खतरा मॉडल title: सुरक्षा x-i18n: generated_at: "2026-07-04T10:42:17Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: 42a398a347f04414c443277c8ab3632953bce73e957c8439883846813f882dd5 source_path: gateway/security/index.md workflow: 16 --- **व्यक्तिगत सहायक trust model.** यह मार्गदर्शन प्रति Gateway एक विश्वसनीय ऑपरेटर सीमा मानता है (एकल-उपयोगकर्ता, व्यक्तिगत-सहायक मॉडल)। OpenClaw एक Agent या Gateway साझा करने वाले कई प्रतिकूल उपयोगकर्ताओं के लिए **hostile multi-tenant** सुरक्षा सीमा **नहीं** है। यदि आपको मिश्रित-विश्वास या प्रतिकूल-उपयोगकर्ता संचालन चाहिए, तो trust boundaries विभाजित करें (अलग Gateway + credentials, आदर्श रूप से अलग OS users या hosts)। ## पहले दायरा: व्यक्तिगत सहायक सुरक्षा मॉडल 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](/hi/gateway/security/exposure-runbook) को pre-flight और rollback checklist की तरह उपयोग करें। ## त्वरित जांच: `openclaw security audit` यह भी देखें: [औपचारिक सत्यापन (सुरक्षा मॉडल)](/hi/security/formal-verification) इसे नियमित रूप से चलाएं (विशेष रूप से config बदलने या network surfaces expose करने के बाद): ```bash openclaw security audit openclaw security audit --deep openclaw security audit --fix openclaw 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](/hi/gateway/security/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](/hi/gateway/security/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](/hi/gateway/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 की तरह उपयोग करें: | Boundary या control | इसका अर्थ | सामान्य गलत पढ़ना | | --------------------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------- | | `gateway.auth` (token/password/trusted-proxy/device auth) | Callers को Gateway APIs पर authenticate करता है | "Secure होने के लिए हर frame पर per-message signatures चाहिए" | | `sessionKey` | Context/session selection के लिए routing key | "Session key एक user auth boundary है" | | Prompt/content guardrails | Model abuse risk घटाते हैं | "Prompt injection अकेले auth bypass साबित करता है" | | `canvas.eval` / browser evaluate | Enabled होने पर intentional operator capability | "कोई भी JS eval primitive इस trust model में अपने-आप vuln है" | | Local TUI `!` shell | Explicit operator-triggered local execution | "Local shell convenience command remote injection है" | | Node pairing और Node commands | Paired devices पर operator-level remote execution | "Remote device control को default रूप से untrusted user access माना जाना चाहिए" | | `gateway.nodes.pairing.autoApproveCidrs` | Opt-in trusted-network Node enrollment policy | "Disabled-by-default allowlist automatic pairing vulnerability है" | ## Design के अनुसार vulnerabilities नहीं ये patterns अक्सर report होते हैं और आम तौर पर no-action के रूप में close किए जाते हैं, जब तक कोई वास्तविक boundary bypass demonstrate न किया जाए: - Policy, auth, या sandbox bypass के बिना prompt-injection-only chains. - ऐसे claims जो एक shared host या config पर hostile multi-tenant operation मानते हैं। - ऐसे claims जो normal operator read-path access (उदाहरण के लिए `sessions.list` / `sessions.preview` / `chat.history`) को shared-gateway setup में IDOR के रूप में classify करते हैं। - Localhost-only deployment findings (उदाहरण के लिए loopback-only Gateway पर HSTS). - Discord inbound webhook signature findings उन inbound paths के लिए जो इस repo में मौजूद नहीं हैं। - Reports जो Node pairing metadata को `system.run` के लिए hidden second per-command approval layer मानती हैं, जबकि real execution boundary अभी भी Gateway की global Node command policy और Node की अपनी exec approvals है। - Reports जो configured `gateway.nodes.pairing.autoApproveCidrs` को अपने-आप vulnerability मानती हैं। यह setting default रूप से disabled है, explicit CIDR/IP entries मांगती है, केवल no requested scopes के साथ first-time `role: node` pairing पर लागू होती है, और operator/browser/Control UI, WebChat, role upgrades, scope upgrades, metadata changes, public-key changes, या same-host loopback trusted-proxy header paths को auto-approve नहीं करती, जब तक loopback trusted-proxy auth explicit रूप से enabled न हो। - "Missing per-user authorization" findings जो `sessionKey` को auth token मानती हैं। ## 60 सेकंड में hardened baseline पहले इस baseline का उपयोग करें, फिर trusted agent के अनुसार tools को selectively re-enable करें: ```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 } } }, }, } ``` यह 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` को प्रति चैनल या प्रति रूम/बातचीत सेट करें. सेटअप विवरण के लिए [समूह चैट](/hi/channels/groups#context-visibility-and-allowlists) देखें. सलाहकारी ट्रायज मार्गदर्शन: - ऐसे दावे जो केवल यह दिखाते हैं कि "मॉडल गैर-अनुमति-सूचीबद्ध प्रेषकों से उद्धृत या ऐतिहासिक पाठ देख सकता है", `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//creds.json` - **Telegram बॉट टोकन**: config/env या `channels.telegram.tokenFile` (केवल नियमित फाइल; symlinks अस्वीकृत) - **Discord बॉट टोकन**: config/env या SecretRef (env/file/exec प्रदाता) - **Slack टोकन**: config/env (`channels.slack.*`) - **पेयरिंग अनुमति-सूचियाँ**: - `~/.openclaw/credentials/-allowFrom.json` (डिफॉल्ट खाता) - `~/.openclaw/credentials/--allowFrom.json` (गैर-डिफॉल्ट खाते) - **मॉडल auth प्रोफाइल**: `~/.openclaw/agents//agent/auth-profiles.json` - **Codex रनटाइम स्थिति (डिफॉल्ट)**: `~/.openclaw/agents//agent/codex-home/` - **साझा Codex रनटाइम स्थिति (ऑप्ट-इन)**: `$CODEX_HOME` या `~/.codex` जब `plugins.entries.codex.config.appServer.homeScope` `"user"` हो. यह मोड नेटिव Codex खाते, config, plugins, और थ्रेड स्टोर का उपयोग करता है; इसे केवल owner-नियंत्रित स्थानीय Gateway के लिए सक्षम करें. [Codex harness](/hi/plugins/codex-harness#share-threads-with-codex-desktop-and-cli) देखें. - **फाइल-समर्थित सीक्रेट्स पेलोड (वैकल्पिक)**: `~/.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 समर्थन के साथ पूरा कैटलॉग [सुरक्षा ऑडिट जांच](/hi/gateway/security/audit-checks) पर देखें. ## 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.controlUi.allowInsecureAuth=true` - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` - `gateway.controlUi.dangerouslyDisableDeviceAuth=true` - `security.audit.suppressions configured ()` - `hooks.gmail.allowUnsafeExternalContent=true` - `hooks.mappings[].allowUnsafeExternalContent=true` - `tools.exec.applyPatch.workspaceOnly=false` - `plugins.entries.acpx.config.permissionMode=approve-all` Control UI और ब्राउजर: - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback` - `gateway.controlUi.dangerouslyDisableDeviceAuth` - `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` चैनल नाम-मिलान (बंडल और Plugin चैनल; लागू होने पर प्रति `accounts.` भी उपलब्ध): - `channels.discord.dangerouslyAllowNameMatching` - `channels.slack.dangerouslyAllowNameMatching` - `channels.googlechat.dangerouslyAllowNameMatching` - `channels.msteams.dangerouslyAllowNameMatching` - `channels.synology-chat.dangerouslyAllowNameMatching` (Plugin चैनल) - `channels.synology-chat.dangerouslyAllowInheritedWebhookPath` (Plugin चैनल) - `channels.zalouser.dangerouslyAllowNameMatching` (Plugin चैनल) - `channels.irc.dangerouslyAllowNameMatching` (Plugin चैनल) - `channels.mattermost.dangerouslyAllowNameMatching` (Plugin चैनल) नेटवर्क एक्सपोजर: - `channels.telegram.network.dangerouslyAllowPrivateNetwork` (प्रति खाते भी) Sandbox Docker (डिफॉल्ट + प्रति-एजेंट): - `agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets` - `agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources` - `agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin` ## रिवर्स प्रॉक्सी कॉन्फिगरेशन यदि आप 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 का उपयोग करें ```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} ``` जब `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 करें): ```nginx proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; ``` खराब रिवर्स प्रॉक्सी व्यवहार (untrusted forwarding headers को append/preserve करें): ```nginx 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](/hi/gateway/trusted-proxy-auth#tls-termination-and-hsts) में है। - 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//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](/hi/gateway/configuration) और [Slash commands](/hi/tools/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 करें: ```json5 { 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 `, `openclaw plugins update `), तो इसे 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](/hi/tools/plugin) ## 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 करें: ```bash openclaw pairing list openclaw pairing approve ``` Details + disk पर files: [Pairing](/hi/channels/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 करने पर विचार करें: ```json5 { 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](/hi/concepts/session) और [Configuration](/hi/gateway/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 के लिए `-allowFrom.json`, non-default accounts के लिए `--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](/hi/gateway/configuration) और [Groups](/hi/channels/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 ``, ``, ``, ``, और समान 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 `<<>>` 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|>`, या `` को 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 के तहत। Tool-enabled agents या untrusted content पढ़ने वाले agents के लिए, पुराने/छोटे models के साथ prompt-injection risk अक्सर बहुत high होता है। उन workloads को weak model tiers पर run न करें। 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): ```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 की अलग 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: ```bash ufw reload iptables -S DOCKER-USER ip6tables -S DOCKER-USER nmap -sT -p 1-65535 --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 करें: ```json5 { discovery: { mdns: { mode: "minimal" }, }, } ``` 3. अगर आप Plugin enabled रखना चाहते हैं लेकिन local device discovery suppress करना चाहते हैं, तो **mDNS mode disable करें**: ```json5 { discovery: { mdns: { mode: "off" }, }, } ``` 4. **Full mode** (opt-in): TXT records में `cliPath` + `sshPort` शामिल करें: ```json5 { 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 करना पड़े: ```json5 { gateway: { auth: { mode: "token", token: "your-token" }, }, } ``` Doctor आपके लिए एक generate कर सकता है: `openclaw doctor --generate-gateway-token`. `gateway.remote.token` और `gateway.remote.password` client credential sources हैं। वे अपने आप local WS access की रक्षा **नहीं** करते। Local call paths `gateway.auth.*` unset होने पर ही fallback के रूप में `gateway.remote.*` का उपयोग कर सकते हैं। अगर `gateway.auth.token` या `gateway.auth.password` SecretRef के माध्यम से explicitly configured है और unresolved है, तो resolution fail closed होता है (कोई remote fallback masking नहीं)। वैकल्पिक: `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](/hi/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](/hi/gateway/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](/hi/gateway/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](/hi/gateway/tailscale) और [Web overview](/hi/web) देखें। ### node host के माध्यम से browser control (recommended) अगर आपका Gateway remote है लेकिन browser किसी दूसरी machine पर चलता है, तो browser machine पर एक **node host** चलाएं और Gateway को browser actions proxy करने दें ([Browser tool](/hi/tools/browser) देखें)। 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//agent/auth-profiles.json`: API keys, token profiles, OAuth tokens, और वैकल्पिक `keyRef`/`tokenRef`। - `agents//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//agent/auth.json`: legacy compatibility file। Static `api_key` entries खोजे जाने पर scrub कर दी जाती हैं। - `agents//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](/hi/gateway/logging) ### DMs: pairing by default ```json5 { channels: { whatsapp: { dmPolicy: "pairing" } }, } ``` ### Groups: require mention everywhere ```json { "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 से बचता है: ```json5 { 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](/hi/gateway/sandboxing) दो complementary approaches: - **पूरा Gateway Docker में चलाएँ** (container boundary): [Docker](/hi/install/docker) - **Tool sandbox** (`agents.defaults.sandbox`, host gateway + sandbox-isolated tools; Docker default backend है): [Sandboxing](/hi/gateway/sandboxing) cross-agent access रोकने के लिए, `agents.defaults.sandbox.scope` को `"agent"` (default) पर रखें या stricter per-session isolation के लिए `"session"` पर रखें। `scope: "shared"` single container या workspace का उपयोग करता है। 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 होते हैं। `tools.elevated` global baseline escape hatch है जो exec को sandbox के बाहर चलाता है। effective host default रूप से `gateway` है, या जब exec target `node` पर configured हो तो `node`। `tools.elevated.allowFrom` tight रखें और इसे strangers के लिए enable न करें। आप `agents.list[].tools.elevated` के जरिए per agent elevated को और restrict कर सकते हैं। देखें [Elevated mode](/hi/tools/elevated)। ### 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: ```json5 { 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](/hi/tools/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) ```json5 { agents: { list: [ { id: "personal", workspace: "~/.openclaw/workspace-personal", sandbox: { mode: "off" }, }, ], }, } ``` ### उदाहरण: केवल-पढ़ने वाले टूल + केवल-पढ़ने वाला कार्यक्षेत्र ```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"], }, }, ], }, } ``` ### उदाहरण: कोई फाइलसिस्टम/शेल एक्सेस नहीं (प्रदाता मैसेजिंग अनुमत) ```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", ], }, }, ], }, } ``` ## घटना प्रतिक्रिया यदि आपका 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//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 हटाएं या रोटेट करें, फिर स्थानीय रूप से पुन: प्रस्तुत करें: ```bash pre-commit run --all-files detect-private-key ``` ## सुरक्षा समस्याओं की रिपोर्ट करना OpenClaw में vulnerability मिली? कृपया जिम्मेदारी से रिपोर्ट करें: 1. ईमेल: [security@openclaw.ai](mailto:security@openclaw.ai) 2. ठीक होने तक सार्वजनिक रूप से पोस्ट न करें 3. हम आपको श्रेय देंगे (जब तक आप गुमनाम रहना पसंद न करें)