كيف بنت Eon تحقيقاً متعدد السحابات مع بوابة MCP على Amazon Bedrock AgentCore

هذه مقالة ضيف كُتبت بالتعاون مع Roei Zavida من شركة Eon.

يحتاج مورّدو البرمجيات المستقلة (ISVs) الذين يبنون منتجات مدعومة بالذكاء الاصطناعي إلى ربط العوامل والبشر بعشرات الأدوات التشغيلية عبر السحابات، لكل منها نماذج مصادقة وحدود شبكية وسياسات وصول مختلفة. وعندما تمتد تلك الأدوات في الوقت نفسه عبر AWS وGCP وAzure، تتضاعف مساحة التكامل.

تصف هذه المقالة كيف استخدمت Eon خدمة Amazon Bedrock AgentCore، وهي منصة لبناء العوامل وربطها وتحسينها على نطاق واسع بأي إطار عمل أو نموذج. استخدمتها Eon لاستبدال بيانات الاعتماد الخاصة بكل أداة وعمليات بروتوكول Model Context Protocol (MCP) المحلية ببوابة واحدة موثقة. النتيجة منحَت المطوّرين والعوامل المستقلة وصولاً موحداً إلى أدوات التحقيق عبر ثلاث سحابات. ويصل المهندسون الجدد الآن إلى جميع أدوات التحقيق الخاصة بهم في نحو دقيقتين بدلاً من اليومين التي كان يستغرقها سابقاً إعداد بيانات الاعتماد وخوادم MCP المحلية.

نبذة عن Eon

توفّر Eon أساس البيانات المستقل لعصر الذكاء الاصطناعي. تكتشف المنصة موارد السحابة وتصنّفها عبر AWS وAzure وGCP. وهي توفر نسخاً احتياطياً مستمراً مزيل التكرار يقلّل تكاليف التخزين بنسبة تصل إلى 50 في المئة وفقاً لقياسات Eon الداخلية. كما تكتشف ضرر برامج الفدية والعوامل الشاردة وتوفر سياقاً حياً مبنياً على الواقع لعوامل الذكاء الاصطناعي. وكل ذلك يعمل من دور AWS Identity and Access Management (IAM) واحد للقراءة فقط، مع تخزين البيانات بصيغتي Apache Parquet وApache Iceberg. أسستها مهندسون سابقون في AWS، وتشغّل Eon بنيتها التحتية كخدمة (SaaS) على AWS.

التحدي

يحقق فريق Eon الهندسي الداخلي في الحوادث الإنتاجية عبر سحابات متعددة وعشرات الأنظمة التشغيلية. فحاوية Kubernetes معطلة تتطلب فحص سجلات الحاويات ومقاييس Grafana وطلب السحب (PR) الخاص بالنشر على GitHub وحالة صحة مزوّد السحابة ضمن الجلسة نفسها.

احتاجت Eon إلى تلبية عدة متطلبات رئيسية:

• توحيد بيانات الاعتماد — كل أداة جديدة كانت تضيف تكاملاً آخر لإعداده وتأمينه وتدويره، وهو ما أصبح أصعب في الحفاظ على اتساقه مع نمو مجموعة الأدوات.
• إزالة عمليات MCP المحلية — كان كل مطوّر يشغّل عدة خوادم MCP محلياً، وهو ما كان يصعب توحيده وإبقائه محدّثاً.
• فصل الهوية — كان المهندسون يصلون إلى كل نظام بصلاحيات قائمة على الأدوار، لكن لم يكن هناك مكان واحد لتحديد الأدوات التي يمكن لكل شخص أو عامل استدعاؤها.
• وصول عبر الحسابات دون أعباء شبكية — استضافة خوادم MCP عبر حسابات AWS متعددة كانت تتطلب تقارن (peering) للشبكات الافتراضية الخاصة (VPC) أو AWS PrivateLink لكل حساب، ما يضاعف التكلفة التشغيلية ووقت الإعداد.
• تهيئة المطوّرين — كان المهندسون الجدد يقضون ما يقرب من 2 من الأيام في إعداد بيانات الاعتماد وخوادم MCP المحلية قبل التحقيق في أول حادث لهم.
• وصول العوامل — احتاج عامل هندسة موثوقية المواقع المستقل (SRE) لدى Eon (الذي يشغّل Claude على Amazon Bedrock) إلى الوصول نفسه إلى الأدوات كما البشر، لكن بصلاحيات مختلفة.

جعل نمو عدد المهندسين، مقترناً بمجموعة سريعة التوسع من أدوات الذكاء الاصطناعي وMCP، صيانة بيانات الاعتماد وخوادم MCP المحلية مكلفة بشكل متزايد. ما دفع Eon نحو حل مركزي.

المناهج المدروسة

قبل البناء على AgentCore، قيّمت Eon البدائل:

الخيار 1: وكيل مركزي بمصادقة مخصصة

كان لكل بيئة تشغيل إعدادها الخاص بالوكيل يتضمن جميع الوجهات. وكيل عكسي واحد يجمع كل الأدوات، مع طبقة مصادقة مخصصة. عالج هذا توحيد بيانات الاعتماد، لكنه دعم MCP عن بُعد فقط، وكان يتطلب بناء وصيانة ترجمة بروتوكولات الأدوات وإدارة الجلسات ومنطق التفويض من الصفر. وكان عبء التنفيذ والصيانة كبيراً.

الخيار 2: Amazon Bedrock AgentCore Gateway

بوابة Amazon Bedrock AgentCore Gateway، وهي إحدى قدرات Amazon Bedrock AgentCore، هي بوابة مُدارة مع اتحاد هويات مدمج وسياسات تفويض قائمة على Cedar واستضافة Runtime تحوّل خوادم MCP المحلية إلى نقاط نهاية HTTP بعيدة. عالج هذا جميع المتطلبات دون بنية تحتية مخصصة.

اختارت Eon الخيار 2 لأنه وفّر فصل الهوية والاتصال عبر الحسابات وفرض السياسات كقدرات مُدارة بدلاً من كود ستحتاج إلى بنائه وصيانته. كان هذان هما الخياران الوحيدان المطروحان.

نظرة عامة على الحل

نشرت Eon مجموعة Amazon Bedrock AgentCore الكاملة: AgentCore Gateway، وPolicy in Amazon Bedrock AgentCore، وAgentCore Runtime، وAgentCore Identity، وكلها إمكانات من Amazon Bedrock AgentCore. يوضح المخطط التالي كيفية تدفق طلبات العملاء عبر طبقة المصادقة إلى بوابة واحدة. توجه البوابة استدعاءات الأدوات المصرح بها إلى الأهداف المستضافة على AgentCore Runtimes عبر حسابات AWS متعددة.

الشكل 1: بنية البوابة المركزية لـ Eon على Amazon Bedrock AgentCore

تتكون البنية من خمس طبقات:

العملاء

يتصل المطورون الذين يستخدمون Claude Code أو Cursor أو OpenAI Codex بعنوان MCP URL واحد. ويتصل وكيل SRE مستقل يعمل بـ Claude على Amazon Bedrock بالبوابة نفسها بهوية مختلفة.

مستوى الهوية

يتم توحيد تسجيل الدخول الأحادي للشركات (SSO) عبر Amazon Cognito، الذي يُصدر رمز الويب JSON (JWT) ويسلّمه إلى البوابة. يعمل Amazon API Gateway في المقدمة كنقطة دخول OAuth للبشر، موفّراً الوكيل لجلسة MCP. وتصادق الوكلاء (Agents) مع Cognito client_credentials عبر منح (grants) مباشرة مقابل البوابة.

بوابة واحدة، وصول بأقل الامتيازات

تعمل بوابة AgentCore MCP واحدة كباب أمامي على مستوى الشركة. تتحكم سياسات Cedar في وضع ENFORCE بتحديد المبادئ (principals) المسموح لها باستدعاء أي أدوات. عمليات القراءة متاحة لمجموعات محددة، وليس لكل مستخدم مصادق عليه. عمليات الكتابة محدودة بإجراءات تعاون منخفضة الأثر، مثل التعليق على طلب سحب (PR) أو تذكرة، وأدوات الإنتاج للقراءة فقط.

السياسة في Amazon Bedrock AgentCore

تربط سياسات Cedar كل مبدأ بالأدوات المسموح بها. عمليات الكتابة محدودة بإجراءات تعاون منخفضة الأثر، مثل التعليق على طلب سحب (PR) أو تذكرة، وأدوات الإنتاج للقراءة فقط. تقيّم البوابة كل tools/call طلب مقابل Cedar قبل إعادة توجيهه إلى الهدف.

الأهداف

عشرات خوادم MCP الهدف التي تعرض مئات الأدوات على بوابة واحدة، تُقدَّم عبر AgentCore Runtimes موزّعة على حسابات AWS متعددة. يحوّل كل Runtime خوادم MCP المحلية المعتمدة على stdio إلى نقاط نهاية Streamable HTTP يمكن الوصول إليها عبر البوابة.

يفتح المطور بيئة التطوير المتكاملة (IDE) الخاصة به، ويضبط عنوان MCP URL واحداً، ويصادق عبر SSO الخاص بالشركة، فتجمّع البوابة مئات الأدوات في استجابة tools/list واحدة. بلا إعداد محلي وبلا رموز لكل أداة.

فصل الهوية والوصول

كان القرار الأمني الأساسي هو فرض حدود القراءة والكتابة من خلال سياسة Cedar على مستوى البوابة.

بوابة واحدة، فصل مفروض بالسياسات:

تقبل البوابة رموز JWT (البشر عبر SSO الخاص بالشركة وCognito) و client_credentials الرموز (الوكلاء). تحدد سياسات Cedar ما يمكن لكل مبدأ فعله. يحصل البشر في المجموعات المعتمدة على وصول للقراءة. تتطلب عمليات الكتابة تصاريح Cedar صريحة تُمنح فقط لهويات وكلاء محددة.

تعزز Cedar التفصيل على مستوى كل أداة:

// Agent "sre-bot" can add comments on GitHub PRs
permit(
    principal == Agent::"sre-bot",
    action == Action::"tools/call",
    resource == Tool::"github_add_pr_comment"
);

// No human principal can invoke mutation tools
forbid(
    principal in Group::"humans",
    action == Action::"tools/call",
    resource in ResourceGroup::"write-tools"
);

تُدار سياسات Cedar كتعليمات برمجية من خلال طلبات سحب على GitHub مع تعليقات مراجعة، مما يمنح الفريق تحكماً بالإصدارات وسجلاً تدقيقياً لكل تغيير في الأذونات.

داخل البوابة، تحدد سياسات Cedar نطاق الوصول إلى الأدوات حسب مجموعة SSO، وتُربط المجموعات بالدور الوظيفي. يتمتع المهندسون افتراضياً بالوصول إلى بيئات التطوير والاختبار. أما الوصول إلى الإنتاج فيتبع ضوابط الأمن والامتثال لدى Eon: فهو للقراءة فقط، ويُمنح في الوقت المناسب (just-in-time) عبر عملية موافقة، ويخضع للتدقيق. تُحدد مجموعة العضو الجديد بنفس الطريقة، حسب الدور لا حسب الخدمة التي يملكها صدفةً. ولأن كل إجراء للوكيل يُفحص مقابل Cedar في وضع ENFORCE ويُقيَّد بمجموعة أدوات بأقل الامتيازات، يعمل الوكيل الذاتي ضمن حدود آمنة ومقيدة. لا يمكنه استدعاء سوى الأدوات المسموح لهوية snippet بها صراحةً باستدعائها.

«في السابق، لم يكن وكيلنا الداخلي قادراً على الوصول إلى أدوات التحقيق نفسها التي يستخدمها المطورون. بعد ذلك، يستخدم البوابة نفسها بهويته الخاصة ومجموعة أدوات أكثر تقييداً.»

— Roei Zavida، مهندس DevOps أول، Eon

الاتصال بين الحسابات

تشغّل Eon الـ Runtimes عبر حسابات AWS متعددة، منظمة حسب البيئة أو حدود الخدمة. تصل بوابة AgentCore Gateway إلى كل Runtime من خلال افتراض أدوار IAM عبر الحسابات. يثق الـ Runtime في الحساب B بدور تنفيذ بوابة AgentCore Gateway في الحساب A عبر سياسة ثقة IAM قياسية.

ما الذي ألغته هذه الطريقة:

• تهيئة VPC peering وإدارة جداول التوجيه عبر حسابات AWS متعددة.
• تكاليف نقاط نهاية PrivateLink لكل حساب.
• تنسيق مجموعات الأمان بين الحسابات.
• أيام من الإعداد لكل حساب جديد (استُبدلت بسياسة ثقة IAM واحدة، قابلة للنشر في دقائق).

أنماط ربط الأهداف:

بحسب نموذج المصادقة والاستضافة لكل أداة، تستخدم Eon نمطين أساسيين للربط. يلخص الجدول التالي متى تستخدم كل نمط ويقدم مثالاً.

معظم الأهداف تستخدم Runtime + IAM. أما Eon فيغلّف فقط MCP بعيدًا لتقليص كتالوجه أو إدراج بيانات اعتماد لا يستطيع البوابة توفيرها بطريقة أخرى.

مسار جلسة التحقيق

يتتبع المسار التالي مطوّرًا يحقق في حادث إنتاجي:

1. المصادقة. يفتح المطوّر Claude Code (أو Cursor/Codex) ويتصل بعنوان URL الخاص ببوابة MCP. تبدأ بيئة التطوير عملية OAuth عبر نظام SSO المؤسسي. يُصدر Cognito رمز JWT يحمل هوية المطوّر وعضوياته في المجموعات.
2. اكتشاف الأدوات. تجمّع البوابة `tools/list` من عشرات الأهداف المتصلة وتُعيد إلى بيئة التطوير بيانًا موحدًا يضم مئات الأدوات. يرى المطوّر جميع أدوات التحقيق المتاحة في قائمة واحدة.
3. استدعاء الأداة. يسأل المطوّر: «أرِني ارتفاع معدل الأخطاء لخدمة المدفوعات في الساعة الأخيرة.» يختار وكيل بيئة التطوير أداة استعلام Grafana ويرسل طلب `tools/call`.
4. تقييم السياسة. تقيّم البوابة الطلب مقابل Cedar. تمنح عضوية المطوّر في المجموعة إمكانية الوصول إلى أداة Grafana. يمرّ الطلب.
5. التنفيذ عبر Runtime. تعيد البوابة توجيه الطلب إلى Runtime الذي يستضيف خادم Grafana MCP (الذي يعمل في حساب AWS منفصل). يصادق Runtime على Grafana باستخدام بيانات اعتماد خدمة مخزّنة في خزنة AgentCore Identity، وينفّذ الاستعلام، ويُعيد النتائج.
6. الربط بين الأدوات. يتابع الوكيل بالتحقق من حالة النشر في Kubernetes ومو utile الطلب المرتبط على GitHub، ويُوجَّه كل منها إلى Runtimes مختلفة. يرى المطوّر نتائج مترابطة دون تبديل الأدوات أو إعادة المصادقة.

الدروس المستفادة عند التوسّع

كشف النشر لأكثر من 100 مطوّر ونحو 10,000 جلسة عن تحديات إنتاجية:

إدارة حجم سياسة Cedar

كل مخطط أداة تُفهرسه البوابة مسبقًا يسهم في حجم سياسة Cedar. مع عشرات الأهداف التي تعرض بيانات أدوات واسعة، اقتربت سياسة Eon من حصة الحجم المسموح بها. الحل: وضع العرض DYNAMIC للأهداف ذات العدد الكبير من الأدوات. في وضع DYNAMIC، تعيد البوابة توجيه tools/list الاستدعاءات إلى خادم MCP وقت الطلب بدلًا من الفهرسة المسبقة للمخططات، مما لا يضيف أي بايت إلى السياسة.

المقايضة هي أن البحث الدلالي في الأدوات غير متاح للأهداف في وضع DYNAMIC. تشغّل Eon تهيئة هجينة: وضع DEFAULT للأهداف التي تتطلب OAuth لكل مستخدم (أعداد أدوات أصغر، وتحتاج مخططات مفهرسة مسبقًا لتدفق الموافقة) ووضع DYNAMIC للأهداف ذات الكتالوجات الكبيرة.

ربط جلسة OAuth لعملاء MCP القياسيين

يتوقع Claude Code وCursor وCodex معامل OAuth state للحماية من تزوير الطلبات عبر المواقع (CSRF). يستخدم AgentCore ربط session-URI. أنشأت Eon طبقة وسيطة على Amazon API Gateway تترجم بين البروتوكولين بحيث يتمكن عملاء MCP القياسيون من إتمام تدفق OAuth دون تعديل.

تصفية أسطح الأدوات

بعض خوادم MCP تعرض مئات الأدوات. لا يحتاج المطوّرون الأفراد إلا إلى مجموعة فرعية لخدمتهم. أنشأت Eon غلاف Runtime يرشّح بيان الأدوات على مستوى الـ Runtime، مما يقلل التشويش في tools/list الاستجابات ويمنع الاستدعاء العرضي لعمليات غير ذات صلة. يحافظ هذا النهج أيضًا على بقاء تلك الأهداف في وضع DEFAULT، مما يحفظ البحث الدلالي والميزات المدمجة التي يضحّي بها وضع DYNAMIC.

النتائج

تم تشغيل بنية البوابة الواحدة في بيئة الإنتاج للفريق الهندسي الداخلي في Eon لعدة أشهر. النتيجة الأوضح هي تهيئة المطورين الجدد، إذ انخفض إعداد الوصول إلى مجموعة الأدوات الكاملة من نحو يومين من تكوين بيانات الاعتماد وخوادم MCP المحلية إلى نحو دقيقتين. يتصل المهندس الجديد بعنوان URL واحد للبوابة، ويثبت هويته عبر SSO المؤسسي، ويرى فورًا الأدوات التي يسمح بها دوره.

يمثل الوكيل الداخلي معظم الوقت الموفَّر، لأنه يحصل على سياق أوسع من خلال البوابة، مما يحسّن دقة التحقيق. ويوفر المهندسون الوقت الذي كان يُنفق سابقًا على إعداد أدوات الذكاء الاصطناعي، لأنهم يحتاجون فقط إلى الاتصال بعنوان URL للبوابة.

تستكشف Eon كيف يمكن للأنماط ذاتها أن تدعم قدرات الذكاء الاصطناعي في منتجها الخاص.

“منحنا AgentCore بوابة MCP واحدة مصادَقة بدلًا من الرموز المخصصة لكل أداة وعمليات MCP المحلية. أصبح المطورون ووكيلنا الداخلي الآن يصلون إلى Kubernetes وGrafana وGitHub وحساباتنا السحابية من عنوان URL واحد.”

— روعي زفيدا، مهندس DevOps أول، Eon

الخاتمة

وصفت هذه المقالة كيف استبدلت Eon بيانات الاعتماد المخصصة لكل أداة وعمليات MCP المحلية ببوابة Amazon Bedrock AgentCore MCP واحدة. والنتيجة هي فصل هويات قائم على Cedar، واتصال عبر الحسابات دون تزايد VPC، ووصول موحد إلى الأدوات لأكثر من 100 مطور ووكلاء مستقلين عبر ثلاث سحابات. إن بنية البوابة الواحدة، وتنفيذ الامتيازات الأدنى في Cedar، ووضع السياسات الهجين DEFAULT وDYNAMIC هي أنماط قابلة لإعادة الاستخدام لشركات البرمجيات المستقلة (ISVs) التي تربط الوكلاء والمطورين بالأدوات عبر سحابات متعددة.

للتعرف على المزيد حول البناء على Amazon Bedrock AgentCore، راجع هذه الموارد:

• وثائق Amazon Bedrock AgentCore Gateway.
• وثائق Amazon Bedrock AgentCore Runtime.
• ورشة البدء مع Amazon Bedrock AgentCore.

عن المؤلفين