सुरक्षा

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

• समर्थित: प्रति Gateway एक उपयोगकर्ता/विश्वास सीमा (प्रति सीमा एक OS उपयोगकर्ता/होस्ट/VPS को प्राथमिकता दें)।
• समर्थित नहीं: परस्पर अविश्वसनीय या विरोधी उपयोगकर्ताओं द्वारा इस्तेमाल किया जाने वाला एक साझा Gateway/एजेंट।
• विरोधी-उपयोगकर्ता पृथक्करण के लिए अलग-अलग Gateway (और आदर्श रूप से अलग OS उपयोगकर्ता/होस्ट) आवश्यक हैं।
• यदि कई अविश्वसनीय उपयोगकर्ता एक टूल-सक्षम एजेंट को संदेश भेज सकते हैं, तो वे उस एजेंट के प्रत्यायोजित टूल प्राधिकार को साझा करते हैं।
• यदि कोई Gateway होस्ट की स्थिति/कॉन्फ़िगरेशन (~/.openclaw, जिसमें openclaw.json शामिल है) बदल सकता है, तो उसे विश्वसनीय ऑपरेटर मानें।
• एक Gateway के भीतर, प्रमाणित ऑपरेटर पहुँच एक विश्वसनीय नियंत्रण-पटल भूमिका है, न कि प्रति-उपयोगकर्ता किरायेदार भूमिका।
• sessionKey (सत्र ID, लेबल) एक रूटिंग चयनकर्ता है, प्राधिकरण टोकन नहीं।

कई उपयोगकर्ताओं या संगठनों को होस्ट कर रहे हैं? एक Gateway साझा करने के बजाय प्रत्येक किरायेदार के लिए एक पृथक Gateway सेल चलाएँ। बहु-किरायेदार होस्टिंग देखें।

दूरस्थ पहुँच, DM नीति, रिवर्स प्रॉक्सी या सार्वजनिक एक्सपोज़र बदलने से पहले, पूर्व-उड़ान/रोलबैक चेकलिस्ट के रूप में Gateway एक्सपोज़र रनबुक पूरी करें।

openclaw security audit

इसे किसी भी कॉन्फ़िगरेशन परिवर्तन के बाद या नेटवर्क सतहों को उजागर करने से पहले चलाएँ:

openclaw security auditopenclaw 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 टूल प्रभाव-क्षेत्र)। गंभीरता और स्वतः-सुधार समर्थन सहित पूर्ण सूची: सुरक्षा ऑडिट जाँचें। औपचारिक सत्यापन भी देखें।

निष्कर्षों की प्राथमिकता तय करने का क्रम

1. टूल सक्षम होने के साथ कुछ भी "खुला" हो: पहले DM/समूहों को प्रतिबंधित करें (पेयरिंग/अनुमति-सूचियाँ), फिर टूल नीति/सैंडबॉक्सिंग को सख्त करें।
2. सार्वजनिक नेटवर्क एक्सपोज़र (LAN बाइंड, Funnel, प्रमाणीकरण अनुपस्थित): तुरंत ठीक करें।
3. ब्राउज़र नियंत्रण का दूरस्थ एक्सपोज़र: इसे ऑपरेटर पहुँच जैसा मानें (केवल टेलनेट, Node को सोच-समझकर पेयर करें, कोई सार्वजनिक एक्सपोज़र नहीं)।
4. अनुमतियाँ: स्थिति/कॉन्फ़िगरेशन/क्रेडेंशियल/प्रमाणीकरण समूह या सभी उपयोगकर्ताओं द्वारा पठनीय नहीं होने चाहिए।
5. Plugins: केवल वही लोड करें जिन पर आप स्पष्ट रूप से विश्वास करते हैं।
6. मॉडल चयन: टूल वाले किसी भी बॉट के लिए आधुनिक, निर्देश-सुदृढ़ मॉडल को प्राथमिकता दें।

60 सेकंड में सुदृढ़ आधाररेखा

{  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 और Node का विश्वास

Gateway और Node को अलग-अलग भूमिकाओं वाला एक ऑपरेटर विश्वास डोमेन मानें:

• Gateway: नियंत्रण तल और नीति सतह (gateway.auth, टूल नीति, रूटिंग)।
• Node: उस Gateway से युग्मित दूरस्थ निष्पादन सतह (कमांड, डिवाइस क्रियाएँ, होस्ट-स्थानीय क्षमताएँ)।
• Gateway से प्रमाणित कॉलर पर Gateway के दायरे में भरोसा किया जाता है; युग्मन के बाद, Node की क्रियाओं को उस Node पर विश्वसनीय ऑपरेटर क्रियाएँ माना जाता है। ऑपरेटर के दायरे देखें।
• साझा 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 को नियंत्रित करता है:

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

विवरण + डिस्क पर फ़ाइलें: युग्मन

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/<channel>-allowFrom.json (डिफ़ॉल्ट खाता) या <channel>-<accountId>-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 को बायपास नहीं करता।

विवरण: कॉन्फ़िगरेशन और समूह

DM सत्र पृथक्करण (बहु-उपयोगकर्ता मोड)

डिफ़ॉल्ट रूप से, OpenClaw विभिन्न डिवाइसों में निरंतरता बनाए रखने के लिए सभी DM को मुख्य सत्र में रूट करता है। यदि कई लोग बॉट को DM कर सकते हैं (खुले DM या बहु-व्यक्ति अनुमति-सूची), तो DM सत्रों को अलग करें:

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

session.dmScope के मान:

स्थानीय CLI ऑनबोर्डिंग स्पष्ट session.dmScope को बनाए रखती है और अन्यथा इसे सेट नहीं करती, इसलिए "main" डिफ़ॉल्ट लागू होता है: सभी चैनलों के प्रत्यक्ष संदेश एजेंट के क्रमिक मुख्य सत्र को साझा करते हैं (व्यक्तिगत-एजेंट डिफ़ॉल्ट)। साझा या बहु-उपयोगकर्ता इनबॉक्स के लिए session.dmScope: "per-channel-peer" सेट करें; बहु-उपयोगकर्ता DM ट्रैफ़िक मिलने पर openclaw security audit पृथक्करण की अनुशंसा करता है।

यह संदेश-संदर्भ की सीमा है, होस्ट-प्रशासक की सीमा नहीं। यदि उपयोगकर्ता परस्पर विरोधी हैं और समान Gateway होस्ट/कॉन्फ़िगरेशन साझा करते हैं, तो प्रत्येक भरोसा सीमा के लिए अलग-अलग Gateway चलाएँ।

यदि वही व्यक्ति कई चैनलों पर आपसे संपर्क करता है, तो उन DM सत्रों को एक प्रामाणिक पहचान में समेकित करने के लिए session.identityLinks का उपयोग करें। सत्र प्रबंधन और कॉन्फ़िगरेशन देखें।

संदर्भ दृश्यता बनाम ट्रिगर प्राधिकरण

दो अलग अवधारणाएँ:

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

contextVisibility दूसरे को नियंत्रित करता है:

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

प्रति चैनल या प्रति कक्ष/वार्तालाप सेट करें—समूह देखें। जो रिपोर्ट केवल यह दिखाती हैं कि "मॉडल अनुमति-सूची से बाहर के प्रेषकों का उद्धृत/ऐतिहासिक पाठ देख सकता है", वे 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 हुक के लिए, अंतर्निहित प्रति-संदेश सत्र वार्तालाप संदर्भ को अलग करता है, लेकिन लक्षित एजेंट की टूल या कार्यस्थान अनुमतियाँ नहीं हटाता। अविश्वसनीय मेल को किसी समर्पित रीडर एजेंट तक रूट करें, प्रति-एजेंट सैंडबॉक्स और टूल प्रतिबंध लागू करें और tools.agentToAgent से मुख्य एजेंट को किए जाने वाले किसी भी हस्तांतरण को सीमित करें। Gmail एकीकरण देखें।
• टूल-सक्षम एजेंटों के लिए 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 उसे स्थानीय रूप से डिकोड करता हो—ब्लॉक में <<&lt;EXTERNAL_UNTRUSTED_CONTENT ...&gt;>> सीमा चिह्नों के साथ 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) पहले से अपना अनुरोध-पक्षीय शुद्धीकरण लागू करते हैं; बाहरी-सामग्री आवरण सक्षम रखें और उपलब्ध होने पर विशेष टोकन को विभाजित/एस्केप करने वाली बैकएंड सेटिंग्स को प्राथमिकता दें।

आउटबाउंड मॉडल प्रतिक्रियाओं के लिए एक अलग शुद्धिकारक है, जो अंतिम चैनल डिलीवरी सीमा पर उपयोगकर्ता को दिखाई देने वाले उत्तरों से लीक हुए <tool_call>, <function_calls>, <system-reminder>, <previous_response> और इसी तरह के आंतरिक ढाँचे को हटा देता है।

यह dmPolicy, अनुमत-सूचियों, exec स्वीकृतियों, सैंडबॉक्सिंग या contextVisibility का स्थान नहीं लेता—यह टोकनाइज़र परत के एक विशिष्ट बायपास को बंद करता है।

बायपास फ़्लैग (प्रोडक्शन में बंद रखें)

• hooks.mappings[].allowUnsafeExternalContent
• hooks.gmail.allowUnsafeExternalContent
• Cron पेलोड फ़ील्ड allowUnsafeExternalContent

इन्हें केवल कड़े सीमित दायरे वाली डीबगिंग के लिए अस्थायी रूप से सक्षम करें; सक्षम होने पर उस एजेंट को पृथक रखें (सैंडबॉक्स + न्यूनतम टूल + समर्पित सत्र नेमस्पेस)।

हुक पेलोड अविश्वसनीय सामग्री होते हैं, भले ही डिलीवरी आपके नियंत्रित सिस्टम से आए (मेल/दस्तावेज़/वेब सामग्री में प्रॉम्प्ट इंजेक्शन हो सकता है)। कमज़ोर मॉडल स्तर इस जोखिम को बढ़ाते हैं—हुक-संचालित स्वचालन के लिए मज़बूत आधुनिक मॉडल स्तरों को प्राथमिकता दें और टूल नीति कड़ी रखें (tools.profile: "messaging" या उससे अधिक सख़्त), साथ ही जहाँ संभव हो सैंडबॉक्सिंग का उपयोग करें।

समूहों में रीजनिंग और विस्तृत आउटपुट

/reasoning, /verbose और /trace आंतरिक रीजनिंग, टूल आउटपुट या सार्वजनिक चैनल के लिए अभिप्रेत न होने वाले Plugin निदान उजागर कर सकते हैं—इनमें टूल तर्क, URL, Plugin निदान और मॉडल द्वारा देखा गया डेटा शामिल हो सकता है। सार्वजनिक कक्षों में इन्हें अक्षम रखें; केवल विश्वसनीय DM या कड़े नियंत्रण वाले कक्षों में सक्षम करें।

कमांड प्राधिकरण

स्लैश कमांड और निर्देश केवल अधिकृत प्रेषकों के लिए स्वीकार किए जाते हैं, जिनका निर्धारण चैनल अनुमत-सूचियों/पेयरिंग और commands.useAccessGroups से होता है (कॉन्फ़िगरेशन और स्लैश कमांड देखें)। यदि किसी चैनल की अनुमत-सूची खाली है या उसमें "*" शामिल है, तो उस चैनल के लिए कमांड प्रभावी रूप से सभी के लिए खुले होते हैं।

/exec अधिकृत ऑपरेटरों के लिए केवल-सत्र सुविधा है—यह कॉन्फ़िगरेशन नहीं लिखती और अन्य सत्रों को नहीं बदलती।

नियंत्रण-प्लेन टूल

दो अंतर्निहित टूल नियंत्रण-प्लेन की दृष्टि से संवेदनशील बने रहते हैं:

• gateway, config.schema.lookup / config.get के साथ कॉन्फ़िगरेशन पढ़ता है। यह कॉन्फ़िगरेशन नहीं लिख सकता, OpenClaw अपडेट नहीं कर सकता या Gateway पुनः आरंभ नहीं कर सकता।
• cron ऐसे निर्धारित जॉब बनाता है जो मूल चैट/कार्य समाप्त होने के बाद भी चलते रहते हैं।

gateway टूल केवल स्वामी के लिए रहता है क्योंकि कॉन्फ़िगरेशन रीड से सीक्रेट और होस्ट टोपोलॉजी उजागर हो सकते हैं। एजेंट स्थायी कॉन्फ़िगरेशन या जीवनचक्र परिवर्तनों का अनुरोध openclaw डेलिगेशन टूल के माध्यम से करते हैं; OpenClaw उन्हें टाइप किए गए ऑपरेशन में मैप करता है और लागू करने से पहले मानवीय स्वीकृति की आवश्यकता रखता है। OpenClaw सेटअप एजेंट देखें।

अविश्वसनीय सामग्री संभालने वाले किसी भी एजेंट/सतह के लिए इन्हें डिफ़ॉल्ट रूप से अस्वीकार करें:

{  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

सैंडबॉक्सिंग

समर्पित दस्तावेज़: सैंडबॉक्सिंग

दो पूरक दृष्टिकोण:

• Docker में पूर्ण Gateway (कंटेनर सीमा): Docker
• टूल सैंडबॉक्स (agents.defaults.sandbox; होस्ट Gateway + सैंडबॉक्स-पृथक टूल; Docker डिफ़ॉल्ट बैकएंड है): सैंडबॉक्सिंग

सैंडबॉक्स के भीतर एजेंट कार्यक्षेत्र की पहुँच (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) भी शामिल हैं। पैरेंट-सिमलिंक तरकीबों और कैननिकल होम उपनामों को मौजूदा पूर्वजों के माध्यम से हल करके दोबारा जाँचा जाता है, इसलिए यदि वे किसी अवरुद्ध रूट में हल होते हैं तो वे अब भी सुरक्षित रूप से विफल होते हैं।

उप-एजेंट डेलिगेशन सुरक्षा-सीमा

यदि आप सत्र टूल की अनुमति देते हैं, तो प्रत्यायोजित उप-एजेंट रन को एक अन्य सीमा-संबंधी निर्णय मानें:

• जब तक एजेंट को वास्तव में प्रत्यायोजन की आवश्यकता न हो, 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 के अंतर्गत स्थिति/कॉन्फ़िगरेशन) को फ़ाइल-सिस्टम टूल के सामने उजागर कर सकते हैं।

प्रति-एजेंट पहुँच प्रोफ़ाइल (बहु-एजेंट)

प्रत्येक एजेंट की अपनी सैंडबॉक्स + टूल नीति हो सकती है: पूर्ण पहुँच, केवल-पठन या कोई पहुँच नहीं। प्राथमिकता नियमों के लिए बहु-एजेंट सैंडबॉक्स और टूल देखें।

सामान्य पैटर्न: व्यक्तिगत एजेंट (पूर्ण पहुँच, कोई सैंडबॉक्स नहीं), परिवार/कार्य एजेंट (सैंडबॉक्सयुक्त + केवल-पठन टूल), सार्वजनिक एजेंट (सैंडबॉक्सयुक्त + कोई फ़ाइल-सिस्टम/शेल टूल नहीं)।

पूर्ण पहुँच (कोई सैंडबॉक्स नहीं)

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

केवल-पठन टूल + केवल-पठन कार्यक्षेत्र

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

कोई फ़ाइल-सिस्टम/शेल पहुँच नहीं (प्रदाता संदेश सेवा अनुमत)

{  agents: {    list: [      {        id: "public",        workspace: "~/.openclaw/workspace-public",        sandbox: { mode: "all", scope: "agent", workspaceAccess: "none" },        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 को ब्राउज़र क्रियाओं का प्रॉक्सी बनने दें (ब्राउज़र टूल देखें); 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 जाँच पहचान/क्वारंटीन सुरक्षा बनी रहती है; पूर्ण रोकथाम के लिए स्वामी-पक्षीय निर्गमन पृथक्करण या नीति लागू करने वाला प्रॉक्सी आवश्यक है।

{  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 बैकएंड पर भी लागू करता है।

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

IPv6 की अलग तालिकाएँ होती हैं—यदि Docker IPv6 सक्षम है, तो /etc/ufw/after6.rules में मेल खाती नीति जोड़ें। इंटरफ़ेस नामों (eth0) को हार्डकोड करने से बचें, क्योंकि वे VPS इमेज (ens3, enp* आदि) के अनुसार बदलते हैं और असंगति आपके अस्वीकृति नियम को चुपचाप छोड़ सकती है।

ufw reloadiptables -S DOCKER-USERip6tables -S DOCKER-USERnmap -sT -p 1-65535 <public-ip> --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 के लिए अनुशंसित) संवेदनशील फ़ील्ड छोड़ देता है:

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

• बंद Plugin को सक्षम रखते हुए स्थानीय खोज को रोकता है:

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

• पूर्ण मोड (ऑप्ट-इन) में cliPath + sshPort शामिल होते हैं:

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

• या कॉन्फ़िगरेशन बदले बिना mDNS अक्षम करने के लिए OPENCLAW_DISABLE_BONJOUR=1 सेट करें।

न्यूनतम मोड में Gateway role, gatewayPort, transport प्रसारित करता है, लेकिन cliPath/sshPort छोड़ देता है; जिन ऐप को CLI पथ चाहिए, वे इसके बजाय प्रमाणीकृत WebSocket कनेक्शन के माध्यम से उसे प्राप्त कर सकते हैं।

Gateway WebSocket प्रमाणीकरण

Gateway प्रमाणीकरण डिफ़ॉल्ट रूप से आवश्यक है—कोई वैध प्रमाणीकरण पथ कॉन्फ़िगर न होने पर Gateway WebSocket कनेक्शन अस्वीकार कर देता है (सुरक्षित रूप से बंद)। ऑनबोर्डिंग डिफ़ॉल्ट रूप से एक टोकन बनाती है (लूपबैक के लिए भी), इसलिए स्थानीय क्लाइंट को प्रमाणीकरण करना आवश्यक है।

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

openclaw doctor --generate-gateway-token आपके लिए एक टोकन बना सकता है।

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 पेयरिंग देखें।

प्रमाणीकरण मोड:

• "token": साझा बेयरर टोकन (अधिकांश सेटअप के लिए अनुशंसित)।
• "password": इसे OPENCLAW_GATEWAY_PASSWORD के माध्यम से सेट करना बेहतर है।
• "trusted-proxy": उपयोगकर्ताओं को प्रमाणित करने और हेडर के माध्यम से पहचान भेजने के लिए पहचान-जागरूक रिवर्स प्रॉक्सी पर भरोसा करें। विश्वसनीय प्रॉक्सी प्रमाणीकरण देखें।

रोटेशन चेकलिस्ट (टोकन/पासवर्ड): नया सीक्रेट जनरेट/सेट करें (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 अक्षम करें और इसके बजाय साझा-सीक्रेट प्रमाणीकरण या विश्वसनीय प्रॉक्सी प्रमाणीकरण का उपयोग करें।

Tailscale और वेब अवलोकन देखें।

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

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; अन्यथा टोकन/पासवर्ड प्रमाणीकरण का उपयोग करें।

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 में मान जोड़ने के बजाय उन्हें अधिलेखित करती है:

# सही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 को सीधे सार्वजनिक इंटरनेट पर उजागर करने से बचें।
• विस्तृत परिनियोजन मार्गदर्शन: विश्वसनीय प्रॉक्सी प्रमाणीकरण।

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 होस्ट पर पूर्ण-डिस्क एन्क्रिप्शन; यदि होस्ट साझा है, तो Gateway के लिए एक समर्पित OS उपयोगकर्ता खाते को प्राथमिकता दें।
• प्रकाशित पैकेज निर्भरता लॉक: स्रोत चेकआउट pnpm-lock.yaml का उपयोग करते हैं; प्रकाशित openclaw npm पैकेज और OpenClaw के स्वामित्व वाले npm plugin पैकेजों में npm-shrinkwrap.json शामिल होता है, ताकि इंस्टॉलेशन के समय नया ग्राफ़ हल करने के बजाय रिलीज़ से समीक्षा किए गए ट्रांज़िटिव निर्भरता ग्राफ़ का उपयोग किया जाए। यह आपूर्ति-श्रृंखला सुदृढ़ीकरण और रिलीज़ पुनरुत्पादकता की सीमा है, सैंडबॉक्स नहीं—देखें npm shrinkwrap।
• सुरक्षित फ़ाइल संचालन: OpenClaw रूट-सीमित फ़ाइल पहुँच, परमाणु लेखन, आर्काइव निष्कर्षण, अस्थायी कार्यस्थलों और गुप्त फ़ाइल सहायकों के लिए @openclaw/fs-safe का उपयोग करता है। वैकल्पिक POSIX Python सहायक डिफ़ॉल्ट रूप से बंद रहता है; OPENCLAW_FS_SAFE_PYTHON_MODE=auto या require केवल तभी सेट करें, जब आपको अतिरिक्त fd-सापेक्ष परिवर्तन सुदृढ़ीकरण चाहिए और आप Python रनटाइम का समर्थन कर सकते हैं। विवरण: सुरक्षित फ़ाइल संचालन।
• साझा Slack कार्यस्थान का जोखिम: यदि Slack में हर कोई बॉट को संदेश भेज सकता है, तो मुख्य जोखिम प्रत्यायोजित टूल प्राधिकार है—कोई भी अनुमत प्रेषक एजेंट की नीति के अंतर्गत टूल कॉल (exec, ब्राउज़र, नेटवर्क/फ़ाइल टूल) करवा सकता है, किसी एक प्रेषक का प्रॉम्प्ट/सामग्री इंजेक्शन साझा स्थिति/डिवाइस/आउटपुट को प्रभावित कर सकता है, और यदि साझा एजेंट के पास संवेदनशील क्रेडेंशियल/फ़ाइलें हैं, तो कोई भी अनुमत प्रेषक टूल के उपयोग द्वारा संभावित रूप से डेटा बाहर निकलवा सकता है। टीम कार्यप्रवाहों के लिए न्यूनतम टूल वाले अलग एजेंट/Gateway का उपयोग करें; व्यक्तिगत-डेटा वाले एजेंट को निजी रखें।
• कंपनी-साझा एजेंट (स्वीकार्य पैटर्न): यह तब उचित है, जब एजेंट का उपयोग करने वाला हर व्यक्ति समान विश्वास सीमा में हो (उदाहरण के लिए, कंपनी की एक टीम) और एजेंट का दायरा केवल व्यावसायिक हो। इसे किसी समर्पित मशीन/VM/कंटेनर पर चलाएँ, समर्पित OS उपयोगकर्ता + समर्पित ब्राउज़र/प्रोफ़ाइल/खातों का उपयोग करें, और उस रनटाइम में व्यक्तिगत Apple/Google खातों या व्यक्तिगत पासवर्ड-मैनेजर/ब्राउज़र प्रोफ़ाइल से साइन इन न करें। एक ही रनटाइम पर व्यक्तिगत और कंपनी की पहचानों को मिलाने से यह पृथक्करण समाप्त हो जाता है और व्यक्तिगत डेटा के उजागर होने का जोखिम बढ़ जाता है।

डिस्क पर गोपनीय जानकारियाँ

मान लें कि ~/.openclaw/ (या $OPENCLAW_STATE_DIR/) के अंतर्गत किसी भी चीज़ में गोपनीय जानकारियाँ या निजी डेटा हो सकता है:

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

बैकअप संबंधी निर्णयों के लिए भी उपयोगी:

• WhatsApp: ~/.openclaw/credentials/whatsapp/<accountId>/creds.json
• Telegram बॉट टोकन: कॉन्फ़िगरेशन/पर्यावरण या channels.telegram.tokenFile (केवल सामान्य फ़ाइल; सिमलिंक अस्वीकृत)
• Discord बॉट टोकन: कॉन्फ़िगरेशन/पर्यावरण या SecretRef (पर्यावरण/फ़ाइल/निष्पादन प्रदाता)
• Slack टोकन: कॉन्फ़िगरेशन/पर्यावरण (channels.slack.*)
• पेयरिंग अनुमति-सूचियाँ: ~/.openclaw/credentials/<channel>-allowFrom.json (डिफ़ॉल्ट खाता) / <channel>-<accountId>-allowFrom.json (गैर-डिफ़ॉल्ट खाते)
• मॉडल प्रमाणीकरण प्रोफ़ाइल: ~/.openclaw/agents/<agentId>/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/<agentId>/sessions/*.jsonl के अंतर्गत संग्रहीत करता है—फ़ाइल सिस्टम एक्सेस वाली कोई भी प्रक्रिया/उपयोगकर्ता उन्हें पढ़ सकता है। डिस्क एक्सेस को विश्वास सीमा मानें और ~/.openclaw अनुमतियों को प्रतिबंधित करें; अधिक मजबूत पृथक्करण के लिए एजेंटों को अलग-अलग OS उपयोगकर्ताओं या होस्ट पर चलाएँ।

Gateway लॉग में टूल सारांश, त्रुटियाँ और URL शामिल हो सकते हैं; सत्र ट्रांसक्रिप्ट में चिपकाए गए सीक्रेट, फ़ाइल सामग्री, कमांड आउटपुट और लिंक शामिल हो सकते हैं।

• लॉग/ट्रांसक्रिप्ट संशोधन चालू रखें (logging.redactSensitive: "tools", डिफ़ॉल्ट)।
• logging.redactPatterns के माध्यम से अपने पर्यावरण के लिए कस्टम पैटर्न जोड़ें (टोकन, होस्टनेम, आंतरिक URL)।
• निदान साझा करते समय कच्चे लॉग के बजाय openclaw status --all (चिपकाने योग्य, सीक्रेट संशोधित) को प्राथमिकता दें।
• यदि आपको लंबे समय तक प्रतिधारण की आवश्यकता नहीं है, तो पुराने सत्र ट्रांसक्रिप्ट और लॉग फ़ाइलें हटाएँ।

विवरण: लॉगिंग

सुरक्षित आधाररेखा (कॉपी/पेस्ट)

{  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 <profile> logs) के साथ Gateway लॉग जाँचें। डिफ़ॉल्ट पथ /tmp/openclaw/openclaw-YYYY-MM-DD.log है; नामित प्रोफ़ाइल /tmp/openclaw/openclaw-<profile>-YYYY-MM-DD.log का उपयोग करती हैं, जब तक कि logging.file उसे ओवरराइड न करे।
2. संबंधित ट्रांसक्रिप्ट की समीक्षा करें: ~/.openclaw/agents/<agentId>/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 हुक चलाता है। यदि यह विफल हो, तो कमिट की गई कुंजी सामग्री हटाएँ या रोटेट करें, फिर स्थानीय रूप से पुनरुत्पादित करें:

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

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

OpenClaw में कोई भेद्यता मिली? ज़िम्मेदारी से रिपोर्ट करें:

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