---
read_when:
    - إضافة ميزات توسّع الوصول أو الأتمتة
summary: اعتبارات الأمان ونموذج التهديد لتشغيل Gateway للذكاء الاصطناعي مع وصول إلى shell
title: الأمان
x-i18n:
    generated_at: "2026-07-04T10:42:41Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 42a398a347f04414c443277c8ab3632953bce73e957c8439883846813f882dd5
    source_path: gateway/security/index.md
    workflow: 16
---

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

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

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

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

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

قبل تغيير الوصول البعيد أو سياسة الرسائل المباشرة أو الوكيل العكسي أو التعريض العام،
استخدم [دليل تشغيل تعريض Gateway](/ar/gateway/security/exposure-runbook) كقائمة
تحقق قبلية وللتراجع.

## فحص سريع: `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 ملف `pnpm-lock.yaml`. وتتضمن حزمة `openclaw` المنشورة على npm
وحزم npm Plugin المملوكة لـ OpenClaw ملف `npm-shrinkwrap.json`،
وهو ملف قفل التبعيات القابل للنشر في npm، بحيث تستخدم عمليات تثبيت الحزمة
رسم التبعيات المتعدية الذي تمت مراجعته من الإصدار بدلًا من حل رسم جديد
وقت التثبيت.

قفل shrinkwrap هو حد لتقوية سلسلة الإمداد وقابلية إعادة إنتاج الإصدار،
وليس صندوق عزل. للنموذج المبسط، وأوامر المشرفين، وفحوصات
معاينة الحزمة، راجع [قفل تبعيات npm](/ar/gateway/security/shrinkwrap).

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

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

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

### عمليات الملفات الآمنة

يستخدم OpenClaw `@openclaw/fs-safe` للوصول إلى الملفات المقيّد بالجذر، والكتابة الذرية، واستخراج الأرشيفات، ومساحات العمل المؤقتة، ومساعدات ملفات الأسرار. يعطّل OpenClaw افتراضيًا مساعد Python الاختياري الخاص بـ POSIX في fs-safe؛ اضبط `OPENCLAW_FS_SAFE_PYTHON_MODE=auto` أو `require` فقط عندما تريد تقوية إضافية للطفرات النسبية إلى واصف الملف ويمكنك دعم بيئة تشغيل Python.

التفاصيل: [عمليات الملفات الآمنة](/ar/gateway/security/secure-file-operations).

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

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

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

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

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

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

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

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

## مفهوم الثقة في Gateway وNode

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

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

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

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

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

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

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

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

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

- سلاسل حقن المحفزات فقط من دون تجاوز سياسة أو مصادقة أو صندوق عزل.
- ادعاءات تفترض تشغيلًا عدائيًا متعدد المستأجرين على مضيف أو
  إعداد مشترك واحد.
- ادعاءات تصنّف وصول مسارات قراءة المشغّل العادي (مثل
  `sessions.list` / `sessions.preview` / `chat.history`) كـ IDOR في
  إعداد Gateway مشترك.
- نتائج النشر المحلي فقط (مثل HSTS على Gateway يقتصر على local loopback).
- نتائج توقيع Discord inbound webhook لمسارات inbound غير
  موجودة في هذا المستودع.
- تقارير تتعامل مع بيانات اقتران Node الوصفية كطبقة موافقة مخفية ثانية لكل أمر
  لـ `system.run`، بينما يظل حد التنفيذ الحقيقي هو
  سياسة أوامر Node العامة في gateway إضافة إلى موافقات exec الخاصة بـ Node نفسه.
- تقارير تتعامل مع `gateway.nodes.pairing.autoApproveCidrs` المضبوطة كثغرة
  بحد ذاتها. هذا الإعداد معطل افتراضيًا، ويتطلب
  إدخالات CIDR/IP صريحة، ولا ينطبق إلا على اقتران `role: node` لأول مرة
  بلا نطاقات مطلوبة، ولا يوافق تلقائيًا على المشغّل/المتصفح/Control UI،
  أو WebChat، أو ترقيات الأدوار، أو ترقيات النطاق، أو تغييرات البيانات الوصفية، أو تغييرات المفتاح العام،
  أو مسارات ترويسة الوكيل الموثوق عبر local loopback على المضيف نفسه ما لم تكن مصادقة الوكيل الموثوق عبر local 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`، وليست بحد ذاتها تجاوزات لحدود المصادقة أو صندوق العزل.
- لكي تكون التقارير ذات أثر أمني، لا تزال تحتاج إلى إثبات تجاوز لحدود الثقة (المصادقة، أو السياسة، أو صندوق العزل، أو الموافقة، أو حد موثق آخر).

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

- **الوصول الوارد** (سياسات الرسائل المباشرة، وسياسات المجموعات، وقوائم السماح): هل يمكن للغرباء تشغيل البوت؟
- **نطاق تأثير الأدوات** (أدوات مرتفعة الصلاحية + غرف مفتوحة): هل يمكن أن يتحول حقن المطالبات إلى إجراءات shell/ملفات/شبكة؟
- **انحراف نظام ملفات exec**: هل تُرفض أدوات نظام الملفات المُعدِّلة بينما يبقى `exec`/`process` متاحين دون قيود نظام ملفات صندوق العزل؟
- **انحراف موافقة exec** (`security=full`، و`autoAllowSkills`، وقوائم السماح للمفسر بدون `strictInlineEval`): هل لا تزال حواجز تنفيذ المضيف تفعل ما تظن أنها تفعله؟
  - `security="full"` تحذير وضعية واسع، وليس دليلا على علة. إنه الافتراضي المختار لإعدادات المساعد الشخصي الموثوق؛ شدده فقط عندما يحتاج نموذج التهديد لديك إلى حواجز موافقة أو قائمة سماح.
- **انكشاف الشبكة** (ربط/مصادقة Gateway، وTailscale Serve/Funnel، ورموز مصادقة ضعيفة/قصيرة).
- **انكشاف التحكم في المتصفح** (العقد البعيدة، ومنافذ الترحيل، ونقاط نهاية CDP البعيدة).
- **نظافة القرص المحلي** (الصلاحيات، والروابط الرمزية، وتضمينات الإعدادات، ومسارات "المجلد المتزامن").
- **Plugins** (تحميل Plugins دون قائمة سماح صريحة).
- **انحراف السياسة/سوء الإعداد** (إعدادات docker لصندوق العزل مهيأة لكن وضع صندوق العزل متوقف؛ أنماط `gateway.nodes.denyCommands` غير فعالة لأن المطابقة تكون باسم الأمر الدقيق فقط (مثلا `system.run`) ولا تفحص نص shell؛ إدخالات `gateway.nodes.allowCommands` خطرة؛ تجاوز `tools.profile="minimal"` العام بواسطة ملفات تعريف لكل وكيل؛ أدوات مملوكة لـ Plugin قابلة للوصول ضمن سياسة أدوات متساهلة).
- **انحراف توقعات وقت التشغيل** (مثلا افتراض أن exec الضمني لا يزال يعني `sandbox` عندما أصبح `tools.exec.host` افتراضيا `auto`، أو تعيين `tools.exec.host="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/`
- **حالة وقت تشغيل Codex المشتركة (اختياري)**: `$CODEX_HOME` أو `~/.codex` عندما يكون
  `plugins.entries.codex.config.appServer.homeScope` هو `"user"`. يستخدم هذا الوضع
  حساب Codex الأصلي وإعداداته وPlugins ومخزن السلاسل؛ فعّله فقط من أجل
  Gateway محلي يتحكم فيه المالك. راجع [حاضنة Codex](/ar/plugins/codex-harness#share-threads-with-codex-desktop-and-cli).
- **حمولة أسرار مدعومة بملف (اختياري)**: `~/.openclaw/secrets.json`
- **استيراد OAuth القديم**: `~/.openclaw/credentials/oauth.json`

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

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

1. **أي شيء "مفتوح" + الأدوات مفعلة**: أغلق الرسائل المباشرة/المجموعات أولا (الاقتران/قوائم السماح)، ثم شدد سياسة الأدوات/العزل.
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/Skills ونتائج الفحص.
- `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` عندما
تكون مفاتيح تصحيح غير آمنة/خطرة معروفة مفعلة. أبقِ هذه غير مضبوطة في
الإنتاج. يُبلغ عن كل علم مفعل كنتيجة مستقلة. إذا كانت كتمات التدقيق
مهيأة، تبقى `security.audit.suppressions.active` في
مخرجات التدقيق النشطة حتى عندما تنتقل النتائج المطابقة إلى `suppressedFindings`.

<AccordionGroup>
  <Accordion title="الأعلام التي يتتبعها التدقيق اليوم">
    - `gateway.controlUi.allowInsecureAuth=true`
    - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true`
    - `gateway.controlUi.dangerouslyDisableDeviceAuth=true`
    - `security.audit.suppressions configured (<count>)`
    - `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 Gateway الأولوية إلى local/loopback. إذا أنهيت TLS عند وكيل عكسي، فاضبط HSTS هناك على نطاق HTTPS المواجه للوكيل.
- إذا كان Gateway نفسه ينهي HTTPS، يمكنك ضبط `gateway.http.securityHeaders.strictTransportSecurity` لإرسال ترويسة HSTS من استجابات OpenClaw.
- توجد إرشادات النشر المفصلة في [مصادقة الوكيل الموثوق](/ar/gateway/trusted-proxy-auth#tls-termination-and-hsts).
- بالنسبة إلى عمليات نشر Control UI خارج loopback، يكون `gateway.controlUi.allowedOrigins` مطلوبًا افتراضيًا.
- `gateway.controlUi.allowedOrigins: ["*"]` سياسة صريحة للسماح بكل أصول المتصفح، وليست إعدادًا افتراضيًا محصنًا. تجنبها خارج الاختبارات المحلية شديدة التحكم.
- تظل إخفاقات مصادقة أصل المتصفح على loopback محدودة المعدل حتى عند تمكين
  الإعفاء العام لـ loopback، لكن مفتاح القفل يكون مضبوط النطاق لكل
  قيمة `Origin` مطبعة بدلًا من دلو localhost مشترك واحد.
- يفعّل `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` وضع الرجوع إلى أصل ترويسة Host؛ تعامل معه كسياسة خطرة يختارها المشغل.
- تعامل مع إعادة ربط DNS وسلوك ترويسة مضيف الوكيل بوصفهما من شواغل تحصين النشر؛ أبقِ `trustedProxies` محكمة وتجنب تعريض Gateway مباشرة للإنترنت العام.

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

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

## تنفيذ Node (system.run)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

موقف OpenClaw:

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

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

لا تُحترم أوامر الشرطة المائلة والتوجيهات إلا من **مرسلين مخولين**. يُشتق التخويل من
قوائم سماح/اقتران القناة بالإضافة إلى `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 ضمن جذر تثبيت plugin النشط.
  - لا يشغّل OpenClaw حظر التعليمات البرمجية المحلية الخطرة المدمج أثناء التثبيت/التحديث. استخدم `security.installPolicy` لقرارات السماح/الحظر المحلية التي يملكها المشغل و`openclaw security audit --deep` للفحص التشخيصي.
  - لا تشغّل تثبيتات npm وgit للـ plugin تقارب اعتماد مدير الحزم إلا أثناء تدفق التثبيت/التحديث الصريح. تُعامل المسارات المحلية والأرشيفات كحزم plugin مكتفية ذاتيًا؛ ينسخها/يشير إليها OpenClaw دون تشغيل `npm install`.
  - فضّل الإصدارات المثبتة والدقيقة (`@scope/pkg@1.2.3`)، وافحص التعليمات البرمجية المفكوكة على القرص قبل التمكين.
  - `--dangerously-force-unsafe-install` مهمل ولم يعد يغير سلوك تثبيت/تحديث plugin.
  - اضبط `security.installPolicy` عندما يحتاج المشغلون إلى أمر محلي موثوق لاتخاذ قرارات سماح/حظر خاصة بالمضيف لتثبيت Skills وplugins. تعمل هذه السياسة بعد تجهيز مادة المصدر ولكن قبل استمرار التثبيت، وتنطبق على Skills من ClawHub أيضًا، ولا تتجاوزها الأعلام غير الآمنة المهملة.

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

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

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

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

وافق عبر CLI:

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

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

## عزل جلسات الرسائل الخاصة (وضع متعدد المستخدمين)

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

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

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

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

### وضع الرسائل الخاصة الآمن (موصى به)

تعامل مع المقتطف أعلاه كـ **وضع الرسائل الخاصة الآمن**:

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

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

## قوائم السماح للرسائل الخاصة والمجموعات

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

- **قائمة سماح الرسائل المباشرة** (`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` للحسابات غير الافتراضية)، وتُدمج مع قوائم السماح في الإعدادات.
- **قائمة سماح المجموعات** (خاصة بالقناة): تحدد المجموعات/القنوات/النقابات التي سيقبل البوت الرسائل منها أصلًا.
  - الأنماط الشائعة:
    - `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)

## حقن الموجهات (ما هو، ولماذا يهم)

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

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

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

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

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

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

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

الإرشادات:

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

ملاحظة مخاطر الخطافات:

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

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

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

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

- استخدام **وكيل قارئ** للقراءة فقط أو معطل الأدوات لتلخيص المحتوى غير الموثوق،
  ثم تمرير الملخص إلى وكيلك الرئيسي.
- إبقاء `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:` الأطول.
- يُطبق التغليف نفسه القائم على العلامات عندما يستخرج فهم الوسائط نصًا
  من المستندات المرفقة قبل إلحاق ذلك النص بموجه الوسائط.
- تمكين العزل وقوائم السماح الصارمة للأدوات لأي وكيل يلامس مدخلات غير موثوقة.
- إبقاء الأسرار خارج الموجهات؛ مررها عبر env/config على مضيف Gateway بدلًا من ذلك.

### خلفيات LLM ذاتية الاستضافة

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

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

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

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

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

التوصيات:

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

## الاستدلال والمخرجات المطولة في المجموعات

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

الإرشادات:

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

## أمثلة تقوية الإعدادات

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

أبقِ الإعدادات + الحالة خاصة على مضيف Gateway:

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

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

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

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

- الافتراضي: `18789`
- الإعدادات/الأعلام/env: `gateway.port`، و`--port`، و`OPENCLAW_GATEWAY_PORT`

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

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

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

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

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

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

قواعد عامة:

- فضّل Tailscale Serve على الربط عبر LAN (يبقي Serve الـ Gateway على local 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 + منافذ الوكيل العكسي لديك).

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

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

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

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

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

1. **أبقِ Bonjour معطّلًا ما لم تكن هناك حاجة إلى اكتشاف LAN.** يبدأ Bonjour تلقائيًا على مضيفي macOS ويكون اختياريًا في أماكن أخرى؛ تتجنب عناوين Gateway المباشرة أو Tailnet أو SSH أو DNS-SD واسع النطاق البث المتعدد المحلي.

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

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

3. **وضع تعطيل mDNS** إذا أردت إبقاء الـ Plugin مفعّلًا مع كتم اكتشاف الأجهزة المحلية:

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

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

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

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

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

### تأمين Gateway WebSocket (مصادقة محلية)

مصادقة 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 ولم يُحلّ، يفشل الحل مغلقًا (من دون إخفاء عبر خيار احتياطي بعيد).
</Note>
اختياري: ثبّت TLS البعيد باستخدام `gateway.remote.tlsFingerprint` عند استخدام `wss://`.
يُقبل النص الصريح `ws://` لـ loopback، وقيم IP الخاصة الحرفية، و`.local`، وعناوين
Gateway في Tailnet `*.ts.net`. لأسماء DNS الخاصة الموثوقة الأخرى، اضبط
`OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` على عملية العميل كمسار طوارئ.
هذا مقصود أن يكون بيئة عملية فقط، وليس مفتاح إعداد
`openclaw.json`.
اقتران الهاتف المحمول ومسارات Gateway اليدوية أو الممسوحة على Android أكثر صرامة:
يُقبل النص الصريح لـ loopback، لكن private-LAN وlink-local و`.local` وأسماء
المضيفين بلا نقاط يجب أن تستخدم TLS ما لم تختر صراحة مسار النص الصريح
للشبكة الخاصة الموثوقة.

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

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

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

- `gateway.auth.mode: "token"`: رمز حامل مشترك (موصى به لمعظم الإعدادات).
- `gateway.auth.mode: "password"`: مصادقة بكلمة مرور (يفضل ضبطها عبر env: `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`) لمصادقة Control
UI/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.

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

- مصادقة حامل Gateway HTTP هي فعليًا وصول مشغّل شامل أو معدوم.
- عامل بيانات الاعتماد التي يمكنها استدعاء `/v1/chat/completions` أو `/v1/responses` أو مسارات Plugin مثل `/api/v1/admin/rpc` أو `/api/channels/*` كأسرار مشغّل كاملة الوصول لذلك الـ Gateway.
- على سطح HTTP المتوافق مع OpenAI، تعيد مصادقة الحامل بسر مشترك نطاقات المشغّل الافتراضية الكاملة (`operator.admin`، و`operator.approvals`، و`operator.pairing`، و`operator.read`، و`operator.talk.secrets`، و`operator.write`) ودلالات المالك لدورات الوكيل؛ لا تقلل قيم `x-openclaw-scopes` الأضيق من مسار السر المشترك هذا.
- لا تنطبق دلالات النطاق لكل طلب على HTTP إلا عندما يأتي الطلب من وضع يحمل هوية مثل مصادقة الوكيل الموثوق، أو من مدخل خاص بلا مصادقة صراحة.
- في هذه الأوضاع الحاملة للهوية، يؤدي حذف `x-openclaw-scopes` إلى الرجوع إلى مجموعة النطاق الافتراضية العادية للمشغّل؛ أرسل الرأس صراحة عندما تريد مجموعة نطاق أضيق. تتطلب رؤوس OpenAI المتوافقة على مستوى المالك مثل `x-openclaw-model` الصلاحية `operator.admin` عندما تكون النطاقات مضيقة.
- تتبع `/tools/invoke` ونقاط نهاية سجل جلسة HTTP قاعدة السر المشترك نفسها: تُعامل مصادقة الحامل بالرمز/كلمة المرور كوصول مشغّل كامل هناك أيضًا، بينما ما زالت الأوضاع الحاملة للهوية تحترم النطاقات المعلنة.
- لا تشارك بيانات الاعتماد هذه مع مستدعين غير موثوقين؛ فضّل 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، remote gateway)، وإعدادات المزوّد، وقوائم السماح.
- `credentials/**`: بيانات اعتماد القنوات (مثال: بيانات اعتماد WhatsApp)، وقوائم السماح بالاقتران، واستيرادات OAuth القديمة.
- `agents/<agentId>/agent/auth-profiles.json`: مفاتيح API، وملفات تعريف الرموز المميزة، ورموز OAuth، و`keyRef`/`tokenRef` اختيارية.
- `agents/<agentId>/agent/codex-home/**`: حساب خادم تطبيق Codex لكل وكيل، والإعداد، وSkills، وplugins، وحالة السلاسل الأصلية، والتشخيصات (الافتراضي).
- `$CODEX_HOME/**` أو `~/.codex/**`: عندما يستخدم Codex plugin صراحة
  `appServer.homeScope: "user"`، يستطيع Gateway قراءة وتحديث حساب Codex الأصلي
  والإعداد وplugins والسلاسل. تعامل مع هذا كوصول مالك ذي امتيازات؛
  الوضع محلي عبر stdio فقط، وإدارة السلاسل الأصلية مخصصة للمالك فقط.
- `secrets.json` (اختياري): حمولة أسرار مدعومة بملف تستخدمها مزوّدات SecretRef من نوع `file` (`secrets.providers`).
- `agents/<agentId>/agent/auth.json`: ملف توافق قديم. تُزال إدخالات `api_key` الثابتة عند اكتشافها.
- `agents/<agentId>/sessions/**`: نصوص الجلسات (`*.jsonl`) + بيانات تعريف التوجيه (`sessions.json`) التي قد تحتوي على رسائل خاصة ومخرجات أدوات.
- حزم plugin المضمّنة: plugins المثبتة (إضافة إلى `node_modules/` الخاصة بها).
- `sandboxes/**`: مساحات عمل صندوق عزل الأدوات؛ يمكن أن تتراكم فيها نُسخ من الملفات التي تقرؤها/تكتبها داخل صندوق العزل.

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

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

### ملفات `.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` غير الموثوقة في مساحة العمل.
- تُحظر أيضًا إعدادات نقاط نهاية القنوات لـ Matrix وMattermost وIRC وSynology Chat من تجاوزات `.env` في مساحة العمل، بحيث لا تستطيع مساحات العمل المستنسخة إعادة توجيه حركة موصلات مضمّنة عبر إعداد نقاط نهاية محلي. يجب أن تأتي مفاتيح بيئة نقاط النهاية (مثل `MATRIX_HOMESERVER` و`MATTERMOST_URL` و`IRC_HOST` و`SYNOLOGY_CHAT_INCOMING_URL`) من بيئة عملية gateway أو `env.shellEnv`، وليس من ملف `.env` محمّل من مساحة العمل.
- الحظر مغلق عند الفشل: أي متغير جديد للتحكم في وقت التشغيل يُضاف في إصدار مستقبلي لا يمكن توريثه من ملف `.env` مُدخل في المستودع أو يقدمه مهاجم؛ يُتجاهل المفتاح ويحتفظ gateway بقيمته الخاصة.
- ما زالت متغيرات بيئة العملية/نظام التشغيل الموثوقة، وdotenv العام لوقت التشغيل، و`env` في الإعداد، واستيراد صدفة تسجيل الدخول المفعّل تُطبّق - هذا يقيّد فقط تحميل ملف `.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)

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

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

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

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

- `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`) لأدوات نظام الملفات.

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

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

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

إذا أردت أيضًا تنفيذ أدوات "أكثر أمانًا افتراضيًا"، فأضف صندوق عزل + احظر الأدوات الخطرة لأي وكيل غير مالك (مثال أدناه تحت "ملفات تعريف الوصول لكل وكيل").

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

## العزل (موصى به)

مستند مخصص: [العزل](/ar/gateway/sandboxing)

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

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

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

فكّر أيضًا في وصول الوكيل إلى مساحة العمل داخل صندوق العزل:

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

<Warning>
`tools.elevated` هو منفذ الهروب الأساسي العام الذي يشغّل exec خارج صندوق العزل. المضيف الفعّال هو `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` مقتصرة على وكلاء هدف معروفين بأنهم آمنون.
- لأي سير عمل يجب أن يبقى معزولًا، استدعِ `sessions_spawn` مع `sandbox: "require"` (الافتراضي هو `inherit`).
- يفشل `sandbox: "require"` بسرعة عندما لا يكون وقت تشغيل الطفل الهدف معزولًا.

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

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

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

### سياسة 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"],
    },
  },
}
```

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

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

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

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

### مثال: وصول كامل (بلا صندوق عزل)

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

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

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

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

```json5
{
  agents: {
    list: [
      {
        id: "public",
        workspace: "~/.openclaw/workspace-public",
        sandbox: {
          mode: "all",
          scope: "agent",
          workspaceAccess: "none",
        },
        // Session tools can reveal sensitive data from transcripts. By default OpenClaw limits these tools
        // to the current session + spawned subagent sessions, but you can clamp further if needed.
        // See `tools.sessions.visibility` in the configuration reference.
        tools: {
          sessions: { visibility: "tree" }, // self | tree | agent | all
          allow: [
            "sessions_list",
            "sessions_history",
            "sessions_send",
            "sessions_spawn",
            "session_status",
            "whatsapp",
            "telegram",
            "slack",
            "discord",
          ],
          deny: [
            "read",
            "write",
            "edit",
            "apply_patch",
            "exec",
            "process",
            "browser",
            "canvas",
            "nodes",
            "cron",
            "gateway",
            "image",
          ],
        },
      },
    ],
  },
}
```

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

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

### الاحتواء

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 مكشوفة خارج local 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. سننسب الفضل إليك (ما لم تفضّل عدم الكشف عن هويتك)