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

המסגרת: בדיקות מורשות בלבד

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

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

סוכן סייבר אוטונומי הוא לא כפתור “פרוץ למערכת”

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

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

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

למה זה כבר לא תיאוריה ב־2026

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

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

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

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

שבע השכבות שהופכות מודל לסוכן שפועל בעולם

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

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

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

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

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

השכבה החמישית היא הזהות: OAuth, אסימון GitHub, חשבון שירות, מפתח ענן או צומת מחובר. מבחינת המערכת החיצונית, הסוכן פועל בשם הזהות הזאת.

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

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

כך נראית ביקורת קוד סוכנית עמוקה

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

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

בשלב הבא הסוכן מנסח השערות ניתנות לבדיקה. ממצא טוב אינו “הקוד נראה חשוד”. ממצא טוב אומר: מקור הקלט הוא X, הבקרה שאמורה לעצור אותו היא Y, הרכיב המסוכן הוא Z, ויש מסלול שמחבר ביניהם בתנאים האלה.

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

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

OpenClaw: שכבת תזמור, לא מערכת קסם לבעלות או תקיפה

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

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

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

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

שרשור סוכנים: למה זה משפר כיסוי וגם מגדיל סיכון

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

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

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

איך הסוכן יודע שהקוד או השרת באמת שלכם?

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

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

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

למה בקשות מסוימות נחסמות גם כשהכוונה לגיטימית

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

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

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

מערכת הבקרה היא מוצר האבטחה האמיתי

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

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

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

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

איך ליישם אפס אמון לסוכני AI

אפס אמון, או Zero Trust, לסוכנים אינו אומר “אל תסמכו על המודל”. הוא אומר משהו רחב יותר: אל תסמכו אוטומטית על אף רכיב בשרשרת — לא על המודל, לא על הכלים, לא על המיומנויות, לא על הזיכרון ולא על קלט שמגיע מבחוץ.

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

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

הנחות שגויות שכדאי להפסיק להאמין בהן

פלטפורמות וכלים בולטים סביב סוכני סייבר

אין פלטפורמה אחת שמתאימה לכל תרחיש. OpenClaw ו־Agent Zero הן מסגרות גמישות לבניית סביבת עבודה סוכנית. Shannon של Keygraph הוא כלי פתוח ופופולרי במיוחד לבדיקות חדירה לבנות־קופסה ליישומי ווב וממשקי תכנות, עם ניתוח קוד והרצת הוכחות ניצול. Codex מתאים יותר לעבודה עם קוד, סקירות, תיקונים וסביבת פיתוח. XBOW מתמקד בבדיקות יישומי ווב וממשקי תכנות. NodeZero מתמקד בתשתיות, זהויות, ענן ורשתות פנימיות.

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

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

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

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

המסקנה: לא שואלים רק מה הסוכן יודע, אלא מה הוא רשאי לעשות

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

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

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