تخطي إلى المحتوى الرئيسي
OpenAI

تشغيل Codex بأمان في OpenAI

نظرة على عناصر التحكم والحدود والقياس عن بُعد التي تستخدمها OpenAI لإدارة وكلاء البرمجة ضمن سير العمل الفعلي.

جاري التحميل...

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

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

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

التحكم في كيفية عمل Codex

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

العزل والموافقات

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

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

TOML

1
# config.toml
2

3
# Turn on auto_review
4
approvals_reviewer = "auto_review"
5
# Add known development directories to the sandbox automatically
6
sandbox_workspace_write.writable_roots = ["~/development"]
7

8
# requirements.toml
9

10
# Require Codex to operate inside the sandbox
11
allowed_sandbox_modes = ["read-only", "workspace-write"]

الوصول إلى الشبكة

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

TOML

1
# requirements.toml
2

3
# Ensure web fetch only comes from OpenAI's cache
4
allowed_web_search_modes = ["cached"]
5

6
[experimental_network]
7
# Turn on Network Proxy
8
enabled = true
9
# Allow Codex to interact with localhost
10
allow_local_binding = true
11
# Block all requests to this domain
12
denied_domains = ["pastebin.com"]
13
# Auto-allow requests to these domains
14
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

الهوية وبيانات الاعتماد

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

TOML

1
# config.toml
2

3
# Store CLI Auth Creds in OS Keychain
4
cli_auth_credentials_store = "keyring"
5
# Store MCP Creds in OS Keychain
6
mcp_oauth_credentials_store = "keyring"
7
# Require Auth via ChatGPT
8
forced_login_method = "chatgpt"
9
# Require Auth to Specific ChatGPT Workspace
10
forced_chatgpt_workspace_id = "<workspace-uuid>"

القواعد

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

Starlark

1
# default.rules
2

3
prefix_rule(
4
pattern = ["gh", "pr", ["view", "list"]],
5
decision = "allow",
6
justification = "Allows read-only GitHub PR inspection via gh CLI.",
7
)
8
prefix_rule(
9
pattern = ["kubectl", ["get", "describe", "logs"]],
10
decision = "allow",
11
justification = "Allows Kubernetes resource inspection for debugging.",
12
)

التهيئات المُدارة

نطبق هذا النهج من خلال مزيج من متطلبات مُدارة عبر السحابة، وتفضيلات مُدارة على macOS، وملفات متطلبات محلية. وتُعد هذه المتطلبات ضوابط يفرضها المسؤول ولا يستطيع المستخدمون تجاوزها. وتتيح لنا التفضيلات المُدارة على macOS وملفات المتطلبات المحلية الحفاظ على خط أساس موحّد، مع الاستمرار في اختبار إعدادات مختلفة بحسب الفريق أو مجموعة المستخدمين أو البيئة. وتنطبق هذه الإعدادات على واجهات Codex المحلية، بما في ذلك تطبيق سطح المكتب، وواجهة سطر الأوامر CLI، وإضافة IDE.

بيانات القياس عن بُعد الأصلية الخاصة بالوكيل ومسارات التدقيق

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

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

TOML

1
# config.toml
2

3
[otel]
4
log_user_prompt = true
5
environment = "prod"
6

7
[otel.exporter.otlp-http]
8
endpoint = "http://localhost:14318/v1/logs"
9
protocol = "binary"

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

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

نظرة إلى المستقبل

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

المؤلف

OpenAI