داخل الحاضنة: الصلاحيات محدودة الدور تتحول إلى بدائية أساسية في بيئات تشغيل الوكلاء

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

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

أهم الخلاصات - الصلاحيات محدودة الدور تعني أن بيئة التشغيل تلتقط لقطة من سياسة الموافقة وسياسة صندوق العزل وملف الصلاحيات عند بدء الدور، وتنفذ كل استدعاء أداة في ذلك الدور مقابل تلك اللقطة. - نموذج التهديد ليس مستخدماً خبيثاً. بل وكيلاً قادراً يتبع تعليمات عدائية، مثل حقن الأوامر، أو ينحرف عن المهمة، وهو يعمل ببيانات اعتمادك على جهازك. - ينفذ Codex الحد عبر ثلاثة محاور مستقلة: سياسة الموافقة، أي هل يسأل؛ ووضع صندوق العزل، أي ما الذي تستطيع الأوامر لمسه؛ وملفات الصلاحيات، أي قواعد دقيقة لنظام الملفات والشبكة. ويُفرض ذلك عبر نظام التشغيل لا النموذج. - التنفيذ يقع تحت النموذج: Seatbelt على macOS، وbubblewrap مع seccomp على Linux، وصندوق عزل مخصص على Windows. عندما يتعذر فرض سياسة، يرفض Codex تشغيل الأمر. - الجبهة غير المحسومة هي تغيير الصلاحيات أثناء الدور: اليوم تبقى اللقطة غير قابلة للتعديل طوال عمر الدور، وهو آمن ومزعج أحياناً.

ماذا حدث؟

خلال أواخر يوليو وأوائل أغسطس، نما سطح الصلاحيات في Codex من إعدادين خشنين إلى شيء أقرب إلى محرك سياسات، ولحقت به الوثائق. النموذج الأقدم كان محورين في config.toml: sandbox_mode بالقيم read-only وworkspace-write وdanger-full-access، وapproval_policy بالقيم untrusted وon-request وnever. النموذج الأحدث يضيف ملفات الصلاحيات، وهي تجريبية حالياً: سياسات مسمّاة وقابلة للتركيب تجمع قواعد نظام الملفات، read وwrite وdeny لكل مسار مع أولوية المنع، وقواعد الشبكة، أي قوائم سماح للنطاقات تفرض عبر وكيل محلي. تأتي ثلاثة ملفات مدمجة مع بيئة التشغيل: :read-only و:workspace و:danger-full-access، وتوسعها بدلاً من البدء من الصفر.

وبجانب سطح التهيئة، أصبحت طريقة التفاعل أكثر ارتباطاً بالدور. يبدل /permissions الأوضاع داخل جلسة جارية. وتسمح سياسة موافقة دقيقة بإبقاء بعض فئات المطالبات تفاعلية، مثل تصعيدات صندوق العزل وطلبات MCP، مع رفض فئات أخرى تلقائياً، ومنها فئة مستقلة باسم request_permissions، وهي حالة أن يطلب الوكيل نفسه وصولاً إضافياً أثناء المهمة. ويمكن توجيه الموافقات إلى وكيل مراجعة آلي يفحص الطلبات بحثاً عن تسريب البيانات ومحاولات الوصول إلى بيانات الاعتماد والأفعال المدمرة قبل أن يراها إنسان، وفق وثائق OpenAI للموافقات والأمن.

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

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

ماذا تعني «محدودة الدور» فعلياً؟

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

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

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

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

نموذج التهديد الذي تجيب عنه

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

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

الانحراف والتجاوز هما الخطر الهادئ. وكيل قادر يؤدي عملاً مشروعاً سيظل يتجول: يثبت شيئاً، أو يجلب تبعية، أو «يساعد» بتنظيف مجلد. يجيب صندوق العزل عن هذا من دون حاجة إلى أن يكون الوكيل خبيثاً، ولهذا يُفرض الحد عبر نظام التشغيل، Seatbelt على macOS وbubblewrap مع seccomp على Linux وصندوق عزل أصلي على Windows، لا عبر حسن تقدير النموذج. وعندما يتعذر على المنصة فرض سياسة مطلوبة، يرفض Codex تشغيل الأمر بدلاً من تشغيله بلا عزل. يفشل مغلقاً، لا متفائلاً.

كشف بيانات الاعتماد هو المضاعف. توضح إرشادات devcontainer في الوثائق الأمر صراحة: شغّل Codex بوصول كامل داخل حاوية، ويمكن لمشروع خبيث تسريب أي شيء داخل الحاوية، بما في ذلك بيانات اعتماد Codex. ولهذا تصبح البدائيات الأحدث محددة جداً بشأن الأسرار: قواعد glob مثل "**/*.env" = "deny" تستثني ملفات بيانات الاعتماد من مساحات العمل القابلة للكتابة، وتُحمى .git و.codex و.agents كمسارات للقراءة فقط داخل جذور قابلة للكتابة، ويمنع وكيل الشبكة الوجهات المحلية والخاصة افتراضياً كدفاع ضد إعادة ربط DNS. هذا هو الشكل نفسه لسؤال المعمارية الأوسع في معمارية الذكاء الاصطناعي الوكيلية: النموذج يقترح، والحاضنة تقرر، وينبغي للحاضنة أن تحتفظ بالأسرار.

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

كيف يترابط التنفيذ فعلياً؟

هناك ثلاثة تفاصيل تنفيذ تستحق السرقة عند التفكير في بيئة التشغيل الخاصة بك.

المنع يتغلب على الكتابة، والكتابة تتغلب على القراءة عند مستوى التحديد نفسه. تتيح ملفات الصلاحيات منح وصول واسع أولاً ثم نحت الاستثناءات: مساحة العمل قابلة للكتابة، و**/*.env ممنوع، و.devcontainer للقراءة فقط. المسارات الأكثر تحديداً تتغلب على الأوسع، ويظل المسار الفرعي الممنوع ممنوعاً داخل أصل قابل للكتابة. ويمكن حتى إعادة فتح شجرة فرعية ضيقة داخل منع واسع، مثل منع ~/Documents مع السماح بالكتابة في ~/Documents/codex. هذا نموذج أولوية صحيح لأنه يجعل أقل قدر من الصلاحيات إضافة إلى الكتابة، لا عملية طرح من الذاكرة.

الوصول إلى الشبكة وتصفية الشبكة مفتاحان منفصلان. network.enabled = true يسمح للأوامر بالوصول إلى الشبكة؛ أما features.network_proxy = true فهو الذي يفرض فعلياً قواعد النطاقات عبر وكيل محلي. أحدهما من دون الآخر يمنحك خروجاً غير مقيد مع إحساس زائف بالحوكمة. تبدأ قواعد النطاقات من قائمة سماح، والمنع يفوز، وتُحظر localhost وما يشابهها ما لم تسمح بها صراحة، لأن وكيلاً معزولاً يستطيع الوصول إلى الخدمات المحلية ليس معزولاً بصورة ذات معنى.

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

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

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

ماذا ينبغي أن تفعل الآن؟

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

2. هذا الأسبوع: اكتب ملفاً مخصصاً واحداً يوسع :workspace، ويمنع **/*.env، ويسمح فقط بنطاقات API التي تستدعيها فعلاً، مع تفعيل network_proxy. اختبره باستخدام codex debug، أمر صندوق العزل، قبل الوثوق به. وإذا كنت تراجع شفرة أطراف ثالثة، اربط تلك المشروعات بملف مشتق من :read-only في إعداد المشروع.

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

الأسئلة الشائعة

ما الصلاحيات محدودة الدور؟

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

كيف يختلف هذا عن تشغيل الوكيل كمستخدم مقيد في نظام التشغيل؟

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

هل يستطيع حقن الأوامر تغيير صلاحيات Codex؟

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

هل ملفات الصلاحيات مستقرة بما يكفي للبناء عليها؟

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

الخلاصة

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

إذا كنت تصمم طبقة الصلاحيات لوكلائك وتريد نظرة ثانية، فهذا عمل أقدمه لفرق العملاء. تواصل معي.

المصادر

• OpenAI Developers، «صلاحيات Codex»: https://developers.openai.com/codex/permissions (استُرجع في 2026-08-29)

• OpenAI Developers، «موافقات الوكلاء والأمن»: https://developers.openai.com/codex/agent-approvals-security (استُرجع في 2026-08-29)

• GitHub، مشكلة openai/codex رقم #32612، «تطبيق تغييرات التحكم بالوصول على الدور الجاري»: https://github.com/openai/codex/issues/32612 (فُتحت في 2026-07-12، واستُرجعت في 2026-08-29)

• GitHub، مشكلة openai/codex رقم #23626، «Codex CLI /permissions يحذف Read-only في WSL2 لكنه يظهره في Windows PowerShell»: https://github.com/openai/codex/issues/23626 (فُتحت في 2026-05-20، واستُرجعت في 2026-08-29)

• مستودع OpenAI Codex: https://github.com/openai/codex (استُرجع في 2026-08-29)