Anthropic ونماذج لغوية أخرى قد تستدعي أدوات مخفية دون إذن

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

تظهر المشكلة في الربط بين النموذج الوكيلي وبيئة العميل، حيث تتباعد قائمة الأدوات المسموح بها عن فضاء الأسماء الفعلي. في العرض التوضيحي لم يُمنح النموذج سوى read_url، لكن الدالة read_secret كانت موجودة في البيئة. وبعد تلميح من نوع from dialoghelper import * استنتج النموذج أن لديه وصولًا إلى read_secret، وحاول استدعاء هذه الأداة. وإذا اكتفت المكتبة أو واجهة API بالتحقق من صيغة الاستدعاء دون مطابقة صارمة لاسم الدالة مع المخطط الممنوح، يمرّ الطلب إلى المرحلة التالية.

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

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

واكتشاف هذا الخلل صعب. ففي حالات كثيرة يتصرف النموذج على نحو صحيح ويمتنع عن الاستدعاء المحظور، ثم ينهار فجأة بسبب تفصيل صغير في السياق: صياغة التلميح، أو سجل الرسائل، أو حتى اسم الوحدة. وتورد المقالة مثالًا دالًّا يُحظر فيه الإجراء نفسه تارة ويمرّ تارة أخرى بعد ذكر عابر وبريء لـ dialoghelper. ويخفّف فك الترميز المهيكل (structured decoding) الخطر جزئيًا لأنه يُلزم النموذج بالتقيد بالمخطط، لكن له هو الآخر مقايضاته: زيادة زمن الاستجابة، وحدودًا صارمة على عدد أدوات strict، وتراجعًا في الأداء مع المجموعات الكبيرة من الدوال. لذلك لا يجوز الاعتماد على حسن سلوك النموذج وحده. يجب أن يتم التحقق من اسم الأداة على جانب المزوّد وفي كود العميل قبل التنفيذ الفعلي.

والخلاصة العملية بسيطة: إذا كنت تبني وكيلًا فوق MCP أو Jupyter أو حزم SDK داخلية أو أي بيئة ديناميكية أخرى، فلا يكفي أن تُخفي الدوال الزائدة من الوصف وتعوّل على انضباط النموذج. ينبغي التحقق الصارم من كل استدعاء أداة (tool call)، وفصل العمليات الحساسة عن المحتوى غير الموثوق، وإبقاء فضاء التنفيذ أضيق من مدى الرؤية المتاح لـ LLM. وإلا فإن تخمينًا واحدًا لـ read_secret أو add_msg يحوّل بنية وكيلية متقنة إلى نظام لا تدوم فيه صلاحيات الوصول إلا حتى أول هلوسة ناجحة.

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