סקיל שנראה תמים יכול להפעיל הרשאות שכבר נתתם לסוכן

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

ממצאי הסריקות מדאיגים, אבל צריך לקרוא אותם בזהירות

בפברואר 2026 Snyk דיווחה שסקרה 3,984 סקילים ממאגרים ציבוריים. ב-1,467 מהם נמצאה לפחות בעיית אבטחה אחת, 534 סווגו עם ממצא קריטי, וחוקרי החברה אישרו 76 מטענים זדוניים. בעיית אבטחה יכולה להיות גם טיפול לא בטוח במפתחות או תלות חיצונית שלא נבדקה. לכן 1,467 אינו מספר הסקילים הזדוניים, ו-36.82% אינו סיכוי של משתמש להיפרץ.

התמונה הרחבה אינה מוגבלת למדגם אחד. ESET דיווחה כי בסריקה של יותר מ-800,000 סקילים מאז מרץ 2026, יותר מ-25,000 סומנו כחשודים ויותר מ-2,500 סווגו כזדוניים. אלה נתוני סריקה של החברה, בתקופה, באוכלוסייה ובשיטת סיווג שונות מאלה של Snyk. אין לחבר את האחוזים או להתייחס אליהם כמדד אחיד של הסיכון בכל סקיל.

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

גם סקיל שנבדק אתמול יכול לשנות התנהגות

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

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

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

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

אותו שם מוצר אינו אומר אותו מסלול תקיפה

כדי להבין את הסיכון במוצרים כמו ChatGPT, Claude ו-Gemini, צריך לזהות איזה רכיב היה מעורב בכל מקרה. ההדגמה של לירן טל עסקה ישירות בקובץ סקיל של Gemini CLI ובמה שהסוכן עשה לאחר שטען אותו. לעומתה, חוקרי Check Point תיעדו חולשות ב-Claude Code שנגעו לקובצי תצורה ול-hooks של פרויקט. לפי החוקרים, החולשות שתיארו תוקנו לפני פרסום המחקר בפברואר 2026. זהו גבול אמון קרוב, משום שקובץ בפרויקט עשוי להשפיע על פעולה, אך הוא אינו אותו סוג של אירוע כמו סקיל זדוני במאגר.

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

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

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

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

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

• אילו קבצים, כלים וחיבורי רשת זמינים לסוכן, ומה מתוכם נחוץ למשימה המסוימת.

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

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

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

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

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

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