أداة Cursor على Claude Opus حذفت قاعدة بيانات PocketOS على Railway في 9 ثوانٍ مع النسخ الاحتياطية

وصف مؤسس PocketOS، جير كرين، حادثة تبدو وكأنها أسوأ سيناريو ممكن للأتمتة بالذكاء الاصطناعي: قام وكيل Cursor على نموذج Claude Opus 4.6 بحذف قاعدة بيانات الإنتاج الخاصة بالشركة في Railway في 9 ثوانٍ، جنبًا إلى جنب مع نسخ احتياطية. وفقًا لكرين، حدث هذا أثناء مهمة روتينية في staging وتصعد بسرعة من خطأ محلي إلى انقطاع الخدمة لعملاء شركات تأجير السيارات في جميع أنحاء البلد.

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

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

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

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

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

بشكل منفصل، أشار إلى أنه في 23 أبريل، كانت Railway تروج لخادم MCP الخاص بها لوكلاء الذكاء الاصطناعي، أي أن هذا ليس عبارة عن إعداد تجريبي عشوائي، بل هو اتجاه تدعمه المنصة نفسها بنشاط.

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

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

يذكر كرين أيضًا أن هذا ليس أول حادثة عامة تتعلق بـ Cursor: في أواخر 2025 وأوائل 2026، كان المستخدمون قد أبلغوا بالفعل عن حالات قام فيها الوكيل بانتهاك قيود Plan Mode أو تنفيذ إجراءات تدميرية على الرغم من التعليمات الصريحة.

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

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

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

يكتب كرين نفسه أن بعض عملائه لا يستطيعون العمل بكامل طاقتهم دون PocketOS، مما يعني أن العملية التي استغرقت تسع ثوانٍ في البنية التحتية تحولت إلى أزمة يدوية لعدة أيام للشركات الحقيقية.

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

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