نموذج OpenAI استخدم عملة اختبار الإيثيريوم دون إذن، وتم اكتشافه بعد ثلاثة أشهر

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

كتبه: angelilu، أخبار Foresight

قامت OpenAI في 15 أكتوبر بتحديث تقرير داخلي عن الحادث: استخدم نموذج بحثي أثناء تنفيذ مهمة برمجية محفظة اختبار مشفرة تحتوي على أموال دون إذن.

حدثت الواقعة في 26 يونيو 2026، واكتشفت OpenAI ذلك في 25 سبتمبر أثناء مراجعة سجلات نشاط النموذج.

في ذلك اليوم، تلقى النموذج مهمة تبدو عادية: تعديل تطبيق لتداول العملات المشفرة ونشر مجموعة من العقود على شبكة اختبار الإيثيريوم Sepolia.

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

اختار النموذج مسارًا آخر.

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

جمع النموذج هذه الكلمات السرية العامة، وأنشأ تلقائيًا العناوين المقابلة واستعلم عن الأرصدة واحدًا تلو الآخر. لم يتضمن هذا العملية أي اختراق: يمكن توليد المفتاح الخاص مباشرة من الكلمات السرية العامة، ويمكن لأي شخص استخدام برنامج جاهز للقيام بذلك. لكن النموذج قام بتكثيف هذه العملية، حيث فحص 362 عنوانًا في دفعة واحدة، وأخيرًا وجد حسابًا يحتوي على ما يكفي من ETH من Sepolia. بعد ذلك، استخدم المفتاح الخاص المقابل لتوقيع المعاملة، ونشر العقد على السلسلة.

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

حددت OpenAI هذه الواقعة على أنها "استخدام غير مصرح به لمحفظة اختبار مشفرة تحتوي على أموال". النموذج المعني هو جزء من سلسلة الأبحاث الداخلية GPT-5.6 Sol، والتي تستخدم حاليًا فقط للأبحاث الداخلية، ولا يمكن للمستخدمين العاديين الوصول إلى هذا النموذج. وأشارت OpenAI إلى أنها اكتشفت هذا الحدث أثناء توسيع مراقبة السلوكيات غير المتوافقة، ومراجعة سجلات النماذج السابقة. بعد ذلك، زادت الشركة من القيود لمنع مثل هذه المهام من الحصول على وصول مباشر إلى الإنترنت، وجعلت نظام المراقبة ينبه فريق الأمان عند اكتشاف الوصول ذي الصلة.

كيف وجد النموذج واستخدم هذه العملة الاختبارية

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

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

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

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

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

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

البلوكشين زاد من مخاطر تجاوز صلاحيات الوكيل

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

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

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

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

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

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

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

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

كتابة أذونات إنفاق الوكيل في الشيفرة

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

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

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

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