האם OpenClaw מאובטח? הערכת סיכונים מעשית לעסק
סוכן שמבצע בדיוק את מה שביקשתם אינו בהכרח סוכן שמתאים לסיכון של העסק.
אם נתתם לו מראש גישה רחבה מדי, ציות מושלם לא יתקן את ההרשאות.
אבטחת OpenClaw תלויה בגרסה שמופעלת, במי ובמה שיכולים להגיע לסוכן, בהרשאות האפקטיביות שלו ובמנגנונים שאוכפים אותן.
אין כאן הבטחה גורפת, וגם אין בסיס להניח שכל התקנה נפרצה.
המדריך נבדק ב8 בספטמבר 2026.
נקודת הקצה הרשמית לגרסה היציבה האחרונה החזירה את v2026.9.2, שפורסמה ב5 בספטמבר 2026 בשעה 20:00:07 לפי UTC.
מספר הגרסה אינו תאריך הפרסום שלה.
לצורך בדיקת ברירות המחדל השתמשנו בתיעוד האבטחה שמוצמד לגרסה הזאת ובהערות הגרסה, ולא הנחנו שהתיעוד המתעדכן מתאים לכל התקנה קיימת.
המקרה בהמשך הוא תהליך עבודה להמחשה, לא סיפור הצלחה של לקוח ולא ביקורת אבטחה של המערכת שלנו.
לא מדדנו לצורך המאמר חיסכון בזמן, שיעור חסימת תקיפות, סיכוי לפריצה או תוצאה עסקית.
מה צריך לבדוק כשאומרים ״מאובטח״
הערכת סיכון שימושית מחברת בין נכס שמגינים עליו, פעולה שרוצים למנוע, מנגנון שאוכף את ההגבלה, ראיה שהמנגנון עובד ואדם שמתחזק אותו.
בסוכן שקורא מסמכים, הנכסים כוללים את קובצי המקור, פרטי הגישה, התשובות שנוצרות והיסטוריית השיחות.
פעולות לא רצויות כוללות קריאת מידע של צוות אחר, שליחת חומר ליעד שלא אושר או שינוי רשומה כשביקשו רק להכין טיוטה.
יש גם סיכונים שלא נראים כמו גניבת מידע.
סיכום משכנע שאין לו בסיס במקורות יכול להטעות מנהל, וריצה לא מוגבלת יכולה לצרוך תקציב או להשאיר תהליך חשוב תקוע.
אלה בעיות שונות, ולא פותרים את כולן באמצעות אותה הגדרה.
מערכת שמתאימה לסיכום מסמכי דמה אינה מקבלת אוטומטית אישור לבצע שינויים כספיים ללא השגחה.
מסגרת ניהול הסיכונים של NIST מציעה דרך רחבה לניהול סיכוני בינה מלאכותית.
היא אינה תעודת אבטחה למוצר או להגדרה מסוימת שלו.
בטיחות המודל ואבטחת המערכת הן שתי שכבות שונות
בטיחות המודל כוללת התנהגות כמו סירוב להוראות מזיקות והתנגדות לניסיון להסיט אותו מהמשימה.
אבטחת המערכת כוללת זיהוי משתמשים, הרשאות, בידוד תהליכים וקבצים, שמירת סודות, הגבלת תקשורת החוצה, אמינות תוספים והתאוששות מתקלות.
שכבות אלה משלימות זו את זו, אך אינן מחליפות זו את זו.
הנחיות OWASP להזרקת הוראות מבחינות בין הוראה שמגיעה ישירות מהמשתמש לבין הוראה שמסתתרת במקור חיצוני.
מסמך, אתר או קובץ מצורף יכולים להכיל טקסט שמנסה להפוך מחומר לקריאה להוראה לביצוע.
סימון הטקסט כלא מהימן מועיל, אבל אינו מוכיח שהמודל תמיד ישמור על ההבחנה.
גם מחקר אבטחת הדפדפן של Anthropic מ24 בנובמבר 2025 מציין במפורש שהזרקת הוראות אינה בעיה שנפתרה, למרות שיפור בהגנות.
שיעורי התקיפה שנמדדו שם תלויים במודל, בהגנות ובניסוי שנבדקו; הם אינם הסתברות לפריצה לOpenClaw.
מודל האיומים של OpenClaw בגרסה שנבדקה מסייע לזהות מסלולי תקיפה וסיכון שנותר אחרי ההגנות.
תיאור של איום אינו ראיה שהוא התממש בעסק שלכם.
וגם סיכון שנמצא מחוץ להגדרת דיווחי החולשות של הפרויקט עדיין יכול להיות סיכון תפעולי שצריך לטפל בו.
ברירות המחדל שכדאי להכיר בגרסה הזאת
התיעוד מגדיר גבול אמון אחד לכל Gateway, שער המערכת שמנהל את הסוכנים והכלים: אדם אחד או צוות שחבריו סומכים זה על זה.
הוא אינו מבטיח הפרדה קשיחה בין משתמשים עוינים שחולקים את אותו שער.
שמות סוכנים שונים וחלונות שיחה נפרדים אינם יוצרים את ההפרדה הזאת.
בהערות v2026.9.2 מופיע שינוי לברירת מחדל של גישה לכל השיחות ותקשורת רגילה פעילה בין סוכנים.
תיעוד האבטחה מדייק: לסוכנים עם כלים, שפועלים ללא בידוד, יש אפשרות לגשת לשיחות של סוכנים אחרים.
סוכנים מבודדים מוגבלים כברירת מחדל לעץ ההרצות שלהם, אבל ההגבלה הזאת אינה מסתירה את התמלילים שלהם מסוכן לא מבודד בעל גישה רחבה.
כשארגונים או משתמשים אינם סומכים זה על זה, ההמלצה הרשמית היא שערים ופרטי גישה נפרדים, ורצוי גם משתמשי מערכת הפעלה או מחשבים נפרדים.
עוד כמה הבחנות חשובות:
- התקנה רגילה על מחשב מארח מאזינה כברירת מחדל למחשב המקומי בלבד. תמונות הקונטיינר המתועדות משתמשות בברירת מחדל חשופה יותר, שצריך לשלב עם אימות גישה ומדיניות רשת מכוונת.
- ברוב ערוצי ההודעות, פנייה פרטית משולח לא מוכר עוברת זיווג לפני עיבוד ההודעה, אך קיימים חריגים לפי הערוץ.
- בידוד הכלים כבוי כברירת מחדל. עצם קיומן של הגדרות בידוד בקובץ אינו הוכחה שההרצה משתמשת בהן.
- בתצורה המיועדת למפעיל מהימן, הרצת פקודות על המארח מותרת ללא בקשות אישור. אל תניחו שיופיע מסך אישור אם המדיניות האפקטיבית אינה דורשת אותו.
אלה מאפייני הגרסה המצוטטת, לא ממצאים על המחשב שלכם.
לפני שמסתמכים על הגדרה, צריך לבדוק את המדיניות בפועל, את ההחרגות לכל סוכן ואת המקום שבו הכלי רץ.
מקרה להמחשה: סוכן שמכין תקציר תפעולי
נניח שצוות שירות רוצה לקבל בכל בוקר תקציר מתוך אוסף מסמכים שאושר מראש.
זהו ארגון דמיוני לצורך ההסבר; אין כאן שחזור של פרטי לקוח.
העבודה הידנית לפני הסוכן
עובד בוחר מסמכים רלוונטיים, מוודא שהם שייכים לתהליך הנכון, קורא אותם ומכין טיוטת תקציר.
אדם נוסף בודק את הטענות ומחליט אם צריך לשלוח הודעה או לעדכן מערכת אחרת.
הקושי העסקי הוא הקריאה והסיכום החוזרים, לא צורך מוכח לתת לתוכנה גישה חופשית לכל הקבצים והערוצים.
לפני שמוסיפים סוכן, כדאי לבדוק אם החיפוש, התבניות והדוחות שכבר קיימים במערכת המסמכים פותרים מספיק מהבעיה.
אם כלל חילוץ קבוע מספיק, תהליך דטרמיניסטי עשוי להיות פשוט יותר לבדיקה ולתחזוקה.
הפתרון המוצע והגבולות שלו
הסוכן מקבל חשבון או חיבור ייעודי לקריאה בלבד, שמוגבל לאוסף המקורות שאושר.
לא מחברים חשבון מנהל כללי רק כדי לקצר את ההקמה.
כל טענה בטיוטה צריכה להפנות למקור, ומידע חסר או סותר נשאר גלוי לבודק.
מתחילים ממסמכי דמה וממשטח שמאפשר הכנת טיוטות בלבד.
אם החיבור הנבחר אינו יודע לאכוף הגבלה לאוסף מסוים, יוצרים אוסף נפרד עם החומר המותר או משאירים את התהליך מחוץ לייצור עד שיש גבול שניתן לאכוף.
לסוכן המוצע אין יכולת לשלוח דואר, להעביר תשלומים, למחוק מידע או להתקין תוספים.
אם בהמשך מתגלה צורך אמיתי בפעולה חיצונית, מעבירים אותה לרכיב ביצוע נפרד שבודק יעד, תוכן והרשאה נוכחית.
סוכן נוסף עם שם אחר באותו שער בעל הרשאות רחבות אינו הפרדה מספקת.
הרכיב המבצע צריך גבול אמיתי ברמת הכלים, חשבון השירות או המארח.
זו הרחבה של העקרונות במדריך למעקב לקוחות עם סוכני AI: מעבר מבדיקת הפעולה שאושרה לבדיקת הסמכות שכדאי לתת לסוכן מלכתחילה.
כשמסמך מנסה לתת הוראות
גם מסמך שנמצא באוסף מאושר יכול להכיל טקסט לא מהימן, למשל בקשה לייצא מידע לא קשור או להתקין הרחבה.
המודל צריך להתייחס לטקסט כמידע, ובמקביל המערכת צריכה למנוע את הפעולה האסורה.
סוכן טיוטות שאין לו כלי ייצוא אינו יכול להשתמש בכלי הזה רק מפני שהמסמך ביקש.
אבל ההגבלה מועילה רק אם אין דרך אחרת להגיע לאותה יכולת, למשל הרצת פקודות חופשית או דפדפן שמחובר לחשבון בעל הרשאות רחבות.
בודקים את כל מסלולי הפעולה הזמינים, לא רק את הכלי שהתכוונו שהסוכן יפעיל.
בידוד, סודות ומידע שיוצא מהמערכת
תיעוד הבידוד מפריד בין סביבת הרצת הכלים לבין שער המערכת, שנשאר על המארח.
בידוד רגיל גם אינו חוסם אוטומטית מסלול יציאה להרצה מוגבהת שהותר במפורש.
במימוש הבידוד המתועד המבוסס על Docker, ברירת המחדל של הרשת היא none.
במימושים אחרים או אחרי שינוי הגדרות, ההתנהגות שונה.
אין להסיק מכך שלמערכת כולה אין תקשורת החוצה.
ספק המודל, שירות החיבורים, הדפדפן ושער המערכת יכולים לפעול בסביבות שונות ודרך מסלולי רשת שונים.
צריך למפות כל מסלול בנפרד.
התקנה עצמית קובעת היכן תוכנת הסוכן רצה, אבל מודל בענן או שירות חיצוני עדיין יכולים לקבל מידע.
בודקים איזה תוכן עובר לכל ספק, מה תנאי השמירה שלו, היכן נמצאים היומנים והגיבויים ואיך מוחקים מידע.
תיעוד הסודות של OpenClaw מתאר מנגנוני גישה נתמכים.
משתמשים באחסון מוגן ובפרטי גישה מוגבלים, ולא מדביקים אותם בשיחות או בקובצי המקור.
אחסון נכון מצמצם חשיפה מקרית, אבל אינו הופך פעולה מורשית בעלת סמכות עודפת לבטוחה.
גם הגבלת כתובות בדפדפן אינה חומת אש מלאה.
תיעוד האבטחה מציין שלא כל הפניה, בקשת רקע או מסלול תעבורה מכוסים בהגנות הניווט.
כשנדרשת אכיפה קשיחה של יעדים, משתמשים בבידוד רשת שבשליטת המפעיל או במתווך שאוכף מדיניות, ובודקים את המסלול המלא.
תוספים ושרשרת האספקה
הנחיות התוספים אומרות להתייחס להתקנת תוסף כמו להרצת קוד.
לפני הפעלה בודקים מי מפרסם ומתחזק אותו, מה המקור, איזו גרסה נבחרה, במה היא תלויה ואילו יכולות היא מוסיפה.
קיבוע גרסאות עוזר לשחזר התקנה, אך צריך גם בעל אחריות שבודק ומיישם תיקונים.
הקפאה של גרסה פגיעה אינה אסטרטגיית אבטחה.
קובץ הנחיות יכול להשפיע על התנהגות הסוכן; תוסף בזמן ריצה יכול להוסיף קוד ויכולות ביצוע.
שניהם מחייבים בדיקת מקור, אבל הם אינם אותו גבול טכנולוגי.
סריקה או הופעה בחנות הרחבות הן ראיות שכדאי לשקול, לא תחליף להבנת הקוד וההרשאות שנותנים לו.
בסוכן התקצירים המוצע, הרשאות ההתקנה נשארות מחוץ לתפקיד שלו.
שתי התרעות רשמיות ומה אפשר להסיק מהן
GHSA-52xj-c9p8-78cv פורסמה ב30 ביוני 2026 ומתארת אפשרות לחשיפת כלי בעלים להרצות של משתמשים שאינם בעלים דרך MCP loopback.
טווח גרסאות npm הפגיעות שמצוין בה הוא מ2026.5.20 ועד לפני 2026.6.6, והגרסה היציבה המתוקנת הראשונה היא 2026.6.6.
GHSA-wgq8-x5wm-g4rw, שפורסמה באותו יום, מתארת מסלולי התקנת תוספים שיכלו לדלג על מדיניות ההתקנה.
הטווח המצוין הוא מ2026.6.5 ועד לפני 2026.6.9, והגרסה היציבה המתוקנת הראשונה היא 2026.6.9.
בשתי ההתרעות ההשפעה המעשית תלויה בכך שהתכונה הרלוונטית מופעלת ונגישה לקלט ברמת אמון נמוכה יותר.
תאריך פרסום ההתרעה אינו תאריך פרסום גרסת התיקון.
אלה אינן ראיות לפריצה להתקנה מסוימת, וגם לא רשימה מלאה של כל ההתרעות.
לפני שימוש עסקי משווים את כלל ההתרעות העדכניות לגרסה המדויקת ולתכונות שמופעלות אצלכם.
לאחר עדכון מוודאים שהגרסה המתוקנת באמת רצה, מבצעים את האתחול או הטעינה מחדש הנדרשים וחוזרים על בדיקות ההרשאות.
אישור אנושי ואחריות בשירות מנוהל
אישורי הרצה עוזרים לשמור על כוונת המפעיל; הם אינם בידוד בין משתמשים עוינים.
בתהליך המוצע, הבודק רואה את הפעולה המדויקת, המקור, היעד והמידע שעומד לצאת.
אישור קבוע ורחב יכול לבטל את נקודת הבדיקה שבה אדם היה מבחין בפעולה חריגה.
בקשה שבוטלה, פגה או השתנתה מהותית צריכה החלטה חדשה בתהליך שמקיף את הסוכן.
אם אין מי שיאשר פעולה רגישה, היא נשארת חסומה.
בשירות מנוהל, עדכונים, גיבויים וניטור תשתית עשויים להיות באחריות הספק, לפי ההסכם בפועל.
האחריות לבחירת היקף המידע, אישור הפעולות והבנת המשמעות העסקית אינה עוברת אליו אוטומטית.
מבקשים ראיות להפרדת לקוחות, הגבלת גישת מפעילים, מסלולי מידע לספקים, מדיניות שמירה, דיווח על אירועים, בעלות על עדכונים ובדיקות שחזור.
בהתקנה עצמית מקצים את אותן אחריויות בתוך הארגון.
המילים ״מנוהל״ ו״מקומי״ אינן תוצאות של ביקורת אבטחה.
תוכנית בדיקה לפני הכנסת מידע אמיתי
זו תוכנית מוצעת, לא ניסוי שבוצע:
- מכינים קבוצת מסמכי דמה ומודדים את העבודה הידנית, כולל זמן הבדיקה והתיקונים.
- כוללים מסמכים רגילים, מקורות סותרים ומידע חסר, ובודקים שהטיוטה מבדילה בין עובדה לאי ודאות.
- מוסיפים הוראות בדיקה לא מזיקות שסותרות את המשימה, ומוודאים שהפעולה האסורה נחסמת בכלי או בשירות, לא רק מסורבת בטקסט.
- בודקים פנייה של משתמש לא מורשה ובקשה למסמך מחוץ לתחום, ומוודאים חסימת גישה בפועל.
- בודקים ניסיון פנייה ליעד שלא אושר באמצעות סימוני דמה, ובוחנים את ראיות הרשת בכל מסלול רלוונטי.
- מבטלים הרשאה, מבטלים אישור, עוצרים ריצה ומפעילים מחדש; בודקים התאוששות ללא פעולה כפולה ולא מכוונת.
מתעדים ניסיונות פעולה, חסימות שנאכפו, יעדים מותרים, נאמנות למקורות, עבודת הבודק והתנהגות ההתאוששות.
גם קבוצת בדיקות שעברה בהצלחה אינה הוכחה לעמידות מול כל תקיפה עתידית.
מתקדמים רק כשבעל האחריות מקבל את הסיכון שנותר וכשאפשר לתחזק את נוהל העבודה בפועל.
אם גבול המידע, בעל האחריות לעדכונים או הגבלת הפעולות עדיין אינם ברורים, נשארים עם מסמכי דמה או הכנת טיוטות בלבד.
ההחלטה הניהולית
מאשרים משימה מוגדרת עם הרשאות מוגדרות וראיות, לא ״OpenClaw לכל החברה״ כהרשאה בלתי מוגבלת.
כך אפשר להרחיב אחריות בהדרגה, בלי להתייחס לנימוס של המודל, למיקום המחשב או למסך סטטוס ירוק כהבטחת אבטחה.
להכוונה מעשית למנהלים שמעריכים תהליכים עם סוכנים, הגישו בקשת הצטרפות לניוזלטר למנהלים.
הבקשות נבדקות באישור אישי, ונדרש אימות כתובת הדוא״ל לפני קבלת גישה.
מקורות
אלפי בונים כבר בפנים. שאלות, פרויקטים, ומה שעובד באמת.
GPT-6 Astra: כל מה שצריך לדעת (מדריך 2026, דוגמאות אמיתיות, מחירים, ואיך אנחנו מטמיעים אותו בארגונים)
מה זה GPT-6 Astra, כמה הוא עולה, איך עובדת הפעלת המחשב, 12 דוגמאות אמיתיות עם זמן וכסף, ואיך אנחנו מטמיעים אותו בתוך ארגונים.
איך בונים ומעצבים משחקים עם GPT-6 Astra: 14 משחקים, טיל אחד ומשחק דארק סולס ב250 דולר
14 משחקים שנבנו עם GPT-6 Astra בשבוע אחד: כמה זמן זה לוקח, כמה זה עולה, אילו פרומפטים עבדו, למה המשחק היפה לא היה הכיפי, ומה נשאר לבן אדם.
אוטומציה למעקב לקוחות ב-CRM: מהצעה לביצוע מאומת
תהליך המחשה למעקב לקוחות עם סוכני AI: מקור לכל משימה, אישור אנושי, מניעת פעולות כפולות ובדיקת התועלת. בלי הבטחות לחיסכון שלא נמדד.