---
read_when:
    - إضافة ميزات توسّع نطاق الوصول أو الأتمتة
summary: اعتبارات الأمان ونموذج التهديد لتشغيل Gateway للذكاء الاصطناعي مع صلاحية الوصول إلى الصدفة
title: الأمان
x-i18n:
    generated_at: "2026-05-03T07:32:36Z"
    model: gpt-5.5
    provider: openai
    source_hash: cee36b337c79199e037d6087f9db0500925ed869d67dca302dedfe0d236b818f
    source_path: gateway/security/index.md
    workflow: 16
---

<Warning>
  **نموذج الثقة للمساعد الشخصي.** يفترض هذا الإرشاد حدًّا واحدًا لمشغّل موثوق
  لكل Gateway (نموذج مستخدم واحد ومساعد شخصي).
  OpenClaw **ليس** حدًّا أمنيًا عدائيًا متعدد المستأجرين لعدة
  مستخدمين خصوم يتشاركون وكيلًا واحدًا أو Gateway واحدًا. إذا كنت تحتاج إلى تشغيل بثقة مختلطة أو
  مستخدمين خصوم، فافصل حدود الثقة (Gateway منفصل +
  بيانات اعتماد، ويفضل مستخدمو نظام تشغيل أو مضيفون منفصلون).
</Warning>

## النطاق أولًا: نموذج أمان المساعد الشخصي

تفترض إرشادات أمان OpenClaw نشر **مساعد شخصي**: حد مشغّل موثوق واحد، وربما عدة وكلاء.

- وضع الأمان المدعوم: مستخدم واحد/حد ثقة واحد لكل Gateway (يفضل مستخدم نظام تشغيل/مضيف/VPS واحد لكل حد).
- ليس حدًا أمنيًا مدعومًا: Gateway/وكيل مشترك واحد يستخدمه مستخدمون غير موثوقين متبادلًا أو خصوم.
- إذا كان عزل المستخدمين الخصوم مطلوبًا، فافصل حسب حد الثقة (Gateway منفصل + بيانات اعتماد، ويفضل مستخدمو/مضيفو نظام تشغيل منفصلون).
- إذا كان بوسع عدة مستخدمين غير موثوقين مراسلة وكيل واحد مفعّل بالأدوات، فتعامل معهم كأنهم يتشاركون صلاحية الأدوات المفوضة نفسها لذلك الوكيل.

تشرح هذه الصفحة التقوية **ضمن ذلك النموذج**. ولا تدّعي عزلًا عدائيًا متعدد المستأجرين على Gateway مشترك واحد.

## فحص سريع: `openclaw security audit`

انظر أيضًا: [التحقق الرسمي (نماذج الأمان)](/ar/security/formal-verification)

شغّل هذا بانتظام (خصوصًا بعد تغيير الإعدادات أو كشف أسطح الشبكة):

```bash
openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --json
```

يبقى `security audit --fix` ضيقًا عمدًا: فهو يحوّل سياسات المجموعات المفتوحة الشائعة
إلى قوائم سماح، ويستعيد `logging.redactSensitive: "tools"`، ويشدّد
أذونات الحالة/الإعدادات/ملفات التضمين، ويستخدم إعادة ضبط ACL في Windows بدلًا من
POSIX `chmod` عند التشغيل على Windows.

يرصد الأخطاء الشائعة (كشف مصادقة Gateway، وكشف التحكم في المتصفح، وقوائم السماح المرتفعة، وأذونات نظام الملفات، وموافقات exec المتساهلة، وكشف أدوات القنوات المفتوحة).

OpenClaw منتج وتجربة في الوقت نفسه: أنت توصل سلوك نماذج متقدمة بأسطح مراسلة حقيقية وأدوات حقيقية. **لا يوجد إعداد “آمن تمامًا”.** الهدف هو أن تكون متعمدًا بشأن:

- من يمكنه التحدث إلى البوت
- أين يُسمح للبوت بالتصرف
- ما الذي يمكن للبوت لمسه

ابدأ بأصغر صلاحية تعمل، ثم وسّعها مع اكتساب الثقة.

### النشر وثقة المضيف

يفترض OpenClaw أن المضيف وحد الإعدادات موثوقان:

- إذا كان بإمكان شخص ما تعديل حالة/إعدادات مضيف Gateway (`~/.openclaw`، بما في ذلك `openclaw.json`)، فتعامل معه كمشغّل موثوق.
- تشغيل Gateway واحد لعدة مشغّلين غير موثوقين متبادلًا/خصوم **ليس إعدادًا موصى به**.
- بالنسبة إلى الفرق ذات الثقة المختلطة، افصل حدود الثقة باستخدام Gateways منفصلة (أو على الأقل مستخدمي/مضيفي نظام تشغيل منفصلين).
- الافتراضي الموصى به: مستخدم واحد لكل جهاز/مضيف (أو VPS)، وGateway واحد لذلك المستخدم، ووكيل واحد أو أكثر في ذلك Gateway.
- داخل مثيل Gateway واحد، يكون وصول المشغّل المصادق عليه دورًا موثوقًا في مستوى التحكم، وليس دور مستأجر لكل مستخدم.
- معرّفات الجلسات (`sessionKey`، ومعرّفات الجلسات، والتسميات) محددات توجيه، وليست رموز تفويض.
- إذا كان بوسع عدة أشخاص مراسلة وكيل واحد مفعّل بالأدوات، فيمكن لكل منهم توجيه مجموعة الأذونات نفسها. يساعد عزل الجلسة/الذاكرة لكل مستخدم في الخصوصية، لكنه لا يحوّل وكيلًا مشتركًا إلى تفويض مضيف لكل مستخدم.

### مساحة عمل Slack مشتركة: خطر حقيقي

إذا كان "كل من في Slack يستطيع مراسلة البوت"، فإن الخطر الأساسي هو صلاحية الأدوات المفوضة:

- يمكن لأي مرسل مسموح له أن يستحث استدعاءات أدوات (`exec`، المتصفح، أدوات الشبكة/الملفات) ضمن سياسة الوكيل؛
- يمكن لحقن الموجه/المحتوى من مرسل واحد أن يسبب إجراءات تؤثر في حالة مشتركة أو أجهزة أو مخرجات؛
- إذا كان لدى وكيل مشترك واحد بيانات اعتماد/ملفات حساسة، فقد يستطيع أي مرسل مسموح له دفع التسريب عبر استخدام الأدوات.

استخدم وكلاء/Gateways منفصلة بأدوات دنيا لسير عمل الفرق؛ وأبق وكلاء البيانات الشخصية خاصين.

### وكيل مشترك للشركة: نمط مقبول

هذا مقبول عندما يكون كل من يستخدم ذلك الوكيل ضمن حد الثقة نفسه (على سبيل المثال فريق شركة واحد) ويكون الوكيل محصورًا بصرامة في نطاق العمل.

- شغّله على جهاز/VM/حاوية مخصصة؛
- استخدم مستخدم نظام تشغيل مخصصًا + متصفحًا/ملفًا شخصيًا/حسابات مخصصة لذلك وقت التشغيل؛
- لا تسجّل دخول ذلك وقت التشغيل إلى حسابات Apple/Google الشخصية أو ملفات مدير كلمات المرور/المتصفح الشخصية.

إذا مزجت الهويات الشخصية وهويات الشركة على وقت التشغيل نفسه، فإنك تلغي الفصل وتزيد خطر كشف البيانات الشخصية.

## مفهوم ثقة Gateway وNode

تعامل مع Gateway وNode كنطاق ثقة مشغّل واحد، مع أدوار مختلفة:

- **Gateway** هو مستوى التحكم وسطح السياسة (`gateway.auth`، سياسة الأدوات، التوجيه).
- **Node** هو سطح التنفيذ البعيد المقترن بذلك Gateway (الأوامر، إجراءات الجهاز، قدرات المضيف المحلية).
- المتصل المصادق عليه لدى Gateway موثوق على نطاق Gateway. بعد الاقتران، تكون إجراءات Node إجراءات مشغّل موثوق على ذلك Node.
- تُلخّص مستويات نطاق المشغّل وفحوصات وقت الموافقة في
  [نطاقات المشغّل](/ar/gateway/operator-scopes).
- يستطيع عملاء الواجهة الخلفية المباشرون عبر local loopback والمصادق عليهم باستخدام رمز/كلمة مرور gateway
  المشتركة إجراء RPCs داخلية لمستوى التحكم دون تقديم هوية جهاز
  مستخدم. هذا ليس تجاوزًا للاقتران البعيد أو اقتران المتصفح: لا يزال عملاء
  الشبكة، وعملاء Node، وعملاء رموز الأجهزة، وهويات الأجهزة الصريحة
  يمرون عبر الاقتران وإنفاذ ترقية النطاق.
- `sessionKey` هو اختيار توجيه/سياق، وليس مصادقة لكل مستخدم.
- موافقات Exec (قائمة السماح + السؤال) حواجز حراسة لقصد المشغّل، وليست عزلًا عدائيًا متعدد المستأجرين.
- الافتراضي المنتج في OpenClaw لإعدادات المشغّل الفردي الموثوق هو السماح بتنفيذ المضيف على `gateway`/`node` دون مطالبات موافقة (`security="full"`، و`ask="off"` ما لم تشدده). هذا الافتراضي تجربة مستخدم مقصودة، وليس ثغرة بحد ذاته.
- تربط موافقات Exec سياق الطلب الدقيق ومعاملات الملفات المحلية المباشرة بأفضل جهد؛ لكنها لا تنمذج دلاليًا كل مسار محمّل وقت تشغيل/مفسّر. استخدم العزل sandboxing وعزل المضيف للحدود القوية.

إذا كنت تحتاج إلى عزل مستخدمين خصوم، فافصل حدود الثقة حسب مستخدم/مضيف نظام التشغيل وشغّل Gateways منفصلة.

## مصفوفة حدود الثقة

استخدم هذا كنموذج سريع عند فرز المخاطر:

| الحد أو التحكم                                            | ما يعنيه                                          | سوء الفهم الشائع                                                            |
| --------------------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------- |
| `gateway.auth` (token/password/trusted-proxy/device auth) | يصادق المتصلين إلى واجهات API الخاصة بـ gateway  | "يتطلب توقيعات لكل رسالة على كل إطار ليكون آمنًا"                            |
| `sessionKey`                                              | مفتاح توجيه لاختيار السياق/الجلسة                | "مفتاح الجلسة حد مصادقة للمستخدم"                                            |
| حواجز الموجه/المحتوى                                     | تقلل خطر إساءة استخدام النموذج                   | "حقن الموجه وحده يثبت تجاوز المصادقة"                                       |
| `canvas.eval` / browser evaluate                          | قدرة مشغّل مقصودة عند تمكينها                    | "أي بدائية JS eval هي تلقائيًا ثغرة في نموذج الثقة هذا"                      |
| صدفة `!` في TUI المحلية                                  | تنفيذ محلي صريح يطلقه المشغّل                    | "أمر ملاءمة الصدفة المحلية هو حقن بعيد"                                      |
| اقتران Node وأوامر Node                                  | تنفيذ بعيد بمستوى المشغّل على الأجهزة المقترنة   | "ينبغي التعامل مع التحكم في الجهاز البعيد كوصول مستخدم غير موثوق افتراضيًا" |
| `gateway.nodes.pairing.autoApproveCidrs`                  | سياسة تسجيل Node في شبكة موثوقة باختيار صريح     | "قائمة سماح معطلة افتراضيًا هي ثغرة اقتران تلقائية"                         |

## ليست ثغرات حسب التصميم

<Accordion title="Common findings that are out of scope">

تُبلّغ هذه الأنماط كثيرًا، وتُغلق عادة دون إجراء ما لم
يُثبت تجاوز حقيقي للحدود:

- سلاسل حقن الموجه فقط دون تجاوز سياسة أو مصادقة أو sandbox.
- ادعاءات تفترض تشغيلًا عدائيًا متعدد المستأجرين على مضيف أو
  إعداد مشترك واحد.
- ادعاءات تصنّف وصول مسار القراءة الطبيعي للمشغّل (على سبيل المثال
  `sessions.list` / `sessions.preview` / `chat.history`) كـ IDOR في
  إعداد Gateway مشترك.
- نتائج نشر مقتصرة على localhost (على سبيل المثال HSTS على gateway
  مقتصر على loopback).
- نتائج توقيع Webhook الوارد في Discord لمسارات واردة غير
  موجودة في هذا المستودع.
- تقارير تتعامل مع بيانات وصف اقتران Node كطبقة موافقة ثانية مخفية لكل أمر
  لـ `system.run`، بينما يبقى حد التنفيذ الحقيقي هو
  سياسة أوامر Node العامة في gateway بالإضافة إلى موافقات exec
  الخاصة بـ Node نفسه.
- تقارير تتعامل مع `gateway.nodes.pairing.autoApproveCidrs` المضبوط كثغرة
  بحد ذاته. هذا الإعداد معطل افتراضيًا، ويتطلب
  إدخالات CIDR/IP صريحة، ولا ينطبق إلا على اقتران `role: node` للمرة الأولى
  دون نطاقات مطلوبة، ولا يوافق تلقائيًا على المشغّل/المتصفح/واجهة Control UI،
  أو WebChat، أو ترقيات الأدوار، أو ترقيات النطاق، أو تغييرات البيانات الوصفية، أو تغييرات المفتاح العام،
  أو مسارات ترويسة trusted-proxy عبر loopback على المضيف نفسه ما لم تكن مصادقة trusted-proxy عبر loopback مفعلة صراحة.
- نتائج "غياب التفويض لكل مستخدم" التي تتعامل مع `sessionKey` كرمز
  مصادقة.

</Accordion>

## خط أساس مقوّى في 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 محليًا فقط، ويعزل الرسائل المباشرة، ويعطل أدوات مستوى التحكم/وقت التشغيل افتراضيًا.

## قاعدة سريعة لصندوق وارد مشترك

إذا كان بإمكان أكثر من شخص مراسلة البوت برسالة مباشرة:

- اضبط `session.dmScope: "per-channel-peer"` (أو `"per-account-channel-peer"` للقنوات متعددة الحسابات).
- أبق `dmPolicy: "pairing"` أو قوائم سماح صارمة.
- لا تجمع أبدًا بين الرسائل المباشرة المشتركة والوصول الواسع إلى الأدوات.
- يقوّي هذا صناديق الوارد التعاونية/المشتركة، لكنه غير مصمم كعزل عدائي لمستأجرين مشاركين عندما يتشارك المستخدمون وصول الكتابة إلى المضيف/الإعدادات.

## نموذج رؤية السياق

يفصل OpenClaw بين مفهومين:

- **تفويض التشغيل**: من يمكنه تشغيل الوكيل (`dmPolicy`، `groupPolicy`، قوائم السماح، بوابات الإشارة).
- **رؤية السياق**: ما السياق التكميلي الذي يُحقن في مدخلات النموذج (نص الرد، النص المقتبس، سجل الخيط، بيانات التعريف المعاد توجيهها).

تضبط قوائم السماح التشغيل وتفويض الأوامر. يتحكم إعداد `contextVisibility` في كيفية ترشيح السياق التكميلي (الردود المقتبسة، جذور الخيوط، السجل المجلب):

- `contextVisibility: "all"` (الافتراضي) يبقي السياق التكميلي كما تم استلامه.
- `contextVisibility: "allowlist"` يرشح السياق التكميلي إلى المرسلين المسموح لهم بفحوصات قائمة السماح النشطة.
- `contextVisibility: "allowlist_quote"` يتصرف مثل `allowlist`، لكنه لا يزال يبقي ردًا مقتبسًا صريحًا واحدًا.

اضبط `contextVisibility` لكل قناة أو لكل غرفة/محادثة. راجع [المحادثات الجماعية](/ar/channels/groups#context-visibility-and-allowlists) لمعرفة تفاصيل الإعداد.

إرشادات فرز الاستشارات:

- الادعاءات التي تُظهر فقط أن "النموذج يمكنه رؤية نص مقتبس أو تاريخي من مرسلين غير مدرجين في قائمة السماح" هي نتائج تقوية يمكن معالجتها باستخدام `contextVisibility`، وليست بحد ذاتها تجاوزات لحدود المصادقة أو sandbox.
- لكي تكون التقارير ذات أثر أمني، لا تزال بحاجة إلى إظهار تجاوز مُثبت لحدود الثقة (المصادقة، السياسة، sandbox، الموافقة، أو حدود أخرى موثقة).

## ما الذي يتحقق منه التدقيق (على مستوى عالٍ)

- **الوصول الوارد** (سياسات الرسائل المباشرة، سياسات المجموعات، قوائم السماح): هل يمكن للغرباء تشغيل البوت؟
- **نطاق تأثير الأدوات** (الأدوات ذات الصلاحيات المرتفعة + الغرف المفتوحة): هل يمكن أن يتحول حقن التعليمات إلى إجراءات shell/ملفات/شبكة؟
- **انحراف موافقات التنفيذ** (`security=full`، و`autoAllowSkills`، وقوائم سماح المفسرات بدون `strictInlineEval`): هل لا تزال حواجز حماية تنفيذ المضيف تفعل ما تظن أنها تفعله؟
  - `security="full"` هو تحذير واسع عن الوضعية، وليس إثباتًا لوجود خطأ. إنه الإعداد الافتراضي المختار لإعدادات المساعد الشخصي الموثوق؛ شدّده فقط عندما يحتاج نموذج التهديد لديك إلى حواجز موافقة أو قائمة سماح.
- **تعرض الشبكة** (ربط/مصادقة Gateway، وTailscale Serve/Funnel، ورموز المصادقة الضعيفة/القصيرة).
- **تعرض التحكم في المتصفح** (العُقد البعيدة، ومنافذ الترحيل، ونقاط نهاية CDP البعيدة).
- **سلامة القرص المحلي** (الأذونات، والروابط الرمزية، وتضمينات الإعداد، ومسارات "المجلد المتزامن").
- **Plugins** (تُحمَّل plugins بدون قائمة سماح صريحة).
- **انحراف/سوء تهيئة السياسة** (إعدادات sandbox docker مهيأة لكن وضع sandbox متوقف؛ أنماط `gateway.nodes.denyCommands` غير فعالة لأن المطابقة تقتصر على اسم الأمر الدقيق فقط (مثل `system.run`) ولا تفحص نص shell؛ إدخالات `gateway.nodes.allowCommands` خطرة؛ تجاوز `tools.profile="minimal"` العام بواسطة ملفات تعريف لكل وكيل؛ أدوات مملوكة لـPlugin يمكن الوصول إليها ضمن سياسة أدوات متساهلة).
- **انحراف توقعات وقت التشغيل** (مثل افتراض أن التنفيذ الضمني لا يزال يعني `sandbox` عندما أصبح `tools.exec.host` افتراضيًا الآن إلى `auto`، أو تعيين `tools.exec.host="sandbox"` صراحةً بينما وضع sandbox متوقف).
- **سلامة النماذج** (التحذير عندما تبدو النماذج المهيأة قديمة؛ ليس حظرًا صارمًا).

إذا شغّلت `--deep`، يحاول OpenClaw أيضًا إجراء فحص Gateway حي بأفضل جهد.

## خريطة تخزين بيانات الاعتماد

استخدم هذا عند تدقيق الوصول أو تحديد ما يجب نسخه احتياطيًا:

- **WhatsApp**: `~/.openclaw/credentials/whatsapp/<accountId>/creds.json`
- **رمز بوت Telegram**: الإعداد/env أو `channels.telegram.tokenFile` (ملف عادي فقط؛ تُرفض الروابط الرمزية)
- **رمز بوت Discord**: الإعداد/env أو SecretRef (مزودو env/file/exec)
- **رموز Slack**: الإعداد/env (`channels.slack.*`)
- **قوائم السماح بالاقتران**:
  - `~/.openclaw/credentials/<channel>-allowFrom.json` (الحساب الافتراضي)
  - `~/.openclaw/credentials/<channel>-<accountId>-allowFrom.json` (الحسابات غير الافتراضية)
- **ملفات تعريف مصادقة النماذج**: `~/.openclaw/agents/<agentId>/agent/auth-profiles.json`
- **حالة وقت تشغيل Codex**: `~/.openclaw/agents/<agentId>/agent/codex-home/`
- **حمولة الأسرار المدعومة بملف (اختياري)**: `~/.openclaw/secrets.json`
- **استيراد OAuth القديم**: `~/.openclaw/credentials/oauth.json`

## قائمة تحقق التدقيق الأمني

عندما يطبع التدقيق النتائج، تعامل معها وفق ترتيب الأولوية هذا:

1. **أي شيء "مفتوح" + الأدوات مفعلة**: أقفل الرسائل المباشرة/المجموعات أولًا (الاقتران/قوائم السماح)، ثم شدّد سياسة الأدوات/sandboxing.
2. **تعرض الشبكة العامة** (ربط LAN، وFunnel، وغياب المصادقة): أصلحه فورًا.
3. **تعرض التحكم البعيد في المتصفح**: عامله مثل وصول المشغّل (tailnet فقط، واقرن العُقد عمدًا، وتجنب التعرض العام).
4. **الأذونات**: تأكد من أن الحالة/الإعداد/بيانات الاعتماد/المصادقة ليست قابلة للقراءة من المجموعة/العالم.
5. **Plugins**: لا تحمّل إلا ما تثق به صراحةً.
6. **اختيار النموذج**: فضّل النماذج الحديثة والمقوّاة تجاه التعليمات لأي بوت لديه أدوات.

## مسرد التدقيق الأمني

كل نتيجة تدقيق مفهرسة بواسطة `checkId` منظم (مثل
`gateway.bind_no_auth` أو `tools.exec.security_full_configured`). فئات الشدة
الحرجة الشائعة:

- `fs.*` — أذونات نظام الملفات على الحالة، والإعداد، وبيانات الاعتماد، وملفات تعريف المصادقة.
- `gateway.*` — وضع الربط، والمصادقة، وTailscale، وواجهة التحكم، وإعداد الوكيل الموثوق.
- `hooks.*`، و`browser.*`، و`sandbox.*`، و`tools.exec.*` — التقوية لكل سطح.
- `plugins.*`، و`skills.*` — سلسلة توريد Plugin/skill ونتائج الفحص.
- `security.exposure.*` — فحوصات شاملة حيث تلتقي سياسة الوصول مع نطاق تأثير الأدوات.

راجع الكتالوج الكامل مع مستويات الشدة، ومفاتيح الإصلاح، ودعم الإصلاح التلقائي في
[فحوصات التدقيق الأمني](/ar/gateway/security/audit-checks).

## واجهة التحكم عبر HTTP

تحتاج واجهة التحكم إلى **سياق آمن** (HTTPS أو localhost) لتوليد هوية الجهاز.
`gateway.controlUi.allowInsecureAuth` هو مفتاح توافق محلي:

- على localhost، يسمح بمصادقة واجهة التحكم بدون هوية الجهاز عندما تُحمَّل الصفحة
  عبر HTTP غير آمن.
- لا يتجاوز فحوصات الاقتران.
- لا يخفف متطلبات هوية الجهاز البعيد (غير localhost).

فضّل HTTPS (Tailscale Serve) أو افتح الواجهة على `127.0.0.1`.

لسيناريوهات كسر الزجاج فقط، يعطل `gateway.controlUi.dangerouslyDisableDeviceAuth`
فحوصات هوية الجهاز بالكامل. هذا خفض أمني شديد؛ أبقه متوقفًا إلا إذا كنت تصحح الأخطاء بنشاط ويمكنك الرجوع بسرعة.

منفصلًا عن تلك العلامات الخطرة، يمكن لنجاح `gateway.auth.mode: "trusted-proxy"`
أن يسمح بجلسات واجهة التحكم بصلاحية **المشغّل** بدون هوية الجهاز. هذا سلوك
مقصود لوضع المصادقة، وليس اختصارًا لـ`allowInsecureAuth`، ولا يزال
لا يمتد إلى جلسات واجهة التحكم بدور العقدة.

يحذر `openclaw security audit` عندما يكون هذا الإعداد مفعلًا.

## ملخص العلامات غير الآمنة أو الخطرة

يرفع `openclaw security audit` النتيجة `config.insecure_or_dangerous_flags` عندما
تكون مفاتيح تصحيح الأخطاء المعروفة غير الآمنة/الخطرة مفعلة. أبقِ هذه غير معينة في
الإنتاج.

<AccordionGroup>
  <Accordion title="العلامات التي يتتبعها التدقيق اليوم">
    - `gateway.controlUi.allowInsecureAuth=true`
    - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true`
    - `gateway.controlUi.dangerouslyDisableDeviceAuth=true`
    - `hooks.gmail.allowUnsafeExternalContent=true`
    - `hooks.mappings[<index>].allowUnsafeExternalContent=true`
    - `tools.exec.applyPatch.workspaceOnly=false`
    - `plugins.entries.acpx.config.permissionMode=approve-all`

  </Accordion>

  <Accordion title="كل مفاتيح `dangerous*` / `dangerously*` في مخطط الإعداد">
    واجهة التحكم والمتصفح:

    - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback`
    - `gateway.controlUi.dangerouslyDisableDeviceAuth`
    - `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork`

    مطابقة أسماء القنوات (القنوات المضمنة وقنوات Plugin؛ متاحة أيضًا لكل
    `accounts.<accountId>` حيثما ينطبق):

    - `channels.discord.dangerouslyAllowNameMatching`
    - `channels.slack.dangerouslyAllowNameMatching`
    - `channels.googlechat.dangerouslyAllowNameMatching`
    - `channels.msteams.dangerouslyAllowNameMatching`
    - `channels.synology-chat.dangerouslyAllowNameMatching` (قناة Plugin)
    - `channels.synology-chat.dangerouslyAllowInheritedWebhookPath` (قناة Plugin)
    - `channels.zalouser.dangerouslyAllowNameMatching` (قناة Plugin)
    - `channels.irc.dangerouslyAllowNameMatching` (قناة Plugin)
    - `channels.mattermost.dangerouslyAllowNameMatching` (قناة Plugin)

    تعرض الشبكة:

    - `channels.telegram.network.dangerouslyAllowPrivateNetwork` (أيضًا لكل حساب)

    Sandbox Docker (الافتراضيات + لكل وكيل):

    - `agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets`
    - `agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources`
    - `agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin`

  </Accordion>
</AccordionGroup>

## تهيئة الوكيل العكسي

إذا شغّلت Gateway خلف وكيل عكسي (nginx، أو Caddy، أو Traefik، إلخ)، فقم بتهيئة
`gateway.trustedProxies` للتعامل الصحيح مع عنوان IP العميل المُمرَّر.

عندما يكتشف Gateway ترويسات وكيل من عنوان **غير** موجود في `trustedProxies`، فلن يعامل الاتصالات كعملاء محليين. إذا كانت مصادقة gateway معطلة، تُرفض تلك الاتصالات. يمنع هذا تجاوز المصادقة حيث كانت الاتصالات الممررة عبر وكيل ستبدو بخلاف ذلك قادمة من localhost وتحصل على ثقة تلقائية.

يغذي `gateway.trustedProxies` أيضًا `gateway.auth.mode: "trusted-proxy"`، لكن وضع المصادقة هذا أشد صرامة:

- تفشل مصادقة trusted-proxy بإغلاق آمن على الوكلاء مصدرهم loopback افتراضيًا
- يمكن للوكلاء العكسيين على loopback في المضيف نفسه استخدام `gateway.trustedProxies` لاكتشاف العميل المحلي والتعامل مع عنوان IP المُمرَّر
- يمكن للوكلاء العكسيين على loopback في المضيف نفسه استيفاء `gateway.auth.mode: "trusted-proxy"` فقط عندما يكون `gateway.auth.trustedProxy.allowLoopback = true`؛ وإلا فاستخدم مصادقة الرمز/كلمة المرور

```yaml
gateway:
  trustedProxies:
    - "10.0.0.1" # reverse proxy IP
  # Optional. Default false.
  # Only enable if your proxy cannot provide X-Forwarded-For.
  allowRealIpFallback: false
  auth:
    mode: password
    password: ${OPENCLAW_GATEWAY_PASSWORD}
```

عند تهيئة `trustedProxies`، يستخدم Gateway ‏`X-Forwarded-For` لتحديد عنوان IP العميل. يتم تجاهل `X-Real-IP` افتراضيًا ما لم يتم تعيين `gateway.allowRealIpFallback: true` صراحةً.

لا تجعل ترويسات الوكيل الموثوق اقتران جهاز العقدة موثوقًا تلقائيًا.
`gateway.nodes.pairing.autoApproveCidrs` هي سياسة مشغّل منفصلة ومعطلة افتراضيًا.
حتى عند تفعيلها، تُستثنى مسارات ترويسات trusted-proxy التي مصدرها loopback
من الموافقة التلقائية على العقدة لأن المتصلين المحليين يمكنهم تزوير تلك
الترويسات، بما في ذلك عندما تكون مصادقة trusted-proxy عبر loopback مفعلة صراحةً.

سلوك وكيل عكسي جيد (استبدال ترويسات التمرير الواردة):

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

سلوك وكيل عكسي سيئ (إلحاق/الحفاظ على ترويسات تمرير غير موثوقة):

```nginx
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
```

## ملاحظات HSTS والأصل

- بوابة OpenClaw محلية/local loopback أولًا. إذا أنهيت TLS عند وكيل عكسي، فعيّن HSTS على نطاق HTTPS المواجه للوكيل هناك.
- إذا كان gateway نفسه ينهي HTTPS، فيمكنك تعيين `gateway.http.securityHeaders.strictTransportSecurity` لإصدار ترويسة HSTS من استجابات OpenClaw.
- توجد إرشادات النشر التفصيلية في [مصادقة الوكيل الموثوق](/ar/gateway/trusted-proxy-auth#tls-termination-and-hsts).
- بالنسبة إلى عمليات نشر واجهة التحكم غير loopback، يكون `gateway.controlUi.allowedOrigins` مطلوبًا افتراضيًا.
- `gateway.controlUi.allowedOrigins: ["*"]` هي سياسة صريحة للسماح بكل أصول المتصفح، وليست افتراضيًا مقوّى. تجنبها خارج الاختبار المحلي الخاضع للرقابة بإحكام.
- لا تزال إخفاقات مصادقة أصل المتصفح على loopback خاضعة لتحديد المعدل حتى عندما يكون
  الإعفاء العام لـloopback مفعلًا، لكن مفتاح القفل يكون محددًا لكل
  قيمة `Origin` مُطبَّعة بدلًا من حاوية localhost مشتركة واحدة.
- يفعّل `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` وضع الرجوع إلى أصل ترويسة Host؛ عامله كسياسة خطرة اختارها المشغّل.
- تعامل مع DNS rebinding وسلوك ترويسة proxy-host كمخاوف تقوية للنشر؛ أبقِ `trustedProxies` محكمة وتجنب تعريض gateway مباشرةً للإنترنت العام.

## سجلات الجلسات المحلية موجودة على القرص

يخزن OpenClaw نصوص الجلسات على القرص ضمن `~/.openclaw/agents/<agentId>/sessions/*.jsonl`.
هذا مطلوب لاستمرارية الجلسة و(اختياريًا) لفهرسة ذاكرة الجلسات، لكنه يعني أيضًا أن
**أي عملية/مستخدم لديه وصول إلى نظام الملفات يمكنه قراءة تلك السجلات**. تعامل مع الوصول إلى القرص كحدود
الثقة وأحكم الأذونات على `~/.openclaw` (راجع قسم التدقيق أدناه). إذا كنت تحتاج
عزلًا أقوى بين الوكلاء، فشغّلهم تحت مستخدمي نظام تشغيل منفصلين أو مضيفين منفصلين.

## تنفيذ العقدة (system.run)

إذا كانت عقدة macOS مقترنة، يمكن لـGateway استدعاء `system.run` على تلك العقدة. هذا **تنفيذ تعليمات برمجية عن بُعد** على Mac:

- يتطلب إقران Node (موافقة + رمز مميز).
- إقران Node مع Gateway ليس سطح موافقة لكل أمر. بل ينشئ هوية/ثقة Node وإصدار الرمز المميز.
- يطبق Gateway سياسة أوامر عامة وخشنة لـ Node عبر `gateway.nodes.allowCommands` / `denyCommands`.
- يتم التحكم على Mac عبر **Settings → Exec approvals** (الأمان + السؤال + قائمة السماح).
- سياسة `system.run` لكل Node هي ملف موافقات التنفيذ الخاص بـ Node (`exec.approvals.node.*`)، ويمكن أن تكون أشد أو أرخى من سياسة معرفات الأوامر العامة في Gateway.
- عندما يعمل Node مع `security="full"` و`ask="off"` فهو يتبع نموذج المشغل الموثوق الافتراضي. تعامل مع ذلك كسلوك متوقع ما لم يتطلب نشرك صراحة موقف موافقة أو قائمة سماح أكثر تشددا.
- يربط وضع الموافقة سياق الطلب الدقيق، وعندما يكون ذلك ممكنا، معاملا واحدا ملموسا لملف/سكربت محلي. إذا لم يتمكن OpenClaw من تحديد ملف محلي مباشر واحد بالضبط لأمر مفسر/بيئة تشغيل، فسيتم رفض التنفيذ المدعوم بالموافقة بدلا من الوعد بتغطية دلالية كاملة.
- بالنسبة إلى `host=node`، تخزن عمليات التشغيل المدعومة بالموافقة أيضا
  `systemRunPlan` محضرا وقياسيا؛ وتعيد عمليات التمرير الموافق عليها لاحقا استخدام تلك الخطة المخزنة، كما يرفض تحقق Gateway تعديلات المستدعي على سياق الأمر/cwd/الجلسة بعد إنشاء طلب الموافقة.
- إذا كنت لا تريد التنفيذ عن بعد، فاضبط الأمان على **deny** وأزل إقران Node لذلك Mac.

هذا التمييز مهم للفرز:

- لا تعد إعادة اتصال Node مقترن يعلن قائمة أوامر مختلفة، بحد ذاتها، ثغرة إذا كانت سياسة Gateway العامة وموافقات التنفيذ المحلية في Node لا تزال تفرض حد التنفيذ الفعلي.
- التقارير التي تعامل بيانات إقران Node الوصفية كطبقة موافقة ثانية مخفية لكل أمر تكون عادة التباسا في السياسة/تجربة المستخدم، وليست تجاوزا لحد أمني.

## Skills الديناميكية (المراقب / العقد البعيدة)

يمكن لـ OpenClaw تحديث قائمة Skills في منتصف الجلسة:

- **مراقب Skills**: يمكن للتغييرات في `SKILL.md` أن تحدث لقطة Skills في دور الوكيل التالي.
- **العقد البعيدة**: يمكن لاتصال Node يعمل بنظام macOS أن يجعل Skills الخاصة بـ macOS فقط مؤهلة (بناء على فحص bin).

تعامل مع مجلدات Skills كـ **كود موثوق** وقيّد من يمكنه تعديلها.

## نموذج التهديد

يمكن لمساعدك الذكي أن:

- ينفذ أوامر shell عشوائية
- يقرأ/يكتب الملفات
- يصل إلى خدمات الشبكة
- يرسل رسائل إلى أي شخص (إذا منحته وصول WhatsApp)

يمكن للأشخاص الذين يراسلونك أن:

- يحاولوا خداع الذكاء الاصطناعي لديك لفعل أشياء سيئة
- يمارسوا الهندسة الاجتماعية للوصول إلى بياناتك
- يفحصوا تفاصيل البنية التحتية

## المفهوم الأساسي: التحكم في الوصول قبل الذكاء

معظم الإخفاقات هنا ليست استغلالات معقدة — إنها "أرسل شخص رسالة إلى البوت، فنفذ البوت ما طلبه."

موقف OpenClaw:

- **الهوية أولا:** قرر من يمكنه التحدث إلى البوت (إقران DM / قوائم السماح / "open" الصريح).
- **النطاق بعد ذلك:** قرر أين يسمح للبوت بالتصرف (قوائم سماح المجموعات + بوابة الذكر، الأدوات، العزل، أذونات الجهاز).
- **النموذج أخيرا:** افترض أن النموذج قابل للتلاعب؛ صمم بحيث يكون نطاق الضرر الناتج عن التلاعب محدودا.

## نموذج تخويل الأوامر

لا يتم احترام أوامر الشرطة المائلة والتوجيهات إلا للمرسلين **المخولين**. يستمد التخويل من
قوائم السماح/الإقران الخاصة بالقناة بالإضافة إلى `commands.useAccessGroups` (راجع [التكوين](/ar/gateway/configuration)
و[أوامر الشرطة المائلة](/ar/tools/slash-commands)). إذا كانت قائمة سماح القناة فارغة أو تتضمن `"*"`,
فإن الأوامر تكون مفتوحة فعليا لتلك القناة.

`/exec` وسيلة راحة مخصصة للجلسة فقط للمشغلين المخولين. لا يكتب التكوين أو
يغير جلسات أخرى.

## مخاطر أدوات مستوى التحكم

يمكن لأداتين مدمجتين إجراء تغييرات دائمة في مستوى التحكم:

- يمكن لـ `gateway` فحص التكوين باستخدام `config.schema.lookup` / `config.get`، ويمكنه إجراء تغييرات دائمة باستخدام `config.apply` و`config.patch` و`update.run`.
- يمكن لـ `cron` إنشاء مهام مجدولة تواصل العمل بعد انتهاء المحادثة/المهمة الأصلية.

لا تزال أداة وقت تشغيل `gateway` المخصصة للمالك فقط ترفض إعادة كتابة
`tools.exec.ask` أو `tools.exec.security`؛ تتم تسوية الأسماء المستعارة القديمة `tools.bash.*`
إلى مسارات التنفيذ المحمية نفسها قبل الكتابة.
تفشل تعديلات `gateway config.apply` و`gateway config.patch` المدفوعة من الوكيل
بإغلاق آمن افتراضيا: لا يمكن للوكيل ضبط إلا مجموعة ضيقة من مسارات المطالبة، والنموذج، وبوابة الذكر.
لذلك تكون أشجار التكوين الحساسة الجديدة محمية
ما لم تتم إضافتها عمدا إلى قائمة السماح.

بالنسبة إلى أي وكيل/سطح يتعامل مع محتوى غير موثوق، ارفض هذه افتراضيا:

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

`commands.restart=false` يحظر إجراءات إعادة التشغيل فقط. ولا يعطل إجراءات تكوين/تحديث `gateway`.

## Plugins

تعمل Plugins **داخل العملية** مع Gateway. تعامل معها ككود موثوق:

- ثبّت Plugins من مصادر تثق بها فقط.
- فضل قوائم سماح `plugins.allow` الصريحة.
- راجع تكوين Plugin قبل التمكين.
- أعد تشغيل Gateway بعد تغييرات Plugin.
- إذا ثبّت أو حدّثت Plugins (`openclaw plugins install <package>`، `openclaw plugins update <id>`)، فتعامل مع ذلك كتشغيل كود غير موثوق:
  - مسار التثبيت هو دليل كل Plugin ضمن جذر تثبيت Plugin النشط.
  - يشغل OpenClaw فحصا مدمجا للكود الخطر قبل التثبيت/التحديث. تحظر النتائج `critical` افتراضيا.
  - تشغيلات تثبيت Plugin عبر npm وgit تنفذ تقارب تبعيات مدير الحزم فقط أثناء تدفق التثبيت/التحديث الصريح. تعامل المسارات المحلية والأرشيفات كحزم Plugin مكتفية بذاتها؛ ينسخها/يشير إليها OpenClaw دون تشغيل `npm install`.
  - فضل الإصدارات المثبتة والدقيقة (`@scope/pkg@1.2.3`)، وافحص الكود المفكوك على القرص قبل التمكين.
  - `--dangerously-force-unsafe-install` مخصص لكسر الطوارئ فقط للنتائج الإيجابية الكاذبة في الفحص المدمج ضمن تدفقات تثبيت/تحديث Plugin. لا يتجاوز حظر سياسة خطاف `before_install` في Plugin ولا يتجاوز إخفاقات الفحص.
  - تتبع تثبيتات تبعيات Skills المدعومة من Gateway نفس تقسيم الخطير/المشبوه: تحظر النتائج المدمجة `critical` ما لم يضبط المستدعي صراحة `dangerouslyForceUnsafeInstall`، بينما تبقى النتائج المشبوهة تحذر فقط. يظل `openclaw skills install` تدفق تنزيل/تثبيت Skills المنفصل من ClawHub.

التفاصيل: [Plugins](/ar/tools/plugin)

## نموذج وصول DM: الإقران، قائمة السماح، الفتح، التعطيل

تدعم جميع القنوات الحالية القادرة على DM سياسة DM (`dmPolicy` أو `*.dm.policy`) تضبط الرسائل الواردة في DM **قبل** معالجة الرسالة:

- `pairing` (افتراضي): يتلقى المرسلون غير المعروفين رمز إقران قصيرا ويتجاهل البوت رسالتهم حتى تتم الموافقة. تنتهي صلاحية الرموز بعد ساعة واحدة؛ ولن تعيد رسائل DM المتكررة إرسال رمز حتى يتم إنشاء طلب جديد. يتم تحديد الطلبات المعلقة عند **3 لكل قناة** افتراضيا.
- `allowlist`: يتم حظر المرسلين غير المعروفين (دون مصافحة إقران).
- `open`: السماح لأي شخص بإرسال DM (عام). **يتطلب** أن تتضمن قائمة سماح القناة `"*"` (اشتراك صريح).
- `disabled`: تجاهل رسائل DM الواردة بالكامل.

وافق عبر CLI:

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

التفاصيل + الملفات على القرص: [الإقران](/ar/channels/pairing)

## عزل جلسات DM (وضع المستخدمين المتعددين)

افتراضيا، يوجه OpenClaw **كل رسائل DM إلى الجلسة الرئيسية** بحيث يحتفظ مساعدك بالاستمرارية عبر الأجهزة والقنوات. إذا كان **عدة أشخاص** يمكنهم إرسال DM إلى البوت (رسائل DM مفتوحة أو قائمة سماح متعددة الأشخاص)، ففكر في عزل جلسات DM:

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

يمنع هذا تسرب السياق بين المستخدمين مع إبقاء محادثات المجموعات معزولة.

هذا حد لسياق المراسلة، وليس حد إدارة مضيف. إذا كان المستخدمون متخاصمين فيما بينهم ويشاركون مضيف/تكوين Gateway نفسه، فشغّل بوابات منفصلة لكل حد ثقة بدلا من ذلك.

### وضع DM الآمن (موصى به)

تعامل مع المقتطف أعلاه كـ **وضع DM الآمن**:

- الافتراضي: `session.dmScope: "main"` (كل رسائل DM تشترك في جلسة واحدة للاستمرارية).
- افتراضي الإعداد الأولي المحلي عبر CLI: يكتب `session.dmScope: "per-channel-peer"` عندما يكون غير مضبوط (مع إبقاء القيم الصريحة الحالية).
- وضع DM الآمن: `session.dmScope: "per-channel-peer"` (يحصل كل زوج قناة+مرسل على سياق DM معزول).
- عزل النظير عبر القنوات: `session.dmScope: "per-peer"` (يحصل كل مرسل على جلسة واحدة عبر كل القنوات من النوع نفسه).

إذا كنت تشغل عدة حسابات على القناة نفسها، فاستخدم `per-account-channel-peer` بدلا من ذلك. إذا اتصل بك الشخص نفسه على عدة قنوات، فاستخدم `session.identityLinks` لدمج جلسات DM تلك في هوية قياسية واحدة. راجع [إدارة الجلسات](/ar/concepts/session) و[التكوين](/ar/gateway/configuration).

## قوائم السماح لرسائل DM والمجموعات

لدى OpenClaw طبقتان منفصلتان من "من يمكنه تشغيلني؟":

- **قائمة سماح DM** (`allowFrom` / `channels.discord.allowFrom` / `channels.slack.allowFrom`; قديم: `channels.discord.dm.allowFrom`, `channels.slack.dm.allowFrom`): من يسمح له بالتحدث إلى البوت في الرسائل المباشرة.
  - عندما يكون `dmPolicy="pairing"`، تكتب الموافقات إلى مخزن قائمة سماح الإقران على نطاق الحساب تحت `~/.openclaw/credentials/` (`<channel>-allowFrom.json` للحساب الافتراضي، و`<channel>-<accountId>-allowFrom.json` للحسابات غير الافتراضية)، وتدمج مع قوائم سماح التكوين.
- **قائمة سماح المجموعات** (خاصة بالقناة): أي مجموعات/قنوات/خوادم guild سيقبل البوت الرسائل منها أصلا.
  - الأنماط الشائعة:
    - `channels.whatsapp.groups`، `channels.telegram.groups`، `channels.imessage.groups`: افتراضيات لكل مجموعة مثل `requireMention`؛ عند ضبطها، تعمل أيضا كقائمة سماح للمجموعات (أدرج `"*"` للإبقاء على سلوك السماح للجميع).
    - `groupPolicy="allowlist"` + `groupAllowFrom`: تقييد من يمكنه تشغيل البوت _داخل_ جلسة مجموعة (WhatsApp/Telegram/Signal/iMessage/Microsoft Teams).
    - `channels.discord.guilds` / `channels.slack.channels`: قوائم سماح لكل سطح + افتراضيات الذكر.
  - تعمل فحوصات المجموعة بهذا الترتيب: `groupPolicy`/قوائم سماح المجموعة أولا، ثم تفعيل الذكر/الرد ثانيا.
  - الرد على رسالة بوت (ذكر ضمني) لا **يتجاوز** قوائم سماح المرسلين مثل `groupAllowFrom`.
  - **ملاحظة أمنية:** تعامل مع `dmPolicy="open"` و`groupPolicy="open"` كإعدادات ملاذ أخير. يجب استخدامها نادرا جدا؛ فضل الإقران + قوائم السماح ما لم تكن تثق تماما بكل عضو في الغرفة.

التفاصيل: [التكوين](/ar/gateway/configuration) و[المجموعات](/ar/channels/groups)

## حقن المطالبة (ما هو، ولماذا يهم)

حقن المطالبة هو عندما يصوغ مهاجم رسالة تتلاعب بالنموذج ليفعل شيئا غير آمن ("تجاهل تعليماتك"، "أفرغ نظام ملفاتك"، "اتبع هذا الرابط وشغل الأوامر"، إلخ).

حتى مع مطالبات نظام قوية، **لم يتم حل حقن المطالبة**. حواجز مطالبة النظام إرشاد ناعم فقط؛ يأتي الإنفاذ الصارم من سياسة الأدوات، وموافقات التنفيذ، والعزل، وقوائم سماح القنوات (ويمكن للمشغلين تعطيل هذه عمدا). ما يساعد عمليا:

- أبقِ الرسائل الخاصة الواردة مقفلة بإحكام (الاقتران/قوائم السماح).
- فضّل بوابة الإشارات في المجموعات؛ وتجنب البوتات "الدائمة التشغيل" في الغرف العامة.
- تعامل مع الروابط والمرفقات والتعليمات الملصقة على أنها عدائية افتراضياً.
- شغّل تنفيذ الأدوات الحساسة داخل sandbox؛ وأبقِ الأسرار خارج نظام الملفات الذي يمكن للوكيل الوصول إليه.
- ملاحظة: العزل في sandbox اختياري. إذا كان وضع sandbox متوقفاً، فإن `host=auto` الضمني يُحلّ إلى مضيف Gateway. أما `host=sandbox` الصريح فيظل يفشل بوضع مغلق لأنه لا يتوفر runtime لـ sandbox. اضبط `host=gateway` إذا كنت تريد أن يكون هذا السلوك صريحاً في config.
- احصر الأدوات عالية المخاطر (`exec`، `browser`، `web_fetch`، `web_search`) بالوكلاء الموثوقين أو قوائم السماح الصريحة.
- إذا أدرجت المفسّرات في قائمة السماح (`python`، `node`، `ruby`، `perl`، `php`، `lua`، `osascript`)، فمكّن `tools.exec.strictInlineEval` حتى تظل صيغ التقييم المضمّن بحاجة إلى موافقة صريحة.
- يرفض تحليل موافقة shell أيضاً صيغ توسيع معاملات POSIX (`$VAR`، `$?`، `$$`، `$1`، `$@`، `${…}`) داخل **heredocs غير المقتبسة**، بحيث لا يستطيع جسم heredoc المدرج في قائمة السماح تمرير توسيع shell خلسة عبر مراجعة قائمة السماح كنص عادي. اقتبس منهي heredoc (مثل `<<'EOF'`) لاختيار دلالات الجسم الحرفي؛ تُرفض heredocs غير المقتبسة التي كان من شأنها توسيع المتغيرات.
- **اختيار النموذج مهم:** النماذج الأقدم/الأصغر/القديمة أقل صموداً بكثير أمام حقن الموجهات وسوء استخدام الأدوات. للوكلاء الممكّنين بالأدوات، استخدم أقوى نموذج متاح من أحدث جيل، ومحصّن بالتعليمات.

إشارات الخطر التي يجب التعامل معها على أنها غير موثوقة:

- "اقرأ هذا الملف/URL وافعل بالضبط ما يقوله."
- "تجاهل موجه النظام أو قواعد السلامة لديك."
- "اكشف تعليماتك المخفية أو مخرجات الأدوات."
- "الصق المحتويات الكاملة لـ ~/.openclaw أو سجلاتك."

## تنظيف الرموز الخاصة للمحتوى الخارجي

يزيل OpenClaw صيغ الرموز الخاصة الشائعة لقوالب محادثة LLM المستضافة ذاتياً من المحتوى الخارجي والبيانات الوصفية المغلفة قبل وصولها إلى النموذج. تشمل عائلات العلامات المغطاة Qwen/ChatML وLlama وGemma وMistral وPhi ورموز الدور/الدوران في GPT-OSS.

لماذا:

- الواجهات الخلفية المتوافقة مع OpenAI التي تشغّل نماذج مستضافة ذاتياً تحتفظ أحياناً بالرموز الخاصة التي تظهر في نص المستخدم، بدلاً من إخفائها. يمكن لمهاجم قادر على الكتابة في المحتوى الخارجي الوارد (صفحة مجلوبة، جسم بريد إلكتروني، مخرجات أداة محتويات ملف) أن يحقن خلاف ذلك حد دور `assistant` أو `system` اصطناعياً ويتجاوز حواجز حماية المحتوى المغلف.
- يحدث التنظيف في طبقة تغليف المحتوى الخارجي، لذلك يُطبّق بشكل موحّد عبر أدوات الجلب/القراءة ومحتوى القنوات الوارد بدلاً من أن يكون لكل موفّر على حدة.
- تمتلك استجابات النموذج الصادرة بالفعل منظفاً منفصلاً يزيل تسريبات `<tool_call>` و`<function_calls>` و`<system-reminder>` و`<previous_response>` وما شابهها من هياكل runtime الداخلية من الردود المرئية للمستخدم عند حد التسليم النهائي للقناة. منظف المحتوى الخارجي هو النظير الوارد.

لا يحل هذا محل وسائل التقوية الأخرى في هذه الصفحة — ما زالت `dmPolicy` وقوائم السماح وموافقات exec وsandboxing و`contextVisibility` تؤدي العمل الأساسي. إنه يغلق تجاوزاً محدداً في طبقة tokenizer ضد الحزم المستضافة ذاتياً التي تمرر نص المستخدم مع بقاء الرموز الخاصة كما هي.

## أعلام تجاوز المحتوى الخارجي غير الآمن

يتضمن OpenClaw أعلام تجاوز صريحة تعطل تغليف سلامة المحتوى الخارجي:

- `hooks.mappings[].allowUnsafeExternalContent`
- `hooks.gmail.allowUnsafeExternalContent`
- حقل حمولة Cron `allowUnsafeExternalContent`

إرشادات:

- أبقِ هذه غير مضبوطة/false في الإنتاج.
- مكّنها مؤقتاً فقط لتصحيح أخطاء محدود النطاق بإحكام.
- إذا تم تمكينها، فاعزل ذلك الوكيل (sandbox + الحد الأدنى من الأدوات + مساحة أسماء جلسة مخصصة).

ملاحظة مخاطر hooks:

- حمولات Hook هي محتوى غير موثوق، حتى عندما يأتي التسليم من أنظمة تتحكم بها (يمكن لمحتوى البريد/المستندات/الويب أن يحمل حقن موجهات).
- تزيد فئات النماذج الضعيفة هذا الخطر. للأتمتة المدفوعة بـ hook، فضّل فئات نماذج حديثة وقوية وأبقِ سياسة الأدوات صارمة (`tools.profile: "messaging"` أو أشد)، مع sandboxing حيثما أمكن.

### لا يتطلب حقن الموجهات رسائل خاصة عامة

حتى إذا كنت **أنت وحدك** قادراً على مراسلة البوت، يمكن أن يحدث حقن الموجهات عبر
أي **محتوى غير موثوق** يقرؤه البوت (نتائج بحث/جلب الويب، صفحات المتصفح،
رسائل البريد الإلكتروني، المستندات، المرفقات، السجلات/الكود الملصق). بعبارة أخرى: ليس المرسل
هو سطح التهديد الوحيد؛ يمكن أن يحمل **المحتوى نفسه** تعليمات معادية.

عند تمكين الأدوات، يكون الخطر المعتاد هو تسريب السياق أو تشغيل
استدعاءات أدوات. قلّل نطاق الضرر عبر:

- استخدام **وكيل قارئ** للقراءة فقط أو معطل الأدوات لتلخيص المحتوى غير الموثوق،
  ثم تمرير الملخص إلى وكيلك الرئيسي.
- إبقاء `web_search` / `web_fetch` / `browser` متوقفة للوكلاء الممكّنين بالأدوات ما لم تكن مطلوبة.
- بالنسبة إلى مدخلات URL في OpenResponses (`input_file` / `input_image`)، اضبط
  `gateway.http.endpoints.responses.files.urlAllowlist` و
  `gateway.http.endpoints.responses.images.urlAllowlist` بإحكام، وأبقِ `maxUrlParts` منخفضاً.
  تُعامل قوائم السماح الفارغة على أنها غير مضبوطة؛ استخدم `files.allowUrl: false` / `images.allowUrl: false`
  إذا أردت تعطيل جلب URL بالكامل.
- بالنسبة إلى مدخلات الملفات في OpenResponses، يظل نص `input_file` المفكوك يُحقن كـ
  **محتوى خارجي غير موثوق**. لا تعتمد على كون نص الملف موثوقاً لمجرد أن
  Gateway فكّه محلياً. ما زالت الكتلة المحقونة تحمل علامات حدود
  `<<<EXTERNAL_UNTRUSTED_CONTENT ...>>>` الصريحة بالإضافة إلى بيانات وصفية `Source: External`،
  رغم أن هذا المسار يحذف لافتة `SECURITY NOTICE:` الأطول.
- يُطبّق التغليف نفسه المعتمد على العلامات عندما يستخرج فهم الوسائط نصاً
  من المستندات المرفقة قبل إلحاق ذلك النص بموجه الوسائط.
- تمكين sandboxing وقوائم السماح الصارمة للأدوات لأي وكيل يلامس مدخلات غير موثوقة.
- إبقاء الأسرار خارج الموجهات؛ مرّرها عبر env/config على مضيف Gateway بدلاً من ذلك.

### الواجهات الخلفية LLM المستضافة ذاتياً

يمكن أن تختلف الواجهات الخلفية المستضافة ذاتياً والمتوافقة مع OpenAI مثل vLLM وSGLang وTGI وLM Studio
أو حزم tokenizer المخصصة من Hugging Face عن الموفّرين المستضافين في كيفية
التعامل مع الرموز الخاصة لقوالب المحادثة. إذا كانت واجهة خلفية ترمّز سلاسل حرفية
مثل `<|im_start|>` أو `<|start_header_id|>` أو `<start_of_turn>` على أنها
رموز بنيوية لقالب محادثة داخل محتوى المستخدم، يمكن للنص غير الموثوق أن يحاول
تزوير حدود الأدوار عند طبقة tokenizer.

يزيل OpenClaw صيغ الرموز الخاصة الشائعة لعائلات النماذج من
المحتوى الخارجي المغلف قبل إرساله إلى النموذج. أبقِ تغليف المحتوى الخارجي
ممكناً، وفضّل إعدادات الواجهة الخلفية التي تفصل أو تهرّب الرموز الخاصة
في المحتوى المقدم من المستخدم عند توفرها. يطبّق الموفّرون المستضافون مثل OpenAI
وAnthropic بالفعل التنظيف الخاص بهم من جهة الطلب.

### قوة النموذج (ملاحظة أمنية)

مقاومة حقن الموجهات **ليست** موحّدة عبر فئات النماذج. النماذج الأصغر/الأرخص تكون عموماً أكثر عرضة لسوء استخدام الأدوات واختطاف التعليمات، خاصة تحت الموجهات المعادية.

<Warning>
بالنسبة إلى الوكلاء الممكّنين بالأدوات أو الوكلاء الذين يقرؤون محتوى غير موثوق، يكون خطر حقن الموجهات مع النماذج الأقدم/الأصغر غالباً مرتفعاً جداً. لا تشغّل هذه الأحمال على فئات نماذج ضعيفة.
</Warning>

التوصيات:

- **استخدم أحدث جيل، وأفضل فئة نموذج** لأي بوت يمكنه تشغيل أدوات أو لمس ملفات/شبكات.
- **لا تستخدم فئات أقدم/أضعف/أصغر** للوكلاء الممكّنين بالأدوات أو صناديق الوارد غير الموثوقة؛ فخطر حقن الموجهات مرتفع جداً.
- إذا كان لا بد من استخدام نموذج أصغر، **قلّل نطاق الضرر** (أدوات للقراءة فقط، sandboxing قوي، وصول أدنى إلى نظام الملفات، قوائم سماح صارمة).
- عند تشغيل نماذج صغيرة، **مكّن sandboxing لكل الجلسات** و**عطّل web_search/web_fetch/browser** ما لم تكن المدخلات مضبوطة بإحكام.
- بالنسبة إلى المساعدين الشخصيين للمحادثة فقط مع مدخلات موثوقة ودون أدوات، تكون النماذج الأصغر مناسبة عادة.

## التفكير والمخرجات المطوّلة في المجموعات

يمكن أن تكشف `/reasoning` و`/verbose` و`/trace` عن التفكير الداخلي أو مخرجات الأدوات
أو تشخيصات Plugin لم تكن مخصصة لقناة عامة. في إعدادات المجموعات، تعامل معها كخيارات **تصحيح أخطاء
فقط** وأبقِها متوقفة ما لم تكن بحاجة إليها صراحة.

إرشادات:

- أبقِ `/reasoning` و`/verbose` و`/trace` معطلة في الغرف العامة.
- إذا مكّنتها، فافعل ذلك فقط في الرسائل الخاصة الموثوقة أو الغرف المضبوطة بإحكام.
- تذكّر: يمكن أن تتضمن المخرجات المطوّلة ومخرجات trace وسيطات الأدوات وURLs وتشخيصات Plugin والبيانات التي رآها النموذج.

## أمثلة تقوية التهيئة

### أذونات الملفات

أبقِ config + state خاصة على مضيف Gateway:

- `~/.openclaw/openclaw.json`: `600` (قراءة/كتابة للمستخدم فقط)
- `~/.openclaw`: `700` (للمستخدم فقط)

يمكن لـ `openclaw doctor` التحذير وعرض تشديد هذه الأذونات.

### التعرض الشبكي (الربط، المنفذ، الجدار الناري)

يمزج Gateway **WebSocket + HTTP** على منفذ واحد:

- الافتراضي: `18789`
- Config/flags/env: `gateway.port`، `--port`، `OPENCLAW_GATEWAY_PORT`

يتضمن سطح HTTP هذا واجهة Control UI ومضيف canvas:

- Control UI (أصول SPA) (مسار الأساس الافتراضي `/`)
- مضيف Canvas: `/__openclaw__/canvas/` و`/__openclaw__/a2ui/` (HTML/JS عشوائي؛ تعامل معه كمحتوى غير موثوق)

إذا حمّلت محتوى canvas في متصفح عادي، فتعامل معه مثل أي صفحة ويب أخرى غير موثوقة:

- لا تعرض مضيف canvas لشبكات/مستخدمين غير موثوقين.
- لا تجعل محتوى canvas يشارك الأصل نفسه مع أسطح الويب ذات الامتيازات إلا إذا كنت تفهم الآثار بالكامل.

يتحكم وضع الربط في المكان الذي يستمع فيه Gateway:

- `gateway.bind: "loopback"` (الافتراضي): يمكن للعملاء المحليين فقط الاتصال.
- الربط غير loopback (`"lan"`، `"tailnet"`، `"custom"`) يوسّع سطح الهجوم. استخدمه فقط مع مصادقة gateway (رمز/كلمة مرور مشتركة أو وكيل موثوق مضبوط بشكل صحيح) وجدار ناري حقيقي.

قواعد عامة:

- فضّل Tailscale Serve على ربط LAN (يبقي Serve الـ Gateway على loopback، ويتولى Tailscale الوصول).
- إذا كان لا بد من الربط بـ LAN، فاقصر المنفذ عبر الجدار الناري على قائمة سماح ضيقة من عناوين IP المصدرية؛ ولا تستخدم إعادة توجيه المنفذ على نطاق واسع.
- لا تعرض Gateway مطلقاً دون مصادقة على `0.0.0.0`.

### نشر منافذ Docker مع UFW

إذا شغّلت OpenClaw باستخدام Docker على VPS، فتذكر أن منافذ الحاويات المنشورة
(`-p HOST:CONTAINER` أو Compose `ports:`) تُمرّر عبر سلاسل التوجيه في Docker،
وليس فقط قواعد `INPUT` على المضيف.

لإبقاء حركة مرور Docker متوافقة مع سياسة الجدار الناري لديك، افرض القواعد في
`DOCKER-USER` (تُقيّم هذه السلسلة قبل قواعد القبول الخاصة بـ Docker).
في العديد من التوزيعات الحديثة، تستخدم `iptables`/`ip6tables` واجهة `iptables-nft`
وما زالت تطبق هذه القواعد على الواجهة الخلفية nftables.

مثال حد أدنى لقائمة سماح (IPv4):

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

لـ IPv6 جداول منفصلة. أضف سياسة مطابقة في `/etc/ufw/after6.rules` إذا كان
Docker IPv6 ممكّناً.

تجنب ترميز أسماء الواجهات مثل `eth0` بشكل ثابت في مقتطفات المستندات. تختلف أسماء الواجهات
بين صور VPS (`ens3`، `enp*`، إلخ) ويمكن لعدم التطابق أن يتخطى
قاعدة الرفض لديك عن طريق الخطأ.

تحقق سريع بعد إعادة التحميل:

```bash
ufw reload
iptables -S DOCKER-USER
ip6tables -S DOCKER-USER
nmap -sT -p 1-65535 <public-ip> --open
```

يجب أن تكون المنافذ الخارجية المتوقعة فقط ما تعرضه عمداً (في معظم
الإعدادات: SSH + منافذ reverse proxy لديك).

### اكتشاف mDNS/Bonjour

يبث Gateway وجوده عبر mDNS (`_openclaw-gw._tcp` على المنفذ 5353) لاكتشاف الأجهزة المحلية. في الوضع الكامل، يتضمن هذا سجلات TXT قد تكشف تفاصيل تشغيلية:

- `cliPath`: المسار الكامل في نظام الملفات إلى ملف CLI الثنائي (يكشف اسم المستخدم وموقع التثبيت)
- `sshPort`: يعلن عن توفر SSH على المضيف
- `displayName`، `lanHost`: معلومات اسم المضيف

**اعتبار أمني تشغيلي:** بث تفاصيل البنية التحتية يجعل الاستطلاع أسهل لأي شخص على الشبكة المحلية. حتى المعلومات "غير الضارة" مثل مسارات نظام الملفات وتوفر SSH تساعد المهاجمين على رسم خريطة بيئتك.

**التوصيات:**

1. **الوضع الأدنى** (افتراضي، موصى به للـ gateways المكشوفة): احذف الحقول الحساسة من بث mDNS:

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

2. **التعطيل بالكامل** إذا لم تكن بحاجة إلى اكتشاف الأجهزة المحلية:

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

3. **الوضع الكامل** (اشتراك اختياري): أدرج `cliPath` + `sshPort` في سجلات TXT:

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

4. **متغير البيئة** (بديل): عيّن `OPENCLAW_DISABLE_BONJOUR=1` لتعطيل mDNS من دون تغييرات في الإعدادات.

في الوضع الأدنى، يظل Gateway يبث ما يكفي لاكتشاف الأجهزة (`role`، `gatewayPort`، `transport`) لكنه يحذف `cliPath` و`sshPort`. يمكن للتطبيقات التي تحتاج إلى معلومات مسار CLI جلبها عبر اتصال WebSocket المصادق عليه بدلًا من ذلك.

### أحكم إغلاق WebSocket الخاص بالـ Gateway (المصادقة المحلية)

مصادقة Gateway **مطلوبة افتراضيًا**. إذا لم يتم تكوين مسار صالح لمصادقة Gateway،
يرفض Gateway اتصالات WebSocket (يفشل بإغلاق آمن).

ينشئ الإعداد الأولي رمزًا مميزًا افتراضيًا (حتى لـ loopback)، لذلك
يجب أن تصادق العملاء المحليون.

عيّن رمزًا مميزًا لكي يكون على **كل** عملاء WS المصادقة:

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

يمكن لـ Doctor إنشاء واحد لك: `openclaw doctor --generate-gateway-token`.

<Note>
`gateway.remote.token` و`gateway.remote.password` هما مصدران لاعتمادات العميل. إنهما **لا** يحميان وصول WS المحلي بمفردهما. يمكن لمسارات الاستدعاء المحلية استخدام `gateway.remote.*` كخيار احتياطي فقط عندما لا يكون `gateway.auth.*` مضبوطًا. إذا تم تكوين `gateway.auth.token` أو `gateway.auth.password` صراحةً عبر SecretRef ولم يتم حله، يفشل الحل بإغلاق آمن (من دون أن يخفيه fallback بعيد).
</Note>
اختياري: ثبّت TLS البعيد باستخدام `gateway.remote.tlsFingerprint` عند استخدام `wss://`.
يكون النص الصريح `ws://` مقتصرًا على loopback افتراضيًا. للمسارات الموثوقة على الشبكة الخاصة،
عيّن `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` في عملية العميل كإجراء كسر زجاج.
هذا مقصود أن يكون ضمن بيئة العملية فقط، وليس مفتاح إعدادات
`openclaw.json`.
اقتران الأجهزة المحمولة ومسارات Gateway اليدوية أو الممسوحة على Android أكثر صرامة:
يُقبل cleartext لـ loopback، لكن private-LAN وlink-local و`.local` وأسماء
المضيفين بلا نقاط يجب أن تستخدم TLS ما لم تختر صراحةً مسار cleartext الموثوق
للشبكة الخاصة.

اقتران الجهاز المحلي:

- تتم الموافقة تلقائيًا على اقتران الجهاز لاتصالات local loopback المباشرة للحفاظ على سلاسة العملاء على المضيف نفسه.
- لدى OpenClaw أيضًا مسار self-connect ضيق محلي للواجهة الخلفية/الحاوية لتدفقات المساعد ذات السر المشترك الموثوقة.
- تُعامل اتصالات tailnet وLAN، بما في ذلك روابط tailnet على المضيف نفسه، كبعيدة لأغراض الاقتران ولا تزال تحتاج إلى موافقة.
- أدلة forwarded-header في طلب loopback تستبعد محلية loopback. الموافقة التلقائية لترقية البيانات الوصفية محدودة النطاق. راجع
  [اقتران Gateway](/ar/gateway/pairing) لكلا القاعدتين.

أوضاع المصادقة:

- `gateway.auth.mode: "token"`: رمز bearer مشترك (موصى به لمعظم الإعدادات).
- `gateway.auth.mode: "password"`: مصادقة بكلمة مرور (يفضل تعيينها عبر البيئة: `OPENCLAW_GATEWAY_PASSWORD`).
- `gateway.auth.mode: "trusted-proxy"`: الوثوق ببروكسي عكسي مدرك للهوية لمصادقة المستخدمين وتمرير الهوية عبر الترويسات (راجع [مصادقة البروكسي الموثوق](/ar/gateway/trusted-proxy-auth)).

قائمة تدوير الاعتمادات (الرمز/كلمة المرور):

1. أنشئ/عيّن سرًا جديدًا (`gateway.auth.token` أو `OPENCLAW_GATEWAY_PASSWORD`).
2. أعد تشغيل Gateway (أو أعد تشغيل تطبيق macOS إذا كان يشرف على Gateway).
3. حدّث أي عملاء بعيدين (`gateway.remote.token` / `.password` على الأجهزة التي تستدعي Gateway).
4. تحقق من أنك لم تعد قادرًا على الاتصال بالاعتمادات القديمة.

### ترويسات هوية Tailscale Serve

عندما تكون `gateway.auth.allowTailscale` هي `true` (الافتراضي لـ Serve)، يقبل OpenClaw
ترويسات هوية Tailscale Serve (`tailscale-user-login`) لمصادقة واجهة التحكم/WebSocket. يتحقق OpenClaw من الهوية عبر حل عنوان
`x-forwarded-for` من خلال عفريت Tailscale المحلي (`tailscale whois`)
ومطابقته مع الترويسة. لا يُفعّل هذا إلا للطلبات التي تصل إلى loopback
وتتضمن `x-forwarded-for` و`x-forwarded-proto` و`x-forwarded-host` كما
تحقنها Tailscale.
بالنسبة إلى مسار فحص الهوية غير المتزامن هذا، تُسلسل المحاولات الفاشلة لنفس `{scope, ip}`
قبل أن يسجل محدد المعدل الفشل. لذلك يمكن لمحاولات إعادة المحاولة السيئة المتزامنة
من عميل Serve واحد أن تقفل المحاولة الثانية فورًا
بدلًا من أن تتسابق كعدم تطابق عاديين.
نقاط نهاية HTTP API (مثل `/v1/*` و`/tools/invoke` و`/api/channels/*`)
**لا** تستخدم مصادقة ترويسة هوية Tailscale. إنها لا تزال تتبع وضع مصادقة HTTP
المكوّن للـ gateway.

ملاحظة حد مهمة:

- مصادقة bearer لـ HTTP في Gateway هي عمليًا وصول مشغل كامل أو لا شيء.
- عامل الاعتمادات التي يمكنها استدعاء `/v1/chat/completions` أو `/v1/responses` أو `/api/channels/*` كأسرار مشغل كاملة الوصول لذلك الـ gateway.
- على سطح HTTP المتوافق مع OpenAI، تعيد مصادقة bearer بالسر المشترك نطاقات المشغل الافتراضية الكاملة (`operator.admin`، `operator.approvals`، `operator.pairing`، `operator.read`، `operator.talk.secrets`، `operator.write`) ودلالات المالك لدورات الوكيل؛ لا تقلل قيم `x-openclaw-scopes` الأضيق ذلك المسار ذي السر المشترك.
- لا تنطبق دلالات النطاق لكل طلب على HTTP إلا عندما يأتي الطلب من وضع حامل للهوية مثل مصادقة البروكسي الموثوق أو `gateway.auth.mode="none"` على مدخل خاص.
- في هذه الأوضاع الحاملة للهوية، يؤدي حذف `x-openclaw-scopes` إلى الرجوع إلى مجموعة النطاقات الافتراضية العادية للمشغل؛ أرسل الترويسة صراحةً عندما تريد مجموعة نطاقات أضيق.
- يتبع `/tools/invoke` قاعدة السر المشترك نفسها: تُعامل مصادقة bearer بالرمز/كلمة المرور كوصول مشغل كامل هناك أيضًا، بينما لا تزال الأوضاع الحاملة للهوية تحترم النطاقات المعلنة.
- لا تشارك هذه الاعتمادات مع مستدعين غير موثوقين؛ فضّل gateways منفصلة لكل حد ثقة.

**افتراض الثقة:** تفترض مصادقة Serve بلا رمز أن مضيف gateway موثوق.
لا تعامل هذا كحماية من عمليات معادية على المضيف نفسه. إذا كان يمكن تشغيل
كود محلي غير موثوق على مضيف gateway، فعطّل `gateway.auth.allowTailscale`
واطلب مصادقة صريحة بسر مشترك باستخدام `gateway.auth.mode: "token"` أو
`"password"`.

**قاعدة أمنية:** لا تمرر هذه الترويسات من البروكسي العكسي الخاص بك. إذا كنت
تنهي TLS أو تستخدم بروكسي أمام gateway، فعطّل
`gateway.auth.allowTailscale` واستخدم مصادقة السر المشترك (`gateway.auth.mode:
"token"` أو `"password"`) أو [مصادقة البروكسي الموثوق](/ar/gateway/trusted-proxy-auth)
بدلًا من ذلك.

البروكسيات الموثوقة:

- إذا كنت تنهي TLS أمام Gateway، فعيّن `gateway.trustedProxies` إلى عناوين IP الخاصة بالبروكسي.
- سيثق OpenClaw بـ `x-forwarded-for` (أو `x-real-ip`) من تلك العناوين لتحديد عنوان IP للعميل لفحوصات الاقتران المحلي ومصادقة HTTP/الفحوصات المحلية.
- تأكد من أن البروكسي **يستبدل** `x-forwarded-for` ويحظر الوصول المباشر إلى منفذ Gateway.

راجع [Tailscale](/ar/gateway/tailscale) و[نظرة عامة على الويب](/ar/web).

### التحكم في المتصفح عبر مضيف Node (موصى به)

إذا كان Gateway بعيدًا لكن المتصفح يعمل على جهاز آخر، فشغّل **مضيف Node**
على جهاز المتصفح ودع Gateway يمرر إجراءات المتصفح عبر بروكسي (راجع [أداة المتصفح](/ar/tools/browser)).
عامل اقتران Node مثل وصول المدير.

النمط الموصى به:

- أبقِ Gateway ومضيف Node على tailnet نفسه (Tailscale).
- قم بإقران Node عن قصد؛ عطّل توجيه بروكسي المتصفح إذا لم تكن بحاجة إليه.

تجنب:

- كشف منافذ الترحيل/التحكم عبر LAN أو الإنترنت العام.
- Tailscale Funnel لنقاط نهاية التحكم في المتصفح (تعريض عام).

### الأسرار على القرص

افترض أن أي شيء تحت `~/.openclaw/` (أو `$OPENCLAW_STATE_DIR/`) قد يحتوي على أسرار أو بيانات خاصة:

- `openclaw.json`: قد تتضمن الإعدادات رموزًا مميزة (gateway، gateway بعيد)، وإعدادات موفرين، وقوائم سماح.
- `credentials/**`: اعتمادات القنوات (مثال: اعتمادات WhatsApp)، وقوائم سماح الاقتران، واستيرادات OAuth القديمة.
- `agents/<agentId>/agent/auth-profiles.json`: مفاتيح API، وملفات تعريف الرموز، ورموز OAuth، و`keyRef`/`tokenRef` اختياري.
- `agents/<agentId>/agent/codex-home/**`: حساب خادم تطبيق Codex لكل وكيل، والإعدادات، وSkills، وplugins، وحالة thread الأصلية، والتشخيصات.
- `secrets.json` (اختياري): حمولة سرية مدعومة بملف تستخدمها موفرات SecretRef من نوع `file` (`secrets.providers`).
- `agents/<agentId>/agent/auth.json`: ملف توافق قديم. تُنظف إدخالات `api_key` الثابتة عند اكتشافها.
- `agents/<agentId>/sessions/**`: سجلات الجلسات (`*.jsonl`) + بيانات تعريف التوجيه (`sessions.json`) التي يمكن أن تحتوي على رسائل خاصة ومخرجات أدوات.
- حزم Plugin المضمنة: plugins المثبتة (بالإضافة إلى `node_modules/` الخاصة بها).
- `sandboxes/**`: مساحات عمل sandbox للأدوات؛ يمكن أن تتراكم فيها نسخ من الملفات التي تقرأها/تكتبها داخل sandbox.

نصائح التقوية:

- أبقِ الأذونات ضيقة (`700` على المجلدات، و`600` على الملفات).
- استخدم تشفير القرص بالكامل على مضيف gateway.
- فضّل حساب مستخدم OS مخصصًا للـ Gateway إذا كان المضيف مشتركًا.

### ملفات `.env` في مساحة العمل

يحمّل OpenClaw ملفات `.env` المحلية لمساحة العمل للوكلاء والأدوات، لكنه لا يسمح لتلك الملفات أبدًا بتجاوز عناصر التحكم في تشغيل gateway بصمت.

- أي مفتاح يبدأ بـ `OPENCLAW_*` يُحظر من ملفات `.env` غير الموثوقة في مساحة العمل.
- إعدادات نقاط نهاية القنوات لـ Matrix وMattermost وIRC وSynology Chat محظورة أيضًا من تجاوزات `.env` في مساحة العمل، لذلك لا يمكن لمساحات العمل المستنسخة إعادة توجيه حركة موصلات bundled عبر إعداد نقاط نهاية محلي. يجب أن تأتي مفاتيح بيئة نقاط النهاية (مثل `MATRIX_HOMESERVER` و`MATTERMOST_URL` و`IRC_HOST` و`SYNOLOGY_CHAT_INCOMING_URL`) من بيئة عملية gateway أو `env.shellEnv`، وليس من ملف `.env` محمّل من مساحة العمل.
- الحظر يفشل بإغلاق آمن: لا يمكن لمتغير تحكم تشغيلي جديد يُضاف في إصدار مستقبلي أن يُورث من ملف `.env` مُدخل في المستودع أو مقدم من مهاجم؛ يتم تجاهل المفتاح ويحتفظ gateway بقيمته الخاصة.
- لا تزال متغيرات بيئة العملية/OS الموثوقة (shell الخاص بالـ gateway، وحدة launchd/systemd، حزمة التطبيق) تنطبق — هذا يقيد فقط تحميل ملفات `.env`.

السبب: غالبًا ما توجد ملفات `.env` في مساحة العمل بجانب كود الوكيل، أو تُرتكب بالخطأ، أو تكتبها الأدوات. يعني حظر بادئة `OPENCLAW_*` بالكامل أن إضافة علم `OPENCLAW_*` جديد لاحقًا لا يمكن أن تتراجع أبدًا إلى وراثة صامتة من حالة مساحة العمل.

### السجلات والنصوص النصية للجلسات (التنقيح والاحتفاظ)

يمكن للسجلات والنصوص النصية للجلسات تسريب معلومات حساسة حتى عندما تكون عناصر التحكم في الوصول صحيحة:

- قد تتضمن سجلات Gateway ملخصات أدوات وأخطاء وعناوين URL.
- يمكن أن تتضمن النصوص النصية للجلسات أسرارًا ملصقة، ومحتويات ملفات، ومخرجات أوامر، وروابط.

التوصيات:

- أبقِ تنقيح السجلات والنصوص النصية للجلسات مفعّلًا (`logging.redactSensitive: "tools"`؛ افتراضي).
- أضف أنماطًا مخصصة لبيئتك عبر `logging.redactPatterns` (رموز، أسماء مضيفين، عناوين URL داخلية).
- عند مشاركة التشخيصات، فضّل `openclaw status --all` (قابل للصق، والأسرار منقحة) على السجلات الخام.
- قلّم النصوص النصية القديمة للجلسات وملفات السجلات إذا لم تكن بحاجة إلى احتفاظ طويل.

التفاصيل: [التسجيل](/ar/gateway/logging)

### الرسائل المباشرة: الاقتران افتراضيًا

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

### المجموعات: اطلب الإشارة في كل مكان

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

في محادثات المجموعات، لا ترد إلا عند الإشارة إليك صراحةً.

### أرقام منفصلة (WhatsApp، Signal، Telegram)

بالنسبة إلى القنوات المعتمدة على رقم الهاتف، فكّر في تشغيل الذكاء الاصطناعي على رقم هاتف منفصل عن رقمك الشخصي:

- الرقم الشخصي: تبقى محادثاتك خاصة
- رقم البوت: يتولى الذكاء الاصطناعي هذه المحادثات، مع الحدود المناسبة

### وضع القراءة فقط (عبر sandbox والأدوات)

يمكنك إنشاء ملف تعريف للقراءة فقط من خلال الجمع بين:

- `agents.defaults.sandbox.workspaceAccess: "ro"` (أو `"none"` لعدم إتاحة الوصول إلى مساحة العمل)
- قوائم السماح/المنع للأدوات التي تحظر `write` و`edit` و`apply_patch` و`exec` و`process` وما إلى ذلك.

خيارات تقوية إضافية:

- `tools.exec.applyPatch.workspaceOnly: true` (الافتراضي): يضمن أن `apply_patch` لا يمكنه الكتابة/الحذف خارج دليل مساحة العمل حتى عندما يكون sandboxing متوقفًا. اضبطه على `false` فقط إذا كنت تريد عمدًا أن يلمس `apply_patch` ملفات خارج مساحة العمل.
- `tools.fs.workspaceOnly: true` (اختياري): يقيّد مسارات `read`/`write`/`edit`/`apply_patch` ومسارات التحميل التلقائي لصور الموجه الأصلية إلى دليل مساحة العمل (مفيد إذا كنت تسمح بالمسارات المطلقة حاليًا وتريد حاجز حماية واحدًا).
- أبقِ جذور نظام الملفات ضيقة: تجنّب الجذور الواسعة مثل دليل المنزل لمساحات عمل الوكيل/مساحات عمل sandbox. يمكن للجذور الواسعة أن تكشف ملفات محلية حساسة (مثل الحالة/الإعدادات ضمن `~/.openclaw`) لأدوات نظام الملفات.

### خط أساس آمن (نسخ/لصق)

إعداد واحد «افتراضي آمن» يبقي Gateway خاصًا، ويتطلب إقران الرسائل المباشرة، ويتجنب بوتات المجموعات الدائمة التشغيل:

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

إذا كنت تريد تنفيذ أدوات «أكثر أمانًا افتراضيًا» أيضًا، فأضف sandbox + امنع الأدوات الخطرة لأي وكيل غير مالك (مثال أدناه ضمن «ملفات تعريف الوصول لكل وكيل»).

خط الأساس المدمج لدورات الوكيل المدفوعة بالمحادثة: لا يمكن للمرسلين غير المالكين استخدام أدوات `cron` أو `gateway`.

## Sandboxing (موصى به)

مستند مخصص: [Sandboxing](/ar/gateway/sandboxing)

نهجان متكاملان:

- **تشغيل Gateway كاملًا داخل Docker** (حدود الحاوية): [Docker](/ar/install/docker)
- **Tool sandbox** (`agents.defaults.sandbox`، بوابة مضيف + أدوات معزولة بـ sandbox؛ Docker هو الخلفية الافتراضية): [Sandboxing](/ar/gateway/sandboxing)

<Note>
لمنع الوصول بين الوكلاء، أبقِ `agents.defaults.sandbox.scope` على `"agent"` (الافتراضي) أو `"session"` لعزل أشد لكل جلسة. يستخدم `scope: "shared"` حاوية واحدة أو مساحة عمل واحدة.
</Note>

ضع في اعتبارك أيضًا وصول الوكيل إلى مساحة العمل داخل sandbox:

- `agents.defaults.sandbox.workspaceAccess: "none"` (الافتراضي) يبقي مساحة عمل الوكيل خارج الحدود؛ تعمل الأدوات ضد مساحة عمل sandbox ضمن `~/.openclaw/sandboxes`
- `agents.defaults.sandbox.workspaceAccess: "ro"` يركّب مساحة عمل الوكيل للقراءة فقط عند `/agent` (يعطّل `write`/`edit`/`apply_patch`)
- `agents.defaults.sandbox.workspaceAccess: "rw"` يركّب مساحة عمل الوكيل للقراءة/الكتابة عند `/workspace`
- يتم التحقق من `sandbox.docker.binds` الإضافية مقابل مسارات مصدر مُطبّعة ومحوّلة إلى مسارات قانونية. ما تزال حيل symlink للأصل والأسماء المستعارة القانونية للمنزل تفشل بإغلاق آمن إذا كانت تُحل إلى جذور محظورة مثل `/etc` أو `/var/run` أو أدلة بيانات الاعتماد ضمن منزل نظام التشغيل.

<Warning>
`tools.elevated` هو منفذ الهروب العام من خط الأساس الذي يشغّل exec خارج sandbox. المضيف الفعّال هو `gateway` افتراضيًا، أو `node` عندما يكون هدف exec مهيأً إلى `node`. أبقِ `tools.elevated.allowFrom` محكمًا ولا تفعّله للغرباء. يمكنك تقييد الوضع المرتفع أكثر لكل وكيل عبر `agents.list[].tools.elevated`. راجع [الوضع المرتفع](/ar/tools/elevated).
</Warning>

### حاجز حماية تفويض الوكلاء الفرعيين

إذا سمحت بأدوات الجلسات، فتعامل مع تشغيلات الوكلاء الفرعيين المفوضة كقرار حدود آخر:

- امنع `sessions_spawn` ما لم يكن الوكيل يحتاج التفويض فعلًا.
- أبقِ `agents.defaults.subagents.allowAgents` وأي تجاوزات لكل وكيل في `agents.list[].subagents.allowAgents` مقتصرة على الوكلاء الهدف المعروفين بأنهم آمنون.
- لأي سير عمل يجب أن يبقى داخل sandbox، استدعِ `sessions_spawn` مع `sandbox: "require"` (الافتراضي هو `inherit`).
- `sandbox: "require"` يفشل سريعًا عندما لا يكون وقت تشغيل الطفل الهدف داخل sandbox.

## مخاطر التحكم في المتصفح

تمكين التحكم في المتصفح يمنح النموذج القدرة على قيادة متصفح حقيقي.
إذا كان ملف تعريف ذلك المتصفح يحتوي بالفعل على جلسات مسجّل دخولها، يمكن للنموذج
الوصول إلى تلك الحسابات والبيانات. تعامل مع ملفات تعريف المتصفح كـ **حالة حساسة**:

- فضّل ملف تعريف مخصصًا للوكيل (ملف التعريف الافتراضي `openclaw`).
- تجنّب توجيه الوكيل إلى ملف تعريفك الشخصي المستخدم يوميًا.
- أبقِ التحكم في متصفح المضيف معطلًا للوكلاء داخل sandbox ما لم تكن تثق بهم.
- واجهة API المستقلة للتحكم في متصفح loopback لا تحترم إلا مصادقة السر المشترك
  (مصادقة حامل رمز Gateway أو كلمة مرور Gateway). لا تستهلك
  ترويسات هوية trusted-proxy أو Tailscale Serve.
- تعامل مع تنزيلات المتصفح كمدخلات غير موثوقة؛ فضّل دليل تنزيلات معزولًا.
- عطّل مزامنة المتصفح/مديري كلمات المرور في ملف تعريف الوكيل إن أمكن (يقلل نطاق الضرر).
- بالنسبة إلى البوابات البعيدة، افترض أن «التحكم في المتصفح» يعادل «وصول المشغّل» إلى أي شيء يمكن لذلك الملف التعريفي الوصول إليه.
- أبقِ مضيفَي Gateway وnode مقتصرين على tailnet؛ تجنّب كشف منافذ التحكم في المتصفح إلى LAN أو الإنترنت العام.
- عطّل توجيه وكيل المتصفح عندما لا تحتاج إليه (`gateway.nodes.browser.mode="off"`).
- وضع Chrome MCP للجلسة الحالية **ليس** «أكثر أمانًا»؛ يمكنه التصرف بصفتك في أي شيء يمكن لملف تعريف Chrome على ذلك المضيف الوصول إليه.

### سياسة Browser SSRF (صارمة افتراضيًا)

سياسة تنقل متصفح OpenClaw صارمة افتراضيًا: تبقى الوجهات الخاصة/الداخلية محظورة ما لم تشترك صراحةً.

- الافتراضي: `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` غير مضبوط، لذا يبقي تنقل المتصفح الوجهات الخاصة/الداخلية/ذات الاستخدام الخاص محظورة.
- الاسم المستعار القديم: ما يزال `browser.ssrfPolicy.allowPrivateNetwork` مقبولًا للتوافق.
- وضع الاشتراك: اضبط `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true` للسماح بالوجهات الخاصة/الداخلية/ذات الاستخدام الخاص.
- في الوضع الصارم، استخدم `hostnameAllowlist` (أنماط مثل `*.example.com`) و`allowedHostnames` (استثناءات مضيف دقيقة، بما في ذلك أسماء محظورة مثل `localhost`) للاستثناءات الصريحة.
- يتم التحقق من التنقل قبل الطلب وتُعاد محاولة التحقق بأفضل جهد على عنوان URL النهائي `http(s)` بعد التنقل لتقليل التحويلات القائمة على إعادة التوجيه.

مثال على سياسة صارمة:

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

## ملفات تعريف الوصول لكل وكيل (متعدد الوكلاء)

مع التوجيه متعدد الوكلاء، يمكن لكل وكيل امتلاك سياسة sandbox + أدوات خاصة به:
استخدم هذا لمنح **وصول كامل** أو **قراءة فقط** أو **عدم وصول** لكل وكيل.
راجع [Sandbox والأدوات متعددة الوكلاء](/ar/tools/multi-agent-sandbox-tools) للحصول على التفاصيل الكاملة
وقواعد الأسبقية.

حالات استخدام شائعة:

- الوكيل الشخصي: وصول كامل، بلا sandbox
- وكيل العائلة/العمل: داخل sandbox + أدوات قراءة فقط
- الوكيل العام: داخل sandbox + بلا أدوات نظام ملفات/صدفة

### مثال: وصول كامل (بلا sandbox)

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

### مثال: أدوات قراءة فقط + مساحة عمل قراءة فقط

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

### مثال: عدم الوصول إلى نظام الملفات/الصدفة (مراسلة المزوّد مسموحة)

```json5
{
  agents: {
    list: [
      {
        id: "public",
        workspace: "~/.openclaw/workspace-public",
        sandbox: {
          mode: "all",
          scope: "agent",
          workspaceAccess: "none",
        },
        // يمكن لأدوات الجلسات كشف بيانات حساسة من النصوص المسجلة. افتراضيًا يحد OpenClaw هذه الأدوات
        // إلى الجلسة الحالية + جلسات الوكلاء الفرعيين المنشأة، لكن يمكنك تشديد ذلك أكثر عند الحاجة.
        // راجع `tools.sessions.visibility` في مرجع الإعدادات.
        tools: {
          sessions: { visibility: "tree" }, // self | tree | agent | all
          allow: [
            "sessions_list",
            "sessions_history",
            "sessions_send",
            "sessions_spawn",
            "session_status",
            "whatsapp",
            "telegram",
            "slack",
            "discord",
          ],
          deny: [
            "read",
            "write",
            "edit",
            "apply_patch",
            "exec",
            "process",
            "browser",
            "canvas",
            "nodes",
            "cron",
            "gateway",
            "image",
          ],
        },
      },
    ],
  },
}
```

## الاستجابة للحوادث

إذا فعل الذكاء الاصطناعي شيئًا سيئًا:

### احتواء

1. **أوقفه:** أوقف تطبيق macOS (إذا كان يشرف على Gateway) أو أنهِ عملية `openclaw gateway` لديك.
2. **أغلق التعرض:** اضبط `gateway.bind: "loopback"` (أو عطّل Tailscale Funnel/Serve) حتى تفهم ما حدث.
3. **جمّد الوصول:** بدّل الرسائل المباشرة/المجموعات الخطرة إلى `dmPolicy: "disabled"` / اطلب الإشارات، وأزل إدخالات السماح للجميع `"*"` إذا كانت لديك.

### تدوير (افترض الاختراق إذا تسرّبت الأسرار)

1. دوّر مصادقة Gateway (`gateway.auth.token` / `OPENCLAW_GATEWAY_PASSWORD`) وأعد التشغيل.
2. دوّر أسرار العملاء البعيدين (`gateway.remote.token` / `.password`) على أي جهاز يمكنه استدعاء Gateway.
3. دوّر بيانات اعتماد المزوّد/API (بيانات اعتماد WhatsApp، ورموز Slack/Discord، ومفاتيح النموذج/API في `auth-profiles.json`، وقيم حمولات الأسرار المشفرة عند استخدامها).

### تدقيق

1. تحقق من سجلات Gateway: `/tmp/openclaw/openclaw-YYYY-MM-DD.log` (أو `logging.file`).
2. راجع النصوص المسجلة ذات الصلة: `~/.openclaw/agents/<agentId>/sessions/*.jsonl`.
3. راجع تغييرات الإعدادات الأخيرة (أي شيء كان يمكن أن يوسّع الوصول: `gateway.bind`، `gateway.auth`، سياسات الرسائل المباشرة/المجموعات، `tools.elevated`، تغييرات Plugin).
4. أعد تشغيل `openclaw security audit --deep` وتأكد من حل النتائج الحرجة.

### اجمع لتقرير

- الطابع الزمني، نظام تشغيل مضيف Gateway + إصدار OpenClaw
- نصوص الجلسة المسجلة + ذيل سجل قصير (بعد التنقيح)
- ما أرسله المهاجم + ما فعله الوكيل
- ما إذا كان Gateway مكشوفًا خارج loopback (LAN/Tailscale Funnel/Serve)

## فحص الأسرار

تشغّل CI خطاف pre-commit `detect-private-key` على المستودع. إذا
فشل، فأزل مادة المفتاح الملتزم بها أو دوّرها، ثم أعد الإنتاج محليًا:

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

## الإبلاغ عن مشكلات الأمان

هل وجدت ثغرة في OpenClaw؟ يُرجى الإبلاغ بمسؤولية:

1. البريد الإلكتروني: [security@openclaw.ai](mailto:security@openclaw.ai)
2. لا تنشر علنًا حتى يتم الإصلاح
3. سننسب الفضل إليك (ما لم تفضّل عدم الكشف عن هويتك)
