מי בודק את ה-Plugins שמקבלים גישה למידע הארגוני?

מאת צוות מדיה דיל · 12.08.2026 · AI Investigation · 7 דק׳

בדקנו מי בפועל בודק את ה-Plugins שמקבלים גישה למידע ארגוני רגיש, וגילינו שברוב הצוותים התשובה היא — אף אחד.

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

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

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

ה-Plugin שנראה תמים ומבקש הכול

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

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

מי בכלל אמור לשאת באחריות לבדיקה

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

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

כשה-plugin עצמו הוא הכלי שמורעל

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

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

הקשר לתופעה רחבה יותר של שוק plugins לא מפוקח

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

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

מה קורה בפועל כשלא בודקים — תרחיש שחזרנו

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

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

איך נראה תהליך אישור שבאמת עובד

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

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

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

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

תגיות: Plugins · AI security · tool poisoning · least agency · ממשל תוכנה

← חזרה לבלוג · צור קשר