הפסיקו להדביק מפתחות גישה של AWS בתוך קבצי ה-.env שלכם.

כולנו היינו שם. זה מאוחר, אתם מנסים לדבג שגיאת הרשאות ב-Lambda, ועוזר ה-AI שלכם ממשיך להמציא שמות שירותים או ARNs עם מזהי חשבון דמיוניים. אתם רוצים שהמודל יראה את המשאבים האמיתיים שלכם כדי שהוא יפסיק להזות ויתחיל לתקן. מתוך ייאוש, אתם לוקחים מפתח גישה, מכניסים אותו לקובץ סביבה, ומזינים אותו לסוכן. זה עובד. תחושת הקלה מציפה אתכם. ואז מגיע הבוקר, ואתם מבינים שהסוד הזה יושב בהיסטוריית ה-shell שלכם, ב-terminal scrollback, או גרוע מכך, ב-commit שזה עתה נדחף למאגר משותף.

זה בדיוק הבלגן שה-Model Context Protocol נועד למנוע.

MCP יוצר גשר סטנדרטי בין סוכן ה-AI שלכם לבין מערכות חיצוניות. במקום למסור הרשאות גולמיות ולקוות שהסוכן לא ידלוף אותן, אתם מתחברים דרך שרת מבוקר שמטפל באימות (authentication), מגדיר טווח הרשאות (scopes), ושומר על המפתחות שלכם מחוץ לחלון הצ'אט לחלוטין.

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

הכירו את ההבדל: ידע מול "ידיים"

האפשרות הראשונה היא ה-AWS Knowledge MCP Server. חשבו עליו כעל מהנדס בכיר ששינן את כל ספריית התיעוד של AWS אך אין לו פרטי התחברות לחשבון שלכם. הוא מיועד לקריאה בלבד (read-only), ומתייחס למסמכים הרשמיים של AWS כדי להעניק לסוכן בסיס לתחביר API אמיתי, שמות שירותים נכונים ושיטות עבודה מומלצות (best practices) עדכניות.

אתם לא צריכים חשבון AWS כדי להשתמש בו. אתם לא מחברים אותו לתשתית שלכם. אתם מפעילים אותו כשאתם שרטוטים דיאגרמת ארכיטקטורה, לומדים שירות חדש כמו ECS או EventBridge, או מוודאים שקריאת API מסוימת עדיין מתנהגת כפי שזכרתם מלפני שנתיים. הוא מונע מהסוכן לנחש. אם תבקשו ממנו לכתוב Terraform עבור S3 bucket policy, הוא יכיר את השדות האמיתיים והערכים התקפים כי הוא שואב מהמקור, ולא מנתוני אימון שנקטעו בשנה שעברה.

האפשרות השנייה היא ה-AWS MCP Server (Managed). האפשרות הזו נותנת לסוכן שלכם "ידיים", ולא רק זיכרון. עם אימות מתאים, הוא יכול לבחון את לוגים של CloudWatch, לרשום את ה-S3 buckets שלכם, לקרוא את הסכימות של טבלאות ה-DynamoDB, לבדוק מדיניות IAM המחוברת לתפקיד (role), או לוודא אילו קבוצות אבטחה (security groups) פתוחות לאינטרנט. הוא פועל על החשבון האמיתי שלכם, מה שהופך אותו לחזק מאוד לפתרון בעיות בייצור (production) או לשיפור (refactoring) של תשתית פעילה.

השרת ה-Managed מסרב למפתחות ארוכי טווח (long-lived keys). הוא מבצע אימות באמצעות OAuth דרך כניסה בדפדפן, או דרך AWS CLI באמצעות חתימת SigV4. כל קריאה לכלי מתבצעת עם טוקנים לטווח קצר, כל פעולה משאירה עקבות ב-CloudTrail, והסוכן פועל אך ורק בתוך גבולות ה-IAM שהגדרתם. הוא לא יכול לסטות מחוץ להרשאות שלו כי הוא כבול לאותו מנוע מדיניות ששולט בכל משתמש או תפקיד AWS אחר בארגון שלכם.

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

למה AWS ממליצה על השרת ה-Managed עבור רוב המשימות

AWS דוחפת כעת את רוב המשתמשים לעבר שרת ה-Managed MCP היחיד במקום להריץ את שניהם במקביל. השרת ה-Managed ספג את הקשר התיעודי (documentation context) ששרת ה-Knowledge סיפק, כך שהוא מטפל גם בחומר ייחוס וגם בפעולות בחשבון חי תחת נקודת קצה (endpoint) אחת.

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

הגדרת השרת ה-Managed באמצעות OAuth

הפעלת השרת ה-Managed לוקחת בערך חמש דקות, אך השלבים חשובים מכיוון שמדובר בחיבור חי לחשבון שלכם.

שלב 1: הכינו את זהות ה-IAM שלכם

צור או בחר תפקיד (role) או משתמש IAM ייעודי. אל תשתמש בחשבון ה-Root שלך. צמד אליו את ה-managed policy בשם AWSMCPSignInOAuthAccessPolicy. מדיניות זו מעניקה רק את ההרשאות הנדרשות כדי להתחיל את תהליך ה-OAuth sign-in עבור גישת MCP. היא אינה מעניקה זכויות ניהול רחבות כשלעצמה. היכולות בפועל שיהיו לסוכן שלך נקבעות על ידי שאר מדיניות ה-IAM שתצמד לזהות הזו. אם ברצונך שהסוכן יקרא לוגים של CloudWatch אך לעולם לא יגע ב-IAM או בחיובים (billing), בנה מדיניות מותאמת אישית המאפשרת logs:DescribeLogGroups ו-logs:FilterLogEvents ושום דבר אחר.

שלב 2: הגדר את הלקוח (client) שלך

הוסף את ה-URL הרשמי של ה-AWS MCP server להגדרות הלקוח שלך. זה עובד עם Claude Desktop, Claude Code ו-Kiro. בקובץ הגדרות ה-MCP שלך, רשום את ה-server endpoint כך שהלקוח ידע לאן לנתב קריאות לכלים (tool calls) הקשורים ל-AWS.

שלב 3: התחברות דרך הדפדפן

בפעם הראשונה שהסוכן מנסה להפעיל כלי AWS, מערכת ההפעלה שלך תפתח חלון דפדפן. התחבר עם אותה זהות IAM שהכנת בשלב 1. תהליך ה-OAuth מחזיר token בעל תוקף קצר ל-MCP server. לא תראה מפתח סודי (secret key). לא תדביק דבר לקובץ הגדרות. ה-token מתרענן באופן אוטומטי ופג תוקפו במהירות.

שלב 4: ודא את גבול האמון (trust boundary)

לאחר האימות, פתח את CloudTrail וודא שפעולות מופיעות תחת הזהות שיצרת. אתה אמור לראות אירועים כמו ListBuckets או DescribeInstances הקשורים למשתמש או לתפקיד ה-IAM הספציפי הזה. אם אתה רואה פעילות של חשבון Root, עשית משהו לא נכון ועליך לבטל את הסשן (session) באופן מיידי.

אם OAuth אינו מתאים לזרימת העבודה שלך, ה-Managed server תומך גם באימות SigV4 באמצעות פרטי ה-AWS CLI הקיימים שלך. נתיב זה מדלג על חלון הקופץ (pop-up) של הדפדפן, אך אתה עדיין נהנה מכך שה-MCP server מטפל בחתימה ובניהול הסשן במקום לחשוף פרטי גישה גולמיים (raw credentials) לסוכן.

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

שרת MCP בטוח רק במידה שהזהות של ה-IAM שמאחוריו בטוחה.

התחל עם עקרון ההרשאה המינימלית (least privilege). הסוכן שלך אינו זקוק ל-AdministratorAccess כדי לתקן אינטגרציה של API Gateway שניתבה לא נכון. תן לו בדיוק את הרשאות הקריאה או הכתיבה הנדרשות למשימה הנוכחית, ורענן (rotate) או בטל אותן כשהעבודה מסתיימת. אם אתה משתמש בתפקיד (role), הגדר משך סשן קצר. אם אתה משתמש במשתמש, הפעל MFA בכל מקום שהכלים שלך מאפשרים זאת.

לעולם אל תאשר פעולות כמשתמש Root. משתמש Root עוקף מדיניות בקרת שירות (service control policies) ונהנה מגישה בלתי מוגבלת לכל החשבון. אם הסוכן מפרש לא נכון הנחיה (prompt) ומנסה למחוק משאבים, אתה תרצה שהבקשה הזו תיחסם על ידי מדיניות גבול (boundary policy). ל-Root אין מגנוני הגנה (guardrails) כאלה.

לבסוף, התייחס לסוכן כמו למתמחה חדש שעוקב אחר הוראות בצורה מושלמת אך חסר שכל ישר. הוא יבצע את מה שתבקש ממנו, באופן מילולי ומיידי. אם תגיד לו "נקה קבוצות אבטחה (security groups) שאינן בשימוש", הוא עלול לסיים את זו המחוברת למסד הנתונים של הייצור (production) שלך כי היא התאימה לקריטריונים הרחבים שנתת לו. סקור כל פקודה הרסנית לפני אישורה, במיוחד כאשר לסוכן יש הרשאת כתיבה.

השורה התחתונה

אין צורך להקריב אבטחה לטובת שימושיות. ה-Managed AWS MCP Server מאפשר לעוזר ה-AI שלך לראות את התשתית האמיתית שלך, לתקן את ההזיות (hallucinations) שלו, ולפעול במסגרת ה-IAM ששולטת בשאר הצוות שלך. אתה מקבל הקשר חי (live context) מבלי להזין סודות לקבצי סביבה (environment files). הגדר את תהליך ה-OAuth, הגבל את ההרשאות, ואפשר לסוכן לעבוד כשהעיניים שלו פקוחות והידיים שלו קשורות למדיניות שלך.