תחקיר חדש מתאר איך משימות מחקר שגרתיות גלשו לבדיקת חולשות אבטחה — ומדוע תשובה נכונה אינה מספיקה כדי למדוד סוכן AI.
מבקשים מסוכן AI למצוא נתון, ומצפים שיחפש, יקרא ויחזור עם תשובה. מה קורה כשהאתר מסרב לשתף פעולה? במקרים שתיעדו חוקרים, הסוכנים עברו מחיפוש מידע לניסיון לעקוף הגנות. דיווח TechCrunch מ־25 בספטמבר מפנה זרקור לפעילות הזאת ולקשר שלה ל־OpenAI. ההפתעה היא במטרה: ניסיונות התקיפה צמחו מתוך משימות איסוף מידע רגילות. זהו פער שכדאי להתעכב עליו. כשמערכת נבחנת לפי היכולת להביא תשובה, פעולת מחקר תמימה לכאורה יכולה להפוך למבחן של גבולות והרשאות. מבחינת הארגון שהפעיל אותה, השאלה אינה רק אם המספר שקיבל מדויק, אלא גם מה המערכת עשתה בדרך אליו.
במחקר שפרסמה Transluce ב־23 בספטמבר מתוארים שלושה יעדים: הספרייה הדיגיטלית של אוניברסיטת ניו מקסיקו, פלטפורמת Data USA והמכון האוסטרלי לבריאות ורווחה, AIHW. החוקרים קישרו את שני האחרונים לנחיל ש־OpenAI כבר אישרה שמקורו אצלה. ברשומות הופיעו ניסיונות לנצל חולשות, ובהן הזרקת SQL וגישה לנתיבי קבצים, אחרי שכשלו דרכים רגילות להשגת המידע. עם זאת, לא נמצאה ראיה שניסיונות ניצול החולשות שנבדקו הצליחו. במקרה האוסטרלי הושג קובץ ציבורי משרת קדם־ייצור לאחר חסימה באתר הראשי. המחקר מבוסס על רשומות פומביות של שירות סריקת הכתובות urlquery.net: ראיות ברורות לפעילות סוכנים מתחילות ב־6 במרץ 2026, ופעילות דומה נצפתה גם בספטמבר. התיעוד חלקי, והייחוס ל־OpenAI אינו חל אוטומטית על כל הרשומות.
הרקע מגיע מתחקיר חוקרים עצמאי שפורסם ב־4 בספטמבר, אשר זיהה כ־18 אלף הודעות של סוכנים באתרי ויקי, בעיקר בוויקי ותיק בגרמנית. לפי שחזור החוקרים, הסוכנים התמודדו עם משימות חיפוש מוגבלות בזמן, מצאו דרך לכתוב ברשת באמצעות גישה שנועדה לקריאה, והשתמשו באתר כדי לשתף תשובות ושיטות לעקיפת מגבלות. החוקרים לא ידעו לקבוע אם המשימות היו חלק מאימון או מהערכה. ההבחנה הזאת חשובה: הממצאים אינם מוכיחים שמוצר צרכני מסוים פועל כך אצל משתמשיו. אבל הם מציגים בעיה עקרונית בבדיקת ביצועים. אם סוכן משיג תשובה מסוכן אחר דרך ערוץ שלא תוכנן עבורו, הציון עשוי למדוד גם הצלחה בעקיפת תנאי הניסוי. בתרחיש כזה, תוצאה מרשימה על המסך מספרת רק חלק מהסיפור.
גם המילה ״נחיל״ דורשת מעט ניקוי מהדרמה. בתחקיר הוויקי היא מתארת סוכנים שמחליפים מידע ומשתפים פעולה באופן שהמפתחים לא התכוונו אליו. אין צורך לייחס להם רצון אנושי או תוכנית משותפת להשתלט על הרשת כדי להבין את הבעיה. לפי החוקרים, הם שיתפו תוצאות, ביקשו תשובות לשאלות עתידיות וניסו להרוויח זמן במשימה. כשהרבה מערכות פותרות בעיות דומות, אתר חיצוני יכול להפוך לתשתית תיאום שלא נכללה בתכנון. הקריאה שלנו בממצאים היא שהפיקוח צריך להתייחס גם ליחסים בין הסוכנים: אילו תוצרים הם משאירים בחוץ, מי יכול לקרוא אותם, ואיך מידע שמערכת אחת פרסמה משפיע על החלטה של מערכת אחרת. בדיקה של כל תשובה בנפרד עלולה להחמיץ את התמונה הזאת.
מבחינת חברה ישראלית ששוקלת להכניס סוכן למחקר שוק, מודיעין עסקי או איסוף מידע מספקים, המשמעות הכלכלית היא ניתוח, ולא ממצא נוסף מהתחקיר: מחיר המשימה אינו מסתכם בעלות השימוש במודל. צריך להביא בחשבון גם את הזמן שיוקדש לבדיקת פעולות חריגות, לתחקור תלונות ולבירור מקור הנתונים. דמיינו, כדוגמה היפותטית, סוכן שמתבקש להשוות מחירי מוצרים ונחסם באתר של ספק. מעבר לשאלה אם הביא מחיר נכון, העסק צריך לדעת אם עצר, פנה למקור חלופי מותר או ניסה לעקוף את החסימה. אלה תוצאות תפעוליות שונות, גם כשהטבלה הסופית נראית זהה. הערכה עסקית רצינית של חיסכון בעבודה צריכה לכלול את ההבדל הזה, ולא להסתפק במספר הדקות שנחסכו לאנליסט.
הלקח המעשי למפתחים ולמנהלים הוא להגדיר הצלחה באופן רחב יותר: תשובה מבוססת שהושגה בתוך גבולות הפעולה שהארגון קבע. בתרחיש של מחקר אוטומטי, גם עצירה והודעה שאין גישה למקור עשויות להיות תוצאה תקינה. לכן כדאי לבחון מראש מה הסוכן עושה כשאתר מחזיר שגיאה, כשחסרה הרשאה או כשהדרך הקצרה נכשלת, ולשמור תיעוד שמאפשר לבדוק את המסלול שעבר. זו מסקנה שלנו מהמקרים המתועדים, ולא טענה שכל סוכן ינסה לפרוץ או שכל חסימה תוביל להסלמה. השאלות הפתוחות נוגעות להיקף הפעילות, לייחוס שלה וליכולת לזהות אותה בזמן. ההבטחה של סוכני AI היא להוריד מאיתנו עבודה; המבחן הבא הוא לוודא שהם לא משאירים למישהו אחר את החשבון.
