הגדרה: מה זה WASM, ולמה זה בכלל רלוונטי לבידוד-סוכנים
ארגז-חול מבוסס-WASM (WASM Agent Sandboxing) הוא טכניקת-בידוד שבה קוד או כלים שסוכן-AI מפעיל — למשל תוסף (plugin) שהסוכן קורא-לו, או קטע-קוד שהמודל עצמו כתב וצריך להריץ — רצים לא ישירות על המכונה המארחת, אלא בתוך זמן-ריצה (Runtime) של WebAssembly (WASM). WebAssembly הוא פורמט-קוד בינארי ניידי שתוכנן במקור להרצת-קוד-מהיר ובטוח בדפדפן, לצד JavaScript — אבל בזכות מודל-האבטחה שלו הוא הפך רלוונטי גם הרחק מהדפדפן, בשרתים ובכלי-פיתוח כלליים. כל מודול-WASM רץ בתוך "זיכרון-לינארי" משלו, מערך-בייטים נפרד לגמרי מזיכרון-המנוע ומהמחסנית של הסביבה-שמארחת אותו, וקוד-WASM לא יכול לגעת בזיכרון שמחוץ לגבול הזה — לא במקרה ולא בזדון. המפרט-עצמו קובע גם שקוד-WASM אינו יכול לגשת ישירות למבנה-המסמך (DOM) או למשאבי-מערכת חיצוניים כלשהם בלי לעבור דרך ממשק מוגדר-במפורש. בהקשר-סוכני-AI, זה אומר שאפשר לתת לסוכן להריץ קוד-שהוא-עצמו-כתב, או תוסף-צד-שלישי שהוא בחר להפעיל, בלי לסמוך על כך שהקוד הזה "ינהג יפה" — הבידוד נאכף ברמת-מבנה-הזיכרון עצמו, לא רק על-ידי בדיקה-חיצונית של מה שהקוד מנסה לעשות.
הבסיס הטכני: WASI ובידוד מבוסס-יכולות
מנגנון-מפתח שמשלים את בידוד-הזיכרון הוא WASI (WebAssembly System Interface) — ממשק שמוזילה פיתחה כדי לתת למודולי-WASM גישה מבוקרת למשאבי-מערכת-הפעלה (קבצים, רשת, שעון) גם מחוץ לדפדפן, בסגנון-פונקציונליות קרוב לזה שממשק POSIX המוכר נותן למערכות-הפעלה מסורתיות. WASI פועל לפי עיקרון "אבטחה מבוססת-יכולות" (Capability-Based Security): במקום שמודול-WASM "יבקש הרשאה" גורפת לגשת לכל מערכת-הקבצים, הוא מקבל מראש רק את ה"ידיות" (handles) הספציפיות למשאבים שהוגדרו לו במפורש — לדוגמה, גישה לתיקייה בודדת אחת, ולא לכל הדיסק, כך שגם אם הכלי עצמו ינסה לגשת לקובץ מחוץ לתיקייה שהוקצתה לו, הבקשה תיכשל ברמת-המערכת ולא רק תיחסם על-ידי בדיקה-לוגית בקוד. גרסת WASI 0.2, שיצאה בינואר 2024, הרחיבה את המודל עם "מודל-הרכיבים" (Component Model), שמאפשר הרכבה של מודולי-WASM שנכתבו בשפות-תכנות שונות זה עם זה, כולל תמיכה ברשת (שקעי TCP/UDP) תחת אותו מודל-הרשאות מבוסס-יכולות, אם כי מודל-הרכיבים הזה עדיין אינו נתמך בדפדפנים ומוגבל בעיקר לזמני-ריצה שרתיים כמו Wasmtime, Wasmer ו-WasmEdge — שלושתם פרויקטי-קוד-פתוח נפרדים שמיישמים את מפרט-ה-WASM/WASI, ומספקים לכל מפתח שרוצה לבנות ארגז-חול משלו בסיס מוכן ובדוק, במקום לממש מנגנון-בידוד ברמת-בייטים מאפס בעצמו. השילוב הזה — בידוד-זיכרון מובנה בשפה, פלוס הרשאות-משאבים גרנולריות ברמת-WASI — הוא מה שמאפשר בידוד "קל-משקל" יחסית: מודול-WASM עולה ויורד תוך מילישניות, לעומת שניות עד עשרות-שניות למכונה-וירטואלית מלאה.
דוגמה מוחשית: Wassette של מיקרוסופט
יישום מוחשי ותעשייתי של הרעיון הוא Wassette, פרויקט קוד-פתוח של מיקרוסופט המתאר את עצמו כ"זמן-ריצה מוכוון-אבטחה שמריץ רכיבי-WebAssembly דרך MCP" — כלומר, כלים שסוכני-AI מפעילים דרך פרוטוקול-הקשר-המודל (Model Context Protocol) רצים בפועל בתוך ארגז-חול מבוסס-WASM, ולא כתהליכים רגילים על המכונה המארחת. התיעוד של הפרויקט מנמק את הבחירה בשלוש סיבות: נוחות (הרחבת סוכני-AI בכלים חדשים בלי לצאת מממשק-הצ'אט, פשוט על-ידי הוספת רכיב-WASM נוסף); שימוש-חוזר (רכיבי-WebAssembly הם כלים גנריים שאפשר להריץ גם מחוץ להקשר-MCP הספציפי, בכל סביבה שתומכת ברכיבי-WASM); וביטחון — בציטוט ישיר מהתיעוד, הפרויקט מבוסס על "ארגז-החול של Wasmtime, שמספק בידוד ברמת-דפדפן לכלים" (Wasmtime הוא זמן-הריצה של WebAssembly שמפתחת Bytecode Alliance, ברית-קוד-פתוח שהוקמה ב-2019 על-ידי מוזילה, Fastly, אינטל ו-Red Hat). זהו ניסוח מדויק לרעיון המרכזי: אותה רמת-בטיחות שדפדפן-אינטרנט מספק כשהוא מריץ קוד-JavaScript לא-מהימן מכל אתר שאתה מבקר בו, מיושמת כאן על כלים שסוכן-AI מפעיל מטעם המשתמש — בלי לדרוש שכבת-בידוד-נוספת כמו מכולה או מכונה-וירטואלית סביב כל כלי בנפרד.
לעומת מה: בידוד ברמת-מערכת-ההפעלה (הדוגמה של Claude Code)
חשוב להבדיל בין הגישה הזו לבין בידוד ברמת-מערכת-ההפעלה, שהיא הגישה הנפוצה-יותר כיום בפועל למוצרי-סוכן מרכזיים. Claude Code, למשל — כפי שמתעד הפוסט ההנדסי של Anthropic מאוקטובר 2025 — בנוי "על גבי פרימיטיבים ברמת-מערכת-ההפעלה כמו bubblewrap בלינוקס ו-seatbelt במקאוס, כדי לאכוף את ההגבלות האלה ברמת-מערכת-ההפעלה" — כלומר בידוד קבצים ורשת שנאכף מחוץ לתהליך עצמו, בעזרת מנגנוני-בקרה של הקרנל, ולא בתוך מבנה-הזיכרון של הקוד שרץ. שתי הגישות פותרות בעיה דומה ממקום שונה: בידוד-OS מתאים במיוחד כשצריך להריץ תהליכים-מלאים ושרירותיים (למשל, קריאה לפקודת-shell כללית, או הרצת סקריפט שמשלב כמה כלי-מערכת יחד) ומגן מפני כל התוצר-הרץ מבחוץ-פנימה, בלי תלות בשפת-התכנות שבה נכתב הקוד; בידוד-WASM מתאים במיוחד כשהקוד-שרץ הוא כלי-ממוקד וידוע-מראש (תוסף, פלאגין, רכיב-MCP), ומגן מבפנים-כלפי-חוץ, ברמת-הזיכרון עצמו — ולכן קל יותר להריץ הרבה ממנו במקביל, וזול יותר בעלות-העלייה (Cold-Start) מאשר מכולה או VM, אם כי מוגבל לשפות ולתלויות שיש להן יעד-קומפילציה תואם-WASM.
יתרונות ומגבלות: מה WASM כן פותר וממה הוא לא מגן
המגבלה המרכזית של הגישה היא שהיא מגנה בעיקר על "הצד השני" — היא מונעת מהקוד-שרץ לפרוץ החוצה ולפגוע במערכת המארחת, אבל לא פותרת אוטומטית בעיות שקשורות למה שהקוד-עצמו עושה בתוך הגבולות שהוקצו לו (למשל, כלי-WASM שמקבל הרשאת-גישה-לרשת לגיטימית עדיין יכול לשלוח מידע-רגיש ליעד-לא-רצוי, אם ההרשאה שניתנה לו רחבה מדי או אם הכלי עצמו נכתב בכוונה-זדונית ומחכה רק להזדמנות לנצל את מה שכן הותר לו). כמו כן, לא כל קוד ניתן להריץ בקלות כמודול-WASM — שפות ומודלי-תכנות מסוימים דורשים התאמה (compilation target) ייעודית, ולא כל ספריית-תלות קיימת עדיין בגרסה תואמת-WASM, מה שעלול להגביל את מגוון-הכלים שאפשר לבודד בשיטה הזו בהשוואה לבידוד-OS הכללי-יותר. בגלל זה, בפועל, מערכות-סוכנים גדולות נוטות לשלב את שתי הגישות — בידוד-OS למשימות-כלליות ופתוחות, ובידוד-WASM לכלים ספציפיים, מוגדרים-היטב, שצריך להריץ בכמות גדולה ובעלות-נמוכה — במקום לבחור אחת מהן כפתרון-יחיד ומספיק לכל תרחיש-שימוש.
למה זה נהיה רלוונטי דווקא עכשיו: התפוצצות-כלי-הצד-השלישי בעידן ה-MCP
הצורך בבידוד קל-משקל וגרנולרי-לכל-כלי החריף בשנים האחרונות בעיקר בגלל אימוץ-רחב של פרוטוקולים כמו MCP, שמאפשרים לסוכן-AI להתחבר בקלות רבה לעשרות ואף מאות "שרתי-כלים" חיצוניים שכתבו צדדים-שלישיים שונים — שרשרת-אספקה שמערכת-בטיחות מסורתית לא תוכננה מלכתחילה להתמודד עם קנה-המידה שלה. כאשר כל כלי-חיצוני כזה עלול, תיאורטית, להיות מוזרק בתוכן-זדוני ("הרעלת-כלים", Tool Poisoning) או פשוט להתנהג באופן בלתי-צפוי, בידוד ברמת-כלי-בודד — ולא רק ברמת-תהליך-הסוכן-כולו — הופך לרלוונטי יותר: אם כל כלי-MCP רץ במודול-WASM נפרד, עם הרשאות-WASI מוגדרות-בדיוק לפי מה שהוא באמת צריך, אזי גם כלי שהתברר כזדוני או פגום לא יכול לגעת בנתונים או בכלים של כלים אחרים באותה מערכת, ולא רק במערכת-ההפעלה החיצונית לה. זו הסיבה המרכזית שפרויקטים כמו Wassette בונים את הגשר בין MCP ל-WASM באופן ישיר וכללי, ולא כפתרון-נקודתי לכלי בודד אחד — הם מתמודדים עם הבעיה הרחבה-יותר של "איך מריצים בבטחה כמות גדולה ומשתנה של כלי-צד-שלישי לא-מוכרים, בעלות סבירה, בלי לבנות תשתית-בידוד ייעודית מחדש עבור כל כלי בנפרד". ככל שסוכני-AI מתחברים ליותר שרתי-MCP חיצוניים בו-זמנית, גם עלות-התחזוקה של בידוד-ידני-לכל-כלי גדלה בהתאם — ומכאן החשיבות של תשתית-בידוד גנרית וסטנדרטית, שמפתח שמוסיף כלי חדש לא צריך להמציא מחדש בכל פעם.
לא ייחודי ל-AI: השורשים בעולם התוספים (Plugins) הכלליים
חשוב להבהיר שהרעיון של הרצת קוד-לא-מהימן בתוך WASM לא נולד עבור סוכני-AI כלל — הוא מוקדם יותר, ומקורו בצורך הכללי להריץ "תוספים" (Plugins) שכתבו צדדים-שלישיים בתוך אפליקציות ושירותים. Extism, למשל, פרויקט-הקוד-הפתוח שמתאר את עצמו כ"התשתית-רב-לשונית לבנייה עם WebAssembly", מציג את עצמו קודם-כל כ"מערכת-תוספים מוכנה-לשימוש" למפתחי-תוכנה בכלל, עם המוטו "להפוך כל תוכנה לתכנתית — להרחיב מבפנים", ומצהיר במפורש: "Extism נבנה עם אבטחה כעיקרון-יסוד, ומבודד-לחלוטין את הרצת-קוד-התוסף" — בלי שום התייחסות ייעודית ל-AI או לסוכנים בטקסט השיווקי שלו. מה שקרה בפועל הוא שסוכני-AI התגלו כמקרה-שימוש נוסף, ומתאים במיוחד, לאותה תשתית-בידוד קיימת: בשני המקרים — תוסף-כללי לאפליקציה, וכלי שסוכן-AI מפעיל — מדובר בקוד-חיצוני שהמערכת המארחת לא כתבה בעצמה, שצריך להריץ אותו בתדירות גבוהה ובעלות-נמוכה, ושרוצים להגביל בדיוק את מה שהוא יכול לגעת בו. זו הסיבה שפרויקטים כמו Wassette יכלו להתבסס ישירות על תשתיות WASM/WASI בוגרות ומוכחות (Wasmtime, Extism ודומיהם) במקום להמציא מנגנון-בידוד חדש מהיסוד עבור עולם-הסוכנים בלבד.