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

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

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

بعد تلميح مثل from dialoghelper import *، قرر النموذج أن لديه وصول إلى read_secret وحاول استدعاء هذه الأداة. إذا كانت المكتبة أو واجهة البرمجة تتحقق فقط من صيغة الاستدعاء ولا تقارن اسم الدالة بصرامة مع المخطط الصادر، تمر الطلب عبر. أظهر المؤلف سلوكاً مماثلاً ليس فقط في Anthropic، بل في سيناريوهات معينة أيضاً في Gemini و Grok وعبر الأغلفة متعددة المزودين.

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

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

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

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

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

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