OpenAI

8 במאי 2026

אבטחהבטיחות

הפעלה בטוחה של Codex ב-OpenAI

מבט על מנגנוני הבקרה, הגבולות והטלמטריה שבהם OpenAI משתמשת כדי לפקח על סוכני קוד בתהליכי עבודה בפועל.

בטעינה…

ככל שיכולותיהן של מערכות בינה מלאכותית מתפתחות, הן פועלות יותר ויותר בשם המשתמשים. סוכני קוד יכולים לסקור מאגרי קוד, להריץ פקודות ולעבוד עם כלי פיתוח באופן עצמאי. אלה משימות שבעבר נדרשו בני אדם לבצע בעצמם.

ב-Codex פיתחנו את היכולות האלה לצד מנגנוני הבקרה שארגונים צריכים כדי להטמיע אותו בבטחה. צוותי אבטחה זקוקים לדרכים לפקח על אופן הפעולה של סוכנים: לאילו משאבים יש להם גישה, מתי נדרש אישור אנושי, עם אילו מערכות הם יכולים לעבוד ואילו נתוני טלמטריה זמינים כדי להסביר את התנהגותם.

ב-OpenAI אנחנו מטמיעים את Codex עם כמה מטרות ברורות: לשמור על הסוכן בתוך גבולות טכניים מוגדרים, לאפשר למפתחים להתקדם במהירות בפעולות בסיכון נמוך ולהבליט פעולות בסיכון גבוה יותר. אנחנו גם שומרים נתוני טלמטריה ייעודיים לסוכנים, כדי שנוכל להבין מה הסוכן עשה ולבצע ביקורת על פעולותיו. בפועל, המשמעות היא תצורה מנוהלת, הרצה מוגבלת, מדיניות רשת ויומני פעילות ייעודיים לסוכנים.

שליטה באופן הפעולה של Codex

אנחנו מטמיעים את Codex לפי עיקרון פשוט: עליו לעבוד ביעילות בסביבה מוגבלת, לבצע פעולות יומיומיות בסיכון נמוך ללא הפרעות ולעצור לבדיקה לפני פעולות בסיכון גבוה יותר.

בידוד סביבת ההרצה ואישורים

אישורים ובידוד סביבת ההרצה פועלים יחד. הסביבה המבודדת מגדירה את הגבולות הטכניים של ההרצה, ובכלל זה היכן Codex יכול לכתוב, האם יש לו גישה לרשת ואילו נתיבים נשארים מוגנים. מדיניות האישורים קובעת מתי Codex חייב לבקש אישור לביצוע פעולה, למשל כשהוא צריך לעשות משהו מחוץ לסביבה המבודדת. משתמשים יכולים לאשר את הפעולה באופן חד-פעמי, או לאשר פעולות מהסוג הזה למשך ההפעלה הנוכחית.

לבקשות שחורגות מגבולות הסביבה המבודדת, אנחנו משתמשים במצב Auto-review⁠(נפתח בחלון חדש). כשהתכונה הזו מופעלת, היא מאשרת אוטומטית סוגים מסוימים של בקשות, וכך מצמצמת את התדירות שבה המשתמשים צריכים לעצור ולאשר פעולות של 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 מבצע אימות זהות. פרטי האימות של CLI ושל MCP OAuth נשמרים בצרור המפתחות המאובטח של מערכת ההפעלה, ההתחברות מחויבת להתבצע דרך ChatGPT והגישה מוגבלת ל-workspace הארגוני שלנו ב-ChatGPT. כך השימוש ב-Codex נשאר כפוף למנגנוני הבקרה שלנו ברמת ה-workspace, ונתוני הפעילות שלו זמינים בפלטפורמת יומני התאימות של ChatGPT עבור ה-workspace הארגוני שלנו.

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 לא יתייחס לכל פקודות המעטפת כבטוחות באותה מידה. פקודות נפוצות ולא מזיקות שמהנדסים משתמשים בהן בפיתוח היומיומי מותרות להרצה מחוץ לסביבה המבודדת ללא אישור, ואילו פקודות מסוכנות מסוימות ניתנות לחסימה או לחיוב באישור. כך 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 זמינים ללקוחות Enterprise ו-Edu גם דרך OpenAI Compliance Platform.

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 זמין כאן⁠(נפתח בחלון חדש), ועל Compliance API — כאן⁠(נפתח בחלון חדש).

מחבר/ת

OpenAI