מיקרוסופט: אל תריצו את OpenClaw על מחשבי עבודה רגילים

ב-19 בפברואר 2026 פרסם צוות המחקר האבטחתי של Microsoft Defender פוסט שכותרתו "הרצת OpenClaw בבטחה: זהות, בידוד וסיכון בזמן ריצה", ובו נתן המלצה שארכיון Orca AI Incident Archive אינו מתעד באף רשומה אחרת: יש להתייחס ל-OpenClaw כ"הרצת קוד לא מהימן עם אישורים מתמשכים", וכן "אין זה הולם להריץ אותו בתחנת עבודה אישית או ארגונית סטנדרטית". OpenClaw היא סביבת הרצה לסוכנים בהתארחות עצמית — המשתמש מתקין אותה במחשב שלו, מעניק לה חשבונות וטוקנים, ומאפשר לה להתקין מיומנויות ממרשם ציבורי ולפעול על טקסט שהיא קוראת מכל מקום. הטיעון של מיקרוסופט הוא ארכיטקטוני, לא דיווח באג: סביבת ההרצה מעבירה את נקודת ההרצה מקוד יישום סטטי לתוכן שמסופק בזמן ריצה, והבקרות סביב זהות, טיפול בקלט והרשאות לא זזו יחד איתה. הפוסט אינו מציין CVE, קמפיין או קורבן, ואינו מתעד שום פריצה. הרשומה המלאה נמצאת בOrca AI Incident Archive, שם היא מסווגת כרשומת מדיניות אבן דרך בדרגת ביטחון A וללא נזק אמיתי מתועד.

מה הפוסט אמר, ומה הוא לא אמר

הפוסט אורך קריאה של כ-12 דקות ואינו כולל כל מנגנון גילוי: אין מזהה CVE, אין טווח גרסאות מושפעות, אין build מתוקן, אין אינדיקטור לפשרה הקשור לפריסה אמיתית. Microsoft Defender Security Research מציין את Idan Hen כתורם. מה שכן יש בו הוא מודל איומים וכלל פריסה, ולכן הארכיון רושם אותו כרשומת מדיניות ולא כאירוע — מידע על חומרה, דירוג מהימנות A, ללא נזק אמיתי מתועד, תאריך ברמת דיוק של יום בודד.

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

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

• "פרטי התחברות ונתונים נגישים עלולים להיחשף או להיות מודלפים."

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

• "סביבת המארח עלולה להיפגע אם הסוכן יוסח לאחזר ולהריץ קוד זדוני."

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

שתי שרשראות אספקה, לולאת ביצוע אחת

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

"התקנת מיומנות היא בעצם התקנת קוד בעל הרשאות," נאמר בפוסט. מיומנויות "מתגלות ומותקנות לעתים קרובות דרך ClawHub, מאגר המיומנויות הציבורי של OpenClaw", ובפריסות מתירניות "ייתכן שסביבת ההרצה תורשה להריץ את תהליך ההתקנה ללא אישור אנושי." שרשרת האספקה השנייה מטופלת על ידי Moltbook, שאותו מתאר הפוסט כפלטפורמה ושכבת זהות ממוקדות סוכנים, שבה סוכנים מפרסמים, קוראים ומאמתים זהות דרך APIs — ולכן, בלשונו, "זרם עתיר-נפח של תוכן שתוקפים יכולים להשפיע עליו, שסוכנים צורכים לפי לוח זמנים." הדחיסות היא העיקר: "פוסט זדוני אחד יכול אפוא להגיע למספר סוכנים."

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

המיומנות המורעלת, בחמישה שלבים

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

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

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

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

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

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

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

העמדה המינימלית שמיקרוסופט תקבל

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

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

ההנחיה היא גם מפת מוצר

המחצית השנייה של הפוסט ממפה כל בקרה מומלצת למוצר של Microsoft: Microsoft Entra ID עבור הרשאה מינימלית וגישה מותנית על זהויות סוכנים, Microsoft Defender for Cloud Apps App Governance עבור מלאי OAuth וסחיפת הסכמה, Microsoft Defender for Endpoint עבור מארח הסוכן, Microsoft Defender XDR עבור קורלציה, Microsoft Purview עבור מניעת אובדן נתונים בנקודות קצה, Microsoft Defender for Cloud עבור יציאת רשת, ו-Microsoft Sentinel היכן שנדרשים שימור ארוך יותר או אוטומציה. זו פרקטיקה רגילה עבור בלוג אבטחה של ספק, וראוי גם לומר זאת בפשטות: המסמך שממליץ להכיל סביבת ריצה של סוכן צד שלישי מתפרסם על ידי חברה שמוכרת את ההכלה.

תוכן הציד הוא החלק ששורד את המסגור הזה, משום שהוא ספציפי. הפוסט מספק שאילתות KQL מול טבלאות Defender XDR — DeviceProcessEvents, CloudProcessEvents, DeviceFileEvents, DeviceNetworkEvents ו-OAuthAppInfo — שמחפשות שורות פקודה של תהליכים ושמות קבצים המכילים "openclaw", "moltbot" או "clawdbot", וכן מחפשות עבור clawhub install — הפעלות עם מזהי מיומנות נדירים, שינויים תכופים בתיקיות ההרחבות בנקודות קצה של מפתחים, אפליקציות OAuth חדשות בעלות הרשאות גבוהות, שירותים מאזינים שנפתחו על ידי תהליכי סוכן, וסביבות ריצה של סוכן שמזנקות cmd.exe, powershell.exe, pwsh.exe, bash, sh, curl או wget. יהיה מה שיחשבו על מיפוי המוצר, השאילתות האלה ניתנות להרצה על ידי כל לקוח Defender XDR ביום הפרסום, והן אינן מניחות ידע מוקדם לגבי אילו מארחים מריצים את סביבת הריצה.

מה מבוסס, ומה לא

מבוסס ומאומת: Microsoft פרסמה את הפוסט ב-19 בפברואר 2026, והציטוטים לעיל לקוחים ממנו. Cybernews דיווחה על האזהרה ב-23 בפברואר 2026 ו-TechRadar ב-24 בפברואר 2026, כששתיהן חוזרות על שני המשפטים המרכזיים ועל הנחיות הבידוד במקום לבחון אותם. חיפושים חוזרים לא העלו סיקור ב-The Register, ב-BleepingComputer, ב-Wired או ב-TechCrunch, כך שגל התקשורת סביב הפוסט הזה היה קטן ונגזר; אף גורם עצמאי לא פרסם בדיקה של הטענה הארכיטקטונית של Microsoft, והאימות הזמין מאשר את מה ש-Microsoft אמרה, לא אם היא צודקת.

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

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

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