האם שרתי MCP הם חוליית האבטחה החלשה החדשה?

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

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

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

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

הבעיה הבסיסית: MCP הוא פרוטוקול, לא ערבות אבטחה

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

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

מה קרה כששרת MCP "תיאר את עצמו" בצורה מטעה

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

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

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

שרשרת האספקה הארוכה מדי לספירה

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

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

למה לא מספיק "לבדוק פעם אחת" ולסמוך

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

הפתרון האמיתי הוא שילוב של שני רכיבים: הרצת כל שרת MCP חדש בתוך סביבה מבודדת שמגבילה את הגישה שלו בפועל, לא רק במסמך התיעוד, ותהליך בדיקה אחיד שכל שרת MCP חדש עובר לפני שהוא מקבל אישור לגעת בנתונים אמיתיים. הרחבנו את שתי הגישות במדריכים על sandboxing לסוכני AI ועל הגנה מפני prompt injection, ששני הנושאים בהם קשורים ישירות לאיך שרתי MCP מתפקדים בפועל בתוך סביבת סוכן.

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

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

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

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

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

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

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

תגיות: MCP servers · Model Context Protocol · tool poisoning · אבטחת AI · שרשרת אספקה

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