אני עוקב אחר עולם ה Skills מהרגע שבו התחיל לקבל צורה החל מהימים הראשונים של OpenClaw, ומאז אני רואה כיצד הוא מתפתח ממנגנון פשוט שמלמד את הסוכן כיצד להשתמש בכלים, לרכיב בעל משמעות ארכיטקטונית ואבטחתית עמוקה הרבה יותר. בתחילת הדרך Skill נתפס בעיקר כדרך להרחיב את היכולות של הסוכן באמצעות קובץ SKILL.md שמגדיר הוראות, הקשר ואופן שימוש בכלים, אבל עם התפתחות המערכת, מנגנוני טעינה, היררכיית Skills, מקורות חיצוניים, מאגרי Skills ויכולת להרכיב מספר Skills בתוך אותה משימה.
בעיני תוקף, Skill הפך בהדרגה מנגנון הרחבה פשוט לוקטור תקיפה שמסוגל להשפיע על הקוד שהסוכן מריץ, על ההקשר שממנו הוא מקבל החלטות, על הכלים שהוא מפעיל ובסופו של דבר גם על הזהות שבאמצעותה הוא ניגש למשאבים ארגוניים.
הפער בין מיפוי למציאות של Skills
הדאטהסטים שמתפרסמים ב Hugging Face כמו אחרים רבים חושף פער משמעותי בין הדרך שבה חלק מהתעשייה מדמה תקיפות נגד סוכני AI לבין הדרך שבה תוקף עשוי לבחון סביבה אמיתית. חלק גדול מהמחקר מתמקד בהזרקת הוראות, עקיפת מנגנוני הגנה וגרימת סטייה מההנחיה המקורית, אך מנקודת מבט התקפית מדובר רק בשלב אחד בתוך שרשרת תקיפה רחבה יותר.
תוקף אינו חייב לתקוף את המודל ישירות והוא יכול למפות את ה Skills הזמינים, מקורות המידע, סביבת ההרצה, הכלים, ההרשאות והזהות שבה הסוכן משתמש, ולאחר מכן לחפש נתיב שמחבר בין הרכיבים האלה. השאלה אינה רק האם ניתן להזריק הוראה, אלא האם אפשר להשפיע על ההקשר, לגרום לסוכן להפעיל Skill מסוים, להעביר מידע בין יכולות ולנצל הרשאות קיימות.
כאן נמצאת גם הראייה הצרה של חלק מהוונדורים. מנגנון שמזהה הזרקת הוראות עשוי לחסום קלט ישיר, אך לא בהכרח לזהות תוכן זדוני שמגיע דרך פלט של כלי, Skill, מקור חיצוני או זיכרון ארוך טווח. אף רכיב בודד אינו חייב להיראות זדוני, אבל כאשר הסוכן מחבר בין יכולות לגיטימיות, הוא עלול ליצור נתיב תקיפה שמוביל מאיסוף מידע ועד לביצוע פעולה באמצעות זהות ארגונית בעלת הרשאות.
מבחינתי, זהו הפער המרכזי במחקר הנוכחי. ההתמקדות עדיין נמצאת לעיתים קרובות בהנחיה עצמה, בזמן שמשטח התקיפה האמיתי נמצא בכל שרשרת הפעולה של הסוכן, מהקלט וההקשר ועד ל Skills, לכלים, להרשאות ולזהות שמבצעת את הפעולה בפועל.
מה חסר מבחינתי? הרבה, ועדיין זה מאמר קצר אז מעלה כמה סוגיות מוכרות.
- חוסר איזון בין המקורות ומודגש כי רוב הזהויות מגיעות מ MalSkillBench או SkillTrustBench.
- טקסונומיית התקיפה חלקי שמכסה משהו כמו 66% מהסוגי תקיפות, ויותר משליש מהזדוניים ללא סיווג תקיפה ולכן זה מגביל הערכה ברמת קטגוריה.
- אמינות התיוג לא נמדדת ושדות רבים כמו ה provenance מלאים ב mixed_unresolved או human+runtime, כלומר תוויות רבות לא הוכרעו ואין הערכת של רעש או תיוג.
- מדגיש סקילים סטטיים בלבד וזה אומר שחסרים כאן וקטורים שלמים שבודק אבטחה היה מצפה להם.
זה למעשה מסביר את התמונה כולה על אבטחת סוכנים ואת העובדה שאין ממש מסגרות מדוייקות או תהליכים שיכולים למפות את כל סיכוני האבטחה. עדיין, יש מסגרות שונות כולל OWASP TOP AI Agent שבו Skills מוזכרים. משם בדקתי benchmark וזה היה פחות או יותר משעשע כי במקרה הזה ה benchmark חושף שאין יישום עקבי של מסגרת אחת.
אז אם מתסכלים על מספרי הכיסוי של מסגרות שונות אז יש מיפוי מינורי עם severity נמוך וכל אחד עם טקסונומיה, evidence regime ו labeling policy משלו וזה עד שנאלצים לבנות harmonized taxonomy רק כדי לדבר בשפה אחת. במקרה כזה גם אחרי ההרמוניזציה, שליש מהדאטה נשאר ללא מיפוי ולכן זו עדות ישירה לפרגמנטציה שאני מדבר עליה ביומיום.
מכאן זה לוקח אותי להבנה רחבה יותר של הפערים וחוסר הדיוק הקיימים כיום בהגנה על Skills. ככל שמעמיקים בניתוח משטח התקיפה, מתברר שהגנה על Skill בודד אינו מספיק כאשר הסיכון האמיתי נוצר מהקשר, משרשור יכולות, ממקורות מידע, מהרשאות ומהזהות שבה הסוכן משתמש. התמקדות בזיהוי קוד זדוני או בהזרקת הוראות בלבד עלולה להשאיר מחוץ לתמונה את נתיב התקיפה המלא, שבו Skill לגיטימי הופך לחלק משרשרת שמאפשרת לתוקף להשפיע על הסוכן ולנצל את היכולות שכבר הוענקו לו. מי אמר התקפה רב שכבתית באמצעות Skills?
הקדמה
כידוע, סוכני AI שינו/משנים את הדרך שבה מערכות מקבלות החלטות ומבצעות פעולות. בניגוד למודל שמקבל קלט ומחזיר תשובה, סוכן מודרני מסוגל לקרוא מידע ממערכות ארגוניות, להפעיל כלים, לגשת לממשקי תכנות, להריץ קוד, לשמור מידע בזיכרון ולבצע פעולות באמצעות זהות שמחזיקה הרשאות אמיתיות בסביבת הארגון. היכולת הזאת הופכת את הסוכן למערכת שימושית וגמישה, אבל במקביל היא יוצרת משטח תקיפה חדש שבו קוד, מידע, הקשר, כלים וזהות מתחברים למנגנון אחד שמסוגל לבצע פעולות בעולם האמיתי.
כדי להרחיב את היכולות של סוכן, משתמשים ב Skills. כידוע, Skill יכול להוסיף לסוכן יכולת לקרוא קבצים, לבצע שאילתות, לנתח מידע, לגשת לשירות חיצוני או להפעיל קוד מקומי. מנקודת מבט של פיתוח, מדובר במנגנון הרחבה טבעי שמאפשר לבנות סוכן מודולרי וגמיש. מנקודת מבט של אבטחה, כל Skill מוסיף רכיב נוסף שאפשר לתקוף, להשפיע עליו או להשתמש בו כחלק משרשרת תקיפה רחבה יותר.
הנקודה החשובה היא שהסיכון אינו נמצא בהכרח בתוך Skill אחד. Skill יכול להיות תקין לחלוטין בפני עצמו ועדיין להפוך לחלק מנתיב תקיפה כאשר הוא מחובר ל Skills אחרים, למידע חיצוני, לזיכרון או לזהות בעלת הרשאות. תוקף אינו חייב להשתלט על כל המערכת כדי להשיג השפעה משמעותית. מספיק שהוא יצליח לשלוט באחד מהקלטים שהסוכן סומך עליהם, לשנות את ההקשר שבו הסוכן מקבל החלטות או לגרום לו לחבר מספר יכולות לגיטימיות בצורה שלא תוכננה על ידי הארגון.
מכאן מגיע שינוי משמעותי באופן שבו צריך להסתכל על אבטחת סוכני AI. במקום לבדוק רק אם הקוד של Skill בטוח, צריך להבין מה קורה כאשר הסוכן מפעיל אותו, באילו הרשאות הוא פועל, איזה מידע הוא יכול לקרוא ולהחזיר, כיצד הפלט שלו נכנס להקשר, אילו Skills אחרים הסוכן יכול להפעיל לאחר מכן ואיזו זהות מבצעת בסופו של דבר את הפעולה מול מערכת היעד.
במאמר הזה אני בוחן את Skill כ־Execution Vector ולא רק כרכיב תוכנה נוסף. המטרה היא למפות את משטח התקיפה מנקודת מבט של חוקר אבטחה ותוקף, ולהראות כיצד תקיפה יכולה להתחיל בקוד או בתלות תוכנה, לעבור דרך ההקשר והזיכרון של הסוכן, ולהסתיים בניצול זהות עננית בעלת הרשאות אמיתיות.
וקטור תקיפה בתוך סביבת הסוכן
כאשר Skill מסוגל להריץ קוד, הוא מקבל משמעות שונה לחלוטין מתוסף תוכנה שמספק מידע בלבד. ברגע שהסוכן מפעיל את ה Skill, הקוד שלו רץ בתוך סביבת ההרצה של הסוכן ולעיתים מקבל גישה לאותם משאבים שהסוכן עצמו יכול לגשת אליהם. סביבת ההרצה יכולה לכלול מערכת קבצים, חיבורי רשת, משתני סביבה, קובצי תצורה, סודות, אסימוני גישה וזהויות ענן, ולכן פגיעה ב Skill יכולה להפוך מהר מאוד מפגיעה ברכיב מקומי לנתיב גישה למערכות נוספות.
תוקף שמצליח להכניס קוד זדוני ל Skill אינו חייב לגרום לסוכן להפעיל פקודה שנראית חשודה. תרחיש מעניין יותר הוא Skill שמבצע את הפעולה שלשמה הוא נועד ובמקביל מבצע פעולות נוספות שאינן חלק מהפונקציונליות שהמשתמש רואה. Skill שמיועד לניתוח קובץ יכול, לדוגמה, לקרוא במקביל משתני סביבה, לבדוק קובצי תצורה, לזהות אישורים זמינים או לאסוף מידע על סביבת ההרצה. אם הפעולות האלה מבוצעות כחלק מהתהליך הרגיל של Skill, הסוכן עצמו עלול שלא לזהות שהתרחשה חריגה.
מבחינת תוקף, זהו יתרון משמעותי משום שההרצה אינה חייבת להיראות כמו פעילות התקפית קלאסית. הסוכן מפעיל את Skill כחלק ממשימה לגיטימית, ה Skill משתמש בהרשאות הזמינות לו, והמערכת יכולה לראות רצף של פעולות שנראות לכאורה הגיוניות. רק כאשר מנתחים את ההתנהגות ברמת הנתונים וההקשר אפשר לזהות שה Skill השתמש בהרשאות שלו כדי לבצע פעולה שלא הייתה קשורה למטרה המקורית.
הסיכון הופך משמעותי יותר כאשר סביבת הסוכן מחוברת לשירותי ענן. אם הסוכן פועל באמצעות זהות מנוהלת, זהות שירות, אסימון הרשאה או מנגנון הזדהות אחר, Skill שרץ בתוך אותה סביבה עשוי לנסות להשתמש ביכולת שהסביבה כבר מספקת לו. במקרה כזה, התוקף אינו חייב לגנוב סיסמה או לבצע ניצול חולשה מול שירות ענן. הוא יכול לנסות להשתמש בזהות שכבר קיבלה הרשאה ולגרום לה לבצע פעולות בשמו.
מכאן נובע עיקרון חשוב עבור צוותי Red Team / Blue Team כאחד. יש לבחון Skill לא רק לפי הפעולה שהוא אמור לבצע, אלא לפי הפעולות שהקוד שלו מסוגל לבצע בתוך סביבת ההרצה. ההבדל הזה משמעותי מאוד, משום שיכולת תמימה ברמת הממשק יכולה להפוך ליכולת מסוכנת ברמת מערכת ההפעלה, הרשת או הענן.
הרעלת שרשרת האספקה
גם כאשר הקוד הראשי של Skill נקי, עדיין קיים משטח תקיפה משמעותי בשרשרת התלויות שלו. Skill יכול להסתמך על ספריות, חבילות תוכנה ורכיבים חיצוניים שמותקנים לפני ההרצה או נטענים בזמן העבודה, ולכן תוקף שמצליח לפגוע באחד מהרכיבים האלה יכול לקבל Execution מבלי לשנות את Skill עצמו.
זהו תרחיש מוכר מעולם אבטחת התוכנה, אבל סביבת סוכן הופכת אותו למעניין יותר משום שהרכיב שנפגע אינו בהכרח רץ בתוך יישום מבודד. הוא יכול לרוץ בתוך מערכת שמחזיקה חיבור למערכות ארגוניות, גישה למידע וזהות עננית. המשמעות היא ששרשרת אספקה שנראית בתחילה כמו בעיית תוכנה מקומית יכולה להפוך לנתיב שמוביל לגישה למידע ארגוני או לשירותים בענן.
מנקודת מבט של תוקף, אחת הבעיות המעניינות היא שהארגון עשוי לבצע בדיקה של הקוד הראשי של Skill ולהתעלם מהתנהגות התלויות בזמן הרצה. בדיקת קוד סטטית יכולה לזהות בעיות רבות, אבל היא אינה בהכרח מספיקה כדי לזהות רכיב שנראה תקין בקוד אך מבצע פעולה חריגה לאחר שהמערכת מתחילה לפעול.
לכן, אבטחת Skill צריכה לכלול גם ניהול שרשרת אספקה, חתימת חבילות, הגבלת מקורות התקנה, נעילת גרסאות, ניתוח תלויות וניטור התנהגות בזמן הרצה. כאשר Skill מקבל גישה לסביבת עבודה שמחזיקה זהות ארגונית, כל רכיב שהוא טוען צריך להיחשב כחלק ממשטח התקיפה ולא כפרט מימוש פנימי שאפשר להתעלם ממנו.
מניפולציה של ההקשר
התקפה על Skill אינה חייבת להתבצע ברמת הקוד. למעשה, אחת הדרכים המעניינות יותר לתקוף סוכן היא להשפיע על ההקשר שממנו הוא מקבל את ההחלטות. סוכן מודרני אינו מקבל החלטה רק על בסיס ההנחיה המקורית של המשתמש. הוא משלב הוראות מערכת, תיאורי כלים, תוצאות של Skills, מידע ממקורות חיצוניים, נתונים שנשלפו מהזיכרון ולעיתים גם מידע שמגיע מסוכנים אחרים.
כל אחד מהמקורות האלה יכול להפוך לקלט שמשפיע על תהליך קבלת ההחלטות. הבעיה היא שסוכן אינו מפריד תמיד בצורה קשיחה בין מידע שצריך לקרוא לבין הוראה שצריך לבצע. אם תוכן שנכנס להקשר מנוסח בצורה שמבקשת מהסוכן לבצע פעולה מסוימת, הוא עלול להתייחס אליו כחלק מהמשימה ולהשתמש בו בהחלטה הבאה.
מכאן נוצר משטח תקיפה חדש שבו התוקף אינו מנסה לשבור את מנגנון ההרשאות או את הקוד. הוא מנסה לשנות את ההחלטה שהסוכן עצמו יקבל.
הזרקת הוראות דרך תיעוד Skill
תיעוד של Skill יכול להיראות כמו רכיב לא מזיק משום שמדובר בטקסט שמסביר כיצד להשתמש ביכולת מסוימת. בפועל, כאשר הסוכן קורא את התיעוד ומשתמש בו כדי להבין מתי וכיצד להפעיל את Skill, התוכן הזה הופך לחלק מההקשר שמשפיע על ההתנהגות שלו.
אם תוקף מצליח לשנות את קובץ התיעוד או להכניס לתוכו הוראות מוסתרות, הוא יכול לנסות לבצע חטיפת מטרה. הסוכן מתחיל עם משימה מוגדרת, קורא את הוראות ה Skill, מקבל מהן הנחיה נוספת ומחליט שהפעולה החדשה היא חלק מהמשימה המקורית. במקרה כזה, לא היה צורך לשנות את קוד הסוכן ולא היה צורך לפרוץ למודל עצמו. התוקף פשוט שינה את המידע שעליו הסוכן מסתמך כאשר הוא מחליט מה לעשות.
זהו הבדל מהותי בין תוכנה מסורתית לבין מערכת שמבוססת על סוכן. בתוכנה מסורתית, קובץ תיעוד בדרך כלל אינו חלק ממנגנון קבלת ההחלטות בזמן הרצה. אצל סוכן, תיעוד יכול להיכנס ישירות להקשר ולהשפיע על הפעולה הבאה. לכן, מרגע ש Skill הופך לחלק ממנגנון קבלת ההחלטות, גם התיעוד שלו צריך להיכלל במודל האבטחה.
הזרקת תוכן דרך פלט של כלי
אותה בעיה יכולה להתרחש גם כאשר התוכן מגיע דרך כלי לגיטימי. סוכן יכול להפעיל Skill שמבצע בקשה לממשק תכנות, לקבל תשובה ולהכניס אותה להקשר. מבחינת המערכת, מדובר בתהליך תקין לחלוטין. הבעיה מתחילה כאשר התוקף מצליח להשפיע על התוכן שמוחזר מהמערכת החיצונית.
במקום לתקוף את הסוכן ישירות, התוקף גורם למקור חיצוני להחזיר תוכן שמנסה להשפיע על ההחלטה הבאה. התוכן עובר דרך Skill, נכנס להקשר, מעובד על ידי הסוכן ולאחר מכן יכול לגרום לו להפעיל כלי נוסף. כך מתקבלת שרשרת שבה מקור חיצוני הופך בפועל למקור הוראות עקיף עבור הסוכן.
המשמעות מבחינת אבטחה היא שכל פלט של כלי צריך להיחשב קלט בלתי מהימן. גם אם הכלי עצמו מאובטח, גם אם החיבור אליו מוצפן וגם אם ההרשאות שלו מוגבלות, עדיין צריך לבדוק האם התוכן שהוא מחזיר יכול להשפיע על החלטות הסוכן ולגרום לו לבצע פעולה שלא הייתה אמורה להתבצע.
שרשור בין Skills
אחת הבעיות המעניינות ביותר בסביבת סוכן היא שלא תמיד אפשר להבין את רמת הסיכון של Skill כאשר בוחנים אותו בנפרד. Skill אחד יכול לקרוא קבצים, Skill אחר יכול לשלוח מידע החוצה, ו Skill שלישי יכול לבצע שאילתות מול שירות ענן. כל אחד מהם יכול לעבור בדיקת אבטחה בפני עצמו משום שאין לו לבדו את היכולת לבצע את התקיפה המלאה.
הבעיה נוצרת כאשר הסוכן מחבר ביניהם. אם Skill אחד קורא מידע רגיש, Skill שני מעבד אותו ו Skill שלישי מסוגל לשלוח מידע ליעד חיצוני, הסוכן יכול להפוך את שלוש היכולות האלה לשרשרת תקיפה אחת. אף Skill אינו בהכרח זדוני, ואף אחד מהם אינו בהכרח מפר את ההרשאות שהוגדרו לו, אבל החיבור ביניהם יוצר יכולת חדשה שלא נבחנה כאשר כל אחד נבדק בנפרד.
זהו למעשה מעבר מאבטחת כלי לאבטחת נתיב פעולה. במקום לשאול מה כל Skill יכול לעשות, צריך לשאול מה הסוכן יכול להשיג כאשר הוא מחבר מספר Skills בהתאם להקשר ולמטרה שהוא מנסה להשיג.
מבחינת צוות אדום, זו נקודה קריטית בבדיקת סוכן. יש לחפש לא רק חולשות בכל כלי, אלא גם שילובים של יכולות שמאפשרים מעבר בין מקורות מידע, עיבוד מידע ופעולות חיצוניות. דווקא היכולת של הסוכן לבחור את רצף הפעולות הופכת את השרשור הזה למסוכן, משום שהתוקף יכול לנסות להשפיע על ההקשר ולגרום לסוכן לבחור את הנתיב הרצוי.
הרעלת זיכרון
הזיכרון מאפשר לסוכן לשמור מידע ולהשתמש בו במשימות עתידיות, אבל אותה יכולת יוצרת מנגנון התמדה חדש. תוקף שמצליח להכניס מידע זדוני לזיכרון אינו בהכרח צריך לבצע את הפעולה באותו רגע. הוא יכול להשאיר מידע שנראה לגיטימי, להמתין עד שהסוכן ישלוף אותו במשימה עתידית ולנסות לגרום לאותו מידע להשפיע על ההחלטה הבאה.
זה שונה מהתמדה מסורתית שבה התוקף משאיר שירות, משימה מתוזמנת או קוד זדוני על מערכת ההפעלה. במקרה של סוכן, התוקף יכול להשאיר מידע שהסוכן עצמו ישמור וישלוף בעתיד. כאשר אותו מידע חוזר להקשר, הוא יכול להשפיע מחדש על ההתנהגות של הסוכן ולהפוך את הזיכרון למנגנון שמחזיר את התקיפה לחיים.
מנקודת מבט של חוקר אבטחה, זהו אחד הווקטורים המעניינים ביותר משום שהוא מטשטש את הגבול בין מידע לבין שליטה. אם תוכן שנשמר בזיכרון מסוגל לשנות את הפעולות שהסוכן מבצע, אז הזיכרון אינו עוד מאגר נתונים בלבד. הוא הופך לרכיב שמשפיע ישירות על מנגנון קבלת ההחלטות.
לכן, ארגון שמפעיל סוכנים צריך לדעת מי כתב כל פריט מידע לזיכרון, מאיזה מקור הוא הגיע, מתי הוא השתנה, מתי הוא נשלף ומה קרה לאחר השליפה. ללא הקשר הזה, קשה מאוד לזהות מצב שבו מידע שנראה תמים בנפרד הופך לחלק מנתיב תקיפה כאשר הוא משולב עם פעולה אחרת של הסוכן.
חטיפת זהות הסוכן
חטיפת זהות הסוכן יכולה להיות מ Skill Compromise לגישה לענן
היעד המשמעותי ביותר אינו תמיד סביבת ההרצה של הסוכן. במקרים רבים, היעד האמיתי הוא הזהות שבאמצעותה הסוכן מבצע פעולות. סוכן שמחובר לשירותי ענן יכול להשתמש בזהות מנוהלת, בזהות שירות, באסימון הרשאה או במנגנון אחר שמאפשר לו לפעול בשם חשבון או יישום ארגוני.
אם תוקף מצליח להגיע לסביבת ההרצה ולגשת לאישורים האלה, הוא יכול לנסות לעבור מפגיעה ב Skill לפגיעה בזהות. בשלב הזה, התקיפה כבר אינה מוגבלת לסוכן עצמו. אם האישור מאפשר גישה ישירה לשירות ענן, התוקף יכול לנסות להשתמש בו כדי לבצע פעולות מחוץ לסביבת הסוכן.
קיים גם תרחיש מסוכן יותר שבו התוקף אינו צריך לגנוב את האישור כלל. במקום לגנוב את הזהות, הוא יכול לגרום לסוכן להשתמש בה בצורה שלא תוכננה. אם הסוכן מחזיק הרשאות רחבות מדי, מניפולציה של ההקשר יכולה לגרום לו לבצע פעולה לגיטימית מבחינת ההרשאות, אך זדונית מבחינת המטרה.
זהו הבדל חשוב בין גניבת זהות לבין ניצול זהות. בגניבת זהות התוקף מנסה להשיג את האישור ולהשתמש בו בעצמו. בניצול זהות התוקף גורם לבעל הזהות לבצע עבורו את הפעולה.
שרשרת התקיפה המלאה: קוד, הקשר, Skills וזהות
כאשר מחברים את כל שכבות התקיפה, מתקבלת תמונה שבה Skill יכול להיות רק השלב הראשון בשרשרת ארוכה הרבה יותר. תוקף יכול להתחיל ב Skill שנפגע בשרשרת האספקה, לקבל הרצת קוד בתוך סביבת הסוכן, לזהות אישורים זמינים, להשפיע על מידע שנכנס להקשר ולגרום לסוכן להפעיל Skill נוסף שמאפשר גישה למערכת חיצונית.
הייחוד של תקיפה כזו הוא שכל שלב יכול להיראות לגיטימי כאשר הוא נבדק בפני עצמו. קריאת קובץ יכולה להיות פעולה תקינה, שימוש בממשק תכנות יכול להיות חלק מהמשימה, הפעלת Skill נוסף יכולה להיות החלטה לגיטימית של הסוכן ושימוש בזהות הענן יכול להיות בדיוק מה שהמערכת תוכננה לעשות. הבעיה מתגלה רק כאשר מחברים את האירועים לנתיב אחד ומבינים כיצד מידע שנקרא בשלב הראשון הפך לקלט לפעולה בשלב האחרון.
זו הסיבה שמערכת הגנה עבור סוכני AI צריכה לעבור ממודל שמזהה אירועים בודדים למודל שמבין רצפי פעולות ונתיבי תקיפה. צריך לדעת מי הפעיל את Skill, איזה מידע נכנס להקשר, איזה כלי הופעל לאחר מכן, איזו זהות ביצעה את הפעולה, לאיזה יעד נשלח המידע והאם הפעולה תואמת את המטרה המקורית של המשימה.
איך צריך להגן על Skills של סוכני AI
הגנה על Skills אינה יכולה להסתיים בבדיקת הקוד בזמן ההתקנה. צריך להתייחס ל Skill כחלק ממחזור החיים האבטחתי של הסוכן ולבחון אותו לפני ההתקנה, בזמן ההרצה ולאחר שהוא כבר פועל בסביבה הארגונית. בדיקה נכונה צריכה לכלול את הקוד, שרשרת התלויות, מקורות התוכן, ההרשאות, ההתנהגות בזמן הרצה והאינטראקציה שלו עם Skills אחרים.
העיקרון הראשון הוא הרשאות מינימליות. Skill שמסוגל לקרוא קבצים אינו צריך בהכרח גישה מלאה לרשת, ו Skill שמבצע פעולה מול שירות חיצוני אינו צריך בהכרח גישה לכל מערכת הקבצים. הפרדה כזאת אינה מונעת את כל סוגי התקיפות, אבל היא מקשה משמעותית על תוקף להפוך Skill בודד לנתיב תקיפה מלא.
העיקרון השני הוא הפרדה בין מידע לבין הוראות. תוכן שמגיע ממקור חיצוני, מתיעוד Skill, מפלט של כלי או מהזיכרון צריך להיחשב בלתי מהימן עד שהמערכת קובעת אחרת. הסוכן צריך לקבל הגנה שמונעת מתוכן חיצוני לשנות את מדיניות האבטחה או לעקוף את ההוראות הבסיסיות שעל פיהן הוא אמור לפעול.
העיקרון השלישי הוא ניטור של שרשרת הפעולות. אירוע בודד כמעט תמיד ייתן תמונה חלקית, בעוד שרצף פעולות יכול לחשוף את הנתיב האמיתי. גישה למידע רגיש ולאחריה עיבוד שלו ולאחר מכן שליחה ליעד חיצוני היא שרשרת שצריכה לקבל משקל אבטחתי שונה משלושת האירועים כאשר הם נבחנים בנפרד.
העיקרון הרביעי הוא הגנה על הזיכרון. כל שינוי בזיכרון צריך להיות ניתן למעקב, כולל המקור שכתב את המידע, הזמן שבו הוא נכתב והסיבה לשינוי. כאשר הזיכרון משפיע על החלטות עתידיות, הוא צריך להיות חלק ממודל האבטחה ולא רק ממודל הנתונים.
העיקרון האחרון הוא הגנה על זהות הסוכן. זהות שמאפשרת לסוכן לבצע פעולות בענן צריכה לקבל הרשאות מינימליות, אישורים קצרי חיים ככל שניתן והפרדה ברורה בין סוכנים ותהליכים. סוכן שמבצע משימה מוגדרת אינו צריך לקבל הרשאות ניהול רחבות רק משום שבעתיד ייתכן שיהיה צורך בהן.
החלק הזה בריפו מתמקד בתקיפה ישירה של סוכני AI בענן דרך וקטור של Agent Skill Injection. במקום להסתבך עם עקיפות פרומפט פרימיטיביות, הוא מנצל את נקודת התורפה האמיתית של האמון העיוור שהסוכן נותן בכלים, במיומנויות ובמטא-דאטה שהוא טוען לזמן ריצה.
התקיפה פועלת על ידי הרעלה של הגדרות הסקיל או ה Tool Definitions. ברגע שהסוכן מושך את היכולת הנגועה, הוא מנתב את זרימת הפעולות לפי פקודות התוקף תוך עקיפה מלאה של ה-Guardrails כי מבחינת המערכת, הסוכן מבצע פעולה מורשית ותקינה.
התוצאה בפועל, חטיפת הרשאות, שימוש לרעה בממשקי API ארגוניים, שאיבת טוקנים וקרדס בענן, והרצת פקודות דרך הסוכן עצמו כפרוקסי פנימי. כלי עבודה אופנסיבי נטו לבדיקות חדירות ולרד-טים שרוצים לפרק סביבות מבוססות Agentic AI.
לסיכום, המעבר מ AI שמייצר תוכן ל AI שמבצע פעולות משנה את מודל האבטחה מהיסוד. כאשר סוכן מקבל Skills, כל Skill הופך ליכולת ביצועית שיכולה להרחיב את טווח הפעולות של הסוכן, אבל במקביל גם להרחיב את משטח התקיפה שלו. הסיכון אינו מסתכם בקוד זדוני, משום שגם תיעוד, פלט של כלי, זיכרון, תלויות וזהות יכולים להפוך לחלק מנתיב תקיפה.
התקיפה המעניינת ביותר אינה בהכרח Skill זדוני שמבצע פעולה חריגה באופן גלוי. תרחיש מורכב יותר הוא Skill שנראה לגיטימי, משתמש בהרשאות קיימות, מחזיר תוכן שנראה תקין ומתחבר ליכולות נוספות שהסוכן כבר מחזיק. כאשר תוקף מצליח להשפיע על הרצף הזה, הסוכן עצמו יכול להפוך למנגנון שמחבר עבורו את השלבים ומבצע את הפעולות באמצעות זהות לגיטימית.
לכן, בעולם של סוכני AI, המודל המסורתי של בדיקת רכיבים כבר אינו מספיק. צריך להבין את הקשר בין קוד, הקשר, Skills, זיכרון, כלים וזהות, ולבחון כיצד תוקף יכול לעבור ביניהם כדי לבנות נתיב תקיפה משמעותי. האתגר האמיתי עבור צוותי אבטחה אינו רק לזהות Skill זדוני, אלא לזהות מתי יכולות לגיטימיות מתחברות ליכולת תקיפה שהארגון מעולם לא התכוון לאפשר.
Skill אינו רק יכולת נוספת של הסוכן. הוא יכול להפוך לוקטור תקיפה שמחבר בין קוד, הקשר, כלים וזהות, ובאמצעות החיבור הזה להפוך פעולה לגיטימית לכאורה לנתיב תקיפה שמאפשר לתוקף להגיע אל משאבים ארגוניים ואל זהויות בעלות הרשאות בסביבת הענן.
