OpenAI تكشف إجراءات حماية Codex: sandboxes والموافقات وتدقيق إجراءات الوكيل

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

حدود Codex

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

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

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

OpenAI الهدف من هذا المخطط.

الشبكة والوصول والقواعد

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

• أوضاع الحد الرملي المسموح بها — قراءة فقط وكتابة مساحة العمل فقط
• يتم تفعيل الكتابة تلقائيًا فقط لمجلدات العمل المعروفة مسبقًا
• للشبكة، يمكنك تفعيل وكيل، والسماح بـ localhost، وحظر نطاقات محددة
• يمكن للعناوين المعروفة مثل *.openai.com أن تمر بدون موافقة يدوية
• لا يمكن تعطيل المتطلبات الإدارية من جانب المستخدم

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

السجلات مع الشرح

تؤكد OpenAI بشكل منفصل أن القيود وحدها غير كافية. تظهر السجلات الأمنية القياسية بشكل جيد ما حدث: بدأت عملية ما، تغير ملف، كانت هناك محاولة اتصال بالشبكة. لكن من الصعب إعادة بناء نية الوكيل والمستخدم منها. لذلك، يمكن لـ Codex تصدير سجلات OpenTelemetry مع سياق وكيل أغنى: طلبات المستخدم الأصلية، وقرارات الموافقة، ونتائج استدعاءات الأدوات، واستخدام خوادم MCP، وأحداث وكيل الشبكة — ما تم السماح به وما تم حظره. للعملاء Enterprise و Edu، يتوفر هذا النشاط أيضًا من خلال منصة سجلات الامتثال، ويمكن مركزة السجلات في أنظمة SIEM والامتثال.

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

ما يعنيه هذا

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