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

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

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

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

מהו שרת MCP?

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

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

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

מה סוכן יכול לעשות דרך שרת MCP?

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

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

למה מפרידים אסימוני גישה?

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

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

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

הרשאות רחבות ומפורטות

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

מסך האישור המקורי כלל חמש קבוצות הרשאה רחבות: mail:read, mail:write, mail:admin, messages:read ו-messages:send. קל יותר להעריך רשימה קצרה מעשרות סעיפים מפורטים. כיום יש הרשאות נוספות, ולכן צריך לקרוא את המסך בפועל. ניהול טיוטות ושליחת הודעות, למשל, הם פעולות שונות.

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

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

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

אישור פעולות הרסניות

תשובה בטוחה של המודל אינה מוכיחה שהוא בחר את המשאב הנכון. במחיקה נדרשת זהירות מיוחדת.

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

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

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

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

ניסיון חוזר בלי ביצוע כפול

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

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

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

תפקידו של יומן הביקורת

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

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

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

אוטומציות שימושיות

המשימות המועילות ביותר הן לעיתים קרובות אלה שפחות בולטות לעין.

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

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

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

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

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

ממה כדאי להימנע

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

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

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

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

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

שאלות נפוצות

אילו יישומי AI תומכים בשרת MCP?

Claude Desktop, Claude Code, Cursor, Windsurf ויישומים נוספים התואמים ל-MCP. הפרוטוקול מקל על החיבור, אך צריך לבדוק דרך תקשורת, הרשאה, גרסת יישום והגדרות חיבור.

האם הסוכן יכול לקרוא את הדואר שלי?

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

מה מונע מחיקה של משאב חשוב?

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

האם שרת MCP שולח את הדואר שלי לספק ה-AI?

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

האם צריך אסימון נפרד לפעולות בהודעות?

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

מה קורה כשהסוכן מגיע למגבלה?

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

אפשר לבדוק מה הסוכן עשה בשבוע שעבר?

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

האם השימוש ב-MCP עולה יותר?

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