הבכורה של סדרת Mythos ומלכודת הראוטינג: כך נראית הארכיטקטורה החדשה של הגנת הסייבר

האירוע הארכיטקטוני

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

כדי להבין את גודל האירוע, צריך להפריד בין hype לבין תכנון הנדסי. אם Fable 5 הוא השער המסחרי הראשון למשפחת יכולות ברמת Mythos, הוא לא “עוד גרסה”. הוא מסמן מצב שבו ארגונים יכולים להשתמש במודלים עמוקים יותר למיפוי מערכות, ניתוח תלות, הבנת קוד ותכנון שכבות הגנה.

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

כלכלת הטוקנים ומלכודת הראוטינג

ההבטחה של Fable 5, כפי שהיא מוצגת בשיח סביב מודלי Mythos, היא יכולת לנתח ארכיטקטורות קוד מורכבות, להבין תלויות עמוקות במערכות הפעלה ולבצע משימות הגנתיות ברמה של אנליסט בכיר. תג המחיר שמוזכר בשוק משקף את זה: 10 דולר למיליון טוקני קלט ו־50 דולר למיליון טוקני פלט.

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

GPT-5.5-Cyber מול Fable 5: מלחמת המסגרות

בעוד חלק מהספקים מטילים מגבלות רוחביות על מודלי סייבר כדי להקטין סיכון, גישת GPT-5.5-Cyber כפי שהיא מתוארת בשיח הארגוני היא מסגרת של Trusted Access: לא סביבה פתוחה לכל שימוש, אלא גישה מותאמת לצוותי הגנה מאומתים, עם פחות סירובים בפעולות הגנתיות מורשות.

זו הבחנה חשובה. סייבר הגנתי אמיתי כולל זיהוי חולשות, ניתוח נוזקות, הנדסה לאחור, בדיקת exploitability ו־Patch Validation. אם המודל מסרב לכל מה שנראה “מסוכן” בלי להבין הקשר והרשאה, הוא לא מתאים לעבודה ארגונית עמוקה. מצד שני, אם אין בקרות, הוא הופך לסיכון בפני עצמו.

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

סוף עידן הקוד כיתרון: המעבר לאופרטורים

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

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

ארכיטקטורה מומלצת: לא מודל אחד, אלא מערכת הפעלה

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

1. מיפוי סביבתי עם מודל עומק

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

2. תשתית מבודדת מול Sandbox צרכני

סוכני סייבר אפקטיביים צריכים סביבת ריצה אמיתית אבל מוגבלת: VPC, שרת ייעודי, bare-metal, מעבדה מבודדת או סביבת on-premise עם הרשאות מדויקות. זו הסיבה שפרויקטים כאלה צריכים הטמעת AI עסקית ולא רק חיבור API מהיר.

3. אורקסטרציה מול מודל סייבר ייעודי

לאחר שהמערכת ממפה את הארכיטקטורה, שכבת האורקסטרציה מעבירה רק את המשימות המתאימות למודל סייבר ייעודי. שם נבדקים וקטורי התקיפה מול המפה שנבנתה, עם פחות רעש ויותר הקשר. זה מצמצם alert fatigue ומעלה את איכות ה־triage.

4. שכבת בקרה ואישור אנושי

כל פעולה שעלולה לשנות קוד, להריץ payload, לפתוח גישה או להשפיע על production חייבת לעבור review. כאן נכנסת שכבת שירות: policy engine, הרשאות, לוגים, אישורים ו־rollback. זה בדיוק ההבדל בין סוכן AI שימושי לבין סוכן מסוכן.

המשמעות לארגונים בישראל

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

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