ما فعله الباحثون
نشرت زينيتي لابس في 8 أكتوبر الجزء الأول من سلسلة تسميها AgentCorruption. والهدف هو Amazon Bedrock AgentCore Runtime، الخدمة المدارة التي تستخدمها الشركات لتشغيل وكلاء الذكاء الاصطناعي على أمازون ويب سيرفسز.
نشر الباحثون وكيلًا تجريبيًا مبنيًا بـStrands، وهي حزمة تطوير الوكلاء مفتوحة المصدر من أمازون، مستخدمين أداتها المدمجة http_request. ثم طلبوا من الوكيل أن يستعلم من نقطة بيانات المثيل الوصفية على العنوان 169.254.169.254 وأن ينقل الرد إلى مستمع يسيطرون عليه. ففعل. وكرروا النتيجة نفسها عبر أداة shell في الحزمة.
خلاصة زينيتي تتعلق بالمنصة لا بالأداة: “لم يقيّد الجهاز الافتراضي المصغّر حركة البيانات إلى خدمة البيانات الوصفية”، و”إخفاق العزل يقع على مستوى المنصة لا على مستوى الأداة”.
ما أفصحت عنه البيانات الوصفية
أعادت خدمة البيانات الوصفية اسم دور تشغيل الوكيل وبيانات اعتماده المؤقتة من خدمة STS. وأكد الباحثون أن هذه البيانات تعمل خارج AgentCore تمامًا: إذ أعاد الأمر aws sts get-caller-identity الدور الذي تقمّصه الوكيل.
ومن هناك واصلت البيانات الوصفية العطاء. كشفت بيانات المستخدم عن معرّف صورة حاوية الوكيل في سجل الحاويات المرن. وكشفت وسوم المثيل عن مادة شهادة ومفتاح mTLS وعن رابط S3 موقّع مسبقًا.
لماذا وصل وكيل واحد إلى الجميع
دور التشغيل هو الجزء الذي تشتد عليه زينيتي: “الدور الذي يربطه AgentCore افتراضيًا ببيئة تشغيل الوكيل مفرط الصلاحيات بشكل سيئ”. فقد حمل صلاحيات قراءة في سجل الحاويات مع أحرف بدل، ويسمّي AgentCore مستودعات الصور بنمط يمكن توقعه هو bedrock-agentcore-<اسم_الوكيل>.
حوّل هذا المزيج وكيلًا واحدًا مخترقًا إلى دليل بكل الوكلاء الآخرين في الحساب والمنطقة نفسيهما. وبعبارة الباحثين: “تشغيل أداتنا الآلية على كل الوكلاء المكتشفين أعطانا كل الشيفرة المصدرية لكل وكلاء المنطقة خلال ثوانٍ”. وتقول زينيتي إن المنشورات اللاحقة ستتناول قدرات القراءة والكتابة والحذف داخل AgentCore وخدمات أمازون الأخرى في المنطقة.
ما غيّرته أمازون وما تقوله الآن
الجدول الزمني لزينيتي غير متسق مع نفسه: فالنص يقول إن النتائج أُرسلت إلى أمازون في 17 ديسمبر 2025، بينما يؤرخ جدولها الخاص الإفصاح عن مشكلة IMDS بـ25 ديسمبر 2025. أما التواريخ اللاحقة فأوضح. ففي 14 فبراير 2026 انتقل AgentCore إلى IMDSv2 حصرًا، فصار الوكلاء المنشورون حديثًا يبدأون به. وفي 12 أبريل 2026 ردّت أمازون وأغلقت التقرير بوصفه “إعلاميًا”. ولم يُخصص أي رقم CVE.
موقف أمازون، في تصريح نقله ذا ديكودر في 9 أكتوبر، هو أن البحث “يصوّر على نحو غير دقيق سلوكًا متوقعًا وموثقًا بوصفه ثغرة”. وقالت الشركة إن الوكيل لا يمكنه بلوغ موارد حساب آخر إلا حين يمنح المطوّر صلاحيات صريحة على دور التشغيل وعلى المورد المستهدف معًا، وتحيل إلى وثائق صلاحيات بيئة التشغيل الخاصة بها وإلى أدوار الحد الأدنى من الامتيازات. ويذكر ذا ديكودر أن أمازون ضيّقت لاحقًا دور التشغيل الافتراضي أيضًا، فأزالت صلاحيات استدعاء وكلاء آخرين وقراءة المحادثات الخاصة وجلب بيانات الاعتماد من Secrets Manager.
الخلاف تحت السطح
يتفق الطرفان على الآلية ويختلفان على من كانت المسؤولية. حجة أمازون أن الدور الافتراضي نقطة بداية وأن الوثائق تطلب تضييقه. وحجة زينيتي أن بيئة تشغيل وكلاء مدارة لا تمنع صندوقها الرملي خدمة البيانات الوصفية، ويستطيع دورها الافتراضي تعداد جيرانه، إنما تشحن إعدادًا افتراضيًا لن يغيّره معظم العملاء أبدًا.
هذا هو النقاش نفسه الذي خاضه قطاع الحوسبة السحابية حول حاويات S3 العامة، وقد حُسم بتغيير الإعداد الافتراضي لا الوثائق.
ما يجب متابعته
تقول زينيتي إن هذه الحلقة الأولى. والحلقات اللاحقة هي المهمة: الوصول الأولي إلى بيانات الاعتماد نتيجة خطيرة، لكن ما لفت الانتباه هو التحرك الجانبي بين كل وكلاء المنطقة، وهذا الجزء لم يُنشر بتفصيل بعد.
أما لمن يشغّل وكلاء على AgentCore اليوم فالإجراء المطلوب ليس محل خلاف. فالمزوّد ومنتقدوه يقولون الشيء ذاته: لا تطلقوا الإنتاج على دور التشغيل الافتراضي.
