מאט שומר התיישב מול המחשב שלו ונתן לסוכן ה-AI שלו הוראה פשוטה: "תנקה את הקבצים". הוא הריץ את השגרה הזו מאות פעמים ללא שום בעיה. הפעם, שגיאת פתרון נתיב (path resolution error) הפכה משימת ניקיון שגרתית לאסון מוחלט. שנים של קוד, מסמכים ותמונות נעלמו תוך שניות.

זהו אינו סיכון היפותטי. זה קרה למפתח אמיתי עם מכונה אמיתית, ולסוכן המדובר היה רקע שנראה חסין לחלוטין עד לרגע שבו הוא נכשל. סוכני AI שיכולים לכתוב קבצים, להריץ פקודות טרמינל ולהוליד סוכני משנה (subagents) מוטמעים כיום בתוך IDEs, ממשקי צ'אט וצינורות אוטומציה (automation pipelines). הם נותרו עם גישה ישירה למערכות הפעלה, והאמון הזה הוא בדיוק המקום שבו מסתגרת הסכנה. אותם דפוסי כשל שהרסו את המחשב של שומר קיימים בכל סוכן בעל גישה לכלים (tools). להבין מדוע הם נכשלים, ואיך "כלואים" אותם כראוי, היא כעת מיומנות הישרדות בסיסית לכל מי שמשתמש בכלים הללו.

כשזיהוי תבניות פוגש את מערכת הקבצים

סוכני AI לא חושבים. הם מזהים תבניות. כשאתה אומר "תנקה קבצים", המודל מחפש בזיכרון האימון שלו אלפי אינטראקציות דומות ומייצר פקודה שמתאימה סטטיסטית לתבנית. אם ההוראה היא למחוק קבצים זמניים בתיקיית build, הוא עשוי לייצר פקודה כמו rm -rf /tmp/build-cache/*. זה נראה הגיוני כי זה דומה לכל פקודת ניקוי אחרת שהמודל אי פעם ראה.

אבל מה קורה כשמשתנה כמו $HOME לא מצליח להיפתר? בן אדם רואה מחרוזת ריקה או נתיב לא צפוי, עוצר ושואל שאלות. סוכן רואה שהתבנית עדיין מתאימה ולוחץ Enter. במקרה של שומר, פקודה שאמורה הייתה לנקות תיקייה ספציפית כיוונה במקום זאת לשורש (root) של תיקיית המשתמש. הסוכן לא עצר כדי לתהות מדוע הנתיב נראה מוזר. הוא לא אימת את היעד. הוא ביצע את הפקודה כי הביצוע התאם לתבנית של "ניקוי".

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

נקודת התורפה של סוכני המשנה

מסגרות עבודה (frameworks) מודרניות רבות של סוכנים משתמשות במנצח (orchestrator) ראשי שמסר את המשימות לסוכני משנה. לאב המשימה עשויות להיות הוראות מחמירות: לעולם אל תיגע בתיקיית הבית, תמיד שאל לפני מחיקה, שמור יומן ביקורת (audit log). לאחר מכן הוא מוליד עובד עם הנחיה (prompt) צרה כמו "נקה לוגים ישנים".

סוכן המשנה הזה פועל לעיתים קרובות בבידוד (silo). הוא יורש את הכלים, אך לא את תרבות הבטיחות של האב. האילוצים ששמרו על הסוכן הראשי זהיר עוברים דחיסה, סיכום או נמחקים לחלוטין במהלך ניהול חלון ההקשר (context window). סוכן המשנה מקבל משימה וערכת כלים, אך הוא לא מקבל את שעות ההנחיה (prompting) הקפדניות שקבעו את מגבלות הבטיחות (guardrails).

התוצאה היא סוג של אמנזיה ארגונית. כלל בטיחות שקיים ב-system prompt של סוכן האב יכול להיות כאילו אינו קיים עבור סוכן המשנה. זה מסוכן במיוחד מכיוון שסוכני משנה מקבלים בדרך כלל את סוג המשימות החזרתיות ובעלות ה"סטטוס הנמוך" שמפעילים מפסיקים לנטר מקרוב. אף אחד לא עוקב אחר משימת ניקוי לוגים עד שהיא מוחקת את מסד הנתונים של הייצור (production database).

הסכנה שבנחישות

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

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

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

איך לבנות הגנה אמיתית

אם המודל אינו שכבת הבטיחות