MCP בעברית ואיך מחברים סוכן AI למערכות בבטחה

מהו MCP ומה נשאר מחוץ לפרוטוקול

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

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

• Host. אפליקציית ה-AI עצמה, זו שמדברת עם המודל ומנהלת את השיחה. Claude Code ו-Claude Desktop הם דוגמאות.
• Client. רכיב בתוך ה-host שמחזיק חיבור אחד לשרת אחד. שני שרתים, שני clients. אין זה פרט טכני בלבד, משום שהבידוד הזה מאפשר להפעיל שרת אחד ולהשבית אחר.
• Server. התוכנה שחושפת את היכולות. היא יכולה לרוץ על המחשב שלכם או על שרת מרוחק, והמילה שרת מתארת כאן תפקיד ולא מיקום.

הפרדה בין המסרים לבין דרך ההעברה

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

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

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

הפרוטוקול חסר מצב

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

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

שלוש היכולות שהשרת יכול לחשוף

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

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

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

{
  "name": "orders_get_status",
  "title": "Order status",
  "description": "Return the current status of one order by its ID",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderId": { "type": "string", "description": "The order ID, e.g. ORD-10293" }
    },
    "required": ["orderId"]
  }
}

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

מה הלקוח מציע לשרת

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

איך זה נראה בפועל

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

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./docs"],
      "env": {}
    },
    "stripe": {
      "type": "http",
      "url": "https://mcp.stripe.com"
    }
  }
}

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

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

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

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

העברת טוקן

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

שליח מבולבל

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

חטיפת מזהה מצב

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

שרת מקומי עוין

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

הרשאות רחבות מדי

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

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

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

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

מה MCP לא פותר

הפרוטוקול פותר את החיבור. הוא לא פותר את השאלה אם כדאי לחבר.

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

שאלות נפוצות

האם צריך MCP כדי לבנות סוכן AI?

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

שרת MCP רץ בענן או אצלי?

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

מה ההבדל בין Tool לבין Resource?

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

האם חיבור שרת MCP חושף את הנתונים שלי למודל?

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

כמה שרתים כדאי לחבר?

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