أُتيح Lilli من McKinsey للعموم في 9 مارس. والسجل لا ينطوي على أي ضرر.

في 9 مارس 2026، نشرت شركة CodeWall الناشئة في مجال الأمن السيبراني روايتها عن كيفية تمكن وكيل ذاتي طورته من الوصول الكامل للقراءة والكتابة إلى قاعدة بيانات الإنتاج التي تقف خلف Lilli، المساعد الذكي على مستوى الشركة لدى McKinsey & Company، خلال ساعتين تقريبًا ودون استخدام أي بيانات اعتماد. وقع الاختراق نفسه في 28 فبراير؛ وما يسجله هذا المدخل في أرشيف حوادث الذكاء الاصطناعي هو اليوم الذي أصبح فيه علنيًا. ووفقًا لـCodeWall، احتوت قاعدة البيانات التي وصل إليها الوكيل على 46.5 مليون رسالة دردشة بنص صريح، و728,000 ملف، و57,000 حساب مستخدم، و95 توجيهًا نظاميًا تتحكم في كيفية إجابة Lilli — وكانت هذه التوجيهات موجودة في قاعدة البيانات نفسها التي كان بإمكان الوكيل الكتابة فيها. والأشخاص الواردون في البيانات كانوا من موظفي McKinsey أنفسهم: وتقول الشركة إن 72 في المئة من موظفيها، أي أكثر من 40,000 شخص، يستخدمون Lilli، الذي يتعامل مع أكثر من 500,000 توجيه شهريًا. السجل الكامل، مع درجاته للخطورة والثقة والسجلات المجاورة التي يقع بينها، موجود في Orca AI Incident Archive.

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

لماذا يُعدّ الإفصاح حدثًا مؤرخًا بذاته

ملخص الأرشيف لهذا المدخل يعود إلى 28 فبراير 2026، وهو اليوم الذي اكتشف فيه وكيل CodeWall الخلل، ويحمل الأرشيف ذلك التاريخ الأسبق كسجل منفصل. وهذا الانقسام ليس بيروقراطيًا. قبل 9 مارس، كانت الأطراف الوحيدة التي تعرف ما حدث داخل Lilli هما McKinsey والباحث الذي كان قد أخبرها بذلك. وبعد 9 مارس، أصبح شكل الفشل، واستجابة الشركة، والادعاء بشأن ما كان في قاعدة البيانات، كلها في السجل العام، حيث يمكن لباحثي أمن آخرين أن يجادلوهم بشأنها.

Lilli ليس مشروعًا جانبيًا. حدّدت The Register موعد طرحه في يوليو 2023، عبر الدردشة وتحليل الوثائق والاسترجاع من البحوث الداخلية للشركة. ويصف مقال CodeWall، الذي يسجّل أيضًا مصدر الاسم — أول امرأة مهنية وظّفتها الشركة، في عام 1945 — أكثر من 100,000 وثيقة داخلية وراءه. وذكرت The Register، التي نقلت الإفصاح في اليوم نفسه، أن نسبة التبني بلغت 72 في المئة من الموظفين وأن الحجم تجاوز 500,000 مطالبة شهريًا — وهي أرقام نشرتها McKinsey بنفسها في دراسة حالة علنية للمنصة.

كيف تمكّن الوكيل من الدخول

يبدأ تقرير CodeWall بالتوثيق، لا بالاستغلال. فقد وجد وكيله توثيق API الخاص بـ Lilli مكشوفًا علنًا وموثقًا بالكامل: أكثر من 200 نقطة نهاية في المجموع، معظمها يتطلب المصادقة، و22 لا تتطلبها. أحد تلك النقاط الطرفية غير المصادقة كان يكتب استعلامات بحث المستخدمين في قاعدة البيانات. كانت القيم تُمرَّر كمعاملات بشكل صحيح، لكن مفاتيح JSON — أسماء الحقول — كانت تُدمج مباشرةً في SQL.

لاحظ الوكيل ذلك لأن رسائل خطأ قاعدة البيانات كانت تعيد تلك المفاتيح من JSON كما هي حرفيًا. ويقول CodeWall إن ماسح ZAP التابع لـ OWASP لم يرصد المشكلة، وإن الوكيل نفّذ بعد ذلك خمس عشرة تكرارًا عمياء، وكانت كل رسالة خطأ تعلّمه المزيد عن شكل الاستعلام، إلى أن بدأت صفوف حية من بيئة الإنتاج تعود. ومن هناك ربط حقن الاستعلامات بخلل في التفويض على مستوى الكائن لقراءة سجلات البحث الخاصة بموظفين أفراد. وتصف الشركة العملية بأكملها بأنها مستقلة تمامًا، من اختيار الهدف إلى التقرير، ومن دون بيانات اعتماد ودون تدخل بشري. وقال مؤسسها ورئيسها التنفيذي، بول برايس، لـ The Register إن العملية كانت "مستقلة تمامًا من البحث عن الهدف وتحليله ومهاجمته إلى إعداد التقرير".

ما يقول CodeWall إنه كان بالداخل

كل رقم في هذا القسم مأخوذ من تقرير CodeWall المؤرَّخ 9 مارس. لم تُنشَر أي حمولات، لذا لا يمكن إعادة إنتاج أيٍّ منها أو عدّها بشكل مستقل — وهو قيدٌ يعالجه القسم التالي.

• 46.5 مليون رسالة دردشة، مخزّنة بنص صريح، تغطي أعمال الاستراتيجية، ومهام العملاء، والبيانات المالية، وعمليات الاندماج والاستحواذ.

• {{1}}728,000 ملف، منها يورد التقرير بالتفصيل 192,000 ملف PDF و93,000 جدول بيانات Excel و93,000 عرض PowerPoint و58,000 مستند Word — أي 436,000 في المجموع، مما يترك 292,000 المتبقية غير مصنفة في الجملة نفسها.{{/1}}

• 57,000 حساب مستخدم، و384,000 مساعد ذكاء اصطناعي، و94,000 مساحة عمل، وهي ما يصفه CodeWall بأنها الهيكل التنظيمي الكامل لكيفية استخدام الشركة للذكاء الاصطناعي داخليًا.

• 95 من مُوجّهات النظام وتكوينات النماذج عبر 12 نوعًا من النماذج، توضح كيف تم توجيه المساعد، وما الضوابط التي كانت قائمة، والنماذج التي كانت تعمل تحته.

• 3.68 مليون قطعة من مستندات التوليد المعزز بالاسترجاع، مع مسارات تخزين S3 وبيانات وصفية داخلية للملفات — قاعدة المعرفة التي تغذّي المساعد.

• 1.1 مليون ملف و217,000 رسالة وكيل تنتقل عبر واجهات برمجة تطبيقات الذكاء الاصطناعي الخارجية، بما في ذلك أكثر من 266,000 مخزن متجهات على منصة OpenAI.

الاكتشاف الذي يعتبره CodeWall العنوان الرئيسي ليس الحقن نفسه، بل المكان الذي وقع فيه الحقن. كانت أوامر النظام الخاصة بـ Lilli عبارة عن صفوف في قاعدة البيانات نفسها التي كان بإمكان الوكيل الكتابة إليها، ما يعني أن مهاجمًا يمتلك الوصول نفسه كان يمكن أن يعيد كتابة تعليمات المساعد باستخدام عبارة UPDATE واحدة ملفوفة في استدعاء HTTP واحد — دون نشر، ودون تغيير في الشيفرة، ودون ملف على القرص يمكن مقارنته. يقول CodeWall إن اختباره الخاص كان للتحقق فقط: فقد قرأ ولم يكتب، ويقول إنه لم تتعطل أي خدمة إنتاجية.

ما قالته McKinsey في اليوم نفسه

قال متحدث باسم McKinsey لـ The Register في 9 مارس إن الشركة أصلحت جميع المشكلات التي حددها CodeWall في غضون ساعات من علمها بها. وقال المتحدث: "لم يحدد تحقيقنا، المدعوم من شركة رائدة في التحقيق الجنائي الرقمي من طرف ثالث، أي دليل على أن بيانات العملاء أو معلومات العملاء السرية قد تم الوصول إليها من قبل هذا الباحث أو أي طرف ثالث غير مصرح له"، مضيفًا أن "أنظمة الأمن السيبراني لدى McKinsey قوية."

ذكرت Silicon UK الموقف نفسه في 13 مارس، في تقرير ماثيو برورزما: إذ قالت McKinsey إنها «أُبلغت مؤخرًا بثغرة تتعلق بأداة الذكاء الاصطناعي الداخلية لدينا، Lilli، من قبل باحث أمني»، وإنها «أكدت الثغرة على الفور وأصلحت المشكلة في غضون ساعات»، وإنه لم يتم الوصول إلى أي بيانات عملاء أو معلومات سرية تخص العملاء. ويلاحظ ذلك التقرير أيضًا أن Price هو الموظف الوحيد في CodeWall، وهو تفصيل يستحق الذكر لأنه ذو حدين — فقد اكتشف فريق بحث من شخص واحد، في ساعتين، ما لم تكتشفه ماسحات الشركة نفسها، كما أن كيانًا من شخص واحد يبيع الأداة التي اكتشفته.

روايتان عن الإصلاح بفارق يوم واحد

يسير الجدول الزمني للإفصاح الخاص بـ CodeWall على النحو التالي: يحدد الوكيل ثغرة حقن SQL ويبدأ في استكشاف قاعدة بيانات الإنتاج في 28 فبراير؛ وتُؤكَّد السلسلة الكاملة في اليوم نفسه مع توثيق 27 اكتشافًا؛ ويُرسَل بريد إفصاح مسؤول إلى فريق الأمن لدى McKinsey في 1 مارس يتضمن ملخصًا عامًا عن التأثير؛ ويقر مسؤول أمن المعلومات الرئيسي في الشركة باستلامه ويطلب أدلة مفصلة في 2 مارس؛ وفي 2 مارس تُرقَّع جميع نقاط النهاية غير المصادق عليها ويُتحقق منها، وتُوقف بيئة التطوير عن العمل وتُحجب وثائق API العامة. ويأتي الإفصاح العلني في 9 مارس.

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

المُثبت، وأُحادي المصدر، والفجوة بينهما

ما هو ثابت ومتفق عليه من الطرفين: كان هناك ضعف غير مصادَق عليه في واجهة API العامة لـ Lilli؛ اكتشفه باحث أمني خارجي لا شخص من الداخل؛ وأكّدت McKinsey وجوده وقامت بتصحيحه؛ وأُغلقت نقاط النهاية غير المصادَق عليها، وأُوقفت بيئة التطوير عن العمل، وحُجبت وثائق API العامة.

من مصدر واحد، من CodeWall:كل عدد مذكور أعلاه، والخط الزمني الممتد لساعتين، والتكرارات العمياء الخمسة عشر، والنتائج الموثقة الـ 27، والادعاء بأن الـ prompts كانت قابلة للكتابة عبر نفس الحقن. لم يُدحض أيٌّ من ذلك. ولم يُتحقق من أيٍّ منه بشكل مستقل أيضًا، لأن الـ payloads التي كانت ستتيح لشخص ما التحقق لم تُنشر، ورفض Price أن يقدّم إلى The Register الـ prompts الدقيقة التي استخدمها فريقه.

نشرت شركة Promptfoo المتخصصة في أمن الذكاء الاصطناعي تقييمًا في 10 مارس يحدد هذا القيد بدقة: فالسجل العام «لا يثبت بشكل مستقل كل عدد صفوف مُبلّغ عنه أو كل خطوة من خطوات الاستغلال»، وإن كان يدعم ملامح الحادث. وهذا هو التفسير الصحيح للمواد المتاحة. ففئة الخلل قابلة لإعادة البناء؛ أما الحجم فهو شهادة.

الضرر الذي لا يحمله السجل

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

إنه لا يستند إلى تدقيق تقني مستقل، ولا إلى قرار من جهة تنظيمية، ولا إلى إشعار بخريق. لم يُسنَد أي معرّف CVE في أي تغطية جرى مراجعتها — فـ Lilli برنامج داخلي وليس منتجًا موزعًا، ولا يشير أي إشعار استشاري إلى أحد — ولا يبدو أن أي سلطة إشرافية فتحت ملفًا. لم تظهر أدلة علنية، في التغطية التي روجعت لهذا المقال، على أن البيانات استُخدمت أو بيعت أو تعرضت لمزيد من الكشف. وهذا ما يعنيه «لم يُسجَّل ضرر حقيقي» هنا: بيان أدلة عن سجل، وليس نتيجة مفادها أن الكشف كان آمنًا.

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

لماذا يُصنَّف على أنه بنية تحتية وليس فشلاً في النموذج

يصنّف الأرشيف هذا السجل ضمن INFRA، والسجل التقني يدعم هذا التصنيف. لم يتطلب أي شيء في رواية CodeWall خداع النموذج. لم يكن هناك أي كسر لحماية النموذج (jailbreak)، ولا حقن مطالبات من مستند، ولا مدخلات عدائية طُلب من المساعد أن يبتلعها. كانت نقطة الدخول عبارة عن وثائق مكشوفة، وفحص مصادقة مفقود، وبناء SQL غير آمن؛ وكان النموذج ببساطة أثمن ما يقف خلف الباب.

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

ماذا تغيّر بعد ذلك؟

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

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

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