أمن الذكاء الاصطناعي مع NVIDIA OpenShell: حدود واضحة للوكلاء

كيف يدعم NVIDIA OpenShell أمن الذكاء الاصطناعي؟

OpenShell بيئة تشغيل مفتوحة المصدر تشغّل الوكيل وتتحكم في وصوله إلى الموارد. يعمل تحت الوكيل، ولا يستبدل قدراته على الاستدلال أو أدواته.

تخيّل متعهدًا يعمل داخل مبنى. تمنحه ورشة، وتسمح له بدخول غرف محددة والاتصال بموردين بعينهم. لكنك لا تسلّمه المفتاح الرئيسي لمجرد أن وصف المهمة يطلب منه «توخي الحذر». يوفّر OpenShell هذه الحدود لوكلاء البرمجيات.

تشرح نظرة عامة على بيئة التشغيل قيود نظام الملفات، وضوابط الشبكة، وقيود العمليات، وحماية بيانات اعتماد مزوّدي الخدمة. Landlock آلية في نواة Linux تحدّ الوصول إلى الملفات؛ أما seccomp فيقيّد استدعاءات النظام، أي الطلبات منخفضة المستوى التي يوجّهها البرنامج إلى نظام التشغيل. يجري إنفاذ هذه القيود خارج عملية استدلال الوكيل.

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

تعرض NVIDIA مسارات لاستخدام Claude Code وCodex وGitHub Copilot CLI وHermes وLangChain Deep Agents وOpenClaw وOpenCode، إلى جانب الوكلاء والصور المخصصة. لكن «مدعوم» لا يعني أن كل أداة مثبّتة مسبقًا: فبيئة العمل الافتراضية الحالية صورة Ubuntu مصغّرة لا تتضمن واجهات سطر أوامر الوكلاء، أي البرامج التي تستخدمها لتشغيلهم.

على مستوى العمل، يتمثل التغيير في إعادة استخدام إعدادات الصلاحيات. فمن دون حدود قابلة لإعادة الاستخدام، قد يفرض كل سير عمل جديد للوكيل جولة أخرى لتحديد الملفات والأسرار والخدمات التي ينبغي إتاحتها. أما بوجودها، فيستطيع الفريق تضمين تلك القرارات مع بيئة العمل ومراجعة التغييرات. قِس الأثر بساعات المهندسين التي تُنفق على إعداد الوصول والتعامل مع المقاطعات؛ لا يوجد رقم موثّق عام لتوفير الوقت يمكن الاستناد إليه.

على أي أنظمة يعمل حاليًا؟

اختر الجهاز المضيف وفق مصفوفة الدعم الحالية. يستند هذا الشرح إلى الوثائق الموسومة v0.1.7، التي جرت مراجعتها في 8 نوفمبر 2026.

يشغّل WSL 2 بيئة Linux على Windows. أما MXC فهو مسار منفصل للعزل الأصلي على Windows. لذلك لا تتعامل مع «دعم Windows» باعتباره مسار تثبيت واحدًا يمكن تبديل مكوناته كيفما اتفق.

يشرح إعلان التعاون الخاص بـWindows إتاحة OpenShell على Windows عبر MXC. لكن هذا التوجه للمنصة لا يعني أن المسار الأصلي يملك اليوم مثبّتًا اعتياديًا مستقرًا. وتنص وثائق التثبيت الحالية صراحة على أن قنوات الإصدارات القياسية لا توفّر ملفات تنفيذية أصلية لـWindows.

للتقييم الأول، اختر إعدادًا مدعومًا على Linux أو Apple Silicon. وتحدد مصفوفة الدعم أيضًا متطلبات النواة وبيئة التشغيل: أضاف Linux 6.2 واجهة Landlock ABI المطلوبة، لكن رقم إصدار النواة وحده لا يكفي. يجب أن تجتاز بيئة التشغيل الفحوص المطلوبة. وفي مسار Docker Desktop على macOS، تعمل خصائص Linux هذه داخل جهازه الافتراضي الذي يشغّل Linux. ولا يلزم استخدام معالجات NVIDIA Vera.

تثبيت واجهة سطر الأوامر وتشغيل أول وكيل

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

1. جهّز المضيف وثبّت OpenShell. إذا اخترت مسار Docker، فيجب أن يكون Docker Desktop قيد التشغيل، أو أن يتوفر Docker Engine 28.0 أو أحدث. على Linux أو macOS المدعومين، يستخدم دليل التثبيت الأمر curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh. راجع برنامج التثبيت قبل تنفيذه. فهو يثبّت واجهة سطر الأوامر وأداة إثبات السياسة والبوابة المحلية. شغّل openshell status للتأكد من أن واجهة سطر الأوامر تتصل بالبوابة.

2. اضبط خدمة النموذج. يستخدم المثال OpenRouter. عيّن OPENROUTER_API_KEY في بيئة المضيف قبل إنشاء المزوّد. يصف ملف تعريف المزوّد نقاط نهاية الخدمة ومسارات الملفات التنفيذية المسموح بها؛ ويخزّن المزوّد بيانات الاعتماد. يسمح ملف التعريف في مثال NVIDIA للبرنامج /usr/local/bin/opencode بالوصول إلى openrouter.ai.

3. استورد ملف التعريف، وأنشئ المزوّد، وشغّل الصورة. نفّذ الأوامر التالية على المضيف بالترتيب:

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

توفّر الصورة OpenCode؛ ويشغّله الأمر الذي يلي -- بوصفه العملية الرئيسية. يستخدم دليل تشغيل أول وكيل هذا النموذج المجاني من دون الحاجة إلى رصيد في OpenRouter. هذا اختيار النموذج في المثال، وليس وعدًا بأن استخدام أي نموذج آخر سيكون بلا تكلفة.

4. راجع طلبات الوصول من المضيف. عندما يحاول الوكيل الاتصال بوجهة غير معتمدة، يرفض OpenShell الطلب ويصوغ مقترح قاعدة ضيقة النطاق. شغّل openshell rule get my-agent --status pending. إذا وافق المقترح الوصول المقصود للمهمة، فاعتمد ذلك المقترح تحديدًا باستخدام openshell rule approve my-agent --chunk-id <chunk-id>، مع استبدال العنصر النائب بالمعرّف الفعلي. تُعاد تهيئة القاعدة، ويستطيع الوكيل المحاولة مجددًا.

5. افحص الصلاحيات التي منحتها فعليًا. شغّل openshell policy get my-agent --base، ثم openshell policy get my-agent --full. يعرض الأول السياسة الأساسية، بينما يشمل الثاني القواعد التي يضيفها المزوّد. راجع الصلاحيات الفعلية قبل إضافة مشروع حقيقي أو خدمة حساسة.

بعد الانتهاء من تقييم مؤقت، احذف البيئة باستخدام openshell sandbox delete my-agent.

ما السياسات التي يمكن تغييرها أثناء التشغيل؟

يمكن تعديل الوصول إلى الشبكة أثناء المهمة. أما حدود نظام الملفات والعمليات فتتطلب إنشاء بيئة معزولة جديدة.

للتغيير «أثناء التشغيل» تبعات أيضًا. فقواعد الشبكة الجديدة تغلق الاتصالات التي فُتحت وفق القواعد السابقة، وعلى العملاء إعادة الاتصال. ويتطلب تسجيل خدمة برمجيات وسيطة خارجية جديدة ضبط البوابة وإعادة تشغيلها. وإضافة مسار ملفات إلى السياسة المحفوظة لا تتيحه لبيئة العمل التي تعمل بالفعل؛ كما يُرفض حذف المسارات أو تغيير إعدادات بدء التشغيل بعد الانطلاق. يشرح دليل إدارة السياسات هذه الفروق بالتفصيل.

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

سياسة لوكيل برمجة يسهل فهم حدودها

امنح وكيل إصلاح الأخطاء مجلد مشروع قابلًا للكتابة ووصولًا للقراءة فقط إلى واجهة API، قبل أن تسمح له بنشر التغييرات.

فيما يلي سياسة توضيحية لصورة برمجة مجهّزة، يوجد فيها المشروع في /workspace والبرنامج curl مثبّتًا في /usr/bin/curl. احفظها باسم policy.yaml ومرّر --policy ./policy.yaml عند إنشاء بيئة معزولة جديدة. هذا قالب يناسب ترتيب الملفات في تلك الصورة، وليس بديلًا جاهزًا لكل صور الوكلاء:

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

يستطيع الوكيل تعديل المشروع والملفات المؤقتة. وتسمح قاعدة الشبكة للملف التنفيذي المحدد بإرسال طلبات GET وHEAD وOPTIONS إلى GitHub API. لكنها لا تمنح البرامج الأخرى وصولًا عامًا إلى الإنترنت، ولا تجيز تنزيل الحزم أو تتيح الدفع عبر Git. ويُضبط مزوّد النموذج بصورة منفصلة.

جهّز أي مجلدات حالة يحتاج الوكيل إلى الكتابة فيها داخل الصورة، وأضفها عن قصد. تشير هذه المسارات إلى نظام الملفات داخل البيئة المعزولة. فلا تفترض أن مجلدًا بالاسم نفسه على المضيف متاح تلقائيًا. كذلك تُضاف مسارات أساسية لنظام الملفات إلى بيئات العمل القادرة على الاتصال بالشبكة، لذا لا يعني اختصار ملف YAML أن حدود الوصول الفعلية لا تضم سوى المسارات الواردة فيه.

هناك إعدادان يستحقان الانتباه. يوقف hard_requirement بدء التشغيل إذا تعذّر إنفاذ قواعد نظام الملفات التي يحددها المستخدم، مع بقاء احتمال تجاوز مسارات منفردة مفقودة أو يتعذّر الوصول إليها. أما enforcement: enforce فيحظر الطلبات المفحوصة غير المسموح بها؛ بينما يسجّل وضع audit الافتراضي في المخطط المخالفات ويسمح بتلك الطلبات. راجع مرجع مخطط السياسة قبل تكييف القالب مع احتياجاتك.

اختبر السماح والرفض معًا. يتحقق دليل سياسة الشبكة من نجاح curl -s https://api.github.com/zen في ظل قاعدة القراءة فقط، ثم يتحقق من رفض طلب POST. افحص openshell logs my-agent --since 5m --source sandbox من المضيف. وفي مشروعك، اختبر أيضًا عملية كتابة مقصودة إلى ملف، ومحاولة وصول إلى ملف خارج النطاق. نجاح تشغيل الوكيل وحده ليس اختبار قبول لسياسة أمنية.

خمسة مسارات عمل جديرة بالتجربة أولًا

أفضل الاستخدامات الأولية هي التي تكون حدود المهمة فيها واضحة، ويوجد شخص قادر على تقييم المخرجات. وفيما يلي ترتيبها وفق قيمتها التشغيلية المرجّحة:

لا يضمن أي من ذلك صحة الشيفرة المولّدة أو موثوقية تشخيص الحوادث. تكمن القيمة في تضييق نطاق ما يمكن أن يحدث أثناء عمل الوكيل. وللمفاضلة بين الأدوات على نطاق أوسع، راجع أفضل أدوات أمن البيئات المعزولة للذكاء الاصطناعي في 2026؛ ولاختيار منصات التنفيذ، راجع أفضل بيئات تنفيذ الشيفرة المعزولة لوكلاء الذكاء الاصطناعي في 2026.

فرصتان لبناء منتج حول OpenShell

الفرصة الأقوى هي حزمة لتهيئة استخدام وكلاء البرمجة داخل الفرق. المشتري المستهدف مسؤول منصات يريد أن يعمل المطورون بإنتاجية داخل بيئة معتمدة. تقدّر DataForSEO وجود 1,300 عملية بحث شهريًا عن “claude code sandbox” في السوق التي أعادها استعلام هذا التشغيل. هذا دليل على الاهتمام بالإعداد، وليس 1,300 عميل محتمل؛ كما أن بعض الباحثين يريدون البيئة المعزولة الخاصة بالوكيل نفسه، وليس OpenShell.

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

الفرصة الثانية هي منصة عمل لمراجعة السياسات. يمكن لفرق الأمن استخدامها لفهم ما تسمح به السياسة الفعلية، ومقارنة التغييرات، وتسجيل الموافقات. تقدّر DataForSEO وجود 480 عملية بحث شهريًا عن “ai agent security”، و70 عن “ai agent security tools.” هذان الاستعلامان المنفصلان إشارتان عامتان للطلب؛ فلا تجمعهما باعتبارهما مشترين فريدين.

يمكن لنسخة أولية قابلة للاستخدام استيراد السياسات الأساسية والفعلية، وإبراز الوجهات وصلاحيات الطلبات المضافة، وإرفاق نتائج الاختبار بسجل المراجعة. والتحدي هو التميّز: فـOpenShell يتضمن بالفعل تحليل السياسات والمقترحات والسجلات. يجب أن يحسّن المنتج عملية المراجعة لدى الفريق، لا أن يضع الأوامر الحالية داخل لوحة تحكم فحسب. ابدأ بحزمة التهيئة، لأن تحديد مشتريها وما ستسلّمه له أسهل.

ما الذي لا يحلّه OpenShell؟

يحدّ OpenShell الوصول، لكنه لا يقرر إن كان الإجراء المسموح به قرارًا تجاريًا سليمًا. فالوكيل المسموح له بالكتابة في ملفات المشروع قد يكتب رقعة سيئة. والوجهة الخارجية المعتمدة قد تتلقى بيانات تسمح سياستك بإرسالها إليها. يجب أن تعكس صلاحيات الملفات واعتماد نقاط النهاية ما تنوي إتاحته فعلًا.

كما أنه لا يحل محل أنظمة الهوية أو مخازن الأسرار أو المراقبة أو الحوكمة. يضع إعلان NVIDIA عن ضوابط بيئة التشغيل الإنفاذ خارج بيئة عمل الوكيل. تعامل مع ذلك باعتباره جزءًا من المنظومة المحيطة، لا مبررًا للاستغناء عن بقية أجزائها.

للمشروع الآن إصدارات مستقرة مخصصة للاستخدام الإنتاجي ضمن مصفوفة دعمه؛ لذا فإن وصف OpenShell كله بأنه عرض تجريبي سيكون مضللًا. حدوده أكثر تحديدًا: قد تتغير الواجهات التجريبية في إصدارات التصحيح، ولا يزال المسار الأصلي لـWindows قيد التطوير، وتقول NVIDIA إن ملف التأهيل الحالي لديها لا يغطي سياسة تأهيل الإصدارات بأكملها. ثبّت إصدار ما تنشره، وتحقق من التوليفة المحددة لبيئة العمل والمضيف.

خطوة يوم الاثنين: اطلب من مسؤول المنصات اختيار مستودع واحد لا يحوي بيانات حساسة ووكيل واحد. ثبّت OpenShell على مضيف مدعوم، وجهّز الصورة، وحدّد الوصول إلى الملفات والشبكة، ثم اختبر عملية مسموحًا بها وأخرى محظورة. سجّل وقت الإعداد وساعات المهندسين التي تُنفق على التعامل مع المقاطعات خلال الأسبوع الأول. لا توسّع الاستخدام إلا بعد أن يستطيع الفريق تفسير كل صلاحية مُنحت.

إذا أردت إدماج ذلك في سير عمل فريقك، يمكننا مساعدتك في وضع ضوابط الاستخدام الإنتاجي موضع التنفيذ.