וכאן צריך להגיד את האמת בלי לעטוף אותה: ארגון שמחבר סוכני AI לכלים פנימיים בלי ממשל הרשאות, בלי ניטור, בלי בעלים ובלי יכולת לעצור פעולה בזמן, לא מאמץ חדשנות. הוא פותח ממשק פעולה חדש לתוקף.
במאמר קודם שלנו, לפני שאתם נותנים הרשאה לסוכן AI, תקראו את זה, הסברנו למה סוכן AI צריך להיחשב זהות בעלת הרשאות ולא כלי עזר חמוד. MCP מחדד את הבעיה הזאת עוד יותר, כי הוא מספק לסוכן דרך תקנית לגלות כלים, לבחור פעולה, להעביר פרמטרים ולקבל תוצאה. מבחינת העסק זו יעילות. מבחינת אבטחת מידע זה משטח תקיפה חדש.
מה זה MCP ולמה אנשי אבטחה צריכים להתעורר
MCP, קיצור של Model Context Protocol, נועד לאפשר לסוכני AI להתחבר בצורה אחידה לכלים חיצוניים: מערכות קבצים, בסיסי נתונים, מערכות CRM, תיבות דואר, מערכות קריאות שירות, מאגרי ידע, סביבת פיתוח, שירותי ענן וספקים חיצוניים. במקום שכל כלי AI יבנה חיבור נפרד לכל מערכת, MCP מציע שכבת חיבור סטנדרטית.
הבעיה אינה עצם התקן. תקנים טובים יכולים להקטין בלגן. הבעיה היא שהסטנדרטיזציה של החיבור יוצרת תחושת ביטחון מוקדמת מדי. כאשר סוכן AI מקבל רשימת כלים, תיאורי פעולות וסכמות פרמטרים, הוא משתמש בהם כדי לבחור מה להפעיל. לפי Microsoft for Developers, הפער הקריטי נמצא בדיוק בין הרגע שבו המודל החליט לקרוא לכלי לבין הרגע שבו מישהו בדק שהקריאה הזאת מותרת, מצומצמת, מתועדת ובטוחה.
זהו שינוי עמוק. בעבר שאלנו אם למשתמש יש הרשאה לקובץ. עכשיו צריך לשאול שאלה רחבה יותר: האם לסוכן מותר לקרוא לקובץ הזה, בהקשר הזה, עבור המשתמש הזה, עם הפרמטרים האלה, בשעה הזאת, ולשלוח את התוצאה לכלי הבא. מי שלא שואל את כל השרשרת, רואה רק פעולה אחת ומפספס את האירוע.
הטעות המסוכנת: מתייחסים לשרת MCP כמו תוסף
שרת MCP אינו תוסף רגיל. הוא מתווך בין סוכן AI לבין פעולה אמיתית. הוא יכול לאפשר קריאה ממסד נתונים, יצירת משימה, פתיחת קריאה לספק, שליחת דואר, עדכון רשומה, שליפת קבצים, הרצת סקריפט או חיבור לשירות חיצוני. כל אחד מהדברים האלה יכול להיות לגיטימי. אבל שילוב שלהם תחת סוכן אוטונומי הוא כבר סיפור אחר.
Microsoft תיארה דפוס תקיפה בשם הרעלת כלי MCP, שבו תיאור כלי או מטא דאטה של כלי משתנים כך שהסוכן מקבל הוראות זדוניות כאילו היו חלק מההקשר התקין שלו. הנקודה החשובה היא שהפעולות הבודדות יכולות להיראות תקינות: הכלי מאושר, ההרשאה שייכת למשתמש, והפנייה יוצאת לשרת שאושר בעבר. השבר נמצא בגבול האמון בין הכלים, לא בהכרח בחולשה אחת ברורה. אפשר לקרוא את הניתוח המלא ב Microsoft Security Blog.
זה בדיוק סוג האירוע שמבלבל ארגונים. אין בהכרח קובץ זדוני. אין בהכרח כניסה ממדינה חריגה. אין בהכרח סיסמה שנגנבה. יש סוכן שקיבל כלי, כלי שקיבל תיאור, תיאור שהשתנה, ושרשרת פעולות שנראית סבירה עד שמבינים שהמידע יצא החוצה.
שלושה תרחישים שצריכים להדליק נורה אדומה
תרחיש ראשון: סוכן כספים מול ספק חיצוני
מחלקת כספים מחברת סוכן AI לתיבת הדואר, למערכת ספקים ולכלי העשרת נתונים חיצוני. המטרה טובה: לבדוק חשבוניות מהר יותר. עכשיו דמיינו ששרת MCP חיצוני מחזיר תשובה שנראית לגיטימית, אבל בתוך תיאור הכלי או הפלט יש הוראה שמכוונת את הסוכן לצרף סיכום חשבונית, פרטי ספק ומספרי הזמנה לקריאה חיצונית. מבחינת הלוגים, ייתכן שהכול נראה כמו שימוש רגיל בכלי מאושר.
תרחיש שני: שרת MCP מקומי על מחשב עובד
עובד מתקין כלי פיתוח שמציע חיבור MCP מקומי. הוא נראה שימושי, עובד מהר, ומתחבר לסביבת הקוד. מסמכי האבטחה של Model Context Protocol מזהירים ששרת MCP מקומי לא מהימן עלול לרוץ עם הרשאות המשתמש, לגשת לקבצים רגישים, לבצע פקודות או לחשוף מידע. בארגון שבו מפתחים עובדים עם סודות גישה, מפתחות API וקוד מקור, זה לא סיכון תיאורטי. זה נתיב דלף כמעט מושלם.
תרחיש שלישי: טוקן אחד שנולד למטרה אחת ומשמש למטרה אחרת
אחד הדפוסים המסוכנים ביותר הוא העברת טוקנים בלי בדיקה נכונה של קהל היעד. מסמכי MCP מגדירים Token Passthrough כאנטי דפוס, משום ששרת שמקבל טוקן שלא הונפק עבורו ומעביר אותו הלאה עלול לעקוף בקרות, לטשטש לוגים ולאפשר שימוש לרעה בהרשאות. זה מתחבר ישירות למה שכתבנו במאמר המפתח שכבר דלף: למה API Keys מסכנים את העסק. סוד גישה שלא מוגבל להקשר, לקהל יעד, לזמן ולפעולה הוא לא סוד. הוא התחלה של אירוע.
למה הרשאות רגילות לא מספיקות בעולם של MCP
הרבה ארגונים עדיין מנהלים הרשאות כאילו כל פעולה נעשית על ידי אדם שמבין את ההקשר. סוכן AI משנה את ההנחה הזאת. הוא יכול לפעול מהר יותר, לחבר מידע ממספר מערכות, ולהמשיך פעולה אחת על בסיס פלט של פעולה אחרת. לכן צריך לעבור מחשיבה של הרשאות בלבד לחשיבה של הרשאות בתוספת סוכנות.
OWASP מציין ברשימת הסיכונים של יישומי LLM ו GenAI סיכונים כמו הזרקת הנחיות, חשיפת מידע רגיש, שרשרת אספקה וסוכנות עודפת. ברשימת הסיכונים ליישומים סוכניים, הדגש נע עוד יותר לכיוון שימוש לרעה בכלים, ניצול זהויות, שרשרת אספקה של סוכנים ושליטה בפעולות. במילים פשוטות: הבעיה כבר אינה רק מה המודל אומר. הבעיה היא מה הוא יכול לעשות.
ארגון שמסתפק בשאלה האם המשתמש עבר MFA מפספס את שכבת הסיכון החדשה. המשתמש עבר אימות, אבל הסוכן פועל בשמו. האפליקציה אושרה, אבל הכלי שמאחוריה השתנה. ההרשאה קיימת, אבל השימוש בה חורג מהמטרה העסקית. זה גם המקום לקרוא שוב את האפליקציה שאישרתם הרגע פתחה לתוקף את הענן, כי MCP, OAuth, טוקנים וסוכני AI נפגשים בדיוק באזור שבו ארגונים רגילים לאבד נראות.
מה חייב להיכנס למדיניות אבטחת MCP
מדיניות MCP טובה לא מתחילה באיסור מוחלט. איסור מוחלט יוצר Shadow AI ו Shadow MCP. עובדים וצוותי פיתוח ימשיכו לחפש את הדרך הקצרה. המדיניות הנכונה צריכה לאפשר עבודה, אבל רק תחת גבולות ברורים.
- מלאי שרתי MCP: כל שרת MCP, מקומי או ענני, חייב להופיע במלאי נכסים. מי מפעיל אותו, מי הבעלים העסקי, מי הבעלים הטכני, לאילו מערכות הוא מחובר, ואילו פעולות הוא מאפשר.
- אישור ספקים וכלים: אין חיבור לשרת MCP חיצוני בלי בדיקת מקור, מוניטין, בעלות, תנאי שימוש, תיעוד אבטחה ומודל הרשאות. שרת MCP הוא ספק תוכנה לכל דבר.
- הרשאות לפי פעולה: אל תתנו גישה כללית אם הסוכן צריך פעולה מוגבלת. הפרידו בין קריאה, כתיבה, יצוא, מחיקה, שינוי הרשאות והרצת פקודות.
- אישור אנושי לפעולות רגישות: שליחת מידע החוצה, שינוי פרטי תשלום, מחיקת נתונים, פתיחת גישה לספק, יצירת משתמש או שינוי הרשאות חייבים לעבור אישור אדם.
- בדיקת תיאורי כלים: תיאור כלי הוא לא טקסט תיעודי תמים. עבור סוכן AI הוא חלק מההקשר שמכוון פעולה. שינוי בתיאור כלי קריטי צריך לעבור ביקורת כמו שינוי בקוד או במדיניות הרשאות.
- טוקנים קצרים ומוגבלים: טוקן צריך להיות קצר חיים, קשור לקהל יעד ברור, מוגבל scope ומתועד. אין סיבה שטוקן שניתן לפעולת סיכום יוכל להפעיל פעולה מנהלית.
- בידוד שרתים מקומיים: שרת MCP שרץ על עמדת קצה צריך לרוץ בסביבה מוגבלת, בלי גישה חופשית לקבצי משתמש, סודות SSH, תיקיות קוד או רשת פנימית.
- לוגים ברמת קריאת כלי: לא מספיק לשמור את שיחת המשתמש עם המודל. צריך לדעת איזה סוכן קרא לאיזה כלי, עם אילו פרמטרים, בשם מי, מול איזה משאב, מה הייתה התוצאה ומה נחסם.
- DLP סביב פלט וכלים: מדיניות מניעת דלף צריכה לראות גם את הפרמטרים שיוצאים לכלי MCP ואת התשובות שחוזרות ממנו. מי שמגן רק על דואר וקבצים מפספס את הצינור החדש.
- ניטור רצפים ולא רק אירועים בודדים: פעולה אחת יכולה להיות תקינה. חמש פעולות רצופות יכולות להיות דלף. היכולת לחבר רצף היא ההבדל בין לוג לבין הגנה.
בהקשר הזה, כדאי לחזור למאמר שלנו על מניעת דלף מידע DLP. כאשר AI מחובר לכלים, דלף מידע לא חייב להיראות כמו קובץ שנשלח במייל. הוא יכול להיות פרמטר, תשובת כלי, קטע סיכום, תוצאת חיפוש או נתון שנעטף בבקשת API תמימה.
איך בודקים אם הארגון כבר חשוף
השאלה הראשונה אינה האם אתם משתמשים ב MCP באופן רשמי. השאלה היא האם מישהו בארגון כבר משתמש בו בלי שאתם יודעים. צוותי פיתוח, אנליסטים, אנשי אוטומציה, צוותי דאטה ומנהלי מוצר נוטים לאמץ כלים כאלה מהר, לעיתים לפני שאבטחת מידע בכלל מכירה את השמות.
אנחנו ממליצים להתחיל בבדיקה קצרה אך חדה:
- סרקו תחנות מפתחים ועמדות כוח לאיתור קבצי הגדרה של כלי AI, חיבורים לשרתי MCP, טוקנים, מפתחות וסקריפטים שמריצים שרתים מקומיים.
- בדקו באילו כלי AI ארגוניים קיימים חיבורי כלים, קונקטורים, אפליקציות מאושרות או הרשאות OAuth.
- עברו על לוגים של יציאות לרשת אל שירותים חדשים, במיוחד סביב תחנות פיתוח וסביבות אוטומציה.
- בדקו אם קיימים סודות גישה בקוד, בקבצי סביבת עבודה ובמערכות CI.
- מפו אילו סוכנים או כלי AI יכולים לקרוא מידע רגיש ולשלוח תוצאה לשירות חיצוני.
- בצעו תרגיל הזרקת הנחיות מול סוכן שמחובר לכלים, ובדקו האם הוא נבלם לפני פעולה מסוכנת.
זה לא תרגיל תאורטי. זה צריך להיות חלק מ סקר סיכונים עדכני. סקר סיכונים שלא בודק שימושי AI, שרתי MCP, אפליקציות OAuth, טוקנים ותוספי דפדפן הוא סקר שנבנה לעולם הישן.
איפה SOC נכנס לתמונה
החולשה הגדולה של אבטחת MCP היא נראות. אם אין לוג על קריאת כלי, אין דרך לדעת מה קרה. אם אין קורלציה בין סוכן, משתמש, כלי, יעד ותוכן רגיש, אין דרך להבדיל בין אוטומציה יעילה לבין דלף מידע.
לכן אירועי MCP צריכים להגיע ל SIEM/SOC: יצירת חיבור חדש, שינוי תיאור כלי, הרשאת כלי רחבה, קריאות חריגות לכלי, יציאה ליעד חדש, שימוש בטוקן חריג, ריבוי קריאות בפרק זמן קצר, גישה למידע רגיש ולאחריה שליחה החוצה. במאמר SOC בלי תגובה הוא רק מסך יפה כתבנו שניטור שאינו מוביל לפעולה הוא אשליה. בעולם MCP זה נכון עוד יותר, כי חלון הזמן בין החלטת הסוכן לבין הפעולה בפועל יכול להיות קצר מאוד.
שירות SIEM/SOC של 010 רלוונטי כאן לא בגלל שמדובר בעוד מקור לוגים, אלא בגלל שצריך לחבר בין נקודות: זהות, עמדת קצה, דוא״ל, ענן, כלים, דלף מידע והתנהגות חריגה. MCP לא חי לבד. הוא יושב בדיוק בצומת של כל השכבות האלה.
מה אנחנו ממליצים
המלצה שלנו ברורה: אל תחכו שהמונח MCP יופיע במסמך מדיניות רשמי כדי להתחיל לטפל בו. התחילו ממיפוי. אילו סוכני AI קיימים, אילו כלים הם מפעילים, מי אישר אותם, אילו הרשאות ניתנו, אילו טוקנים קיימים, ומה קורה אם כלי אחד מתנהג אחרת ממה שתכננתם.
בשלב הבא, חברו את זה ל מעטפת הגנת הסייבר: סקר סיכונים שמזהה חשיפות AI, מודעות עובדים שמסבירה למה אישור כלי אינו פעולה טכנית בלבד, DLP שמזהה מידע רגיש גם בתוך קריאות כלי, מודיעין סייבר שמאתר סודות וזהויות שדלפו, ו SOC שמסוגל לראות רצף ולא רק אירוע בודד.
אין כאן מקום להיסטריה. יש מקום למשמעת. MCP יכול להיות תשתית מצוינת לארגונים שרוצים להפיק ערך אמיתי מ AI. אבל בלי בקרה הוא הופך מצינור עבודה לצינור דלף. בלי בעלים הוא הופך מנכס עסקי לאזור אפור. בלי לוגים הוא הופך לאירוע שאי אפשר לחקור. בלי גבולות הוא נותן לסוכן AI בדיוק את מה שתוקף רוצה: דרך לפעול בשם הארגון בלי להיראות כמו תוקף.
השורה התחתונה
MCP הוא לא הבעיה. חיבור בלי שליטה הוא הבעיה. סוכן AI שמחובר לכלים, קבצים, דואר ומערכות עסקיות צריך לקבל יחס כמו עובד דיגיטלי עם הרשאות, לא כמו חלון צ׳אט.
הפעולה הנכונה לשבוע הקרוב: הכינו רשימת שרתי MCP וחיבורי AI, בטלו הרשאות רחבות שאין להן בעלים, בדקו טוקנים וסודות גישה, חברו לוגים ל SOC, והגדירו אילו פעולות דורשות אישור אנושי. לא בעוד רבעון. עכשיו.
כי הפריצה הבאה לא חייבת להתחיל בפישינג. היא יכולה להתחיל בכלי שסוכן AI קיבל אליו גישה כדי לעזור לכם לעבוד מהר יותר.
