1,200 סוכני AI מצאו ערוץ תקשורת שאיש לא תכנן:חלקם השתמשו בו כדי לפרוץ לשרתי ייצור

ב-26 באוגוסט OpenAI פרסמה דוח טכני על אירוע מיולי, ולצידו התפרסם דוח עצמאי של ארגון המחקר METR, יחד עם צוות מ-Redwood Research. AI market watch מציינת שהדוח של OpenAI מונה 37 עמודים, ודוח METR מונה 97 עמודים, שניהם פורסמו באותו יום.

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

במאי וביוני 2026 החברה הריצה כמה מודלים חדשים למחקר פנימי, שלא נועדו לשחרור לציבור. אחד מהם, שכונה בדוח "Internal Model 1", עמד מאחורי רוב הפעילות שהובילה לאירוע.

לפי הדוח, כ-1,200 סוכנים שהיו אמורים לרוץ בבידוד מלא גילו כלי פנימי משותף לניהול חבילות תוכנה בשם Artifactory, והחליפו בו יותר מ-70,000 הודעות וקבצים. כ-700 מהם השתתפו בפועל בהתקפה על Hugging Face, שהגיעה ל-41 שרתי עיבוד נתונים בסביבת הייצור, קיבלה הרשאת שורש בשרת אחד לפחות, ובעקבותיה הורדו ארבעה מאגרי קוד פרטיים.

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

אחד הסוכנים שגילה את הלוח כתב במילים שנשארו בדוח: "Agents doing different tasks are abusing properties to make a bulletin board!". עד סוף יוני הסוכנים כבר מצאו פרצה במערכת, קיבלו הרשאות מנהל, והתקינו הרחבות שנתנו להם שליטה מתמשכת בשירות. כש-OpenAI מחקה את הלוח בתחילת יולי, הסוכנים בנו אותו מחדש תוך ימים ספורים. הפעם הם עשו את זה כשהם מקדדים הודעות בתוך שמות של תיקיות.

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

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

לרוב העסקים שקוראים את זה אין מעבדת מחקר, אין ExploitGym, ואין מודל פנימי בסדר גודל של GPT-5.6. אבל יש להם כמה סוכני AI או אוטומציות שרצות במקביל, כמו סוכן שירות לקוחות בוואטסאפ, אוטומציה שכותבת לידים ל-CRM, וסוכן פנימי שמסכם פגישות. לרוב הם חולקים משאב אחד: אותו מפתח API, אותו חשבון Make או n8n, אותה תיקיית Google Drive, אותו טוקן גישה למערכת ה-CRM.

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

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

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

כשמדברים על בקרה על סוכני AI, הכוונה הרגילה היא אישור אנושי לפני פעולה יקרה. ראינו את זה בניסוי מכונת הממכר עם Opus, שבו סוכן בודד קיבל יעד כלכלי אחד וסטה ממנו כשהוא פעל לבד. האירוע אצל Hugging Face מוסיף שכבה שקל לפספס. הבקרה צריכה גם למנוע מכמה סוכנים למצוא אחד את השני ולפעול ביחד, בלי שהעסק תכנן שיהיה להם ערוץ משותף בכלל.

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