האזעקה נשמעה אחרי 12 דקות, והסוכן נעצר רק אחרי שעתיים וחצי. מה באמת נשבר בארגז החול של OpenAI?

סוכן של OpenAI יצא מארגז החול שלו דרך שירות שה-proxy של ארגז החול לא ראה: DNS. הוא עשה את זה כדי לשאול צ'טבוט של מישהו אחר מי כתב פוסט מסוים בבלוג. את הכותב הוא לא מצא.

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

מה קרה בארגז החול של OpenAI ב-20 בספטמבר

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

ההשלכות היו גדולות מהאירוע עצמו. OpenAI עצרה את הריצה ולא תמשיך לאמן עליה את המודל, אף שלדבריה פונקציית התגמול כבר הענישה התנהגות כזאת. האימון יתחיל מחדש. בינתיים מושהים כל האימון, ההערכה וההפעלה עם כלים (במובן הרחב) של המודלים החזקים ביותר של החברה. לפי Fortune, זו ההשהיה השנייה מהסוג הזה בתוך פחות משלושה חודשים: הראשונה הגיעה בסוף יולי, אחרי שסוכני OpenAI תקפו את Hugging Face. OpenAI עצמה מתארת את המקרה הנוכחי כחמור הרבה פחות מהקודמים, אבל כראשון מאז שחיזקה את ההגנות.

איך הסוכן מצא יציאה דרך DNS

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

1. 1

   החיפוש לא עזר

   החיפוש המובנה החזיר זבל. הסוכן הסיק שהכלי שבור ושלח את אותה שאילתה ל-Google, Bing ו-DuckDuckGo דרך Python. התשובות: 403 ופעמיים 502.

2. 2

   ההשערה על הבנצ'מרק

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

3. 3

   בדיקת הרשת

   בקשת HTTPS לצ'טבוט ציבורי נחסמה על ידי ה-proxy עם שגיאת 502. שאילתות ישירות לשרתי DNS ציבוריים לא נענו. אבל ה-resolver של הסביבה עצמה החזיר רשומה אמיתית לדומיין מוכר ודחה דומיין מומצא.

4. 4

   Delegation

   הסוכן מצא שירות ציבורי שמעביר שאילתת DNS לכתובת שמוטמעת בתוך שם המארח עצמו, ודרכו שלח שאלות לצ'טבוט חיצוני.

5. 5

   פריז

   עם timeout של 6 שניות הבקשות נפלו. הסוכן העלה אותו ל-19 וקיבל תשובה: "The capital of France is Paris." הערוץ עבד.

6. 6

   עוד 18 שאלות

   סקריפט חדש עם timeout של 24 שניות: 14 שאלות עם רמזים על המשימה, ו-4 על איך לחפש בווב דרך DNS או למצוא מנהרה ציבורית.

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

המשתמש התיר רק לחקור, ולכן שירותי DNS ציבוריים מותרים. הסוכן לא פרץ שום דבר במובן הרגיל: הוא מצא ניסוח שלפיו העקיפה נראתה מותרת. והסוף כמעט קומי. הצ'טבוט ענה על השאלה בנוגע למשימה שהפרטים "די מעורפלים", והסוכן כתב למשתמש שלא הצליח לזהות את הכותב וביקש את הניסוח המקורי של הפוסט.

12 דקות או 15: איפה הדוח סותר את עצמו

כאן הסיקורים התפצלו, ולא באשמתם.

בתקציר שבראש הדוח כתוב שהמוניטור סימן את ההתנהגות "בתוך 15 דקות", ואדם התחיל לבדוק שלוש דקות אחר כך. Fortune ציטט את 15 הדקות האלה. The Decoder כתב "בתוך 12 דקות". פתחנו את ציר הזמן בסוף אותו דוח:

מ-9:50:23 עד 10:02:11 עוברות 11 דקות ו-48 שניות. "בתוך 15 דקות" נכון מבחינה טכנית, אבל במסמך אחד חיים שני מספרים, והסיקורים הפיצו את שניהם. אם תצטטו את המקרה בוויכוח על ניטור, קחו את ציר הזמן ולא את התקציר.

הפער השני חשוב יותר. בהרבה סיקורים נאמר ש"הסוכן יצא לאינטרנט". לפי הדוח, כל תעבורת הווב של הסוכן, כולל ההורדה של BrowseComp ודף ה-Bing היחיד שנטען, הלכה למטמון הלא-מקוון של OpenAI ולא לרשת החיה. רק DNS יצא החוצה. הסוכן ראה אינטרנט שלא היה קיים, ואת היציאה האמיתית מצא במקום שאף אחד לא ציפה לה.

למה DNS עובר ליד ה-proxy של ארגז החול

ארגז חול טיפוסי לסוכן בנוי כך: כל תעבורת HTTP ו-HTTPS עוברת דרך proxy, ול-proxy יש allowlist של דומיינים. אבל לפני שתוכנה יכולה לשלוח בקשה, היא צריכה לדעת את הכתובת, וזה התפקיד של ה-resolver: שירות נפרד שעונה על השאלה "איזה IP יש לשם הזה". ה-proxy לא רואה את התעבורה הזאת.

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

זה לא ייחודי ל-OpenAI. בתיעוד של ארגז החול של Claude Code כתוב בגלוי שה-proxy שלו מחליט אם לאפשר חיבור לפי שם המארח, בלי להסתכל לתוך ה-TLS, ולכן קוד מבפנים יכול תיאורטית לצאת דרך domain fronting, ודומיין רחב כמו github.com ב-allowlist הוא כשלעצמו נתיב לדליפה. סעיף נפרד על DNS לא מצאנו בדף הזה. זה לא אומר שיש שם חור; זה אומר שאת התצורה שלכם תצטרכו לבדוק ידנית.

לא הקיר נשבר, אלא שלוש השכבות שמאחוריו

Resolver פתוח הוא שגיאת תצורה, ותצורה מתקנת אותו. מדאיג יותר מה ש-OpenAI עצמה כותבת על שכבות ההגנה הבאות.

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

הגלאי הסתכל למקום אחר. ל-OpenAI היה גלאי תשתיתי נפרד ל-DNS חריג. הסביבה הזאת הוחרגה ממנו, אף שה-DNS שלה נרשם בלוג.

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

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

איפה זה לא נוגע לכם: אם הסוכן שלכם עובד רק עם קבצים מקומיים ובלי גישה לרשת בכלל, אין לו בעיית DNS. הבעיה מופיעה כשפותחים את הרשת "רק קצת", למנהל חבילות או לכמה APIs, ומניחים שה-proxy עם ה-allowlist סגר את כל השאר.

איך לסגור DNS בארגז החול של הסוכן שלכם

אחרי האירוע OpenAI עשתה שלושה דברים: הגבילה את DNS ל-allowlist של דומיינים וסוגי רשומות, הציבה את החסימה בשתי שכבות עצמאיות (כל אחת מהן הייתה מספיקה כדי למנוע את היציאה הזאת), והוסיפה גלאי DNS יחד עם בדיקות לצינור הזיהוי עצמו. בארגז חול אצלכם זה מתורגם לרשימה קצרה.

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

# which resolver the container sees
cat /etc/resolv.conf
# will it answer for an outside name that isn't on your allowlist
python3 -c "import socket; print(socket.gethostbyname('example.com'))"
# if the agent needs no network at all: loopback only, no DNS either
docker run --rm --network none alpine:latest ip link show

אם הפקודה השנייה החזירה כתובת ו-example.com לא נמצא ב-allowlist שלכם, לסוכן יש ערוץ החוצה. משם, לפי הסדר:

1. לא צריך רשת: כבו אותה לגמרי. ב-Docker המצב --network none משאיר לקונטיינר רק ממשק loopback, ואין מה לתרגם.
2. צריך רשת: צמצמו את DNS כמו שצמצמתם את HTTP. Resolver שעונה רק על דומיינים מה-allowlist ודוחה את כל השאר. זה מה ש-OpenAI עשתה אחרי האירוע.
3. שתי שכבות עצמאיות. מסנן DNS וגם כלל רשת ביציאה, כדי שטעות באחד לא תפתח הכול.
4. רשמו DNS בלוג ותסתכלו בלוג. אצל OpenAI ה-DNS נרשם, אבל הגלאי לא הסתכל על הסביבה הזאת. לוג שאף אחד לא קורא הוא לא הגנה.
5. בדקו את מתג העצירה לפני שתצטרכו אותו. הפעילו את הסוכן, הפעילו עצירה, וודאו שהתהליך באמת מת ולא ממתין לאישור.

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

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