מהו שער MCP? איך הוא פועל ומתי להשתמש בו

איך שער MCP פועל

Model Context Protocol ‏(MCP) מאפשר ליישומים להתחבר לשרתים שחושפים כלים, משאבים והנחיות. יישום AI מארח לקוח MCP; שרת MCP מספק את היכולות שהלקוח יכול להשתמש בהן. הפרוטוקול אינו מגדיר תפקיד נפרד של שער.

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

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

שער MCP לעומת שרת, פרוקסי ושער API

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

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

מתי צריך שער MCP?

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

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

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

בקשה דרך Durin

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

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

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

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

מה לבדוק לפני ההפעלה

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

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

איפה זה מתאים לפקדים קיימים

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

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