الفرز هو المنتج: تشغيل وكلاء الذكاء الاصطناعي على كود بروتوكول إيثيريوم

ملاحظات من فريق أمان البروتوكول التابع لـ مؤسسة إيثيريوم حول تشغيل وكلاء ذكاء اصطناعي منسقين على كود بروتوكول حقيقي، بما في ذلك كيفية تنظيمنا للعمل، وما يصمد أمام التدقيق، وما يمكن لفرق العملاء وباحثي الأمان الاستفادة منه. هذا المنشور قائم بذاته؛ وستتعمق المنشورات اللاحقة في العملاء الفرديين.

ما كنا نقوم بتشغيله، وما فاجأنا

في فريق أمان البروتوكول التابع لـ مؤسسة إيثيريوم، كنا نقوم بتشغيل وكلاء ذكاء اصطناعي منسقين على أنواع الأنظمة التي تعتمد عليها شبكة، مثل برمجيات الأنظمة، وكود التشفير، والعقود التي يجب أن تكون صحيحة. وجد الوكلاء أخطاءً حقيقية. أحدها أصبح الآن علنيًا: حالة ذعر (panic) يمكن إطلاقها عن بُعد في gossipsub الخاص بـ libp2p، وهو جزء أساسي من طبقة نظير إلى نظير التي تعمل عليها عملاء إجماع إيثيريوم، وقد تم إصلاحه والإفصاح عنه كـ CVE-2026-34219 مع نسب الفضل للفريق.

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

هذا المنشور موجه لفرق العملاء وباحثي الأمان الذين يرغبون في القيام بالشيء نفسه. ويغطي كيفية تنظيمنا للوكلاء، والمعيار الذي يجب أن يتجاوزه المرشح قبل اعتباره اكتشافًا، والعادات التي تحافظ على موثوقية النتائج.

تتجه فرق أخرى في أماكن مختلفة نحو نفس الوصفة. قام فريق الحدود الأحمر (Frontier Red Team) التابع لشركة Anthropic ببناء وكيل يكتب اختبارات قائمة على الخصائص ووجد أخطاءً حقيقية عبر نظام Python البيئي. وقامت Cloudflare بتشغيل نموذج الحدود من خلال بيئة اختبار لأبحاث الأمان على أنظمتها الخاصة. يصل الجميع إلى نفس الحلقة: توجيه نموذج قادر نحو قاعدة برمجية، والسماح له بالبحث، وفرز ما يعود به. لذا فإن السؤال الحقيقي هو كيفية القيام بذلك دون الغرق في ضوضاء تبدو واثقة من نفسها.

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

الوكيل هو أداة بحث، وليس أوراكل

الوكيل الموجه نحو قاعدة برمجية هو أداة بحث، يشبه إلى حد كبير أداة اختبار التشويش (fuzzer). الاختلاف يكمن في ما يعود به. تمنحك أداة اختبار التشويش انهيارًا وتتبعًا للمكدس (stack trace). بينما يمنحك الوكيل أكثر من ذلك بكثير، بما في ذلك تقرير مكتوب (سلسلة الاستدعاءات، مطالبة التأثير، الخطورة المقترحة) والأدلة التي تدعمه، مثل إثبات المفهوم (proof-of-concept) الذي يمكنك تشغيله على الكود الحقيقي.

كل ذلك يجعل النتيجة سهلة القراءة وسهلة الثقة، وخاصة إثبات المفهوم القابل للتشغيل. لذا لا تحصِ عدد المرشحين الذين ينتجهم الوكيل. بل احصِ عدد الذين يتبين أنهم حقيقيون.

كيف يتم تنظيم العمل

نقوم بتشغيل العديد من الوكلاء بالتوازي على هدف واحد. ينسقون فيما بينهم من خلال المستودع نفسه، مع حالة مشتركة في نظام التحكم في الإصدارات وبدون عملية مركزية توزع العمل. يكتب الوكيل مطالبة حيث يمكن للآخرين رؤيتها، وينجز العمل، ثم يقوم بإيداعه (commits).

لقد استلهمنا هذا النهج من تقرير Anthropic حول بناء مترجم C باستخدام أسطول من الوكلاء، والذي ينسق بنفس الطريقة. لا يوجد منسق مركزي لبنائه أو صيانته، وهناك احتمالات أقل لحدوث أخطاء.

يتم إنشاء الأدوار من خلال العمل الذي يتم اكتشافه:

• الاستطلاع (Recon) يحول سطح الهجوم إلى فرضيات ملموسة وقابلة للاختبار. ليس "تدقيق وحدة فك التشفير" بل "هذا الحقل موثوق به بعد هذه النقطة؛ إليك الخاصية التي يجب أن يحتفظ بها، والطريقة التي قد ينكسر بها، والإثبات الذي سيحسم الأمر".
• الصيد (Hunting) يأخذ فرضية واحدة، ويتتبع مسار الكود، ويحاول بناء مُعيد إنتاج (reproducer).
• سد الفجوات (Gap-filling) ينظر إلى ما تم قبوله وما تم رفضه، ويكتب الدفعة التالية من الفرضيات، ويتتبع التغطية حتى لا يستمر الوكلاء في المرور على نفس المسار.
• التحقق (Validation) يعيد فحص كل مرشح بشكل مستقل، ويزيل التكرارات، ويتخذ القرار.

لم نخترع هذا المسار. تصف Cloudflare نفس المراحل: الاستطلاع، والصيد المتوازي، والتحقق المستقل، وإزالة التكرارات، وإعداد التقارير، وقد ساعد تقريرهم في تشكيل تقريرنا.

إليك كيف يبدو المرشح قبل أن يُعتبر اكتشافًا:

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

المخطط موجود لسبب ما. فهو يفرض مطالبة محددة وقابلة للاختبار وتعريفًا واضحًا للإنجاز. الوكيل الذي يتعين عليه كتابة إثبات يمكن ملاحظته لا يمكنه التراجع إلى القول "هذا يبدو محفوفًا بالمخاطر".

قابل لإعادة الإنتاج أو لم يحدث

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

مُعيد الإنتاج لا يقرأ التقرير المكتوب، ولا يهتم بمدى ثقة النموذج. فهو إما أن يعمل أو لا يعمل.

تكمن معظم قيمته في الإيجابيات الكاذبة التي يكتشفها. تظهر ثلاثة منها مرارًا وتكرارًا، وكل منها يمثل حصول الوكيل على نجاح لسبب خاطئ:

• حالة ذعر تحدث فقط في بناء التصحيح (debug build). قم بتجميعه وتشغيله بالطريقة التي يتم بها شحن البرنامج فعليًا، وستلتف القيمة ببساطة. لا شيء ينهار. يبدو وكأنه انهيار، لكنه ليس كذلك.
• مُعيد إنتاج يبني بعض القيم الداخلية يدويًا، وهي قيم لا يمكن لأي إدخال حقيقي أن ينتجها أبدًا، لأن كل مسار يتحكم فيه المهاجم يرفضها في وقت مبكر. الخطأ "يُعاد إنتاجه" فقط ضد دالة لا يستدعيها أي شيء يمكن الوصول إليه بهذه الطريقة.
• في أعمال التحقق الرسمي، إثبات يمر ولكنه لا يعني ما أردته. العبارة صحيحة بشكل بديهي بغض النظر عما يفعله الكود، أو أنها أضعف من الخاصية التي قصدت التقاطها. يكون متحقق راضيًا، لكن النظرية لا تقيد السلوك الذي اهتممت به فعليًا.

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

نسبة الإشارة إلى الضوضاء هي معظم العمل

معظم المرشحين يكونون إما خاطئين، أو مكررين، أو خارج النطاق. هذه ليست مشكلة في الطريقة؛ بل هكذا تعمل. الهدف هو رفض المرشحين الخاطئين بسرعة ودعم الحقيقيين بإثبات يصعب الجدال فيه.

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

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

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

لسنا الوحيدين الذين وجدوا أن الفرز هو الجزء الصعب. كانت النتيجة الرئيسية لـ Cloudflare هي أن النطاق الضيق يتفوق على المسح الواسع. قام وكيل الاختبار القائم على الخصائص التابع لـ Anthropic بإنشاء ما يقرب من ألف تقرير مرشح، ثم استخدم التصنيف ومراجعة الخبراء للوصول إلى فئة عليا صمدت في حوالي 86% من الوقت. كان الإنشاء هو الجزء السهل. لن أنشر أرقامنا الخاصة هنا؛ لأنها مرتبطة بهدف محدد، وستعبر عن الهدف أكثر مما تعبر عن الطريقة.

ما يجيده الوكلاء، وأين يضللون

هناك ضجة في كلا الاتجاهين، لذا إليك قائمة واضحة بما يفعله الوكلاء بشكل جيد وأين يضللون.

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

الصف الأخير هو الأهم. جلسة الوكيل الواحد جيدة في الاستنتاج من لقطة واحدة وسيئة في الأخطاء التي تمتد عبر تسلسل من الخطوات، حيث تكون كل خطوة صالحة والترتيب فقط هو الخاطئ. بالنسبة لهذه الأخطاء، لا يكون الوكيل هو أداة البحث. وظيفته هي اقتراح التسلسلات التي تستحق التشغيل من خلال بيئة اختبار ذات حالة (stateful test harness). عند استخدامه بهذه الطريقة، فإنه يعمل بشكل جيد. أما عند استخدامه كبديل لبيئة الاختبار، فإنه يغفل عن أكثر الأخطاء تكلفة، وهي تلك التي تظهر فقط عبر تسلسل.

الحفاظ على المصداقية

تقوم بعض العادات بمعظم العمل لجعل اكتشافات الوكيل جديرة بالثقة، ولا توجد أي منها معقدة.

• المصدر لكل أداة: ما الذي أنتجها، وبأي سياق، ومقابل أي مراجعة. يجب أن يكون الاكتشاف شيئًا يمكنك إعادة تشغيله بعد أشهر.
• الحتمية حيثما يهم الأمر: بيئة واحدة، وطريقة واحدة للبناء والتشغيل، بحيث تعني كلمة "يُعاد إنتاجه" نفس الشيء على كل جهاز، وليس فقط الجهاز الذي تم العثور عليه فيه.
• المعايير، وليس النصوص البرمجية (scripts): أخبر الوكلاء بما يهم، والثوابت، والمعيار لاكتشاف حقيقي، بدلاً من إجراء مرقم. الوكلاء المبرمجون بشكل مفرط ينكسرون بنفس الطريقة التي تنكسر بها الاختبارات المحددة بشكل مفرط، حيث يستمرون في اتباع الخطوات بعد أن تتوقف الخطوات عن كونها منطقية. وجدت دراسة لملفات سياق المستودع نفس الشيء: أدت المتطلبات الإضافية إلى خفض نجاح المهمة وزيادة التكلفة بأكثر من 20%، ويوصي المؤلفون بإبقاء السياق عند الحد الأدنى من المتطلبات.
• شخص يتخذ القرار النهائي: الوكلاء يقترحون. إنهم لا يقررون ما هو حقيقي، أو ما هو تكرار لمشكلة معروفة، أو ما يتم الإفصاح عنه ومتى.

انتقال عنق الزجاجة

لم يستبدل الذكاء الاصطناعي باحث الأمان. بل نقل العمل. الوقت الذي كان يُقضى في التوصل إلى الفرضيات ومطاردتها يذهب الآن إلى الحكم عليها على نطاق واسع، بما في ذلك بناء أوراكل، وتشغيل الفرز، والاحتفاظ بقائمة المشكلات المعروفة، والتعامل مع الإفصاح.

لم يختفِ عنق الزجاجة. بل انتقل من العثور على الأخطاء إلى الثقة في النتائج، وهو مكان أفضل له، لأن هذا هو المكان الذي يهم فيه الحكم البشري فعليًا. لكنه لا يزال عنق زجاجة، وتجاهل ذلك هو ما يؤدي في النهاية إلى شحن عبارة "كل شيء على ما يرام" الخاطئة.

الممارسات التي تجعل هذا العمل ناجحًا ليست جديدة. الإخفاقات القابلة لإعادة الإنتاج، والأوراكل الحقيقية، والفرز الدقيق هي نفس الممارسات التي حولت اختبار التشويش (fuzzing) من موضوع بحثي إلى ممارسة قياسية على مدار الخمسة عشر عامًا الماضية. الأدوات جديدة. لكن الممارسات ليست كذلك.

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

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