--- read_when: - पहुँच या स्वचालन का विस्तार करने वाली सुविधाएँ जोड़ना summary: शेल एक्सेस वाले AI गेटवे को चलाने के लिए सुरक्षा संबंधी विचार और खतरा मॉडल title: सुरक्षा x-i18n: generated_at: "2026-07-27T17:49:41Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 8cdf1b1455ecb35a3cf5b9ab968a55c89b7b7c283231b99d4d740bb75fa11700 source_path: gateway/security/index.md workflow: 16 --- **व्यक्तिगत सहायक विश्वास मॉडल।** यह मार्गदर्शन प्रत्येक Gateway के लिए एक विश्वसनीय ऑपरेटर सीमा (एकल-उपयोगकर्ता, व्यक्तिगत-सहायक मॉडल) मानता है। OpenClaw एक एजेंट या Gateway साझा करने वाले कई विरोधी उपयोगकर्ताओं के लिए शत्रुतापूर्ण बहु-किरायेदार सुरक्षा सीमा **नहीं** है। मिश्रित-विश्वास या विरोधी-उपयोगकर्ता संचालन के लिए, विश्वास सीमाएँ अलग करें: अलग Gateway + क्रेडेंशियल, और आदर्श रूप से अलग OS उपयोगकर्ता या होस्ट। ## दायरा: व्यक्तिगत सहायक सुरक्षा मॉडल - समर्थित: प्रति Gateway एक उपयोगकर्ता/विश्वास सीमा (प्रति सीमा एक OS उपयोगकर्ता/होस्ट/VPS को प्राथमिकता दें)। - समर्थित नहीं: परस्पर अविश्वसनीय या विरोधी उपयोगकर्ताओं द्वारा इस्तेमाल किया जाने वाला एक साझा Gateway/एजेंट। - विरोधी-उपयोगकर्ता पृथक्करण के लिए अलग-अलग Gateway (और आदर्श रूप से अलग OS उपयोगकर्ता/होस्ट) आवश्यक हैं। - यदि कई अविश्वसनीय उपयोगकर्ता एक टूल-सक्षम एजेंट को संदेश भेज सकते हैं, तो वे उस एजेंट के प्रत्यायोजित टूल प्राधिकार को साझा करते हैं। - यदि कोई Gateway होस्ट की स्थिति/कॉन्फ़िगरेशन (`~/.openclaw`, जिसमें `openclaw.json` शामिल है) बदल सकता है, तो उसे विश्वसनीय ऑपरेटर मानें। - एक Gateway के भीतर, प्रमाणित ऑपरेटर पहुँच एक विश्वसनीय नियंत्रण-पटल भूमिका है, न कि प्रति-उपयोगकर्ता किरायेदार भूमिका। - `sessionKey` (सत्र ID, लेबल) एक रूटिंग चयनकर्ता है, प्राधिकरण टोकन नहीं। कई उपयोगकर्ताओं या संगठनों को होस्ट कर रहे हैं? एक Gateway साझा करने के बजाय प्रत्येक किरायेदार के लिए एक पृथक Gateway सेल चलाएँ। [बहु-किरायेदार होस्टिंग](/hi/gateway/multi-tenant-hosting) देखें। दूरस्थ पहुँच, DM नीति, रिवर्स प्रॉक्सी या सार्वजनिक एक्सपोज़र बदलने से पहले, पूर्व-उड़ान/रोलबैक चेकलिस्ट के रूप में [Gateway एक्सपोज़र रनबुक](/hi/gateway/security/exposure-runbook) पूरी करें। ## `openclaw security audit` इसे किसी भी कॉन्फ़िगरेशन परिवर्तन के बाद या नेटवर्क सतहों को उजागर करने से पहले चलाएँ: ```bash openclaw security audit openclaw security audit --deep # लाइव Gateway जाँच का प्रयास करता है openclaw security audit --fix # सुरक्षित सुधार लागू करें openclaw security audit --json ``` `--fix` जानबूझकर सीमित है: यह खुली समूह नीतियों को अनुमति-सूचियों में बदलता है, `logging.redactSensitive: "tools"` को पुनर्स्थापित करता है, स्थिति/कॉन्फ़िगरेशन/सम्मिलित फ़ाइल की अनुमतियों को सख्त करता है (`600` फ़ाइलें, `700` निर्देशिकाएँ), और Windows पर POSIX `chmod` के बजाय ACL रीसेट का उपयोग करता है। ### ऑडिट क्या जाँचता है (उच्च स्तर पर) - **इनबाउंड पहुँच** - DM/समूह नीतियाँ, अनुमति-सूचियाँ: क्या अजनबी बॉट को सक्रिय कर सकते हैं? - **टूल प्रभाव-क्षेत्र** - उन्नत टूल + खुले कक्ष: क्या प्रॉम्प्ट इंजेक्शन शेल/फ़ाइल/नेटवर्क कार्रवाइयों में बदल सकता है? - **Exec फ़ाइल-सिस्टम विचलन** - फ़ाइल-सिस्टम बदलने वाले टूल अस्वीकृत हैं, जबकि `exec`/`process` सैंडबॉक्स प्रतिबंधों के बिना उपलब्ध रहते हैं। - **Exec अनुमोदन विचलन** - `security="full"`, `autoAllowSkills`, `strictInlineEval` के बिना इंटरप्रेटर अनुमति-सूचियाँ। अकेला `security="full"` व्यापक सुरक्षा-मुद्रा चेतावनी है, किसी बग का प्रमाण नहीं—विश्वसनीय व्यक्तिगत-सहायक सेटअप के लिए यही चुना गया डिफ़ॉल्ट है; इसे केवल तभी सख्त करें जब आपके खतरा मॉडल को अनुमोदन या अनुमति-सूची सुरक्षा-सीमाओं की आवश्यकता हो। - **नेटवर्क एक्सपोज़र** - Gateway बाइंड/प्रमाणीकरण, Tailscale Serve/Funnel, कमज़ोर/छोटे प्रमाणीकरण टोकन। - **ब्राउज़र नियंत्रण एक्सपोज़र** - दूरस्थ Node, रिले पोर्ट, दूरस्थ CDP एंडपॉइंट। - **स्थानीय डिस्क स्वच्छता** - अनुमतियाँ, सिमलिंक, कॉन्फ़िगरेशन सम्मिलन, सिंक किए गए फ़ोल्डर के पथ। - **Plugins** - स्पष्ट अनुमति-सूची के बिना लोड होना। - **नीति विचलन** - सैंडबॉक्स Docker सेटिंग्स कॉन्फ़िगर हैं लेकिन सैंडबॉक्स मोड बंद है; `gateway.nodes.commands.deny` प्रविष्टियाँ जो प्रभावी दिखती हैं लेकिन केवल सटीक कमांड ID (उदाहरण के लिए `system.run`) से मेल खाती हैं, पेलोड के भीतर के शेल टेक्स्ट से नहीं; खतरनाक `gateway.nodes.commands.allow` प्रविष्टियाँ; वैश्विक `tools.profile="minimal"` को प्रति एजेंट ओवरराइड किया गया है; अनुमति देने वाली नीति के अंतर्गत Plugin-स्वामित्व वाले टूल सुलभ हैं। - **रनटाइम अपेक्षा विचलन** - यह मानना कि अंतर्निहित exec का अर्थ अभी भी `sandbox` है, जबकि `tools.exec.host` अब डिफ़ॉल्ट रूप से `auto` है, या सैंडबॉक्स मोड बंद रहते हुए `tools.exec.host="sandbox"` सेट करना। - **मॉडल स्वच्छता** - पुराने कॉन्फ़िगर किए गए मॉडल पर चेतावनी देता है (हल्की चेतावनी, कठोर अवरोध नहीं)। प्रत्येक निष्कर्ष में एक संरचित `checkId` होता है (उदाहरण के लिए `gateway.bind_no_auth`, `tools.exec.security_full_configured`)। उपसर्ग: `fs.*` (अनुमतियाँ), `gateway.*` (बाइंड/प्रमाणीकरण/Tailscale/Control UI/विश्वसनीय-प्रॉक्सी), `hooks.*`/`browser.*`/`sandbox.*`/`tools.exec.*` (प्रति-सतह सुदृढ़ीकरण), `plugins.*`/`skills.*` (आपूर्ति शृंखला), `security.exposure.*` (पहुँच नीति x टूल प्रभाव-क्षेत्र)। गंभीरता और स्वतः-सुधार समर्थन सहित पूर्ण सूची: [सुरक्षा ऑडिट जाँचें](/hi/gateway/security/audit-checks)। [औपचारिक सत्यापन](/hi/security/formal-verification) भी देखें। ### निष्कर्षों की प्राथमिकता तय करने का क्रम 1. टूल सक्षम होने के साथ कुछ भी "खुला" हो: पहले DM/समूहों को प्रतिबंधित करें (पेयरिंग/अनुमति-सूचियाँ), फिर टूल नीति/सैंडबॉक्सिंग को सख्त करें। 2. सार्वजनिक नेटवर्क एक्सपोज़र (LAN बाइंड, Funnel, प्रमाणीकरण अनुपस्थित): तुरंत ठीक करें। 3. ब्राउज़र नियंत्रण का दूरस्थ एक्सपोज़र: इसे ऑपरेटर पहुँच जैसा मानें (केवल टेलनेट, Node को सोच-समझकर पेयर करें, कोई सार्वजनिक एक्सपोज़र नहीं)। 4. अनुमतियाँ: स्थिति/कॉन्फ़िगरेशन/क्रेडेंशियल/प्रमाणीकरण समूह या सभी उपयोगकर्ताओं द्वारा पठनीय नहीं होने चाहिए। 5. Plugins: केवल वही लोड करें जिन पर आप स्पष्ट रूप से विश्वास करते हैं। 6. मॉडल चयन: टूल वाले किसी भी बॉट के लिए आधुनिक, निर्देश-सुदृढ़ मॉडल को प्राथमिकता दें। ## 60 सेकंड में सुदृढ़ आधाररेखा ```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 को केवल स्थानीय रखता है, DM को पृथक करता है और नियंत्रण-पटल/रनटाइम टूल को डिफ़ॉल्ट रूप से अक्षम करता है। इसके बाद प्रत्येक विश्वसनीय एजेंट के लिए टूल को चुनिंदा रूप से फिर से सक्षम करें। चैट-संचालित एजेंट टर्न के लिए अंतर्निहित आधाररेखा: गैर-स्वामी प्रेषक कॉन्फ़िगरेशन की परवाह किए बिना `cron` या `gateway` टूल का उपयोग नहीं कर सकते। ### अनुरोधकर्ता-दायरे वाले नियंत्रण और प्रॉम्प्ट संदर्भ `tools.toolsBySender`, प्रेषक स्वामित्व और केवल-स्वामी टूल सूची का मूल्यांकन वर्तमान टर्न के मूल अनुरोधकर्ता के आधार पर किया जाता है। वे उस मॉडल प्रॉम्प्ट की अन्य सामग्री को प्रमाणित या स्वच्छ नहीं करते, जिसमें उद्धृत टेक्स्ट, पहले का साझा-कक्ष इतिहास, अग्रेषित सामग्री, प्राप्त की गई सामग्री, अटैचमेंट, टूल परिणाम या अन्य प्रॉम्प्ट इनपुट शामिल हैं। इसलिए किसी अन्य व्यक्ति की सामग्री स्वामी द्वारा सक्रिय किए गए टर्न को प्रभावित कर सकती है, जब वह उस टर्न के संदर्भ में शामिल हो। इन नियंत्रणों को गहन रक्षा मानें, जो किसी अनुरोधकर्ता की प्रत्यक्ष क्षमता कम करती है, न कि शत्रुतापूर्ण बहु-उपयोगकर्ता पृथक्करण। समर्थित चैनल-प्रदत्त संदर्भ को फ़िल्टर करने के लिए `contextVisibility` का उपयोग करें, टूल को प्रतिबंधित करें और एजेंट को सैंडबॉक्स में रखें, तथा जब प्रतिभागी परस्पर विरोधी हों तो अलग-अलग Gateway और आदर्श रूप से अलग OS उपयोगकर्ता या होस्ट का उपयोग करें। ## विश्वास सीमा मैट्रिक्स जोखिम रिपोर्ट की प्राथमिकता तय करने के लिए संक्षिप्त मॉडल: | सीमा या नियंत्रण | इसका अर्थ | सामान्य गलत व्याख्या | | --------------------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------- | | `gateway.auth` (टोकन/पासवर्ड/विश्वसनीय-प्रॉक्सी/डिवाइस प्रमाणीकरण) | Gateway API के कॉलर को प्रमाणित करता है | "सुरक्षित होने के लिए हर फ़्रेम पर प्रति-संदेश हस्ताक्षर आवश्यक हैं" | | `sessionKey` | संदर्भ/सत्र चयन के लिए रूटिंग कुंजी | "सत्र कुंजी उपयोगकर्ता प्रमाणीकरण सीमा है" | | प्रॉम्प्ट/सामग्री सुरक्षा-सीमाएँ | मॉडल के दुरुपयोग का जोखिम कम करती हैं | "अकेला प्रॉम्प्ट इंजेक्शन प्रमाणीकरण बायपास सिद्ध करता है" | | `canvas.eval` / ब्राउज़र मूल्यांकन | सक्षम होने पर जानबूझकर दी गई ऑपरेटर क्षमता | "इस विश्वास मॉडल में कोई भी JS eval प्रिमिटिव स्वतः एक कमज़ोरी है" | | स्थानीय TUI `!` शेल | ऑपरेटर द्वारा स्पष्ट रूप से सक्रिय स्थानीय निष्पादन | "स्थानीय शेल सुविधा कमांड दूरस्थ इंजेक्शन है" | | Node पेयरिंग और Node कमांड | पेयर किए गए डिवाइस पर ऑपरेटर-स्तरीय दूरस्थ निष्पादन | "दूरस्थ डिवाइस नियंत्रण को डिफ़ॉल्ट रूप से अविश्वसनीय उपयोगकर्ता पहुँच माना जाना चाहिए" | | `gateway.nodes.pairing.autoApproveCidrs` | वैकल्पिक विश्वसनीय-नेटवर्क Node नामांकन नीति | "डिफ़ॉल्ट रूप से अक्षम अनुमति-सूची स्वतः पेयरिंग कमज़ोरी है" | | `gateway.nodes.pairing.sshVerify` | ऑपरेटर SSH पर कुंजी-सत्यापित Node नामांकन | "डिफ़ॉल्ट रूप से चालू स्वतः-अनुमोदन स्वतः पेयरिंग कमज़ोरी है" | ## डिज़ाइन के अनुसार कमज़ोरियाँ नहीं - नीति, प्रमाणीकरण या सैंडबॉक्स बायपास के बिना केवल प्रॉम्प्ट-इंजेक्शन शृंखलाएँ। - ऐसे दावे जो एक साझा होस्ट या कॉन्फ़िगरेशन पर शत्रुतापूर्ण बहु-किरायेदार संचालन मानते हैं। - साझा-Gateway सेटअप में सामान्य ऑपरेटर पठन-पथ पहुँच (उदाहरण के लिए `sessions.list` / `sessions.preview` / `chat.history`) को IDOR के रूप में वर्गीकृत करना। - केवल-localhost परिनियोजन के निष्कर्ष (उदाहरण के लिए केवल loopback वाले Gateway पर HSTS का अभाव)। - इस रेपो में अस्तित्वहीन इनबाउंड पथों के लिए Discord इनबाउंड Webhook हस्ताक्षर संबंधी निष्कर्ष। - Node पेयरिंग मेटाडेटा को `system.run` के लिए छिपी हुई दूसरी प्रति-कमांड अनुमोदन परत मानना; वास्तविक निष्पादन सीमा Gateway की वैश्विक Node कमांड नीति और Node के अपने exec अनुमोदन हैं। - `gateway.nodes.pairing.sshVerify` को डिफ़ॉल्ट रूप से सक्षम होने के कारण कमज़ोरी मानना। यह केवल नेटवर्क निकटता या SSH पहुँच-योग्यता के आधार पर कभी अनुमोदन नहीं करता: Gateway SSH पर डिवाइस पहचान वापस पढ़ता है (BatchMode, सख्त होस्ट कुंजियाँ) और केवल लंबित अनुरोध के साथ डिवाइस-कुंजी का सटीक मिलान होने पर अनुमोदन करता है, जिसके लिए कनेक्ट होने वाली कुंजी-जोड़ी का ऑपरेटर के नियंत्रण वाले होस्ट पर ऑपरेटर के खाते के अंतर्गत पहले से मौजूद होना आवश्यक है। जाँच निजी/CGNAT स्रोत पतों तक सीमित होती हैं, विश्वसनीय-CIDR पात्रता न्यूनतम स्तर (केवल नया, दायरा-रहित `role: node`) साझा करती हैं, और `sshVerify: false` इस सुविधा को बंद कर देता है। - `gateway.nodes.pairing.autoApproveCidrs` को अपने-आप में कमज़ोरी मानना। यह डिफ़ॉल्ट रूप से अक्षम है, स्पष्ट CIDR/IP प्रविष्टियों की आवश्यकता होती है, केवल पहली बार की `role: node` पेयरिंग पर लागू होता है जिसमें कोई अनुरोधित दायरा नहीं होता, और ऑपरेटर/ब्राउज़र/Control UI, WebChat, भूमिका/दायरा उन्नयन, मेटाडेटा या सार्वजनिक-कुंजी परिवर्तन, या समान-होस्ट loopback विश्वसनीय-प्रॉक्सी हेडर पथों को कभी स्वतः अनुमोदित नहीं करता (भले ही loopback विश्वसनीय-प्रॉक्सी प्रमाणीकरण सक्षम हो)। - ऐसे "प्रति-उपयोगकर्ता प्राधिकरण अनुपस्थित" निष्कर्ष जो `sessionKey` को प्रमाणीकरण टोकन मानते हैं। ## Gateway और Node का विश्वास Gateway और Node को अलग-अलग भूमिकाओं वाला एक ऑपरेटर विश्वास डोमेन मानें: - **Gateway**: नियंत्रण तल और नीति सतह (`gateway.auth`, टूल नीति, रूटिंग)। - **Node**: उस Gateway से युग्मित दूरस्थ निष्पादन सतह (कमांड, डिवाइस क्रियाएँ, होस्ट-स्थानीय क्षमताएँ)। - Gateway से प्रमाणित कॉलर पर Gateway के दायरे में भरोसा किया जाता है; युग्मन के बाद, Node की क्रियाओं को उस Node पर विश्वसनीय ऑपरेटर क्रियाएँ माना जाता है। [ऑपरेटर के दायरे](/hi/gateway/operator-scopes) देखें। - साझा Gateway टोकन/पासवर्ड से प्रमाणित प्रत्यक्ष लूपबैक बैकएंड क्लाइंट, उपयोगकर्ता डिवाइस पहचान प्रस्तुत किए बिना आंतरिक नियंत्रण-तल RPC कर सकते हैं। यह दूरस्थ या ब्राउज़र युग्मन को बायपास नहीं करता—नेटवर्क क्लाइंट, Node क्लाइंट, डिवाइस-टोकन क्लाइंट और स्पष्ट डिवाइस पहचान अब भी युग्मन और दायरा-अपग्रेड प्रवर्तन से गुजरते हैं। - निष्पादन अनुमोदन (अनुमति-सूची + पूछना) ऑपरेटर के आशय के लिए सुरक्षात्मक सीमाएँ हैं, शत्रुतापूर्ण बहु-किरायेदार पृथक्करण नहीं। वे सटीक अनुरोध संदर्भ और सर्वोत्तम-प्रयास वाले प्रत्यक्ष स्थानीय फ़ाइल ऑपरेंड से बँधते हैं; वे प्रत्येक रनटाइम/इंटरप्रेटर लोडर पथ का अर्थगत मॉडल नहीं बनाते। सुदृढ़ सीमाओं के लिए सैंडबॉक्सिंग और होस्ट पृथक्करण का उपयोग करें। - विश्वसनीय एकल-ऑपरेटर डिफ़ॉल्ट: `gateway`/`node` पर होस्ट निष्पादन अनुमोदन संकेतों के बिना अनुमत है (`security="full"`, `ask="off"`)। यह जानबूझकर बनाया गया UX है, अपने-आप में कोई भेद्यता नहीं। शत्रुतापूर्ण उपयोगकर्ताओं के पृथक्करण के लिए, भरोसे की सीमाओं को OS उपयोगकर्ता/होस्ट के अनुसार विभाजित करें और अलग-अलग Gateway चलाएँ। ## खतरा मॉडल आपका AI सहायक मनमाने शेल कमांड निष्पादित कर सकता है, फ़ाइलें पढ़/लिख सकता है, नेटवर्क सेवाओं तक पहुँच सकता है और किसी को भी संदेश भेज सकता है (यदि उसे चैनल पहुँच दी गई हो)। उसे संदेश भेजने वाले लोग उसे हानिकारक कार्य करने के लिए छलने, आपके डेटा तक पहुँच पाने हेतु सोशल इंजीनियरिंग करने या अवसंरचना के विवरणों की जाँच करने का प्रयास कर सकते हैं। यहाँ अधिकांश विफलताएँ असामान्य कारनामे नहीं हैं—वे ऐसी स्थितियाँ हैं जहाँ "किसी ने बॉट को संदेश भेजा और बॉट ने वही किया जो उससे कहा गया।" OpenClaw का दृष्टिकोण, क्रम से: 1. **पहले पहचान**—निर्धारित करें कि बॉट से कौन बात कर सकता है (DM युग्मन / अनुमति-सूचियाँ / स्पष्ट "open")। 2. **फिर दायरा**—निर्धारित करें कि बॉट कहाँ कार्य कर सकता है (समूह अनुमति-सूचियाँ + उल्लेख गेटिंग, टूल, सैंडबॉक्सिंग, डिवाइस अनुमतियाँ)। 3. **अंत में मॉडल**—मानकर चलें कि मॉडल में हेरफेर किया जा सकता है; ऐसी संरचना बनाएँ कि हेरफेर का प्रभाव-क्षेत्र सीमित रहे। ## DM पहुँच: युग्मन, अनुमति-सूची, खुला, अक्षम DM में सक्षम प्रत्येक चैनल `dmPolicy` (या `*.dm.policy`) का समर्थन करता है, जो संदेश संसाधित होने से पहले आने वाले DM को नियंत्रित करता है: | नीति | व्यवहार | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `pairing` | डिफ़ॉल्ट। अज्ञात प्रेषकों को युग्मन कोड मिलता है; अनुमोदित होने तक बॉट उनकी उपेक्षा करता है। कोड 1 घंटे बाद समाप्त हो जाते हैं; नया अनुरोध बनने तक बार-बार भेजे गए DM से कोड दोबारा नहीं भेजा जाता। लंबित अनुरोध प्रति चैनल अधिकतम 3 हैं। | | `allowlist` | अज्ञात प्रेषक अवरुद्ध रहते हैं, कोई युग्मन हैंडशेक नहीं होता। | | `open` | कोई भी DM कर सकता है (सार्वजनिक)। चैनल की अनुमति-सूची में `"*"` शामिल होना आवश्यक है (स्पष्ट स्वीकृति)। | | `disabled` | आने वाले DM की पूरी तरह उपेक्षा की जाती है। | ```bash openclaw pairing list openclaw pairing approve ``` विवरण + डिस्क पर फ़ाइलें: [युग्मन](/hi/channels/pairing) `dmPolicy="open"` और `groupPolicy="open"` को अंतिम उपाय वाली सेटिंग मानें; जब तक आपको कक्ष के प्रत्येक सदस्य पर पूर्ण भरोसा न हो, युग्मन + अनुमति-सूचियों को प्राथमिकता दें। ### अनुमति-सूचियाँ (दो परतें) - **DM अनुमति-सूची** (`allowFrom` / `channels.discord.allowFrom` / `channels.slack.allowFrom`; पुराना: `channels.discord.dm.allowFrom`, `channels.slack.dm.allowFrom`): बॉट को कौन DM कर सकता है। जब `dmPolicy="pairing"` हो, तो अनुमोदन `~/.openclaw/credentials/-allowFrom.json` (डिफ़ॉल्ट खाता) या `--allowFrom.json` (गैर-डिफ़ॉल्ट खाते) में लिखे जाते हैं और कॉन्फ़िगरेशन अनुमति-सूचियों के साथ मिला दिए जाते हैं। - **समूह अनुमति-सूची** (चैनल-विशिष्ट): बॉट किन समूहों/चैनलों/गिल्ड को स्वीकार करता है। - `channels.whatsapp.groups`, `channels.telegram.groups`, `channels.imessage.groups`: प्रति-समूह डिफ़ॉल्ट, जैसे `requireMention`; सेट होने पर यह समूह अनुमति-सूची के रूप में भी कार्य करता है (सभी को अनुमति देने वाला व्यवहार बनाए रखने के लिए `"*"` शामिल करें)। `agents.entries.*.groupChat.mentionPatterns` (उदाहरण के लिए `["@openclaw", "@mybot"]`) से उल्लेख ट्रिगर अनुकूलित करें, ताकि `requireMention` आपके अपने बॉट नामों के आधार पर नियंत्रण करे। - `groupPolicy="allowlist"` + `groupAllowFrom`: सीमित करें कि समूह सत्र में बॉट को कौन ट्रिगर कर सकता है (WhatsApp/Telegram/Signal/iMessage/Microsoft Teams)। - `channels.discord.guilds` / `channels.slack.channels`: प्रति-सतह अनुमति-सूचियाँ + उल्लेख डिफ़ॉल्ट। - जाँच क्रम: पहले `groupPolicy`/समूह अनुमति-सूचियाँ, फिर उल्लेख/उत्तर सक्रियण। किसी बॉट संदेश का उत्तर देना (अंतर्निहित उल्लेख) `groupAllowFrom` को बायपास **नहीं** करता। विवरण: [कॉन्फ़िगरेशन](/hi/gateway/configuration) और [समूह](/hi/channels/groups) ### DM सत्र पृथक्करण (बहु-उपयोगकर्ता मोड) डिफ़ॉल्ट रूप से, OpenClaw विभिन्न डिवाइसों में निरंतरता बनाए रखने के लिए सभी DM को मुख्य सत्र में रूट करता है। यदि कई लोग बॉट को DM कर सकते हैं (खुले DM या बहु-व्यक्ति अनुमति-सूची), तो DM सत्रों को अलग करें: ```json5 { session: { dmScope: "per-channel-peer" } } ``` `session.dmScope` के मान: | मान | दायरा | | -------------------------- | ---------------------------------------------------------------------- | | `main` (कॉन्फ़िगरेशन डिफ़ॉल्ट) | सभी DM एक सत्र साझा करते हैं। | | `per-channel-peer` | प्रत्येक चैनल+प्रेषक जोड़ी को अलग DM संदर्भ मिलता है (सुरक्षित DM मोड)। | | `per-account-channel-peer` | ऊपर जैसा, लेकिन खाते के अनुसार और विभाजित (बहु-खाता चैनल)। | | `per-peer` | प्रत्येक प्रेषक को समान प्रकार के सभी चैनलों में एक सत्र मिलता है। | स्थानीय CLI ऑनबोर्डिंग स्पष्ट `session.dmScope` को बनाए रखती है और अन्यथा इसे सेट नहीं करती, इसलिए `"main"` डिफ़ॉल्ट लागू होता है: सभी चैनलों के प्रत्यक्ष संदेश एजेंट के क्रमिक मुख्य सत्र को साझा करते हैं (व्यक्तिगत-एजेंट डिफ़ॉल्ट)। साझा या बहु-उपयोगकर्ता इनबॉक्स के लिए `session.dmScope: "per-channel-peer"` सेट करें; बहु-उपयोगकर्ता DM ट्रैफ़िक मिलने पर `openclaw security audit` पृथक्करण की अनुशंसा करता है। यह संदेश-संदर्भ की सीमा है, होस्ट-प्रशासक की सीमा नहीं। यदि उपयोगकर्ता परस्पर विरोधी हैं और समान Gateway होस्ट/कॉन्फ़िगरेशन साझा करते हैं, तो प्रत्येक भरोसा सीमा के लिए अलग-अलग Gateway चलाएँ। यदि वही व्यक्ति कई चैनलों पर आपसे संपर्क करता है, तो उन DM सत्रों को एक प्रामाणिक पहचान में समेकित करने के लिए `session.identityLinks` का उपयोग करें। [सत्र प्रबंधन](/hi/concepts/session) और [कॉन्फ़िगरेशन](/hi/gateway/configuration) देखें। ## संदर्भ दृश्यता बनाम ट्रिगर प्राधिकरण दो अलग अवधारणाएँ: - **ट्रिगर प्राधिकरण**: एजेंट को कौन ट्रिगर कर सकता है (`dmPolicy`, `groupPolicy`, अनुमति-सूचियाँ, उल्लेख गेट)। - **संदर्भ दृश्यता**: मॉडल तक कौन-सा पूरक संदर्भ पहुँचता है (उत्तर का मुख्य भाग, उद्धृत पाठ, थ्रेड इतिहास, अग्रेषित मेटाडेटा)। `contextVisibility` दूसरे को नियंत्रित करता है: - `"all"` (डिफ़ॉल्ट): पूरक संदर्भ प्राप्त रूप में रखा जाता है। - `"allowlist"`: पूरक संदर्भ को सक्रिय अनुमति-सूची जाँचों द्वारा अनुमत प्रेषकों तक सीमित किया जाता है। - `"allowlist_quote"`: `allowlist` जैसा, लेकिन फिर भी एक स्पष्ट उद्धृत उत्तर रखता है। प्रति चैनल या प्रति कक्ष/वार्तालाप सेट करें—[समूह](/hi/channels/groups#context-visibility-and-allowlists) देखें। जो रिपोर्ट केवल यह दिखाती हैं कि "मॉडल अनुमति-सूची से बाहर के प्रेषकों का उद्धृत/ऐतिहासिक पाठ देख सकता है", वे `contextVisibility` से संबोधित किए जा सकने वाले सुदृढ़ीकरण निष्कर्ष हैं, अपने-आप में प्रमाणीकरण या सैंडबॉक्स बायपास नहीं; सुरक्षा को प्रभावित करने वाली रिपोर्ट में अब भी भरोसा सीमा के प्रदर्शित बायपास की आवश्यकता है। ## प्रॉम्प्ट इंजेक्शन हमलावर ऐसा संदेश तैयार करता है जो मॉडल को असुरक्षित कार्रवाई के लिए प्रभावित करता है ("अपने निर्देशों की उपेक्षा करें", "अपनी फ़ाइल-प्रणाली की सामग्री उजागर करें", "इस लिंक पर जाएँ और कमांड चलाएँ")। केवल सिस्टम प्रॉम्प्ट की सुरक्षात्मक सीमाएँ प्रॉम्प्ट इंजेक्शन का **समाधान नहीं करतीं**—वे केवल सामान्य मार्गदर्शन हैं; कठोर प्रवर्तन टूल नीति, निष्पादन अनुमोदन, सैंडबॉक्सिंग और चैनल अनुमति-सूचियों से आता है (जिन्हें ऑपरेटर संरचना के अनुसार अब भी अक्षम कर सकते हैं)। प्रॉम्प्ट इंजेक्शन के लिए सार्वजनिक DM आवश्यक नहीं हैं: भले ही केवल आप बॉट को संदेश भेज सकें, उसके द्वारा पढ़ी गई कोई भी **अविश्वसनीय सामग्री** (वेब खोज/फ़ेच परिणाम, ब्राउज़र पृष्ठ, ईमेल, दस्तावेज़, संलग्नक, चिपकाए गए लॉग/कोड) में प्रतिकूल निर्देश हो सकते हैं। केवल प्रेषक ही नहीं, सामग्री स्वयं भी खतरे की सतह है। अविश्वसनीय माने जाने वाले चेतावनी संकेत: - "इस फ़ाइल/URL को पढ़ें और इसमें जो लिखा है, ठीक वही करें।" - "अपने सिस्टम प्रॉम्प्ट या सुरक्षा नियमों की उपेक्षा करें।" - "अपने छिपे हुए निर्देश या टूल आउटपुट प्रकट करें।" - "~/.openclaw या अपने लॉग की पूरी सामग्री चिपकाएँ।" व्यवहार में सहायक उपाय: - आने वाले DM को प्रतिबंधित रखें (युग्मन/अनुमति-सूचियाँ); समूहों में उल्लेख गेटिंग को प्राथमिकता दें; सार्वजनिक कक्षों में हमेशा सक्रिय रहने वाले बॉट से बचें। - लिंक, संलग्नक और चिपकाए गए निर्देशों को डिफ़ॉल्ट रूप से शत्रुतापूर्ण मानें। - संवेदनशील टूल निष्पादन को सैंडबॉक्स में चलाएँ; गोपनीय जानकारी को एजेंट की पहुँच वाली फ़ाइल-प्रणाली से बाहर रखें। सैंडबॉक्सिंग स्वैच्छिक है: यदि सैंडबॉक्स मोड बंद है, तो अंतर्निहित `host=auto` Gateway होस्ट पर समाधान करता है, जबकि स्पष्ट `host=sandbox` अब भी सुरक्षित रूप से विफल होता है (कोई सैंडबॉक्स रनटाइम उपलब्ध नहीं)। इस व्यवहार को कॉन्फ़िगरेशन में स्पष्ट बनाने के लिए `host=gateway` सेट करें। - उच्च-जोखिम वाले टूल (`exec`, `browser`, `web_fetch`, `web_search`) को विश्वसनीय एजेंटों या स्पष्ट अनुमति-सूचियों तक सीमित रखें। - यदि आप इंटरप्रेटर (`python`, `node`, `ruby`, `perl`, `php`, `lua`, `osascript`) को अनुमति-सूची में रखते हैं, तो `tools.exec.strictInlineEval` सक्षम करें ताकि इनलाइन मूल्यांकन रूपों (`-c`, `-e` और समान) के लिए अब भी स्पष्ट अनुमोदन आवश्यक हो। अनुमति-सूची मोड में, प्रत्येक heredoc खंड (`<<`) के लिए उद्धरण की परवाह किए बिना हमेशा समीक्षक या स्पष्ट अनुमोदन आवश्यक होता है—अनुमति-सूची में शामिल कमांड, अनुमति-सूची समीक्षा को बायपास करने के लिए heredoc मुख्य भाग का उपयोग नहीं कर सकता। - अविश्वसनीय सामग्री का सारांश बनाने के लिए केवल-पढ़ने योग्य या टूल-अक्षम **रीडर एजेंट** का उपयोग करके प्रभाव-क्षेत्र घटाएँ, फिर सारांश अपने मुख्य एजेंट को दें। - Gmail हुक के लिए, अंतर्निहित प्रति-संदेश सत्र वार्तालाप संदर्भ को अलग करता है, लेकिन लक्षित एजेंट की टूल या कार्यस्थान अनुमतियाँ नहीं हटाता। अविश्वसनीय मेल को किसी समर्पित रीडर एजेंट तक रूट करें, [प्रति-एजेंट सैंडबॉक्स और टूल प्रतिबंध](/hi/tools/multi-agent-sandbox-tools) लागू करें और [`tools.agentToAgent`](/hi/gateway/config-tools#toolsagenttoagent) से मुख्य एजेंट को किए जाने वाले किसी भी हस्तांतरण को सीमित करें। [Gmail एकीकरण](/hi/gateway/configuration-reference#gmail-integration) देखें। - टूल-सक्षम एजेंटों के लिए `web_search` / `web_fetch` / `browser` को आवश्यकता न होने तक बंद रखें। - OpenResponses URL इनपुट (`input_file` / `input_image`) के लिए, कड़ा `gateway.http.endpoints.responses.files.urlAllowlist` / `images.urlAllowlist` सेट करें और `maxUrlParts` को कम रखें (खाली अनुमति-सूचियाँ अनसेट मानी जाती हैं)। URL फ़ेचिंग पूरी तरह अक्षम करने के लिए `files.allowUrl: false` / `images.allowUrl: false` का उपयोग करें। - गोपनीय जानकारी को प्रॉम्प्ट से बाहर रखें; इसके बजाय उसे Gateway होस्ट पर env/कॉन्फ़िगरेशन के माध्यम से दें। **मॉडल का चयन मायने रखता है।** प्रॉम्प्ट-इंजेक्शन प्रतिरोध सभी मॉडल स्तरों पर समान नहीं होता—छोटे/सस्ते मॉडल प्रतिकूल प्रॉम्प्ट के तहत टूल के दुरुपयोग और निर्देशों के अपहरण के प्रति अधिक संवेदनशील होते हैं। टूल-सक्षम एजेंटों या अविश्वसनीय सामग्री पढ़ने वाले एजेंटों के लिए, पुराने/छोटे मॉडलों में प्रॉम्प्ट-इंजेक्शन का जोखिम अक्सर बहुत अधिक होता है। ऐसे कार्यभार कमजोर मॉडल स्तरों पर न चलाएँ। - टूल चला सकने या फ़ाइलों/नेटवर्क को प्रभावित कर सकने वाले किसी भी बॉट के लिए नवीनतम पीढ़ी के सर्वोत्तम स्तर वाले मॉडल का उपयोग करें। - टूल-सक्षम एजेंटों या अविश्वसनीय इनबॉक्स के लिए पुराने/कमज़ोर/छोटे स्तरों का उपयोग न करें। - यदि छोटे मॉडल का उपयोग करना ही पड़े, तो प्रभाव-क्षेत्र घटाएँ: केवल-पढ़ने योग्य टूल, मज़बूत सैंडबॉक्सिंग, फ़ाइल सिस्टम तक न्यूनतम पहुँच और सख़्त अनुमत-सूचियाँ। सभी सत्रों के लिए सैंडबॉक्सिंग सक्षम करें और इनपुट पर कड़ा नियंत्रण न होने पर `web_search`/`web_fetch`/`browser` अक्षम करें। - विश्वसनीय इनपुट और बिना टूल वाले केवल-चैट निजी सहायकों के लिए छोटे मॉडल सामान्यतः पर्याप्त होते हैं। ### बाहरी सामग्री और अविश्वसनीय इनपुट का आवरण OpenResponses `input_file` टेक्स्ट को अब भी अविश्वसनीय बाहरी सामग्री के रूप में अंतःक्षेपित किया जाता है, भले ही Gateway उसे स्थानीय रूप से डिकोड करता हो—ब्लॉक में `<<>>` सीमा चिह्नों के साथ `Source: External` मेटाडेटा होता है (इस पथ में अन्य जगह प्रयुक्त लंबा `SECURITY NOTICE:` बैनर शामिल नहीं होता)। संलग्न दस्तावेज़ों से टेक्स्ट निकालकर उसे मीडिया प्रॉम्प्ट में जोड़ने से पहले मीडिया-अंडरस्टैंडिंग में भी यही चिह्न-आधारित आवरण लागू होता है। OpenClaw मॉडल तक पहुँचने से पहले आवरित बाहरी सामग्री और मेटाडेटा से सामान्य स्व-होस्टेड LLM चैट-टेम्पलेट विशेष-टोकन लिटरल (Qwen/ChatML, Llama, Gemma, Mistral, Phi, GPT-OSS भूमिका/टर्न टोकन) भी हटा देता है। स्व-होस्टेड OpenAI-संगत बैकएंड (vLLM, SGLang, TGI, LM Studio, कस्टम Hugging Face टोकनाइज़र स्टैक) कभी-कभी उपयोगकर्ता सामग्री के भीतर `<|im_start|>` या `<|start_header_id|>` जैसी लिटरल स्ट्रिंग को संरचनात्मक चैट-टेम्पलेट टोकन के रूप में टोकनाइज़ करते हैं; इस शुद्धीकरण के बिना किसी प्राप्त पेज, ईमेल बॉडी या फ़ाइल-सामग्री टूल आउटपुट का अविश्वसनीय टेक्स्ट एक कृत्रिम `assistant`/`system` भूमिका सीमा गढ़ सकता है। शुद्धीकरण बाहरी-सामग्री आवरण परत पर होता है, इसलिए यह फ़ेच/रीड टूल और इनबाउंड चैनल सामग्री पर समान रूप से लागू होता है। होस्टेड प्रदाता (OpenAI, Anthropic) पहले से अपना अनुरोध-पक्षीय शुद्धीकरण लागू करते हैं; बाहरी-सामग्री आवरण सक्षम रखें और उपलब्ध होने पर विशेष टोकन को विभाजित/एस्केप करने वाली बैकएंड सेटिंग्स को प्राथमिकता दें। आउटबाउंड मॉडल प्रतिक्रियाओं के लिए एक अलग शुद्धिकारक है, जो अंतिम चैनल डिलीवरी सीमा पर उपयोगकर्ता को दिखाई देने वाले उत्तरों से लीक हुए ``, ``, ``, `` और इसी तरह के आंतरिक ढाँचे को हटा देता है। यह `dmPolicy`, अनुमत-सूचियों, exec स्वीकृतियों, सैंडबॉक्सिंग या `contextVisibility` का स्थान नहीं लेता—यह टोकनाइज़र परत के एक विशिष्ट बायपास को बंद करता है। ### बायपास फ़्लैग (प्रोडक्शन में बंद रखें) - `hooks.mappings[].allowUnsafeExternalContent` - `hooks.gmail.allowUnsafeExternalContent` - Cron पेलोड फ़ील्ड `allowUnsafeExternalContent` इन्हें केवल कड़े सीमित दायरे वाली डीबगिंग के लिए अस्थायी रूप से सक्षम करें; सक्षम होने पर उस एजेंट को पृथक रखें (सैंडबॉक्स + न्यूनतम टूल + समर्पित सत्र नेमस्पेस)। हुक पेलोड अविश्वसनीय सामग्री होते हैं, भले ही डिलीवरी आपके नियंत्रित सिस्टम से आए (मेल/दस्तावेज़/वेब सामग्री में प्रॉम्प्ट इंजेक्शन हो सकता है)। कमज़ोर मॉडल स्तर इस जोखिम को बढ़ाते हैं—हुक-संचालित स्वचालन के लिए मज़बूत आधुनिक मॉडल स्तरों को प्राथमिकता दें और टूल नीति कड़ी रखें (`tools.profile: "messaging"` या उससे अधिक सख़्त), साथ ही जहाँ संभव हो सैंडबॉक्सिंग का उपयोग करें। ### समूहों में रीजनिंग और विस्तृत आउटपुट `/reasoning`, `/verbose` और `/trace` आंतरिक रीजनिंग, टूल आउटपुट या सार्वजनिक चैनल के लिए अभिप्रेत न होने वाले Plugin निदान उजागर कर सकते हैं—इनमें टूल तर्क, URL, Plugin निदान और मॉडल द्वारा देखा गया डेटा शामिल हो सकता है। सार्वजनिक कक्षों में इन्हें अक्षम रखें; केवल विश्वसनीय DM या कड़े नियंत्रण वाले कक्षों में सक्षम करें। ## कमांड प्राधिकरण स्लैश कमांड और निर्देश केवल अधिकृत प्रेषकों के लिए स्वीकार किए जाते हैं, जिनका निर्धारण चैनल अनुमत-सूचियों/पेयरिंग और `commands.useAccessGroups` से होता है ([कॉन्फ़िगरेशन](/hi/gateway/configuration) और [स्लैश कमांड](/hi/tools/slash-commands) देखें)। यदि किसी चैनल की अनुमत-सूची खाली है या उसमें `"*"` शामिल है, तो उस चैनल के लिए कमांड प्रभावी रूप से सभी के लिए खुले होते हैं। `/exec` अधिकृत ऑपरेटरों के लिए केवल-सत्र सुविधा है—यह कॉन्फ़िगरेशन नहीं लिखती और अन्य सत्रों को नहीं बदलती। ## नियंत्रण-प्लेन टूल दो अंतर्निहित टूल नियंत्रण-प्लेन की दृष्टि से संवेदनशील बने रहते हैं: - `gateway`, `config.schema.lookup` / `config.get` के साथ कॉन्फ़िगरेशन पढ़ता है। यह कॉन्फ़िगरेशन नहीं लिख सकता, OpenClaw अपडेट नहीं कर सकता या Gateway पुनः आरंभ नहीं कर सकता। - `cron` ऐसे निर्धारित जॉब बनाता है जो मूल चैट/कार्य समाप्त होने के बाद भी चलते रहते हैं। `gateway` टूल केवल स्वामी के लिए रहता है क्योंकि कॉन्फ़िगरेशन रीड से सीक्रेट और होस्ट टोपोलॉजी उजागर हो सकते हैं। एजेंट स्थायी कॉन्फ़िगरेशन या जीवनचक्र परिवर्तनों का अनुरोध `openclaw` डेलिगेशन टूल के माध्यम से करते हैं; OpenClaw उन्हें टाइप किए गए ऑपरेशन में मैप करता है और लागू करने से पहले मानवीय स्वीकृति की आवश्यकता रखता है। [OpenClaw सेटअप एजेंट](/hi/cli/openclaw#operations-and-approval) देखें। अविश्वसनीय सामग्री संभालने वाले किसी भी एजेंट/सतह के लिए इन्हें डिफ़ॉल्ट रूप से अस्वीकार करें: ```json5 { tools: { deny: ["gateway", "cron", "sessions_spawn", "sessions_send"], }, } ``` `commands.restart=false`, `/restart` और बाहरी `SIGUSR1` पुनः आरंभ अनुरोधों को अक्षम करता है। `gateway` एजेंट टूल में पुनः आरंभ कार्रवाई नहीं है। ## Node निष्पादन (`system.run`) यदि कोई macOS Node पेयर किया गया है, तो Gateway उस पर `system.run` चला सकता है—यह उस Mac पर दूरस्थ कोड निष्पादन है। - Node पेयरिंग (स्वीकृति + टोकन) आवश्यक है। पेयरिंग Node की पहचान/विश्वास और टोकन जारी करना स्थापित करती है; यह प्रति-कमांड स्वीकृति सतह नहीं है। - Gateway, `gateway.nodes.commands.allow` / `gateway.nodes.commands.deny` के माध्यम से एक मोटी वैश्विक Node कमांड नीति लागू करता है। अस्वीकार-सूची केवल सटीक Node कमांड नामों (उदाहरण के लिए `system.run`) से मेल खाती है, कमांड पेलोड के भीतर के शेल टेक्स्ट से नहीं—यदि Gateway की वैश्विक नीति और Node की अपनी exec स्वीकृतियाँ अब भी सीमा लागू करती हैं, तो अलग कमांड सूची विज्ञापित करने वाला पुनः कनेक्ट हो रहा Node अपने आप में कोई भेद्यता नहीं है। - प्रति-Node `system.run` नीति Node की अपनी exec स्वीकृति फ़ाइल (`exec.approvals.node.*`) है, जिसे Mac पर Settings -> Exec approvals (security + ask + allowlist) के माध्यम से नियंत्रित किया जाता है; यह Gateway की वैश्विक कमांड-ID नीति से अधिक सख़्त या शिथिल हो सकती है। - `security="full"` और `ask="off"` चलाने वाला Node डिफ़ॉल्ट विश्वसनीय-ऑपरेटर मॉडल का पालन करता है—यह अपेक्षित व्यवहार है, बग नहीं, जब तक कि आपके डिप्लॉयमेंट को अधिक कड़ा रुख आवश्यक न हो। - स्वीकृति मोड सटीक अनुरोध संदर्भ और जहाँ संभव हो, एक ठोस स्थानीय स्क्रिप्ट/फ़ाइल ऑपरेंड को बाँधता है। यदि OpenClaw किसी इंटरप्रेटर/रनटाइम कमांड के लिए ठीक एक प्रत्यक्ष स्थानीय फ़ाइल की पहचान नहीं कर सकता, तो पूर्ण सिमेंटिक कवरेज का वादा करने के बजाय स्वीकृति-समर्थित निष्पादन अस्वीकार कर दिया जाता है। - `host=node` के लिए, स्वीकृति-समर्थित रन एक कैननिकल तैयार `systemRunPlan` भी संग्रहीत करते हैं; बाद के स्वीकृत फ़ॉरवर्ड उसी संग्रहीत योजना का पुनः उपयोग करते हैं, और Gateway सत्यापन स्वीकृति अनुरोध बनने के बाद कमांड/cwd/सत्र संदर्भ में कॉलर द्वारा किए गए संपादन अस्वीकार करता है। - दूरस्थ निष्पादन पूरी तरह अक्षम करने के लिए: सुरक्षा को `deny` पर सेट करें और उस Mac की Node पेयरिंग हटा दें। ## डायनेमिक Skills (वॉचर / दूरस्थ Node) OpenClaw सत्र के बीच में Skills सूची रीफ़्रेश कर सकता है: `SKILL.md` बदलने पर Skills वॉचर अगले एजेंट टर्न में स्नैपशॉट अपडेट करता है, और macOS Node कनेक्ट होने पर केवल-macOS Skills पात्र हो सकते हैं (बाइनरी जाँच के आधार पर)। Skill फ़ोल्डरों को विश्वसनीय कोड मानें और यह सीमित करें कि उन्हें कौन संशोधित कर सकता है। ## Plugins Plugins, Gateway के साथ प्रक्रिया के भीतर चलते हैं—उन्हें विश्वसनीय कोड मानें। - केवल विश्वसनीय स्रोतों से इंस्टॉल करें; स्पष्ट `plugins.allow` अनुमत-सूचियों को प्राथमिकता दें; सक्षम करने से पहले Plugin कॉन्फ़िगरेशन की समीक्षा करें; Plugin परिवर्तनों के बाद Gateway पुनः आरंभ करें। - Plugins इंस्टॉल/अपडेट करने पर निष्पादन योग्य कोड चलता है: - इंस्टॉल पथ सक्रिय Plugin इंस्टॉल रूट के अंतर्गत प्रति-Plugin डायरेक्टरी है। - ClawHub पैकेज और OpenClaw की बंडल/आधिकारिक कैटलॉग विश्वसनीय स्रोत हैं। नया मनमाना npm, `npm-pack:`, git, स्थानीय पथ/आर्काइव या मार्केटप्लेस स्रोत इंस्टॉल से पहले चेतावनी देता है; गैर-संवादात्मक इंस्टॉल के लिए उस स्रोत की समीक्षा करके उस पर विश्वास करने के बाद `--force` आवश्यक है। `--force` उद्गम की पुष्टि करता है और ओवरराइट की अनुमति देता है; यह `security.installPolicy` या शेष इंस्टॉल सुरक्षा जाँचों को बायपास नहीं करता। अपडेट पहले से चुने गए स्रोत का पुनः उपयोग करते हैं। - OpenClaw इंस्टॉल/अपडेट के दौरान अंतर्निहित स्थानीय खतरनाक-कोड अवरोधन नहीं चलाता। ऑपरेटर-स्वामित्व वाले स्थानीय अनुमति/अवरोध निर्णयों के लिए `security.installPolicy` और निदान स्कैनिंग के लिए `openclaw security audit --deep` का उपयोग करें। - npm और git Plugin इंस्टॉल केवल स्पष्ट इंस्टॉल/अपडेट प्रवाह के दौरान पैकेज-मैनेजर निर्भरता अभिसरण चलाते हैं। स्थानीय पथों और आर्काइव को स्व-निहित पैकेज माना जाता है; OpenClaw `npm install` चलाए बिना उन्हें कॉपी/संदर्भित करता है। - पिन किए गए सटीक संस्करणों (`@scope/pkg@1.2.3`) को प्राथमिकता दें और सक्षम करने से पहले अनपैक किए गए कोड का निरीक्षण करें। - `--dangerously-force-unsafe-install` अप्रचलित है और अब इंस्टॉल/अपडेट व्यवहार नहीं बदलता। - `security.installPolicy` ऑपरेटरों को Skill और Plugin इंस्टॉल के लिए होस्ट-विशिष्ट अनुमति/अवरोध निर्णय लेने हेतु विश्वसनीय स्थानीय कमांड चलाने देता है। यह स्रोत सामग्री स्टेज होने के बाद, लेकिन इंस्टॉल जारी रहने से पहले चलता है, ClawHub Skills पर भी लागू होता है और अप्रचलित असुरक्षित फ़्लैग द्वारा बायपास नहीं किया जाता। विवरण: [Plugins](/hi/tools/plugin) ## सैंडबॉक्सिंग समर्पित दस्तावेज़: [सैंडबॉक्सिंग](/hi/gateway/sandboxing) दो पूरक दृष्टिकोण: - **Docker में पूर्ण Gateway** (कंटेनर सीमा): [Docker](/hi/install/docker) - **टूल सैंडबॉक्स** (`agents.defaults.sandbox`; होस्ट Gateway + सैंडबॉक्स-पृथक टूल; Docker डिफ़ॉल्ट बैकएंड है): [सैंडबॉक्सिंग](/hi/gateway/sandboxing) एजेंटों के बीच पहुँच रोकने के लिए `agents.defaults.sandbox.scope` को `"agent"` (डिफ़ॉल्ट) पर रखें या अधिक सख़्त प्रति-सत्र पृथक्करण के लिए `"session"` का उपयोग करें। `scope: "shared"` एकल कंटेनर या कार्यक्षेत्र का उपयोग करता है। सैंडबॉक्स के भीतर एजेंट कार्यक्षेत्र की पहुँच (`agents.defaults.sandbox.workspaceAccess`): - `"none"` (डिफ़ॉल्ट): टूल `~/.openclaw/sandboxes` के अंतर्गत सैंडबॉक्स कार्यक्षेत्र देखते हैं; एजेंट कार्यक्षेत्र तक पहुँच निषिद्ध है। - `"ro"`: एजेंट कार्यक्षेत्र को `/agent` पर केवल-पढ़ने योग्य रूप में माउंट करता है (`write`/`edit`/`apply_patch` अक्षम करता है)। - `"rw"`: एजेंट कार्यक्षेत्र को `/workspace` पर पढ़ने/लिखने योग्य रूप में माउंट करता है। अतिरिक्त `sandbox.docker.binds` को सामान्यीकृत, कैननिकल किए गए स्रोत पथों के विरुद्ध सत्यापित किया जाता है। अवरुद्ध-पथ अस्वीकार-सूची में `/etc`, `/private/etc`, `/proc`, `/sys`, `/dev`, `/root`, `/boot` और वे डायरेक्टरियाँ शामिल हैं जिनमें सामान्यतः Docker सॉकेट होता है या जो उसका उपनाम होती हैं (उनके अंतर्गत `/run`, `/var/run` और `docker.sock`), साथ ही HOME क्रेडेंशियल उपपथ (`.aws`, `.cargo`, `.config`, `.docker`, `.gnupg`, `.netrc`, `.npm`, `.ssh`) भी शामिल हैं। पैरेंट-सिमलिंक तरकीबों और कैननिकल होम उपनामों को मौजूदा पूर्वजों के माध्यम से हल करके दोबारा जाँचा जाता है, इसलिए यदि वे किसी अवरुद्ध रूट में हल होते हैं तो वे अब भी सुरक्षित रूप से विफल होते हैं। `tools.elevated` वैश्विक आधारभूत एस्केप हैच है, जो exec को सैंडबॉक्स के बाहर चलाता है। प्रभावी होस्ट डिफ़ॉल्ट रूप से `gateway` है, या जब exec लक्ष्य को `node` के रूप में कॉन्फ़िगर किया गया हो तब `node` है। `tools.elevated.allowFrom` को सख़्त रखें और इसे अजनबियों के लिए सक्षम न करें। प्रति एजेंट `agents.entries.*.tools.elevated` के माध्यम से इसे और सीमित करें। [उन्नत मोड](/hi/tools/elevated) देखें। ### उप-एजेंट डेलिगेशन सुरक्षा-सीमा यदि आप सत्र टूल की अनुमति देते हैं, तो प्रत्यायोजित उप-एजेंट रन को एक अन्य सीमा-संबंधी निर्णय मानें: - जब तक एजेंट को वास्तव में प्रत्यायोजन की आवश्यकता न हो, `sessions_spawn` को अस्वीकार करें। - `agents.defaults.subagents.allowAgents` और किसी भी प्रति-एजेंट `agents.entries.*.subagents.allowAgents` ओवरराइड को ज्ञात-सुरक्षित लक्ष्य एजेंटों तक सीमित रखें। - जिन कार्यप्रवाहों को सैंडबॉक्स में ही रहना आवश्यक है, उनके लिए `sessions_spawn` को `sandbox: "require"` के साथ कॉल करें (डिफ़ॉल्ट `"inherit"` है); जब लक्ष्य चाइल्ड रनटाइम सैंडबॉक्स में नहीं होता, तो `"require"` तुरंत विफल हो जाता है। ### केवल-पठन मोड `agents.defaults.sandbox.workspaceAccess: "ro"` (या कार्यक्षेत्र तक पहुँच न देने के लिए `"none"`) को उन टूल अनुमति/अस्वीकृति सूचियों के साथ संयोजित करके केवल-पठन प्रोफ़ाइल बनाएँ जो `write`, `edit`, `apply_patch`, `exec`, `process` आदि को अवरुद्ध करती हों। - `tools.exec.applyPatch.workspaceOnly: true` (डिफ़ॉल्ट): सैंडबॉक्सिंग बंद होने पर भी `apply_patch` को कार्यक्षेत्र डायरेक्टरी के बाहर लिखने/हटाने से रोकता है। `false` केवल तभी सेट करें जब आप जानबूझकर चाहते हों कि `apply_patch` कार्यक्षेत्र के बाहर की फ़ाइलों को छुए। - `tools.fs.workspaceOnly: true` (वैकल्पिक): `read`/`write`/`edit`/`apply_patch` पथों और नेटिव प्रॉम्प्ट छवि के स्वतः-लोड पथों को कार्यक्षेत्र डायरेक्टरी तक सीमित करता है। - फ़ाइल-सिस्टम रूट सीमित रखें—एजेंट/सैंडबॉक्स कार्यक्षेत्रों के लिए अपनी होम डायरेक्टरी जैसे व्यापक रूट से बचें, क्योंकि वे संवेदनशील स्थानीय फ़ाइलों (उदाहरण के लिए `~/.openclaw` के अंतर्गत स्थिति/कॉन्फ़िगरेशन) को फ़ाइल-सिस्टम टूल के सामने उजागर कर सकते हैं। ## प्रति-एजेंट पहुँच प्रोफ़ाइल (बहु-एजेंट) प्रत्येक एजेंट की अपनी सैंडबॉक्स + टूल नीति हो सकती है: पूर्ण पहुँच, केवल-पठन या कोई पहुँच नहीं। प्राथमिकता नियमों के लिए [बहु-एजेंट सैंडबॉक्स और टूल](/hi/tools/multi-agent-sandbox-tools) देखें। सामान्य पैटर्न: व्यक्तिगत एजेंट (पूर्ण पहुँच, कोई सैंडबॉक्स नहीं), परिवार/कार्य एजेंट (सैंडबॉक्सयुक्त + केवल-पठन टूल), सार्वजनिक एजेंट (सैंडबॉक्सयुक्त + कोई फ़ाइल-सिस्टम/शेल टूल नहीं)। ### पूर्ण पहुँच (कोई सैंडबॉक्स नहीं) ```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" }, tools: { // सत्र टूल ट्रांसक्रिप्ट डेटा प्रकट कर सकते हैं। डिफ़ॉल्ट दायरा वर्तमान + स्पॉन किए गए सत्र हैं; // पठन में परिवेशी समूह जागरूकता के माध्यम से देखे जाने वाले समान-एजेंट समूह भी शामिल होते हैं। // उन देखे गए सत्रों को बाहर रखने के लिए visibility: "self" का उपयोग करें। sessions: { visibility: "tree" }, // self | tree | agent | all allow: [ "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "session_status", "discord", "slack", "telegram", "whatsapp", ], deny: [ "apply_patch", "browser", "canvas", "cron", "edit", "exec", "gateway", "image", "nodes", "process", "read", "write", ], }, }, ], }, } ``` ## ब्राउज़र नियंत्रण के जोखिम ब्राउज़र नियंत्रण सक्षम करने से मॉडल को एक वास्तविक ब्राउज़र मिलता है। यदि उस प्रोफ़ाइल में पहले से लॉग-इन सत्र हैं, तो मॉडल उन खातों और डेटा तक पहुँच सकता है—ब्राउज़र प्रोफ़ाइल को संवेदनशील स्थिति मानें। - एजेंट के लिए एक समर्पित प्रोफ़ाइल को प्राथमिकता दें (डिफ़ॉल्ट `openclaw` प्रोफ़ाइल); अपनी व्यक्तिगत दैनिक-उपयोग प्रोफ़ाइल से बचें। - सैंडबॉक्सयुक्त एजेंटों के लिए होस्ट ब्राउज़र नियंत्रण तब तक अक्षम रखें, जब तक आप उन पर भरोसा न करते हों। - स्टैंडअलोन लूपबैक ब्राउज़र नियंत्रण API केवल साझा-सीक्रेट प्रमाणीकरण (Gateway टोकन बेयरर प्रमाणीकरण या Gateway पासवर्ड) का पालन करता है—यह विश्वसनीय-प्रॉक्सी या Tailscale Serve पहचान हेडर का उपयोग नहीं करता। - ब्राउज़र डाउनलोड को अविश्वसनीय इनपुट मानें; एक पृथक डाउनलोड डायरेक्टरी को प्राथमिकता दें। - यदि संभव हो, तो एजेंट प्रोफ़ाइल में ब्राउज़र सिंक/पासवर्ड मैनेजर अक्षम करें। - दूरस्थ Gateway के लिए, "ब्राउज़र नियंत्रण" उस प्रोफ़ाइल की पहुँच वाले संसाधनों पर "ऑपरेटर पहुँच" के समतुल्य है। - Gateway और Node होस्ट को केवल टेलनेट तक सीमित रखें; ब्राउज़र नियंत्रण पोर्ट को LAN या सार्वजनिक इंटरनेट पर उजागर करने से बचें। - आवश्यकता न होने पर ब्राउज़र प्रॉक्सी रूटिंग अक्षम करें (`gateway.nodes.browser.mode="off"`)। - Chrome MCP का मौजूदा-सत्र मोड "अधिक सुरक्षित" नहीं है—यह उस होस्ट Chrome प्रोफ़ाइल की पहुँच वाले संसाधनों पर आपकी ओर से कार्य कर सकता है। - ब्राउज़र मशीन पर एक **Node होस्ट** चलाएँ और जब Gateway ब्राउज़र से दूरस्थ हो, तो Gateway को ब्राउज़र क्रियाओं का प्रॉक्सी बनने दें ([ब्राउज़र टूल](/hi/tools/browser) देखें); Node पेयरिंग को व्यवस्थापक पहुँच की तरह मानें, Gateway और Node होस्ट को एक ही टेलनेट पर रखें और रिले/नियंत्रण पोर्ट को LAN, सार्वजनिक इंटरनेट या Tailscale Funnel पर उजागर करने से बचें। ### ब्राउज़र SSRF नीति (डिफ़ॉल्ट रूप से सख्त) जब तक आप स्पष्ट रूप से ऑप्ट-इन नहीं करते, निजी/आंतरिक गंतव्य अवरुद्ध रहते हैं। - डिफ़ॉल्ट: `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` सेट नहीं होता, इसलिए निजी/आंतरिक/विशेष-उपयोग गंतव्य अवरुद्ध रहते हैं। पुराना उपनाम `allowPrivateNetwork` अभी भी स्वीकार किया जाता है। - ऑप्ट-इन: उन गंतव्यों की अनुमति देने के लिए `dangerouslyAllowPrivateNetwork: true` सेट करें। - सख्त मोड में, स्पष्ट अपवादों के लिए `hostnameAllowlist` (`*.example.com` जैसे पैटर्न) और `allowedHostnames` (सटीक होस्ट अपवाद, जिनमें `localhost` जैसे अन्यथा-अवरुद्ध नाम शामिल हैं) का उपयोग करें। - प्रत्यक्ष नेविगेशन अनुरोधों की पूर्व-जाँच की जाती है। क्रिया और क्रिया-पश्चात सीमित अनुग्रह अवधि के दौरान, संरक्षित Playwright इंटरैक्शन (क्लिक, निर्देशांक क्लिक, होवर, ड्रैग, स्क्रॉल, चयन, कुंजी दबाना, टाइप करना, फ़ॉर्म भरना और मूल्यांकन) HTTP अनुरोध बाइट भेजे जाने से पहले नीति द्वारा अस्वीकृत शीर्ष-स्तरीय और सबफ़्रेम दस्तावेज़ लोड को रोकते हैं, फिर अंतिम `http(s)` URL की यथासंभव पुनः-जाँच करते हैं। - प्रत्येक नए प्रबंधित Chrome लॉन्च से पहले, OpenClaw यथासंभव नेटवर्क पूर्वानुमान अक्षम करता है, जिससे उन अस्वीकृत लोड के लिए Chromium का देखा गया सट्टात्मक प्रीकनेक्ट दब जाता है। यह बहुस्तरीय सुरक्षा है, नीति सीमा नहीं: नियंत्रण-सेवा पुनरारंभ के दौरान पुनः उपयोग किया गया ब्राउज़र और अन्य ब्राउज़र बैकएंड समान सुदृढ़ीकरण साझा नहीं कर सकते। पृष्ठ रूटिंग अनुरोध-स्तरीय अवरोधन ही रहती है, नेटवर्क फ़ायरवॉल नहीं: रीडायरेक्ट चरण, पॉपअप का पहला अनुरोध, Service Worker ट्रैफ़िक, सीमित सुरक्षा अवधि के बाद चलने वाला पृष्ठ कोड और कुछ पृष्ठभूमि/उप-संसाधन पथ इसे बायपास कर सकते हैं। अंतिम-URL जाँच पहचान/क्वारंटीन सुरक्षा बनी रहती है; पूर्ण रोकथाम के लिए स्वामी-पक्षीय निर्गमन पृथक्करण या नीति लागू करने वाला प्रॉक्सी आवश्यक है। ```json5 { browser: { ssrfPolicy: { dangerouslyAllowPrivateNetwork: false, hostnameAllowlist: ["*.example.com", "example.com"], allowedHostnames: ["localhost"], }, }, } ``` ## नेटवर्क एक्सपोज़र ### बाइंड, पोर्ट, फ़ायरवॉल Gateway एक पोर्ट पर WebSocket + HTTP को मल्टीप्लेक्स करता है (डिफ़ॉल्ट `18789`; कॉन्फ़िगरेशन/फ़्लैग/पर्यावरण चर: `gateway.port`, `--port`, `OPENCLAW_GATEWAY_PORT`)। उस HTTP सतह में Control UI (SPA एसेट, डिफ़ॉल्ट आधार पथ `/`) और कैनवास होस्ट (`/__openclaw__/canvas` और `/__openclaw__/a2ui`—मनमाना HTML/JS; सामान्य ब्राउज़र में लोड किए जाने पर इसे अविश्वसनीय सामग्री मानें; इसे अविश्वसनीय नेटवर्क/उपयोगकर्ताओं के सामने उजागर न करें और न ही विशेषाधिकार-प्राप्त वेब सतहों के साथ एक ही ओरिजिन साझा करें) शामिल हैं। `gateway.bind` नियंत्रित करता है कि Gateway कहाँ सुनता है: - `"loopback"` (डिफ़ॉल्ट): केवल स्थानीय क्लाइंट कनेक्ट कर सकते हैं। - `"lan"`, `"tailnet"`, `"custom"`: आक्रमण सतह बढ़ाते हैं। केवल Gateway प्रमाणीकरण (साझा टोकन/पासवर्ड या सही ढंग से कॉन्फ़िगर किया गया विश्वसनीय प्रॉक्सी) और वास्तविक फ़ायरवॉल के साथ उपयोग करें। व्यावहारिक नियम: LAN बाइंड की तुलना में Tailscale Serve को प्राथमिकता दें (Serve Gateway को लूपबैक पर रखता है और Tailscale पहुँच संभालता है); यदि LAN से बाइंड करना आवश्यक हो, तो व्यापक पोर्ट-फ़ॉरवर्डिंग के बजाय पोर्ट को सीमित स्रोत-IP अनुमति सूची से फ़ायरवॉल करें; Gateway को `0.0.0.0` पर बिना प्रमाणीकरण के कभी उजागर न करें। ### UFW के साथ Docker पोर्ट प्रकाशन प्रकाशित कंटेनर पोर्ट (`-p HOST:CONTAINER` या Compose `ports:`) केवल होस्ट `INPUT` नियमों से नहीं, बल्कि Docker की फ़ॉरवर्डिंग शृंखलाओं से रूट होते हैं। नियमों को `DOCKER-USER` में लागू करें (Docker के अपने स्वीकार नियमों से पहले मूल्यांकित); अधिकांश आधुनिक डिस्ट्रो `iptables-nft` फ़्रंटएंड का उपयोग करते हैं, जो इन नियमों को nftables बैकएंड पर भी लागू करता है। ```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 की अलग तालिकाएँ होती हैं—यदि Docker IPv6 सक्षम है, तो `/etc/ufw/after6.rules` में मेल खाती नीति जोड़ें। इंटरफ़ेस नामों (`eth0`) को हार्डकोड करने से बचें, क्योंकि वे VPS इमेज (`ens3`, `enp*` आदि) के अनुसार बदलते हैं और असंगति आपके अस्वीकृति नियम को चुपचाप छोड़ सकती है। ```bash ufw reload iptables -S DOCKER-USER ip6tables -S DOCKER-USER nmap -sT -p 1-65535 --open ``` अपेक्षित बाहरी पोर्ट केवल वही होने चाहिए जिन्हें आप जानबूझकर उजागर करते हैं (अधिकांश सेटअप के लिए: SSH + रिवर्स प्रॉक्सी पोर्ट)। ### mDNS/Bonjour खोज जब बंडल किया गया `bonjour` Plugin सक्षम होता है, तो Gateway स्थानीय डिवाइस खोज के लिए mDNS (`_openclaw-gw._tcp`, पोर्ट 5353) के माध्यम से अपनी उपस्थिति प्रसारित करता है। पूर्ण मोड में ऐसे TXT रिकॉर्ड शामिल होते हैं जो परिचालन विवरण उजागर करते हैं: `cliPath` (उपयोगकर्ता नाम और इंस्टॉलेशन स्थान बताने वाला फ़ाइल-सिस्टम पथ), `sshPort` (SSH उपलब्धता का विज्ञापन करता है), `displayName`/`lanHost` (होस्टनाम जानकारी)। अवसंरचना विवरण प्रसारित करने से LAN की टोह लेना आसान हो जाता है। - जब तक LAN खोज आवश्यक न हो, Bonjour को अक्षम रखें—यह macOS होस्ट पर स्वतः शुरू होता है और अन्य जगहों पर ऑप्ट-इन है; प्रत्यक्ष Gateway URL, टेलनेट, SSH या वाइड-एरिया DNS-SD स्थानीय मल्टीकास्ट की आवश्यकता समाप्त करते हैं। - **न्यूनतम मोड** (Bonjour सक्षम होने पर डिफ़ॉल्ट, उजागर Gateway के लिए अनुशंसित) संवेदनशील फ़ील्ड छोड़ देता है: ```json5 { discovery: { mdns: { mode: "minimal" } } } ``` - **बंद** Plugin को सक्षम रखते हुए स्थानीय खोज को रोकता है: ```json5 { discovery: { mdns: { mode: "off" } } } ``` - **पूर्ण मोड** (ऑप्ट-इन) में `cliPath` + `sshPort` शामिल होते हैं: ```json5 { discovery: { mdns: { mode: "full" } } } ``` - या कॉन्फ़िगरेशन बदले बिना mDNS अक्षम करने के लिए `OPENCLAW_DISABLE_BONJOUR=1` सेट करें। न्यूनतम मोड में Gateway `role`, `gatewayPort`, `transport` प्रसारित करता है, लेकिन `cliPath`/`sshPort` छोड़ देता है; जिन ऐप को CLI पथ चाहिए, वे इसके बजाय प्रमाणीकृत WebSocket कनेक्शन के माध्यम से उसे प्राप्त कर सकते हैं। ### Gateway WebSocket प्रमाणीकरण Gateway प्रमाणीकरण डिफ़ॉल्ट रूप से आवश्यक है—कोई वैध प्रमाणीकरण पथ कॉन्फ़िगर न होने पर Gateway WebSocket कनेक्शन अस्वीकार कर देता है (सुरक्षित रूप से बंद)। ऑनबोर्डिंग डिफ़ॉल्ट रूप से एक टोकन बनाती है (लूपबैक के लिए भी), इसलिए स्थानीय क्लाइंट को प्रमाणीकरण करना आवश्यक है। ```json5 { gateway: { auth: { mode: "token", token: "your-token" } } } ``` `openclaw doctor --generate-gateway-token` आपके लिए एक टोकन बना सकता है। `gateway.remote.token` और `gateway.remote.password` क्लाइंट क्रेडेंशियल स्रोत हैं—वे स्वयं स्थानीय WS एक्सेस को सुरक्षित नहीं करते। स्थानीय कॉल पथ `gateway.remote.*` का उपयोग केवल फ़ॉलबैक के रूप में करते हैं, जब `gateway.auth.*` सेट न हो। यदि `gateway.auth.token` या `gateway.auth.password` को SecretRef के माध्यम से स्पष्ट रूप से कॉन्फ़िगर किया गया है और उसका समाधान नहीं हो पाता, तो समाधान बंद अवस्था में विफल होता है (रिमोट फ़ॉलबैक द्वारा कोई छिपाव नहीं)। `wss://` का उपयोग करते समय रिमोट TLS को `gateway.remote.tlsFingerprint` से पिन करें। प्लेनटेक्स्ट `ws://` को लूपबैक, निजी IP लिटरल, `.local`, और Tailnet `*.ts.net` gateway URL के लिए स्वीकार किया जाता है; अन्य विश्वसनीय निजी-DNS नामों के लिए, ब्रेक-ग्लास के रूप में क्लाइंट प्रोसेस पर `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` सेट करें (केवल प्रोसेस एनवायरनमेंट, कोई `openclaw.json` कुंजी नहीं)। मोबाइल पेयरिंग और Android के मैन्युअल/स्कैन किए गए gateway रूट अधिक सख्त हैं: क्लियरटेक्स्ट केवल लूपबैक के लिए अनुमत है, जबकि निजी-LAN, लिंक-लोकल, `.local`, और डॉट-रहित होस्टनाम को TLS का उपयोग करना होगा, जब तक कि आप विश्वसनीय निजी-नेटवर्क क्लियरटेक्स्ट पथ को स्पष्ट रूप से न चुनें। प्रत्यक्ष स्थानीय लूपबैक कनेक्शन के लिए डिवाइस पेयरिंग स्वतः स्वीकृत होती है (साथ ही विश्वसनीय साझा-सीक्रेट सहायक प्रवाहों के लिए एक सीमित बैकएंड/कंटेनर-स्थानीय स्व-कनेक्ट पथ); Tailnet और LAN कनेक्शन, जिनमें Tailnet पते पर समान-होस्ट कनेक्शन भी शामिल हैं, रिमोट माने जाते हैं और उन्हें अभी भी स्वीकृति की आवश्यकता होती है। हल किया गया `tailnet` पता या `127.0.0.1` अथवा `0.0.0.0` के अतिरिक्त कोई `custom` पता एक अलग `127.0.0.1` लिसनर जोड़ता है; केवल उस स्थानीय लिसनर के कनेक्शन को लूपबैक अर्थ-विज्ञान मिलता है। लूपबैक अनुरोध पर फ़ॉरवर्डेड-हेडर साक्ष्य लूपबैक स्थानीयता को अमान्य कर देता है; मेटाडेटा-अपग्रेड की स्वतः स्वीकृति का दायरा सीमित है। [Gateway पेयरिंग](/hi/gateway/pairing) देखें। प्रमाणीकरण मोड: - `"token"`: साझा बेयरर टोकन (अधिकांश सेटअप के लिए अनुशंसित)। - `"password"`: इसे `OPENCLAW_GATEWAY_PASSWORD` के माध्यम से सेट करना बेहतर है। - `"trusted-proxy"`: उपयोगकर्ताओं को प्रमाणित करने और हेडर के माध्यम से पहचान भेजने के लिए पहचान-जागरूक रिवर्स प्रॉक्सी पर भरोसा करें। [विश्वसनीय प्रॉक्सी प्रमाणीकरण](/hi/gateway/trusted-proxy-auth) देखें। रोटेशन चेकलिस्ट (टोकन/पासवर्ड): नया सीक्रेट जनरेट/सेट करें (`gateway.auth.token` या `OPENCLAW_GATEWAY_PASSWORD`); Gateway को रीस्टार्ट करें (या macOS ऐप को, यदि वह Gateway की निगरानी करता है); रिमोट क्लाइंट अपडेट करें (`gateway.remote.token`/`.password`); सत्यापित करें कि पुराने क्रेडेंशियल अब काम नहीं करते। ### Tailscale Serve पहचान हेडर जब `gateway.auth.allowTailscale`, `true` हो (Serve के लिए डिफ़ॉल्ट), तो OpenClaw Control UI/WebSocket प्रमाणीकरण के लिए Tailscale Serve पहचान हेडर `tailscale-user-login` को स्वीकार करता है। यह स्थानीय Tailscale डेमन (`tailscale whois`) के माध्यम से `x-forwarded-for` पते को हल करके और उसे हेडर से मिलाकर पहचान सत्यापित करता है—यह केवल उन लूपबैक अनुरोधों के लिए सक्रिय होता है जिनमें Tailscale द्वारा इंजेक्ट किए गए `x-forwarded-for`, `x-forwarded-proto`, और `x-forwarded-host` मौजूद हों। इस एसिंक्रोनस जाँच के लिए, समान `{scope, ip}` के विफल प्रयासों को लिमिटर द्वारा विफलता दर्ज करने से पहले क्रमबद्ध किया जाता है, इसलिए एक Serve क्लाइंट से एक साथ किए गए गलत पुनः प्रयास दूसरे प्रयास को तुरंत लॉक आउट कर सकते हैं। HTTP API एंडपॉइंट (`/v1/*`, `/tools/invoke`, `/api/channels/*`) Tailscale पहचान-हेडर प्रमाणीकरण का उपयोग नहीं करते—वे gateway के कॉन्फ़िगर किए गए HTTP प्रमाणीकरण मोड का पालन करते हैं। Gateway HTTP बेयरर प्रमाणीकरण प्रभावी रूप से पूर्ण-या-शून्य ऑपरेटर एक्सेस है। वे क्रेडेंशियल जो `/v1/chat/completions`, `/v1/responses`, `/api/v1/admin/rpc` जैसे Plugin रूट, या `/api/channels/*` को कॉल कर सकते हैं, उस gateway के लिए पूर्ण-एक्सेस ऑपरेटर सीक्रेट हैं: साझा-सीक्रेट बेयरर प्रमाणीकरण पूर्ण डिफ़ॉल्ट ऑपरेटर स्कोप (`operator.admin`, `operator.approvals`, `operator.pairing`, `operator.read`, `operator.talk.secrets`, `operator.write`) और एजेंट टर्न के लिए स्वामी अर्थ-विज्ञान पुनर्स्थापित करता है, तथा अधिक सीमित `x-openclaw-scopes` मान उस साझा-सीक्रेट पथ को कम नहीं करते। प्रति-अनुरोध स्कोप अर्थ-विज्ञान केवल तभी लागू होता है, जब अनुरोध पहचान-धारक मोड (विश्वसनीय प्रॉक्सी प्रमाणीकरण) या स्पष्ट रूप से बिना-प्रमाणीकरण वाले निजी इनग्रेस से आता है; इन मोड में, `x-openclaw-scopes` को छोड़ने पर सामान्य ऑपरेटर डिफ़ॉल्ट स्कोप सेट का फ़ॉलबैक उपयोग होता है, और स्कोप सीमित होने पर `x-openclaw-model` जैसे स्वामी-स्तरीय हेडर के लिए `operator.admin` आवश्यक होता है। `/tools/invoke` और HTTP सेशन इतिहास एंडपॉइंट समान साझा-सीक्रेट नियम का पालन करते हैं। इन क्रेडेंशियल को अविश्वसनीय कॉलर के साथ साझा न करें; प्रत्येक विश्वास सीमा के लिए अलग gateway को प्राथमिकता दें। टोकन-रहित Serve प्रमाणीकरण यह मानता है कि gateway होस्ट स्वयं विश्वसनीय है—यह उसी होस्ट की दुर्भावनापूर्ण प्रोसेस के विरुद्ध सुरक्षा नहीं है। यदि gateway होस्ट पर अविश्वसनीय स्थानीय कोड चल सकता है, तो `allowTailscale` अक्षम करें और स्पष्ट साझा-सीक्रेट प्रमाणीकरण (`token` या `password`) आवश्यक करें। इन हेडर को अपनी रिवर्स प्रॉक्सी से फ़ॉरवर्ड न करें। यदि आप gateway के सामने TLS समाप्त करते हैं या प्रॉक्सी लगाते हैं, तो `allowTailscale` अक्षम करें और इसके बजाय साझा-सीक्रेट प्रमाणीकरण या [विश्वसनीय प्रॉक्सी प्रमाणीकरण](/hi/gateway/trusted-proxy-auth) का उपयोग करें। [Tailscale](/hi/gateway/tailscale) और [वेब अवलोकन](/hi/web) देखें। ### रिवर्स प्रॉक्सी कॉन्फ़िगरेशन nginx/Caddy/Traefik/आदि के पीछे फ़ॉरवर्ड किए गए क्लाइंट IP को सही ढंग से संभालने के लिए `gateway.trustedProxies` सेट करें। जब Gateway किसी ऐसे पते से प्रॉक्सी हेडर का पता लगाता है जो `trustedProxies` में **नहीं** है, तो वह कनेक्शन को स्थानीय नहीं मानेगा; यदि gateway प्रमाणीकरण अक्षम है, तो वह कनेक्शन अस्वीकार कर दिया जाता है। इससे प्रॉक्सी किए गए कनेक्शन localhost से आए हुए दिखाई देकर स्वतः विश्वास प्राप्त नहीं कर पाते। `trustedProxies`, `gateway.auth.mode: "trusted-proxy"` को भी इनपुट देता है, जो अधिक सख्त है: यह डिफ़ॉल्ट रूप से लूपबैक-स्रोत प्रॉक्सी के लिए बंद अवस्था में विफल होता है। समान-होस्ट लूपबैक रिवर्स प्रॉक्सी स्थानीय-क्लाइंट पहचान और फ़ॉरवर्डेड-IP प्रबंधन के लिए `trustedProxies` का उपयोग कर सकते हैं, लेकिन `trusted-proxy` प्रमाणीकरण मोड को केवल तब संतुष्ट कर सकते हैं जब `gateway.auth.trustedProxy.allowLoopback = true`; अन्यथा टोकन/पासवर्ड प्रमाणीकरण का उपयोग करें। ```yaml gateway: trustedProxies: - "10.0.0.1" # रिवर्स प्रॉक्सी IP allowRealIpFallback: false # डिफ़ॉल्ट false; केवल तभी सक्षम करें जब आपकी प्रॉक्सी X-Forwarded-For प्रदान न कर सके auth: mode: password password: ${OPENCLAW_GATEWAY_PASSWORD} ``` जब `trustedProxies` सेट होता है, तो Gateway क्लाइंट IP निर्धारित करने के लिए `X-Forwarded-For` का उपयोग करता है; जब तक `gateway.allowRealIpFallback: true` को स्पष्ट रूप से सेट न किया जाए, `X-Real-IP` को अनदेखा किया जाता है। सुनिश्चित करें कि आपकी प्रॉक्सी `X-Forwarded-For`/`X-Real-IP` में मान जोड़ने के बजाय उन्हें **अधिलेखित** करती है: ```nginx # सही proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; # गलत: अविश्वसनीय क्लाइंट द्वारा दिए गए मानों को बनाए रखता/जोड़ता है proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ``` विश्वसनीय प्रॉक्सी हेडर Node डिवाइस पेयरिंग को स्वतः विश्वसनीय नहीं बनाते—`gateway.nodes.pairing.autoApproveCidrs` एक अलग, डिफ़ॉल्ट रूप से अक्षम ऑपरेटर नीति है, और लूपबैक-स्रोत विश्वसनीय-प्रॉक्सी हेडर पथ तब भी Node की स्वतः स्वीकृति से बाहर रहते हैं जब लूपबैक विश्वसनीय-प्रॉक्सी प्रमाणीकरण सक्षम हो (क्योंकि स्थानीय कॉलर उन हेडर की जालसाजी कर सकते हैं)। ### HSTS और ओरिजिन संबंधी टिप्पणियाँ - OpenClaw का gateway पहले स्थानीय/लूपबैक के लिए बनाया गया है। यदि आप किसी रिवर्स प्रॉक्सी पर TLS समाप्त करते हैं, तो HSTS वहीं सेट करें। - यदि gateway स्वयं HTTPS समाप्त करता है, तो `gateway.http.securityHeaders.strictTransportSecurity` OpenClaw प्रतिक्रियाओं से HSTS हेडर उत्सर्जित करता है। - गैर-लूपबैक Control UI परिनियोजन के लिए डिफ़ॉल्ट रूप से `gateway.controlUi.allowedOrigins` आवश्यक है; `allowedOrigins: ["*"]` एक स्पष्ट सभी-अनुमत नीति है, कोई सुदृढ़ डिफ़ॉल्ट नहीं—अत्यंत नियंत्रित स्थानीय परीक्षण के बाहर इससे बचें। - सामान्य लूपबैक छूट सक्षम होने पर भी लूपबैक पर ब्राउज़र-ओरिजिन प्रमाणीकरण विफलताएँ दर-सीमित रहती हैं, लेकिन लॉकआउट कुंजी एक साझा localhost बकेट के बजाय प्रत्येक सामान्यीकृत `Origin` मान के अनुसार सीमित होती है। - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` Host-हेडर ओरिजिन फ़ॉलबैक मोड सक्षम करता है; इसे ऑपरेटर द्वारा चुनी गई खतरनाक नीति मानें। - DNS रीबाइंडिंग और प्रॉक्सी-होस्ट हेडर व्यवहार को परिनियोजन सुदृढ़ीकरण की चिंता मानें; `trustedProxies` को कड़ा रखें और gateway को सीधे सार्वजनिक इंटरनेट पर उजागर करने से बचें। - विस्तृत परिनियोजन मार्गदर्शन: [विश्वसनीय प्रॉक्सी प्रमाणीकरण](/hi/gateway/trusted-proxy-auth#tls-termination-and-hsts)। ### HTTP पर Control UI डिवाइस पहचान जनरेट करने के लिए Control UI को सुरक्षित संदर्भ (HTTPS या localhost) की आवश्यकता होती है। - `gateway.controlUi.allowInsecureAuth`: स्थानीय संगतता टॉगल। localhost पर, जब पृष्ठ असुरक्षित HTTP के माध्यम से लोड होता है, तो डिवाइस पहचान के बिना Control UI प्रमाणीकरण की अनुमति देता है। पेयरिंग जाँच को बायपास नहीं करता और रिमोट (गैर-localhost) डिवाइस पहचान आवश्यकताओं को शिथिल नहीं करता। HTTPS (Tailscale Serve) को प्राथमिकता दें या UI को `127.0.0.1` पर खोलें। - `gateway.controlUi.dangerouslyDisableDeviceAuth`: सेवानिवृत्त ब्रेक-ग्लास इनपुट। पुराने कॉन्फ़िग उपचार के लिए प्रमाणित, केवल-पेयरिंग Control UI एक्सेस तब तक बनाए रखते हैं, जब तक HTTPS या localhost पर दोबारा खोला गया ब्राउज़र सीमित, स्पष्ट स्व-पेयरिंग माइग्रेशन पूरा नहीं कर लेता; इसे वर्तमान कॉन्फ़िग में न जोड़ें। - उन फ़्लैग से अलग, एक सफल `gateway.auth.mode: "trusted-proxy"` डिवाइस पहचान के बिना **ऑपरेटर** Control UI सेशन स्वीकार कर सकता है—यह जानबूझकर किया गया प्रमाणीकरण-मोड व्यवहार है, कोई `allowInsecureAuth` शॉर्टकट नहीं, और यह Node-भूमिका वाले Control UI सेशन तक विस्तारित नहीं होता। `allowInsecureAuth` सक्षम होने पर `openclaw security audit` चेतावनी देता है। ### असुरक्षित/खतरनाक फ़्लैग `openclaw security audit` प्रत्येक सक्षम ज्ञात असुरक्षित/खतरनाक डीबग स्विच के लिए `config.insecure_or_dangerous_flags` उठाता है (प्रत्येक फ़्लैग के लिए एक निष्कर्ष)। उत्पादन में इन्हें सेट न रखें। यदि ऑडिट दमन कॉन्फ़िगर किए गए हैं, तो मेल खाते निष्कर्षों के `suppressedFindings` में जाने पर भी `security.audit.suppressions.active` सक्रिय आउटपुट में बना रहता है। - `gateway.controlUi.allowInsecureAuth=true` - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` - सेवानिवृत्त `gateway.controlUi.dangerouslyDisableDeviceAuth=true` से आयातित लंबित Control UI डिवाइस-प्रमाणीकरण माइग्रेशन - `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.googlechat.dangerouslyAllowNameMatching` - `channels.msteams.dangerouslyAllowNameMatching` - `channels.slack.dangerouslyAllowNameMatching` - `channels.irc.dangerouslyAllowNameMatching` (Plugin चैनल) - `channels.mattermost.dangerouslyAllowNameMatching` (Plugin चैनल) - `channels.synology-chat.dangerouslyAllowNameMatching` (Plugin चैनल) - `channels.synology-chat.dangerouslyAllowInheritedWebhookPath` (Plugin चैनल) - `channels.zalouser.dangerouslyAllowNameMatching` (Plugin चैनल) नेटवर्क एक्सपोज़र: - `channels.telegram.network.dangerouslyAllowPrivateNetwork` (प्रति अकाउंट भी) सैंडबॉक्स Docker (डिफ़ॉल्ट + प्रति-एजेंट): - `agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets` - `agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources` - `agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin` ## परिनियोजन और होस्ट विश्वास - Gateway होस्ट पर पूर्ण-डिस्क एन्क्रिप्शन; यदि होस्ट साझा है, तो Gateway के लिए एक समर्पित OS उपयोगकर्ता खाते को प्राथमिकता दें। - प्रकाशित पैकेज निर्भरता लॉक: स्रोत चेकआउट `pnpm-lock.yaml` का उपयोग करते हैं; प्रकाशित `openclaw` npm पैकेज और OpenClaw के स्वामित्व वाले npm plugin पैकेजों में `npm-shrinkwrap.json` शामिल होता है, ताकि इंस्टॉलेशन के समय नया ग्राफ़ हल करने के बजाय रिलीज़ से समीक्षा किए गए ट्रांज़िटिव निर्भरता ग्राफ़ का उपयोग किया जाए। यह आपूर्ति-श्रृंखला सुदृढ़ीकरण और रिलीज़ पुनरुत्पादकता की सीमा है, सैंडबॉक्स नहीं—देखें [npm shrinkwrap](/hi/gateway/security/shrinkwrap)। - सुरक्षित फ़ाइल संचालन: OpenClaw रूट-सीमित फ़ाइल पहुँच, परमाणु लेखन, आर्काइव निष्कर्षण, अस्थायी कार्यस्थलों और गुप्त फ़ाइल सहायकों के लिए `@openclaw/fs-safe` का उपयोग करता है। वैकल्पिक POSIX Python सहायक डिफ़ॉल्ट रूप से **बंद** रहता है; `OPENCLAW_FS_SAFE_PYTHON_MODE=auto` या `require` केवल तभी सेट करें, जब आपको अतिरिक्त fd-सापेक्ष परिवर्तन सुदृढ़ीकरण चाहिए और आप Python रनटाइम का समर्थन कर सकते हैं। विवरण: [सुरक्षित फ़ाइल संचालन](/hi/gateway/security/secure-file-operations)। - साझा Slack कार्यस्थान का जोखिम: यदि Slack में हर कोई बॉट को संदेश भेज सकता है, तो मुख्य जोखिम प्रत्यायोजित टूल प्राधिकार है—कोई भी अनुमत प्रेषक एजेंट की नीति के अंतर्गत टूल कॉल (`exec`, ब्राउज़र, नेटवर्क/फ़ाइल टूल) करवा सकता है, किसी एक प्रेषक का प्रॉम्प्ट/सामग्री इंजेक्शन साझा स्थिति/डिवाइस/आउटपुट को प्रभावित कर सकता है, और यदि साझा एजेंट के पास संवेदनशील क्रेडेंशियल/फ़ाइलें हैं, तो कोई भी अनुमत प्रेषक टूल के उपयोग द्वारा संभावित रूप से डेटा बाहर निकलवा सकता है। टीम कार्यप्रवाहों के लिए न्यूनतम टूल वाले अलग एजेंट/Gateway का उपयोग करें; व्यक्तिगत-डेटा वाले एजेंट को निजी रखें। - कंपनी-साझा एजेंट (स्वीकार्य पैटर्न): यह तब उचित है, जब एजेंट का उपयोग करने वाला हर व्यक्ति समान विश्वास सीमा में हो (उदाहरण के लिए, कंपनी की एक टीम) और एजेंट का दायरा केवल व्यावसायिक हो। इसे किसी समर्पित मशीन/VM/कंटेनर पर चलाएँ, समर्पित OS उपयोगकर्ता + समर्पित ब्राउज़र/प्रोफ़ाइल/खातों का उपयोग करें, और उस रनटाइम में व्यक्तिगत Apple/Google खातों या व्यक्तिगत पासवर्ड-मैनेजर/ब्राउज़र प्रोफ़ाइल से साइन इन न करें। एक ही रनटाइम पर व्यक्तिगत और कंपनी की पहचानों को मिलाने से यह पृथक्करण समाप्त हो जाता है और व्यक्तिगत डेटा के उजागर होने का जोखिम बढ़ जाता है। ## डिस्क पर गोपनीय जानकारियाँ मान लें कि `~/.openclaw/` (या `$OPENCLAW_STATE_DIR/`) के अंतर्गत किसी भी चीज़ में गोपनीय जानकारियाँ या निजी डेटा हो सकता है: | पथ | सामग्री | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `openclaw.json` | कॉन्फ़िगरेशन में टोकन (Gateway, रिमोट Gateway), प्रदाता सेटिंग्स और अनुमति-सूचियाँ शामिल हो सकती हैं। | | `credentials/**` | चैनल क्रेडेंशियल (उदाहरण के लिए WhatsApp क्रेडेंशियल), पेयरिंग अनुमति-सूचियाँ, पुराने OAuth आयात। | | `state/openclaw.sqlite` | साझा रनटाइम स्थिति, जिसमें नेटिव MCP OAuth एक्सेस/रिफ़्रेश टोकन, डायनेमिक क्लाइंट पंजीकरण सीक्रेट और डिस्कवरी स्थिति शामिल हैं। | | `agents//agent/openclaw-agent.sqlite` | प्रति-एजेंट रनटाइम स्थिति, जिसमें मॉडल प्रमाणीकरण प्रोफ़ाइल शामिल हैं। | | `agents//agent/auth-profiles.json` | पुराने मॉडल-प्रमाणीकरण माइग्रेशन का स्रोत; doctor समर्थित रिकॉर्ड को प्रति-एजेंट SQLite डेटाबेस में आयात करता है। | | `agents//agent/codex-home/**` | प्रति-एजेंट Codex ऐप-सर्वर खाता, कॉन्फ़िगरेशन, कौशल, Plugin, नेटिव थ्रेड स्थिति, निदान (डिफ़ॉल्ट)। | | `$CODEX_HOME/**` या `~/.codex/**` | नेटिव Codex रनटाइम स्थिति। सामान्य हार्नेस इसे केवल स्पष्ट `plugins.entries.codex.config.appServer.homeScope: "user"` के साथ एक्सेस करता है। अलग पर्यवेक्षण कनेक्शन इसे तब एक्सेस करता है जब उसका निर्धारित होम स्कोप `"user"` हो, जो सेट न होने पर stdio या Unix के लिए डिफ़ॉल्ट है। इसमें नेटिव Codex खाता, कॉन्फ़िगरेशन, Plugin और थ्रेड स्टोर शामिल हैं। पर्यवेक्षण स्रोत मेटाडेटा सूचीबद्ध करता है और उस कनेक्शन पर जारी Chat की प्रामाणिक नेटिव शाखा तथा बाद के टर्न बनाए रखता है; ब्रांचिंग सीमित स्थायी उपयोगकर्ता और सहायक इतिहास को एक प्रमाणित, मॉडल-लॉक किए गए OpenClaw Chat में कॉपी करती है। इसे केवल स्वामी-नियंत्रित Gateway के लिए सक्षम करें। [Codex हार्नेस](/hi/plugins/codex-harness#share-threads-with-codex-desktop-and-cli) और [Codex पर्यवेक्षण](/hi/plugins/codex-supervision) देखें। | | `secrets.json` (वैकल्पिक) | `file` SecretRef प्रदाताओं (`secrets.providers`) द्वारा उपयोग किया जाने वाला फ़ाइल-समर्थित सीक्रेट पेलोड। | | `agents//agent/auth.json` | पुरानी संगतता फ़ाइल; मिलने पर स्थिर `api_key` प्रविष्टियाँ हटा दी जाती हैं। | | `agents//agent/openclaw-agent.sqlite` | प्रति-एजेंट रनटाइम स्थिति, जिसमें ऐसे सत्र रिकॉर्ड और ट्रांसक्रिप्ट शामिल हैं जिनमें निजी संदेश और टूल आउटपुट हो सकते हैं। | | `agents//sessions/**` | पुराने सत्र माइग्रेशन स्रोत और अभिलेखागार, जिनमें निजी संदेश और टूल आउटपुट हो सकते हैं। | | बंडल किए गए Plugin पैकेज | इंस्टॉल किए गए Plugin (और उनके `node_modules/`)। | | `sandboxes/**` | टूल सैंडबॉक्स कार्यस्थान; सैंडबॉक्स के भीतर पढ़ी/लिखी गई फ़ाइलों की प्रतियाँ जमा हो सकती हैं। | ### क्रेडेंशियल संग्रहण मानचित्र बैकअप संबंधी निर्णयों के लिए भी उपयोगी: - WhatsApp: `~/.openclaw/credentials/whatsapp//creds.json` - Telegram बॉट टोकन: कॉन्फ़िगरेशन/पर्यावरण या `channels.telegram.tokenFile` (केवल सामान्य फ़ाइल; सिमलिंक अस्वीकृत) - Discord बॉट टोकन: कॉन्फ़िगरेशन/पर्यावरण या SecretRef (पर्यावरण/फ़ाइल/निष्पादन प्रदाता) - Slack टोकन: कॉन्फ़िगरेशन/पर्यावरण (`channels.slack.*`) - पेयरिंग अनुमति-सूचियाँ: `~/.openclaw/credentials/-allowFrom.json` (डिफ़ॉल्ट खाता) / `--allowFrom.json` (गैर-डिफ़ॉल्ट खाते) - मॉडल प्रमाणीकरण प्रोफ़ाइल: `~/.openclaw/agents//agent/openclaw-agent.sqlite` (`auth_profile_store`) - MCP OAuth सत्र: `~/.openclaw/state/openclaw.sqlite` (`mcp_oauth_stores`) - लेगेसी OAuth आयात: `~/.openclaw/credentials/oauth.json` सुदृढ़ीकरण: अनुमतियाँ प्रतिबंधित रखें (डायरेक्टरी पर `700`, फ़ाइलों पर `600`); Gateway होस्ट पर पूर्ण-डिस्क एन्क्रिप्शन का उपयोग करें; यदि होस्ट साझा है, तो समर्पित OS उपयोगकर्ता खाते को प्राथमिकता दें। ### फ़ाइल अनुमतियाँ - `~/.openclaw/openclaw.json`: `600` (केवल उपयोगकर्ता के लिए पढ़ना/लिखना) - `~/.openclaw`: `700` (केवल उपयोगकर्ता) `openclaw doctor` चेतावनी दे सकता है और इन्हें अधिक प्रतिबंधित करने का विकल्प दे सकता है। ### वर्कस्पेस `.env` फ़ाइलें OpenClaw एजेंटों और टूल के लिए वर्कस्पेस-स्थानीय `.env` फ़ाइलें लोड करता है, लेकिन उन्हें कभी भी Gateway रनटाइम नियंत्रणों को चुपचाप ओवरराइड नहीं करने देता: - अविश्वसनीय वर्कस्पेस `.env` फ़ाइलों से प्रदाता क्रेडेंशियल पर्यावरण चर अवरुद्ध किए जाते हैं—उदाहरण के लिए `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`, और इंस्टॉल किए गए विश्वसनीय plugins द्वारा घोषित प्रदाता प्रमाणीकरण कुंजियाँ। इसके बजाय प्रदाता क्रेडेंशियल को Gateway प्रक्रिया के पर्यावरण, `~/.openclaw/.env` (`$OPENCLAW_STATE_DIR/.env`), कॉन्फ़िगरेशन के `env` ब्लॉक, या वैकल्पिक लॉगिन-शेल आयात में रखें। - `OPENCLAW_` से शुरू होने वाली प्रत्येक कुंजी अविश्वसनीय वर्कस्पेस `.env` फ़ाइलों से अवरुद्ध की जाती है, जिससे पूरा रनटाइम नेमस्पेस आरक्षित रहता है, ताकि भविष्य का `OPENCLAW_*` नियंत्रण डिफ़ॉल्ट रूप से फ़ेल-क्लोज़्ड हो, न कि चेक-इन की गई या हमलावर द्वारा प्रदान की गई `.env` सामग्री से चुपचाप इनहेरिट हो सके। - चैनल और प्रदाता एंडपॉइंट-रूटिंग सेटिंग भी वर्कस्पेस `.env` ओवरराइड से अवरुद्ध हैं (उदाहरण के लिए `MATRIX_HOMESERVER`, `MATTERMOST_URL`, `IRC_HOST`, `SYNOLOGY_CHAT_INCOMING_URL`, `AZURE_SPEECH_ENDPOINT`, और `_ENDPOINT` पर समाप्त होने वाली अन्य कुंजियाँ), ताकि क्लोन किया गया वर्कस्पेस स्थानीय एंडपॉइंट कॉन्फ़िगरेशन के माध्यम से बंडल किए गए कनेक्टर ट्रैफ़िक को पुनर्निर्देशित न कर सके। इन्हें Gateway प्रक्रिया के पर्यावरण, वैश्विक रनटाइम dotenv, स्पष्ट कॉन्फ़िगरेशन, या `env.shellEnv` से आना चाहिए। - विश्वसनीय प्रक्रिया/OS पर्यावरण चर, वैश्विक रनटाइम dotenv, कॉन्फ़िगरेशन `env`, और सक्षम लॉगिन-शेल आयात अब भी लागू होते हैं—यह केवल वर्कस्पेस `.env` फ़ाइल लोडिंग को सीमित करता है। वर्कस्पेस `.env` फ़ाइलें प्रायः एजेंट कोड के पास रहती हैं, दुर्घटनावश कमिट हो जाती हैं, या टूल द्वारा लिखी जाती हैं; प्रदाता क्रेडेंशियल को अवरुद्ध करने से क्लोन किया गया वर्कस्पेस हमलावर-नियंत्रित प्रदाता खातों का प्रतिस्थापन नहीं कर सकता। ### लॉग और ट्रांसक्रिप्ट OpenClaw सत्र निरंतरता और वैकल्पिक मेमोरी इंडेक्सिंग के लिए सत्र ट्रांसक्रिप्ट को डिस्क पर `~/.openclaw/agents//sessions/*.jsonl` के अंतर्गत संग्रहीत करता है—फ़ाइल सिस्टम एक्सेस वाली कोई भी प्रक्रिया/उपयोगकर्ता उन्हें पढ़ सकता है। डिस्क एक्सेस को विश्वास सीमा मानें और `~/.openclaw` अनुमतियों को प्रतिबंधित करें; अधिक मजबूत पृथक्करण के लिए एजेंटों को अलग-अलग OS उपयोगकर्ताओं या होस्ट पर चलाएँ। Gateway लॉग में टूल सारांश, त्रुटियाँ और URL शामिल हो सकते हैं; सत्र ट्रांसक्रिप्ट में चिपकाए गए सीक्रेट, फ़ाइल सामग्री, कमांड आउटपुट और लिंक शामिल हो सकते हैं। - लॉग/ट्रांसक्रिप्ट संशोधन चालू रखें (`logging.redactSensitive: "tools"`, डिफ़ॉल्ट)। - `logging.redactPatterns` के माध्यम से अपने पर्यावरण के लिए कस्टम पैटर्न जोड़ें (टोकन, होस्टनेम, आंतरिक URL)। - निदान साझा करते समय कच्चे लॉग के बजाय `openclaw status --all` (चिपकाने योग्य, सीक्रेट संशोधित) को प्राथमिकता दें। - यदि आपको लंबे समय तक प्रतिधारण की आवश्यकता नहीं है, तो पुराने सत्र ट्रांसक्रिप्ट और लॉग फ़ाइलें हटाएँ। विवरण: [लॉगिंग](/hi/gateway/logging) ## सुरक्षित आधाररेखा (कॉपी/पेस्ट) ```json5 { gateway: { mode: "local", bind: "loopback", port: 18789, auth: { mode: "token", token: "your-long-random-token" }, }, channels: { whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } }, }, }, } ``` Gateway को निजी रखता है, DM पेयरिंग आवश्यक बनाता है, और हमेशा सक्रिय रहने वाले समूह बॉट से बचाता है। टूल निष्पादन को भी अधिक सुरक्षित बनाने के लिए, किसी भी गैर-स्वामी एजेंट के लिए सैंडबॉक्स जोड़ें और खतरनाक टूल अस्वीकार करें (ऊपर "प्रति-एजेंट एक्सेस प्रोफ़ाइल" देखें)। ### अलग नंबर (WhatsApp, Signal, Telegram) फ़ोन नंबर-आधारित चैनलों के लिए सहायक को अपने व्यक्तिगत नंबर से अलग नंबर पर चलाने पर विचार करें, ताकि व्यक्तिगत बातचीत निजी रहे और बॉट नंबर अपनी सीमाओं के भीतर स्वचालन संभाले। ## घटना प्रतिक्रिया ### नियंत्रण 1. इसे रोकें: macOS ऐप को रोकें (यदि वह Gateway की निगरानी करता है) या अपनी `openclaw gateway` प्रक्रिया समाप्त करें। 2. एक्सपोज़र बंद करें: जब तक आप यह न समझ लें कि क्या हुआ, `gateway.bind: "loopback"` सेट करें (या Tailscale Funnel/Serve अक्षम करें)। 3. एक्सेस स्थगित करें: जोखिमपूर्ण DM/समूहों को `dmPolicy: "disabled"` पर स्विच करें / उल्लेख आवश्यक बनाएँ, और सभी को अनुमति देने वाली कोई भी `"*"` प्रविष्टि हटाएँ। ### रोटेट करें (सीक्रेट लीक होने पर समझौता मानें) 1. Gateway प्रमाणीकरण (`gateway.auth.token` / `OPENCLAW_GATEWAY_PASSWORD`) रोटेट करें और पुनः आरंभ करें। 2. Gateway को कॉल कर सकने वाली प्रत्येक मशीन पर दूरस्थ क्लाइंट सीक्रेट (`gateway.remote.token` / `.password`) रोटेट करें। 3. प्रदाता/API क्रेडेंशियल (WhatsApp क्रेडेंशियल, Slack/Discord टोकन, `auth-profiles.json` में मॉडल/API कुंजियाँ, और उपयोग होने पर एन्क्रिप्ट किए गए सीक्रेट पेलोड मान) रोटेट करें। ### ऑडिट 1. `openclaw logs` (या नामित प्रोफ़ाइल के लिए `openclaw --profile logs`) के साथ Gateway लॉग जाँचें। डिफ़ॉल्ट पथ `/tmp/openclaw/openclaw-YYYY-MM-DD.log` है; नामित प्रोफ़ाइल `/tmp/openclaw/openclaw--YYYY-MM-DD.log` का उपयोग करती हैं, जब तक कि `logging.file` उसे ओवरराइड न करे। 2. संबंधित ट्रांसक्रिप्ट की समीक्षा करें: `~/.openclaw/agents//sessions/*.jsonl`। 3. हाल के उन कॉन्फ़िगरेशन परिवर्तनों की समीक्षा करें जिन्होंने एक्सेस बढ़ाया हो सकता है: `gateway.bind`, `gateway.auth`, DM/समूह नीतियाँ, `tools.elevated`, Plugin परिवर्तन। 4. `openclaw security audit --deep` को फिर से चलाएँ और पुष्टि करें कि गंभीर निष्कर्षों का समाधान हो गया है। ### रिपोर्ट के लिए एकत्र करें - टाइमस्टैम्प, Gateway होस्ट OS + OpenClaw संस्करण। - सत्र ट्रांसक्रिप्ट + लॉग का एक छोटा अंतिम भाग (संशोधन के बाद)। - हमलावर ने क्या भेजा और एजेंट ने क्या किया। - क्या Gateway लूपबैक से आगे एक्सपोज़ था (LAN/Tailscale Funnel/Serve)। ## सीक्रेट स्कैनिंग CI रिपॉज़िटरी पर प्री-कमिट `detect-private-key` हुक चलाता है। यदि यह विफल हो, तो कमिट की गई कुंजी सामग्री हटाएँ या रोटेट करें, फिर स्थानीय रूप से पुनरुत्पादित करें: ```bash pre-commit run --all-files detect-private-key ``` ## सुरक्षा समस्याओं की रिपोर्ट करना OpenClaw में कोई भेद्यता मिली? ज़िम्मेदारी से रिपोर्ट करें: 1. ईमेल: [security@openclaw.ai](mailto:security@openclaw.ai) 2. सुधार होने तक सार्वजनिक रूप से पोस्ट न करें। 3. हम आपको श्रेय देंगे (जब तक आप गुमनाम रहना पसंद न करें)।