الدور الافتراضي، لا النموذج: كيف استولى موجّه واحد على كل الوكلاء في حساب AWS

النقاط الرئيسية

• موجّه واحد أُرسل إلى وكيل متاح للجمهور اخترق كل وكلاء AgentCore في حساب AWS نفسه ومنطقته — كشف Zenity Labs عن سلسلة AgentCorruption في 8 أكتوبر 2026 في مؤتمر SecTor بتورونتو، بعد عملية إفصاح مسؤول بدأت في 25 ديسمبر 2025.
• نطاق الضرر كان خاصية للدور لا للنموذج — حمل دور التنفيذ الافتراضي صلاحيات bedrock-agentcore:InvokeAgentRuntime وbedrock-agentcore:ListEvents وصلاحية كتابة في الذاكرة عبر الوكلاء وbedrock-agentcore:GetResourceApiKey وsecretsmanager:GetSecretValue، وكلها بنطاق يمتد على منطقة الحساب بأكملها لا على الوكيل الواحد.
• الإصلاح استغرق 278 يومًا — نقلت AWS منصة AgentCore إلى IMDSv2 بحلول 14 فبراير 2026، لكن إعادة فحص Zenity في 22 يونيو 2026 وجدت الدور الافتراضي دون تغيير؛ ولم تُطبَّق إزالة الصلاحيات إلا في 29 سبتمبر 2026.
• ذاكرة الوكيل سطح استمرار — زرع الباحثون ذكريات تعيد توجيه محادثات الوكلاء المستقبلية إلى وجهة يتحكم فيها المهاجم، بينما واصل المستخدمون الحديث مع ما يبدو وكيلًا مؤسسيًا موثوقًا.
• وصفت AWS السلوك بأنه «documented and expected» — وتنصح العملاء بمنح أدوار التنفيذ الصلاحيات التي يحتاجها وكلاؤهم فقط. مراجعة الدور الافتراضي هي مسؤولية العميل، على أي منصة مُدارة.

في 8 أكتوبر 2026، في مؤتمر SecTor بتورونتو، كشف Zenity Labs عن AgentCorruption: سلسلة من الثغرات في Amazon Bedrock AgentCore، منصة AWS المُدارة لنشر وكلاء الذكاء الاصطناعي وتشغيلهم. موجّه واحد أُرسل إلى وكيل عام — وكيل خدمة عملاء مكشوف على الإنترنت مثلًا — أعاد بيانات اعتماد AWS المؤقتة المخصصة لآلة ذلك الوكيل. كانت تلك البيانات ملكًا لدور IAM افتراضي لم تُقيَّد صلاحياته بذلك الوكيل، بل بكل وكلاء AgentCore في حساب AWS نفسه ومنطقته. بواسطتها استدعى الباحثون وكلاء داخليين لم يكونوا مخوّلين لهم قط، وقرأوا المحادثات الخاصة عبر الوكلاء والمستخدمين، ونزّلوا صور الحاويات الخاصة بالوكلاء لاستخراج الكود المصدري، وسحبوا مفاتيح API ورموز OAuth من AWS Secrets Manager، وزرعوا ذكريات ظلت تعمل بعد انتهاء الجلسة.

لم يتطلب أي من ذلك فشلًا في النموذج. المهمة الوحيدة للنموذج في السلسلة كانت إرسال طلب HTTP واحد عندما يُطلب منه ذلك. كل ما تلا ذلك كان IAM. يرسم هذا المقال سلسلة الهجوم المكونة من خمس خطوات، والصلاحيات المحددة التي جعلت كل خطوة ممكنة، والجدول الزمني للإفصاح البالغ 278 يومًا، والأسئلة الخمسة التي ينبغي على أي فريق طرحها قبل نشر وكلاء على منصة وكلاء مُدارة — أيًّا كان مزوّدها.

سلسلة الهجوم، خطوة بخطوة

نشر Zenity Labs البحث كاملًا كسلسلة تقنية من خمسة أجزاء؛ وتنضغط السلسلة في خمس حركات.

الخطوة 1: حقن موجّه نحو IMDS. يعمل وكلاء AgentCore داخل أجهزة Firecracker microVM الافتراضية الدقيقة التي لم يمنع عزلها الشبكي خدمة بيانات تعريف المثيل. أي أداة وكيل قادرة على إرسال طلب HTTP صادر ترسل ذلك الطلب من داخل المثيل نفسه — وهذه أولية SSRF. موجّه واحد وجّه الوكيل المكشوف إلى استدعاء 169.254.169.254، خدمة بيانات تعريف المثيل، التي سلمت بيانات اعتماد IAM المؤقتة للدور المخصص لعبء العمل. كانت كلفة الدخول هي الوصول الدردشي إلى وكيل واحد بأداة شائعة الاستخدام.

الخطوة 2: الاستكشاف على مستوى الحساب. كانت بيانات الاعتماد ملكًا لدور تنفيذ افتراضي غير مقيّد بالوكيل المعني. ومن بين صلاحياته DescribeLogGroups، التي استخدمها الباحثون لسرد كل وكيل ومعرّفه عبر منطقة الحساب بأكملها. وجاء مسار استكشاف ثانٍ مجانًا: أسماء مستودعات Elastic Container Registry كانت مطابقة لمعرّفات الوكلاء، فمكّنت صلاحية السحب من ECR الباحثين من تنزيل صورة حاوية أي وكيل وقراءة كوده المصدري كاملًا.

الخطوة 3: الحركة الجانبية. تضمّن الدور صلاحية bedrock-agentcore:InvokeAgentRuntime بنطاق يمتد على المنطقة كلها. استطاع الباحثون استدعاء أي وكيل AgentCore في الحساب — بما في ذلك وكلاء داخليون حساسون لم يكن مصرّحًا لهم بالوصول إليهم. المثال المشروح في الكشف: مهاجم يدخل عبر وكيل خدمة العملاء المكشوف على الإنترنت يتحرك جانبيًا إلى وكيل مالي داخلي في المنطقة نفسها، فيستدعيه ويصل إلى بياناته وأدواته وبيانات اعتماده.

الخطوة 4: الوصول إلى البيانات وبيانات الاعتماد. أعادت bedrock-agentcore:ListEvents كل المحادثات الخاصة لكل الوكلاء والمستخدمين والجلسات — حدود الخصوصية الخاصة بالمنصة وقد ذابت. ثم وصلت bedrock-agentcore:GetResourceApiKey وsecretsmanager:GetSecretValue إلى بيانات الاعتماد التي تعمد AgentCore إبعادها عن الوكيل: مفاتيح API ورموز OAuth وإدخالات Secrets Manager، بما فيها بيانات الاعتماد المستخدمة للاتصال بموارد المؤسسة وخدمات الطرف الثالث خارج AWS.

الخطوة 5: الاستمرار عبر الذاكرة. حمل الدور أيضًا صلاحية كتابة في الذاكرة — bedrock-agentcore:CreateEvent على BedrockAgentCoreMemory. أنشأ الباحثون ذكريات جديدة عبر وكلاء ومستخدمين مختلفين غيّرت سلوك الوكلاء تغييرًا مستمرًا واختطفت أهدافهم عبر الجلسات المقبلة، موجهة المحادثات إلى وجهة يتحكم فيها المهاجم. نجا الاختراق من الجلسة التي أنشأته.

المخطط التالي يرسم الحركات الخمس وما كشفه كل منها:

الدور، لا النموذج

الدرس البنيوي يكمن فيما لم تتطلبه الخطوات الخمس. لا كسر لقيود النموذج، ولا فشل في المواءمة، ولا هندسة موجّهات متطورة تتجاوز «استدعِ هذا العنوان». صاغ مايكل بارغوري، الشريك المؤسس والمدير التقني في Zenity، السبب الجذري كتوتر تصميمي تُشحن معه كل منصة: «أمن السحابة كله يتعلق بالتقسيم والوصول بأقل امتياز. أما وكلاء الذكاء الاصطناعي فيحتاجون إلى مساحتهم الإبداعية ليكونوا مفيدين. وخلط الاثنين يخلق تعارضًا كامنًا في التصميم». وخلاصته: «كل شركة تنشر وكلاء في السحابة ستواجه الخيارات الجوهرية نفسها بين الوكالة وأقل الامتياز».

حلّ AgentCore هذا التعارض لصالح الوكالة — لراحة المنصة، لا لأمن العميل. كان دور التنفيذ الافتراضي واسعًا كي تعمل الوكلاء فور التشغيل، وكانت صلاحياته تغطي كل موارد الوكلاء في منطقة الحساب. بيان AWS نفسه، المنشور مع البحث، يقول إن السلوك «documented and expected»، وإن الوكلاء يستطيعون الوصول إلى بيانات اعتماد دور تنفيذهم عبر خدمة بيانات التعريف، وإنه «كممارسة مثالية، ننصح العملاء بمنح أدوار التنفيذ الصلاحيات التي يحتاجها وكلاؤهم فقط»، مشيرًا إلى إدارة بيانات الاعتماد وصلاحيات وقت التشغيل وإرشادات أقل الامتياز.

قراءة هذين الحقيقتين معًا تجعل موقف المشتري قاطعًا: تعامل المنصة الدور الافتراضي كنقطة انطلاق، وتعامل نطاق ضرر الوكيل المخترق كمسألة تهيئة تقع على العميل. وهذا موقف مشروع لمزوّد سحابي — فأقل الامتياز في IAM كان مسؤولية العميل منذ وُجد IAM. لكنه يصطدم بإطار تسويق منصات الوكلاء المُدارة، وهو أن المنصة تتكفل بالتحصين التشغيلي حتى لا تضطر فرقتك إلى ذلك. سلسلة AgentCorruption هي شكل هذا الاصطدام عمليًا: كان الافتراضي الخاص بالمنصة هو الثغرة، وكان توثيق المنصة هو التخفيف.

278 يومًا من الإفصاح إلى الإصلاح

الجدول الزمني للإفصاح هو الدرس الثاني. أبلغت Zenity عن وصول IMDS الأولي في 25 ديسمبر 2025. حدّثت AWS منصة AgentCore إلى IMDSv2 حصريًا للوكلاء المنشورة حديثًا بحلول 14 فبراير 2026، وأغلقت ذلك التقرير الأول بوصفه «معلوماتيًا» في 12 أبريل. لكن تقرير Zenity الثاني — نطاق ضرر الدور الافتراضي، المقدم في 12 يناير 2026 — سار أبطأ. في 25 فبراير قالت AWS إن الفريق يعمل عليه بنشاط بينما بقي الدور الافتراضي كما هو. في 22 يونيو 2026 أعادت Zenity الفحص وأكدت أن الصلاحيات لم تتغير. الإصلاح الجوهري — إزالة الصلاحيات التي كانت تتيح تنفيذ الوكلاء على نطاق واسع وقراءة المحادثات الخاصة والوصول إلى Secrets Manager — رُصد في 29 سبتمبر 2026، بعد 278 يومًا من الإفصاح الأول وقبيل النشر العام بأيام.

التاريخ	الحدث
25 ديسمبر 2025	تبلغ Zenity شركة AWS عن وصول IMDS الأولي
12 يناير 2026	تقدم Zenity تقرير نطاق ضرر الدور الافتراضي
14 فبراير 2026	انتقال AgentCore إلى IMDSv2 حصريًا للوكلاء المنشورة حديثًا
25 فبراير 2026	تؤكد AWS أن العمل جارٍ؛ الدور الافتراضي دون تغيير
12 أبريل 2026	تغلق AWS تقرير IMDS بوصفه «معلوماتيًا»
22 يونيو 2026	إعادة فحص Zenity: الدور الافتراضي ما يزال دون تغيير
29 سبتمبر 2026	تحصين الدور الافتراضي — إزالة صلاحيات العبور بين الوكلاء وقراءة المحادثات وSecrets Manager

هناك دلالتان لكل فريق يعتمد على الافتراضيات في منصة مُدارة. الأولى: قد يظل افتراضي مصمم للراحة ثغرة قائمة قرابة عام كامل حتى بعد إفصاح مسؤول — النافذة بين «بلّغنا» و«أُصلح» تقاس بالأشهر، ووكلاؤكم يعملون داخلها. والثانية: الإصلاح نفسه هو البرهان على الأطروحة: لم تعِد AWS تدريب نموذج ولم تُضِف مرشح أمان. بل عدّلت سياسة دور. كان نطاق الضرر طوال الوقت مستند IAM واحدًا.

الذاكرة سطح استمرار

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

وهذه هي فئة تعديل السلوك ذاتها التي دفعت Anthropic إلى قطع الوصول الحي إلى الإنترنت عن كل تقييمات الوكلاء الداخلية، كما كشفت في أكتوبر 2026 — وهو موضوع مختبران رائدان واعتراضٌ واحد. يغطي ذلك المقال إقرار المختبر الرائد بأن تدريب المواءمة وحده لا يكفي للسيطرة على سلوك الوكلاء. ويُظهر AgentCorruption المشكلة نفسها طبقة أدنى، في طبقة المنصة: مخزن ذاكرة يمكن لأي شيء يحمل صلاحية IAM الصحيحة أن يكتب فيه هو آلية استمرار — وعلى معماريات مفتاح الإيقاف التي يغطيها مفتاح الإيقاف بالتصميم أن تعامل الذاكرة كجزء من الحالة المخترقة، لا كجزء من وقت التشغيل فحسب.

خمسة أسئلة قبل النشر على أي منصة وكلاء مُدارة

AgentCore هو المثال المشروح، لا الاستثناء. بيان Zenity الصحفي يطرح النقطة العامة بنفسه: تشغّل المؤسسات بانتظام وكلاء مواجهين للعملاء ووكلاء داخليين جنبًا إلى جنب في بيئات السحابة نفسها، ونقطة ضعف واحدة غير متوقعة في وكيل واحد قد تُنهار بها حدود بيئة كاملة. المنصة ستختلف؛ أما فئات الصلاحيات فستتشابه. قبل دخول أي وكيل حيز الإنتاج على منصة مُدارة، احصل على إجابات مكتوبة عن هذه الأسئلة الخمسة:

1. ما الذي يحتويه دور التنفيذ الافتراضي بالضبط؟ ليس «هل هو آمن افتراضيًا» — بل مستند السياسة، صلاحية بصلاحية. علّم كل صلاحية نطاقها * أو جميع وكلاء الحساب. سلسلة AgentCorruption هي إجابة من خمس صلاحيات عن هذا السؤال.
2. هل يستطيع وكيل واحد اكتشاف الوكلاء الآخرين؟ أي صلاحية سرد أو وصف على مستوى الحساب تحوّل وكيلًا مخترقًا إلى جرد أهداف. كانت DescribeLogGroups خطوة التعداد؛ ولكل منصة سطح سرد مكافئ.
3. هل يستطيع وكيل استدعاء وكيل آخر؟ الاستدعاء بين الوكلاء هو أولية الحركة الجانبية. إن كانت المنصة لا تستطيع تقييد الاستدعاء بقوائم سماح صريحة لكل وكيل، فتعامل مع كل وكلاء الحساب كنطاق ثقة واحد — لأن المهاجم سيتعامل معهم كذلك.
4. أين تُخزَّن بيانات اعتماد الأدوات، وأي دور يستطيع قراءتها؟ لا تنقل بوابة الأسرار الخطر إلا إذا لم يستطع أي دور وكيل استدعاء GetSecretValue عليها. كان دور AgentCorruption يقرأ تحديدًا بيانات الاعتماد التي صُمم نظام المنصة على إبعادها عن الوكلاء.
5. هل يمكن لغير الوكيل نفسه، خارج جلسته، الكتابة في الذاكرة؟ عمليات الكتابة في الذاكرة عبر الوكلاء والمستخدمين تحوّل مخزن الذاكرة إلى سطح استمرار. إن كانت الإجابة صلاحية يمكنك تقييدها فقيّدها؛ وإن لم تكن كذلك، فأدخل مخزن الذاكرة في خطة استجابتك للحوادث بوصفه حالة يتحكم فيها المهاجم.

قراءات ذات صلة

• Bedrock vs OpenAI: اختيار منصة ذكاء اصطناعي مُدارة لوكلاء الإنتاج — مقارنة المنصات المُدارة التي يقع عليها هذا الحادث: التكلفة والخصوصية واستقرار المزوّد، مع إضافة مسألة الدور الافتراضي الآن إلى قائمة العناية الواجبة
• 126 حادثة في شهر واحد: أول جرد شامل لأمن الذكاء الاصطناعي وما يثبته عن مخاطر الوكلاء — بيان التواتر الذي يقف خلف هذا الحادث: كانت استغلالات طبقة الوكلاء أكبر فئة لنواقل الهجوم في سبتمبر 2026
• قائمة مراجعة حوكمة وكلاء الذكاء الاصطناعي: مراجعة ما قبل النشر لوكلاء الإنتاج — مراجعة ما قبل النشر الكاملة، بما فيها أدوار التنفيذ بأقل امتياز والاستكشاف بين الوكلاء كبندي مراجعة

موزّع صناعي متوسط الحجم يشغّل وكيلين على منصة مُدارة — وكيل عروض أسعار عام أمام واجهة متجره وكتالوجه على BigCommerce، ووكيل داخلي بمستويات أسعار NetSuite وصلاحية وصول إلى المخزون — يملك تمامًا الطبولوجيا التي استغلها AgentCorruption: وكيل مكشوف على الإنترنت ووكيل مهام خلفية في الحساب نفسه. النمط الذي نبني به يمنح كل وحدة موصل دورها الخاص بأقل امتياز، ويسجّل كل أداة يمكن للوكيل استدعاءها، ويقيّد الذاكرة لكل وكيل، ويكتب مسار تدقيق يُظهر الكتابة في الذاكرة من خارج الجلسة. والغاية ليست أن البناء المقيّد الصلاحيات محصّن ضد عيب من جانب المنصة؛ بل إن نطاق ضرر الحادثة القادمة تحدده سياسة الدور التي راجعتها فرقتكم، لا تلك التي شحنتها المنصة كافتراضي.

أسبوع اكتشاف واحد. تحصل على جرد للأنظمة وخريطة لتدفقات العمل ونطاق ثابت — سواء بنيت معنا أو لا.

اطلب بناءً بنطاق محدد.