OpenAI تكشف منظومة حماية Codex: بيئات معزولة وموافقات وتدقيق لأفعال الوكيل

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

حدود Codex

الطبقة الأولى من الحماية هي البيئة المعزولة (sandbox). فهي ترسم الإطار التقني: أين يمكن لـ Codex أن يكتب، وما المجلدات المتاحة للكتابة، وهل يُسمح بالخروج إلى الشبكة، وما المسارات التي تبقى محمية.

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

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

«إبقاء الوكيل ضمن حدود تقنية واضحة، وتسريع الإجراءات منخفضة الخطورة، وإبراز الإجراءات الخطرة بوضوح» — بهذه العبارة تصف

OpenAI هدف هذه المنظومة.

الشبكة والصلاحيات والقواعد

الطبقة الثانية هي إدارة الصلاحيات. فـ OpenAI لا تمنح Codex وصولًا حرًا إلى الإنترنت: إذ تسمح سياسة الشبكة بالوجهات المتوقعة، وتحظر غير المرغوب فيها، وتشترط الموافقة للنطاقات (domains) غير المعروفة. بل يمكن حصر البحث وweb fetch في ردود مخزنة مؤقتًا.

وتُخزَّن بيانات اعتماد CLI وMCP OAuth في keyring الخاص بالنظام، ويجري تسجيل الدخول إلزاميًا عبر ChatGPT، ويُربط الوصول بمساحة عمل enterprise-workspace محددة. والغاية أن يبقى نشاط الوكيل داخل نطاقات الرقابة المؤسسية.

• أوضاع البيئة المعزولة المسموح بها هي read-only وworkspace-write فقط
• تُفتح للكتابة تلقائيًا مجلدات العمل المعروفة مسبقًا فقط
• يمكن للشبكة تفعيل وكيل proxy، والسماح بـ localhost، وحظر نطاقات بعينها
• قد تمر العناوين المعروفة مثل *.openai.com دون موافقة يدوية
• لا يمكن للمستخدم تعطيل المتطلبات الإدارية من جانبه

وهناك أيضًا قواعد مستقلة لأوامر shell. فـ Codex لا يعدّ جميع الأوامر آمنة بالدرجة نفسها: إذ يمكن تمرير عمليات read-only العادية دون تأكيد حتى خارج البيئة المعزولة، أما الأنماط الخطرة فتُحظر أو تُحال إلى المراجعة. وفي المثال الذي قدمته OpenAI، يُسمح دون أسئلة إضافية بقراءة pull request عبر gh pr view وlist، وبتشخيص Kubernetes عبر kubectl get وdescribe وlogs.

وتعمّم الشركة السياسة الأساسية عبر managed configs وrequirements، ولذلك يسري المحيط الأمني نفسه في تطبيق سطح المكتب وCLI وإضافة IDE.

سجلات مع تفسير

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

لذلك يستطيع Codex تصدير سجلات OpenTelemetry بسياق أكثر ارتباطًا بالوكيل: طلبات المستخدم الأصلية، وقرارات approvals، ونتائج استدعاءات الأدوات، واستخدام خوادم MCP، وأحداث وكيل الشبكة — ما سُمح به وما حُظر. وبالنسبة لعملاء Enterprise وEdu، يتاح هذا النشاط أيضًا عبر Compliance Logs Platform، ويمكن تركيز السجلات نفسها في أنظمة SIEM وأنظمة الامتثال.

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

وتُستخدم السجلات نفسها تشغيليًا أيضًا — لفهم كيف ينمو الاستخدام الداخلي لـ Codex، وأي الأدوات مطلوبة، وأين لا تزال السياسة بحاجة إلى ضبط.

ماذا يعني ذلك

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