توقف عن لصق مفاتيح وصول AWS في ملفات .env الخاصة بك.
لقد مررنا جميعاً بهذا الموقف. الوقت متأخر، وأنت تحاول تصحيح خطأ في أذونات Lambda، ومساعد الذكاء الاصطناعي الخاص بك يستمر في اختراع أسماء خدمات أو ARNs بمعرفات حسابات وهمية. تريد من النموذج أن يرى مواردك الفعلية ليتوقف عن الهلوسة ويبدأ في الإصلاح. ومن شدة اليأس، تأخذ مفتاح وصول وتضعه في ملف بيئة (environment file) وتقدمه للوكيل (agent). يعمل الأمر. يغمرك شعور بالراحة. ثم يأتي الصباح، وتدرك أن هذا السر موجود في سجل الأوامر (shell history)، أو في سجل التمرير في الطرفية (terminal scrollback)، أو والأسوأ من ذلك، في عملية commit تم دفعها للتو إلى مستودع مشترك.
هذه هي الفوضى التي صُمم بروتوكول سياق النموذج (Model Context Protocol - MCP) لمنعها تحديداً.
ينشئ MCP جسراً قياسياً بين وكيل الذكاء الاصطناعي الخاص بك والأنظمة الخارجية. بدلاً من تسليم بيانات الاعتماد الخام والأمل في ألا يسربها الوكيل، يمكنك الاتصال من خلال خادم محكوم يدير المصادقة، ويحدد نطاق الأذونات، ويبقي مفاتيحك بعيدة تماماً عن نافذة الدردشة.
بالنسبة لـ AWS، لديك حالياً خادمان رسميان من نوع MCP للاختيار من بينهما. اختيار الخادم الخاطئ إما سيترك وكيلك أعمى أو يمنحه وصولاً زائداً مع رقابة قليلة جداً.
اعرف الفرق: المعرفة مقابل القدرة على التنفيذ (Hands)
الخيار الأول هو AWS Knowledge MCP Server. فكر فيه كمهندس أول حفظ مكتبة وثائق AWS بالكامل ولكنه لا يملك بيانات اعتماد تسجيل الدخول لحسابك. إنه مصمم للقراءة فقط، حيث يرجع إلى وثائق AWS الرسمية لتزويد الوكيل بالبنية الصحيحة لواجهة برمجة التطبيقات (API syntax)، وأسماء الخدمات الصحيحة، وأفضل الممارسات الحالية.
لا تحتاج إلى حساب AWS لاستخدامه. ولا تقوم بتوصيله ببنيتك التحتية. يمكنك تشغيله عندما ترسم مخططاً معمارياً، أو تتعلم خدمة جديدة مثل ECS أو EventBridge، أو تتحقق مما إذا كان استدعاء API معين لا يزال يتصرف بالطريقة التي تتذكرها من عامين. إنه يمنع الوكيل من التخمين. إذا طلبت منه كتابة Terraform لسياسة S3 bucket، فسيعرف الحقول الحقيقية والقيم الصالحة لأنه يسحب من المصدر، وليس من بيانات التدريب التي توقفت العام الماضي.
الخيار الثاني هو AWS MCP Server (Managed). هذا الخيار يمنح وكيلك "يدين" (قدرة على التنفيذ)، وليس مجرد ذاكرة. مع المصادقة المناسبة، يمكنه فحص سجلات CloudWatch الخاصة بك، وسرد S3 buckets، وقراءة مخططات جداول DynamoDB، والتحقق من سياسات IAM المرتبطة بدور (role) معين، أو التحقق من مجموعات الأمان (security groups) المفتوحة للإنترنت. إنه يعمل على حسابك الحقيقي، مما يجعله قوياً لاستكشاف مشكلات الإنتاج وإصلاحها أو إعادة هيكلة البنية التحتية الحية.
يرفض الخادم المدار (Managed server) المفاتيح طويلة الأمد. فهو يقوم بالمصادقة عبر OAuth من خلال تسجيل الدخول عبر المتصفح، أو من خلال AWS CLI باستخدام توقيع SigV4. كل استدعاء للأدوات يتم باستخدام رموز (tokens) قصيرة الأمد، وكل إجراء يترك أثراً في CloudTrail، ويعمل الوكيل بدقة ضمن حدود IAM التي تحددها. لا يمكنه الخروج عن أذوناته لأنه مقيد بنفس محرك السياسات الذي يحكم كل مستخدم أو دور آخر في AWS داخل مؤسستك.
إليك القاعدة الذهبية التي يجب تذكرها: خادم واحد يمنح وكيلك المعرفة، والآخر يمنحه القدرة على التنفيذ. استخدم خادم المعرفة (Knowledge server) عندما تكون في مرحلة الدراسة أو التصميم. واستخدم الخادم المدار (Managed server) عندما تكون في مرحلة التشغيل أو الإصلاح.
لماذا توصي AWS بالخادم المدار (Managed Server) لمعظم المهام
تدفع AWS الآن معظم المستخدمين نحو خادم Managed MCP Server الوحيد بدلاً من تشغيل كليهما بالتوازي. لقد استوعب الخادم المدار سياق الوثائق الذي كان يوفره خادم المعرفة، لذا فهو يتعامل مع كل من المواد المرجعية وإجراءات الحساب الحية من خلال نقطة نهاية (endpoint) واحدة.
قد يؤدي تشغيل كلا الخادمين في وقت واحد إلى تدهور التجربة في الواقع. يتلقى الوكيل تعريفات أدوات متداخلة وقد يرتبك بشأن ما إذا كان يجب استدعاء بحث في الوثائق للقراءة فقط أو استدعاء API حي مقابل حسابك. هذا التردد يؤدي إلى استجابات أبطأ وأخطاء عرضية في اختيار الأدوات. إن دمج العمليات في الخادم المدار يبسط إعداداتك ويبقي الوكيل مركزاً.
إعداد الخادم المدار (Managed Server) باستخدام OAuth
يستغرق تشغيل الخادم المدار حوالي خمس دقائق، ولكن الخطوات مهمة لأن هذا اتصال مباشر بحسابك.
الخطوة 1: جهز هوية IAM الخاصة بك
قم بإنشاء أو اختيار دور (role) أو مستخدم IAM مخصص. لا تستخدم حساب الجذر (Root account) الخاص بك. قم بإرفاق السياسة المدارة المسماة AWSMCPSignInOAuthAccessPolicy به. تمنح هذه السياسة فقط الأذونات المطلوبة لبدء تدفق تسجيل الدخول عبر OAuth للوصول إلى MCP. هي لا تمنح حقوقاً إدارية واسعة بحد ذاتها. يتم تحديد القدرات الفعلية التي سيتمتع بها الوكيل (agent) الخاص بك من خلال بقية سياسات IAM التي ترفقها بتلك الهوية. إذا كنت تريد من الوكيل قراءة سجلات CloudWatch ولكن دون المساس بـ IAM أو الفواتير (billing)، فقم ببناء سياسة مخصصة تسمح بـ logs:DescribeLogGroups و logs:FilterLogEvents ولا شيء غير ذلك.
الخطوة 2: تهيئة العميل الخاص بك
أضف رابط (URL) خادم AWS MCP الرسمي إلى تهيئة العميل الخاص بك. يعمل هذا مع Claude Desktop و Claude Code و Kiro. في ملف إعدادات MCP الخاص بك، قم بتسجيل نقطة نهاية الخادم (server endpoint) حتى يعرف العميل وجهة توجيه استدعاءات الأدوات المتعلقة بـ AWS.
الخطوة 3: المصادقة عبر المتصفح
في المرة الأولى التي يحاول فيها الوكيل استدعاء أداة AWS، سيقوم نظام التشغيل الخاص بك بفتح نافذة متصفح. قم بتسجيل الدخول باستخدام نفس هوية IAM التي أعددتها في الخطوة 1. يعيد تدفق OAuth رمزاً (token) قصير الأمد إلى خادم MCP. لن ترى مفتاحاً سرياً (secret key). ولن تقوم بلصق أي شيء في ملف تهيئة. يتم تحديث الرمز تلقائياً وينتهي مفعوله بسرعة.
الخطوة 4: التحقق من حدود الثقة
بمجرد إتمام المصادقة، افتح CloudTrail وتأكد من أن الإجراءات تظهر تحت الهوية التي أنشأتها. يجب أن ترى أحداثاً مثل ListBuckets أو DescribeInstances مرتبطة بمستخدم أو دور IAM المحدد ذاك. إذا رأيت نشاطاً لحساب الجذر (Root account)، فقد ارتكبت خطأً ويجب عليك إلغاء الجلسة فوراً.
إذا كان OAuth لا يناسب سير عملك، فإن الخادم المدار (Managed server) يدعم أيضاً المصادقة عبر SigV4 من خلال بيانات اعتماد AWS CLI الحالية لديك. يتخطى هذا المسار النافذة المنبثقة للمتصفح، ولكنك ستظل تستفيد من قيام خادم MCP بمعالجة التوقيع وإدارة الجلسة بدلاً من تعريض بيانات الاعتماد الخام للوكيل.
عادات أمنية تهم حقاً
أمان خادم MCP يعتمد كلياً على هوية IAM التي تقف خلفه.
ابدأ بمبدأ الحد الأدنى من الصلاحيات (least privilege). لا يحتاج الوكيل الخاص بك إلى AdministratorAccess لإصلاح تكامل API Gateway موجه بشكل خاطئ. امنحه بالضبط أذونات القراءة أو الكتابة المطلوبة للمهمة الحالية، وقم بتدويرها أو إلغائها عند انتهاء المهمة. إذا كنت تستخدم دوراً (role)، فقم بتعيين مدة جلسة قصيرة. وإذا كنت تستخدم مستخدماً، فقم بتفعيل المصادقة متعددة العوامل (MFA) حيثما تسمح أدواتك بذلك.
لا تصرح أبداً بصفتك مستخدم الجذر (Root user). يتجاوز مستخدم الجذر سياسات التحكم في الخدمة (service control policies) ويتمتع بوصول غير مقيد عبر الحساب بأكمله. إذا أخطأ الوكيل في تفسير أمر ما وحاول حذف موارد، فستحتاج إلى حظر ذلك الطلب بواسطة سياسة حدودية (boundary policy). مستخدم الجذر لا يمتلك مثل هذه الضمانات.
أخيراً، تعامل مع الوكيل كأنه متدرب جديد يتبع التعليمات بدقة ولكنه يفتقر إلى المنطق السليم. سينفذ ما تطلبه منه حرفياً وفوراً. إذا قلت له "قم بتنظيف مجموعات الأمان غير المستخدمة"، فقد يقوم بإنهاء المجموعة المرتبطة بقاعدة بيانات الإنتاج الخاصة بك لأنها تطابقت مع المعايير الواسعة التي أعطيتها له. راجع أي أوامر تدميرية قبل تأكيدها، خاصة عندما يمتلك الوكيل صلاحية الكتابة.
الخلاصة الحقيقية
لست بحاجة للمقايضة بين الأمان والمنفعة. يتيح لك خادم AWS MCP المدار لمساعدك الذكي رؤية بنيتك التحتية الحقيقية، وتصحيح هلوساته الخاصة، والعمل ضمن إطار عمل IAM نفسه الذي يحكم بقية فريقك. ستحصل على سياق مباشر دون تسريب أسرار في ملفات البيئة (environment files). قم بإعداد تدفق OAuth، وأحكم إغلاق الأذونات، واترك الوكيل يعمل وعيناه مفتوحتان ويداه مقيدتان بسياساتك.