أبلغ مستخدم Vercel عن مشكلة بدت مخيفة للغاية. قاعدة شيفرة مجهولة لنظام GitHub OSS يتم نشرها على فريقهم. بالطبع، أخذنا التقرير على محمل الجد للغاية وبدأنا تحقيقا. الأمن وهندسة البنية التحتية مفعلة. اتضح أن Opus 4.6 *توهم معرف مستودع عام* واستخدم واجهة برمجة التطبيقات الخاصة بنا لنشره. لحسن حظ هذا المستخدم، كان المستودع غير ضار وعشوائي. كان حمولة JSON تبدو كالتالي: "gitSource": { "type": "github", "repoId": "913939401", // ⚠️ هلوسة "المرجع": "الرئيسي" } عندما طلب المستخدم من الوكيل شرح الفشل، اعترف: الوكيل لم يبحث أبدا عن معرف مستودع GitHub عبر واجهة GitHub. لا توجد أي استدعاءات API ل GitHub في الجلسة التي تسبق أول نشر غير دقيق. الرقم 913939401 يظهر لأول مرة في السطر 877 — حيث قام الوكيل بتلفهه بالكامل. كان الوكيل يعرف معرف المشروع (prj_▒▒▒▒▒▒) واسم المشروع (▒▒▒▒▒▒) الصحيحين لكنه اخترع معرف مستودع رقمي يبدو معقولا بدلا من البحث عنه. بعض النقاط المستخلصة: ▪️ حتى أذكى النماذج لديها أوضاع فشل غريبة تختلف كثيرا عن موديلنا. البشر يرتكبون الكثير من الأخطاء، لكنهم بالتأكيد لا يخترعون معرف مستودع عشوائي. ▪️ تخلق واجهات برمجة التطبيقات القوية مخاطر إضافية للوكلاء. الواجهة موجودة لاستيراد ونشر كود شرعي، لكن ليس إذا قرر الوكيل أن يتخيل أي كود يجب نشره! ▪️ لذا، من المحتمل أن الوكيل كان سيحصل على نتائج أفضل لو لم يقرر استخدام واجهة برمجة التطبيقات واستمر مع CLI أو MCP. وهذا يعزز التزامنا بجعل Vercel المنصة الأكثر أمانا لهندسة الوكلاء. من خلال تكاملات أعمق مع أدوات مثل Claude Code وضوابط إضافية، نحن واثقون من أن الأمن والخصوصية سيحافظان على ذلك. ملاحظة: معرف المستودع أعلاه عشوائي لأسباب تتعلق بالخصوصية.

بعض الملاحظات الإضافية: ▪️ كان المستخدم ينشر باستخدام OpenClaw + Opus 4.6، لكن لا أعتقد أن OpenClaw كان السبب هنا بالضرورة. هو مجرد وكيل لديه وصول إلى الأدوات والمفاتيح. ▪️ معرف المستودع كان *بالكامل* هلوسا. هذا ليس خطأ من الخطأ الفردي. تماما غير طبيعي.