OpenShell من NVIDIA يضع صلاحيات الوكلاء تحت تحكم السياسات — ما الذي أصبح جاهزًا للاختبار

OpenShell هو الجزء مفتوح المصدر من جهد NVIDIA الجديد لجعل احتواء الوكلاء المستقلين أسهل. يضع المشروع وكلاء مثل Codex وClaude Code وOpenCode وGitHub Copilot CLI داخل مساحات معزولة، ثم يطبّق قواعد على الملفات التي يستطيعون لمسها، والبرامج التي يمكنهم تشغيلها، والوجهات الشبكية التي يمكنهم الوصول إليها، وبيانات الاعتماد التي يُسمح لهم باستخدامها.

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

أعلنت NVIDIA منصة Open Agent Safety Platform الأوسع في 28 سبتمبر 2026. وتضم المنصة أيضًا Sentry، وهو تصميم منفصل للمراقبة والاحتواء مرتبط بأجهزة NVIDIA. أما OpenShell فهو الجزء الذي يستطيع المطورون فحصه وتشغيله عبر عدة خيارات للبنية التحتية. وهو مرخّص بموجب Apache 2.0، لكنه لا يزال مشروعًا ناشئًا يفرض تعقيدًا تشغيليًا ومتطلبات على المضيف ونموذج سياسات يحتاج إلى اختبار دقيق.

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

الزاوية الحالية: حدّ الوكيل هو المنتج

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

من السهل أن تضيع هذه النقطة لأن المشروع يظهر في خضم موجة من إطلاق الوكلاء. يستطيع وكيل برمجي نموذجي قراءة نسخة عمل، وتعديل ملفات المصدر، وتثبيت الاعتماديات، والاتصال بسجلات الحزم، واستخدام Git، والوصول إلى واجهات سحابية، وتشغيل عمليات فرعية. قد يطلب منه prompt أن يكون حذرًا، لكن prompt ليس آلية إنفاذ. فإذا تلقى الوكيل تعليمات خبيثة من ملف README أو من issue، فقد يحتفظ بالصلاحيات التي منحتها له الصدفة المحيطة به.

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

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

ما الذي يتحكم فيه OpenShell فعليًا

تضم السياسة الأساسية عدة مجالات، ولا تعمل كلها بالطريقة نفسها. وفهم هذا الاختلاف الزمني من أول الأمور التي ينبغي للمقيّم استيعابها.

يحدد filesystem_policy المسارات القابلة للقراءة وتلك القابلة للكتابة. ويستخدم المشروع ضوابط مبنية على Landlock للوصول إلى نظام الملفات. تُطبَّق إعدادات نظام الملفات وLandlock عند بدء المساحة المعزولة، ولذلك فإن تغييرها ليس ك changing قاعدة شبكة على حِمل عمل قيد التشغيل. قد تسمح السياسة للوكيل بالكتابة إلى مجلد المشروع ومجلد مؤقت، مع إبقاء بيانات الاعتماد ومفاتيح SSH وملفات تعريف المتصفح والبيانات غير المتعلقة بالمشروع خارج نطاق رؤيته.

يتحكم قسم process في الهوية وظروف العملية المستخدمة عند إنشاء المساحة المعزولة. والهدف هو منع حِمل العمل من تحويل مهمة برمجية عادية ببساطة إلى تمرين على تصعيد الامتيازات. لكن هذا يظل معتمدًا على بيئة التشغيل المضيفة وإعدادها المختار؛ فملف السياسة لا يمحو الافتراضات الأمنية الخاصة بـ Docker أو Podman أو Kubernetes أو الآلة الافتراضية أو نظام التشغيل الموجود تحتها.

تتحكم network_policies في الاتصالات الصادرة. يستخدم OpenShell نموذج المنع الافتراضي لاتصالات المساحة المعزولة، ثم يسمح بوجهات مسماة، وبملفات ثنائية محددة حيثما جرى إعداد ذلك. ويمكن للقاعدة التمييز بين مدير حزم وأمر صدفة، أو بين عميل Git وعميل HTTP عام. ويتيح هذا السماح بمسار ضيق من دون منح كل عملية نفس الخروج إلى الشبكة.

كما تستطيع طبقة الشبكة فحص الطلبات على مستوى أعلى. يتيح مثال NVIDIA للأداة curl قراءة واجهة GitHub REST API، مع رفض طلب كتابة. والتفصيل المهم هو أن السماح بمضيف لا يعني بالضرورة السماح بكل عملية على ذلك المضيف. يمكن للسياسة وصف نقطة نهاية ومنفذ وبروتوكول وملف ثنائي مسموح به، إلى جانب وصول للقراءة فقط أو للكتابة.

وتوفر network_middlewares موضعًا آخر للفحص أو التحويل أو الحجب. عمليًا، يمكن للسياسة هنا أن تصبح أكثر تحديدًا من قاعدة جدار ناري تقليدية. تصف وثائق المشروع ضوابط لحركة HTTP وGraphQL وModel Context Protocol. وهذا لا يعني أن كل بروتوكول تطبيقي ناضج بالقدر نفسه أو سهل التعبير بالقدر نفسه؛ بل يعني أن بيئة التشغيل مصممة للتفكير في الطلبات، لا في عناوين IP والمنافذ وحدها.

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

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

سياسة صغيرة أكثر إفادة من ادعاء تسويقي

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

يبدو شكل مبسط للسياسة كما يلي:

version: 1
filesystem_policy:
  include_workdir: true
  read_only:
    - /usr
    - /lib
    - /etc
  read_write:
    - /tmp
landlock:
  compatibility: best_effort
network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

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

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

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

من ينبغي له تجربته الآن

يناسب OpenShell من يشغّلون وكلاء يملكون صلاحية محلية مؤثرة ويريدون قياس الفارق بين الحذر على مستوى prompt والإنفاذ على مستوى بيئة التشغيل. يستطيع مهندسو الأمن استخدامه لبناء اختبارات قابلة للتكرار للهروب من العزل واستخراج البيانات. ويمكن لفرق المنصات دراسة انتقال السياسات من حاسوب المطور إلى بوابة Kubernetes. كما يستطيع مطورو أدوات الوكلاء اختبار سلوك أشجار عملياتهم واتصالاتهم الشبكية وتكاملات المزوّدين داخل بيئة مقيدة.

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

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

أما الفرق التي تبحث عن لوحة تحكم مؤسسية جاهزة فعليها أن تكون أكثر حذرًا. يضم المستودع بوابة وواجهات SDK ومعالجة للمزوّدين وسلوكًا للتدقيق ومسار نشر على Kubernetes، لكن جمع هذه الأجزاء في نظام واحد مشروع أنظمة بحد ذاته. فهو يشمل إدارة الصور وامتيازات بيئة التشغيل وإنفاذ الشبكة والهوية والأسرار والسجلات والاستجابة للحوادث وملكية السياسات. تثبيت CLI لا يساوي إنجاز هذا العمل.

ما زال المضيف وبيئة التشغيل مهمين

يستهدف التشغيل السريع حاليًا Linux وmacOS على Apple Silicon وWindows عبر WSL 2 على أساس تجريبي. ويتوقع المشروع وجود طبقة حاويات أو افتراضية مثل Docker أو Podman أو افتراضية المضيف. ويدعم Kubernetes من خلال نشر Helm، مع تنبيه المشروع إلى أن طبقة شبكة العنقود يجب أن تنفذ سياسة الشبكة المعنية.

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

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

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

وساطة بيانات الاعتماد واعدة، لكنها ليست سحرًا

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

لكن ذلك لا يلغي مخاطر بيانات الاعتماد. فما زال على الخدمة إصدار رموز معقولة. ولا يزال يتعين إعداد ملف تعريف المزوّد بصورة صحيحة. كما يجب أن يتعرف الوكيل على الحركة التي يفترض أن يفحصها. وتظل بيانات الاعتماد المخولة بحذف مستودعات خطرة إذا سمحت السياسة بطريقة API المعنية. ويمكن للنموذج أن ينتج مخرجات ضارة داخل النطاق الممنوح له.

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

يقول OpenShell إنه يسجل قرارات السياسة في سجل تدقيق وفق Open Cybersecurity Schema Framework. وهذا مفيد للاستجابة للحوادث، لكن السجلات لا تساعد إلا إذا جُمعت وحُفظت وحُميت من حِمل العمل وربطت بهوية الشخص أو الأتمتة التي وافقت على التغيير. فسجل عرض محلي ليس بعد نظام تدقيق مؤسسيًا.

ما الذي لا يحله المشروع

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

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

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

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

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

الترخيص ونضج المشروع

يحدد مستودع OpenShell ترخيص Apache 2.0 ترخيصًا له. وهو ترخيص متساهل مألوف في مشاريع البنية التحتية وأدوات المطورين. ويجعل ذلك فحص الشفرة وتعديلها ودمجها أسهل، مع الخضوع للترخيص وبنود منفصلة قد تتعلق بالمواد المسترجعة وصور الحاويات والنماذج والمزوّدين والمكونات التابعة لجهات أخرى.

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

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

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

البدائل والمكملات

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

تحل هذه الأساليب أجزاء مختلفة من المشكلة. فالحاويات والـpods توفر ركائز لبيئة التشغيل. وقد توفر الآلات الافتراضية المصغرة حد عزل أقوى مقابل تكلفة في زمن البدء وإدارة الصور. وتفيد مشغلات CI في المهام القابلة للتكرار لكنها قد تكون غير مريحة للتطوير التفاعلي. أما سياسة النواة المباشرة فقد تكون خفيفة، لكنها تترك للفرق بناء وساطة بيانات الاعتماد ووساطة الشبكة وإدارة دورة الحياة واتفاقيات التدقيق الخاصة بها.

حجة OpenShell هي أن أحمال عمل الوكلاء تحتاج إلى تنسيق هذه الأجزاء. فالسياسة ينبغي ألا تصف ما يستطيع process قراءته فحسب، بل أي ملف تنفيذي يمكنه استدعاء أي نقطة نهاية، وأي بيانات اعتماد مرتبطة بتلك النقطة، وكيف تتغير السياسة قيد التشغيل، وكيف تُسجل النتيجة. وهذا التنسيق هو السبب الرئيسي لوجود المشروع.

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

خطة تقييم معقولة

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

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

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

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

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

الخلاصة

يستحق NVIDIA OpenShell الاهتمام لأنه يتعامل مع سلطة الوكيل بوصفها بنية تحتية، لا وعدًا مضمّنًا في system prompt. تمنح شفرته المرخصة بموجب Apache، وسياساته التصريحية، وضوابط نظام الملفات المدعومة من النواة، ووساطة الشبكة، وبيانات اعتماد المزوّدين، ونموذج البوابة، المطورين شيئًا ملموسًا للاختبار. كما يتصل المشروع طبيعيًا بمنظومة المصدر المفتوح: فهو يدعم عدة أدوات لتشغيل الوكلاء، ويقدم SDKs، ويوثق مسار Kubernetes، ويمكن تشغيله على عتاد يتجاوز NVIDIA.

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

بالنسبة إلى جمهور Open Source Radar، الخطوة المنطقية التالية هي تجربة مخبرية، لا انتقال إنتاجي. استخدم OpenShell لبناء حزام اختبار قابل للتكرار لمسارات عمل الوكلاء التي تملك حاليًا صلاحيات زائدة. قِس الأفعال المحجوبة، والإنذارات الإيجابية الكاذبة، وسلوك بدء التشغيل، ومراجعة السياسة، والسجلات، والتعافي. فإذا صمدت الضوابط أمام هذه العملية من دون تحويل كل مهمة إلى طابور موافقات، فقد يصبح OpenShell أساسًا عمليًا لتطوير وكلاء أكثر أمانًا. وإذا لم تصمد، فستكشف التجربة على الأقل بدقة المواضع التي يعتمد فيها مسار العمل على الصلاحية المحيطة — وهذه معلومة تحتاج إليها معظم مشاريع الوكلاء.

المصادر والإسناد

يحافظ هذا التكييف على الإسناد الوارد في المقال الأساسي إلى مستودع NVIDIA OpenShell ووثائق سياساته ومواد NVIDIA التقنية وصفحة المنتج، وإلى ملف الترخيص في المستودع. كما يحافظ على الإشارة السياقية إلى تغطية Associated Press ونقاش Hacker News المتعلق بالمشروعات مفتوحة المصدر الحالية. لم تُضف مصادر أو ادعاءات جديدة إلى المادة الأصلية.