نشرت Zenity Labs في 8 أكتوبر 2026 بحثًا بعنوان AgentCorruption عن خدمة Amazon Bedrock AgentCore. الخلاصة: باحثون لم يكن لديهم سوى إمكانية الدردشة مع وكيل ذكاء اصطناعي عام أرسلوا إليه أمرًا نصيًا واحدًا، ومنه وصلوا إلى كل وكلاء AgentCore الآخرين في الحساب والمنطقة نفسيهما على AWS. قرأوا محادثات خاصة، وسحبوا صور الحاويات الخاصة بالوكلاء، وزرعوا ذكريات غيّرت سلوك الوكلاء لاحقًا، واستخرجوا أسرارًا من AWS Secrets Manager.
قلّصت AWS منذ ذلك الحين الصلاحيات الافتراضية، وتقول Zenity إن المشكلات المبلّغ عنها عولجت. لذلك ليست هذه قصة «رقّع الليلة». إنها درس في التصميم ينطبق على كل فريق يضع وكيل ذكاء اصطناعي أمام المستخدمين، أيًا كانت السحابة أو الإطار.
كيف تحوّل أمر واحد إلى اختراق على مستوى المنطقة
لم تحتج السلسلة إلى أي ثغرة في الذاكرة. احتاجت فقط إلى وكيل لديه أداة لطلبات الويب، ودور (Role) بصلاحيات أوسع من اللازم. بحسب تقرير Zenity:
- طلب الأمر من الوكيل فتح عنوان البيانات الوصفية المحلي 169.254.169.254 من داخل الـ microVM الخاص به. هذا تزوير طلب من جهة الخادم (SSRF) يُقاد بالنص بدل الشيفرة.
- ردّت خدمة البيانات الوصفية ببيانات اعتماد مؤقتة لدور التنفيذ الافتراضي للوكيل.
- كان هذا الدور يستطيع سرد مجموعات السجلات، فكشف معرّفات الوكلاء الآخرين في المنطقة. وكانت مستودعات الحاويات تحمل أسماء هذه المعرّفات، فأمكن سحب الصور أيضًا.
- بصلاحية
bedrock-agentcore:InvokeAgentRuntimeأمكن استدعاء وكلاء آخرين، وبصلاحيةListEventsقراءة المحادثات عبر الوكلاء والمستخدمين والجلسات، وبصلاحيةCreateEventكتابة ذكريات مزيفة توجّه الجلسات اللاحقة. - وكشفت
bedrock-agentcore:GetResourceApiKeyوsecretsmanager:GetSecretValueبيانات اعتماد الخدمات المتصلة.
الجزء المتعلق بالذاكرة هو الأخطر. الجلسة المسروقة تنتهي، أما الذاكرة المسمومة فتظل تؤثر في كل مستخدم يتحدث إلى الوكيل بعدها، دون أن يظهر أي تسجيل دخول جديد.
موقف AWS ولماذا يملك الطرفان جزءًا من الحق
استمر الإفصاح قرابة عام. أبلغت Zenity عن الوصول إلى البيانات الوصفية في 25 ديسمبر 2025، وعن الدور الافتراضي الواسع في 12 يناير 2026. انتقلت AgentCore إلى IMDSv2 فقط في 14 فبراير، وبحلول 29 سبتمبر، أثناء المراجعة النهائية لـ Zenity، كان الدور الافتراضي قد قُلّص بشكل كبير. أما بيان AWS فيصف سلوك البيانات الوصفية بأنه موثّق ومتوقع.
وهو موثّق فعلًا. تقول صفحة إدارة بيانات الاعتماد في AgentCore إن أي شيفرة أو جهة تعمل داخل الجهاز الافتراضي يمكنها الوصول إلى هذه البيانات باستدعاء نقطة البيانات الوصفية، وتوصي بمبدأ أقل الصلاحيات، خصوصًا مع النماذج اللغوية القادرة على توليد شيفرة عشوائية. المشكلة أن الإعدادات الافتراضية هي التي تنتصر. كثير من الفرق تنشر الدور الذي تنشئه الخدمة لها، وكان الدور الافتراضي هنا واسعًا.
ما الذي تراجعه في إعداد وكلائك هذا الأسبوع
- تعامل مع خانة الأوامر كعميل شبكة. إذا كان الوكيل يستطيع جلب عناوين الويب فهو يستطيع جلب العناوين الداخلية. احجب النطاقات المحلية والخاصة في طبقة الخروج من الشبكة، لا في الأمر النظامي.
- دور مستقل لكل وكيل، محصور في موارده. روبوت الدردشة العام لا ينبغي أن يحمل صلاحيات تشير إلى وكلاء آخرين أو ذاكرة غيره أو مخزن الأسرار كله. ابدأ بإزالة الرموز الشاملة من ARN.
- أبعد الأسرار عن بيانات اعتماد الوكيل نفسه. إذا احتاج الوكيل مفتاح API فليُجلب عبر خدمة منفصلة لا يتحدث إليها النموذج مباشرة.
- افصل الوكلاء العامين عن الداخليين في حسابات منفصلة، أو على الأقل بأدوار لا تستطيع استدعاء بعضها.
- اجعل الكتابة في الذاكرة مرئية. سجّل كل حدث ذاكرة مع جلسته المصدر، وراجع الذكريات طويلة الأمد الجديدة كما تراجع تغيير إعدادات.
- راقب الاستدعاءات المملة. دور روبوت دردشة يسرد مجموعات السجلات أو يقرأ الأسرار في الثالثة فجرًا إشارة واضحة. ضع تنبيهًا لها.
تناولنا جانب الأدوات من المشكلة نفسها في قائمة تدقيق خوادم MCP الخبيثة: كل ما يستطيع الوكيل استدعاءه يستطيع المهاجم الذي يتحدث إليه استدعاءه أيضًا.
أين يقف FanMind
FanMind مساعد للمستندات، لذا فمساحة تعرضه أضيق من وكيل عام لديه وصول إلى سطر الأوامر. القاعدة التي نلتزم بها هي نفسها التي كسرها AgentCorruption: النموذج لا يملك أبدًا صلاحيات أكثر من الشخص الذي يسأل. يُصفّى الاسترجاع وفق صلاحيات المستخدم قبل أن يصل أي شيء إلى النموذج، ويجب أن تستشهد الإجابة بمستند وصفحة، والبحث على الويب محدود وليس مفعّلًا لكل سؤال. شرحنا جانب التحكم في الوصول في لماذا لا يستطيع مساعد ذكاء اصطناعي عام قراءة مستندات مؤسستك ببساطة. قد يُخدع النموذج بأمر نصي، والمهم هو مدى ضآلة ما يصل إليه هذا الخداع.
لمعرفة ما يجب تسجيله لكل استدعاء أداة، راجع دليل سجلات تدقيق خوادم MCP.
الأسئلة الشائعة
هل لا يزال AgentCorruption قابلًا للاستغلال؟
تقول Zenity إن AWS عالجت المشكلات المبلّغ عنها، وإن الدور الافتراضي في AgentCore تغيّر بشكل كبير بحلول 29 سبتمبر 2026. أما الوكلاء الذين نشرتهم سابقًا بدور مخصص واسع من إعدادك فمسألة منفصلة، فراجع تلك الأدوار بنفسك.
هل يعنيني الأمر إن لم أكن على AWS؟
نعم. السلسلة هي حقن أوامر مع أداة طلبات ويب وهوية بصلاحيات واسعة. النمط نفسه يعمل على أي منصة وكلاء تستطيع بيئة تشغيلها الوصول إلى خدمة بيانات وصفية أو تحمل بيانات اعتماد واسعة.
ما الإصلاح الأكثر فائدة؟
احصر دور التنفيذ في الوكيل الواحد والموارد التي يحتاجها بالضبط، واحجب الطلبات الصادرة إلى العناوين المحلية والخاصة. معًا يجعلان بيانات الاعتماد المسروقة شبه عديمة الفائدة.
لماذا الذاكرة المسمومة أسوأ من المحادثات المسروقة؟
المحادثات المسروقة تسريب لمرة واحدة. أما الذاكرة المزروعة فتغيّر ما يفعله الوكيل لكل مستخدم لاحق، وتبدو كسلوك طبيعي، فتبقى حتى يراجع أحدهم مخزن الذاكرة.
