חזרה לכל המאמרים
    הזרקת פרומפטים ב-MCP: סוכן אחד שטעה יכול להטעות צוות שלם
    AI SecurityPrompt InjectionMCPAI AgentsLeast Privilege

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

    Y

    Yoni Fraimorice

    שיתוף:

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

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

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

    דיווח של Unite.AI מ-5 באוקטובר מדגיש את הסיכון דרך עבודתו של חוקר האבטחה Syed Anas Mohiuddin על protocol pivoting — מעבר בין פרוטוקולים כדי לחצות גבולות אמון. עדכון המחקר שלו מאוקטובר מחבר בין תרחיש תקיפה קודם שעובר בין סוכנים לבין חולשות שנמצאו בכלים אמיתיים.

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

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

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

    MCP, קיצור של Model Context Protocol, מחבר יישומי AI לכלים ולמידע. הוא אינו זהה ל-A2A, פרוטוקול לתקשורת בין סוכנים. תהליך עבודה יכול לשלב ביניהם או להשתמש במערכת הודעות פנימית משלו.

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

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

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

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

    Google: הכלי יכול היה להגיע ליעד הלא נכון

    CVE-2026-14540 עוסק ב-MCP Toolbox של Google בגרסאות 0.3.0 עד 1.4.0. ללקוח ה-HTTP שלו חסרו הגבלות מתאימות על הפניות ובדיקת כתובת ה-IP של היעד.

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

    התיקון שמוזג ב-Google הוסיף הגנת SSRF, בדיקת כתובות בזמן יצירת החיבור, גבולות IP ניתנים להגדרה ובדיקת כתובת הבסיס בזמן האתחול. הוא נכלל בגרסה v1.5.0.

    הלקח רחב יותר מ״לבדוק את הקישור״. צריך לבדוק את היעד בפועל, כולל הפניות ושינויי DNS, בנקודה שבה נוצר החיבור.

    JPMorgan: כלי בטוח אחד לא הגן על הכלי שלצידו

    לפי Mohiuddin, רכיב חיפוש התיעוד ב-MCP של JPMorgan בדק אילו מתחמים מותרים ב-read_documentation, אבל הכלי related() משך כתובת שסיפק הפונה בלי אותה מגבלה.

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

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

    השאלה המועילה לצוות שלכם פשוטה: האם הגנתם על כל כלי שמושך תוכן, או רק על הכלי שהשם שלו כולל ״קריאה״?

    Rapid7: הזרקה אחרת, עם השפעה מוגבלת יותר

    הודעת האבטחה של Rapid7 על CVE-2026-97228 מתארת הזרקת שאילתות GraphQL ב-Bulk Export MCP בגרסאות 0.2.5 עד 0.6.1.

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

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

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

    הבעיה המשותפת היא אמון, לא תולעת MCP קסומה

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

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

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

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

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

    1. לתת לכל סוכן גבול הרשאות משלו

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

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

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

    2. לשמור את המקור האמיתי של ההודעה

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

    צרו ואמתו את המטא-דאטה מחוץ למודל. אל תקבלו את הטענה של ההודעה עצמה שהיא הגיעה ממנהל מערכת.

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

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

    3. לסנן פלט, ואז לאכוף את גבול הפעולה

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

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

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

    בדיקות ההפניה של Google ומשתני השאילתה של Rapid7 מטפלים בחלקים שונים של הגבול הזה.

    4. לבדוק את כל השרשרת, לא רק את הסוכן הראשון

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

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

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

    חבר צוות הוא שולח, לא מקור סמכות

    מערכות מרובות סוכנים יכולות להאיץ עבודה מועילה. הן גם יכולות לגרום להוראה לא מהימנה להיראות רשמית יותר בכל שלב.

    אל תשאלו רק ״האם אני סומך על הסוכן הזה?״ שאלו: ״מאיפה הבקשה התחילה, מי אישר את הפעולה הזאת ומה המקבל יכול לבצע בפועל?״

    כך מונעים משיתוף פעולה להפוך לקיצור דרך מסביב לבקרות שלכם.

    מקורות

    צילום ראשי: Offutt Air Force Base operator — מפעילת מרכזייה בבסיס Offutt, צילום של חיל האוויר האמריקאי שבו נראית סמלת Suzann K. Harry מפעילה מרכזייה ב-1967; שם הצלם או הצלמת לא צוין. נחלת הכלל כיצירה של הממשל הפדרלי בארה״ב. הוקטן מ-2821 x 2149 ל-1920 x 1462 פיקסלים ונדחס כ-JPEG; ללא עריכות נוספות. זהו צילום ארכיוני שממחיש העברת תקשורת, לא מערכת AI או חולשה שדווחה. אין בו הבעת תמיכה.

    שיתוף: