يونيكود غير المرئي يفجّر ثغرة أمنية في قلب بروتوكولات أدوات الذكاء الاصطناعي

سطر واحد من نص غير مرئي كفيل بتمرير تعليمات خفية أمام عين المُراجع البشري، لتصل مباشرة إلى نافذة سياق (Context Window) النموذج اللغوي. هذه هي الخلاصة المحورية لدراسة جديدة تفحص بروتوكول سياق النموذج (Model Context Protocol - MCP)، المعيار الذي أصبح الطريقة الافتراضية التي تعتمدها وكلاء البرمجة (Coding Agents) لاكتشاف الأدوات الخارجية واستدعائها.

يعمل البروتوكول عبر مصافحة بسيطة: يعرض الخادم نقطة نهاية (Endpoint) باسم tools/list تُرجع اسم كل أداة، ووصفاً بلغة طبيعية، ومخطط JSON يوضح مدخلاتها. يعرض العميل هذه البيانات الوصفية (Metadata) للمستخدم في نافذة موافقة تظهر مرة واحدة فقط، ثم يعيد استخدامها بصمت، حاقناً (Injecting) نفس النص في سياق النموذج مع كل تفاعل لاحق. المشكلة أن البروتوكول نفسه لا يضمن تطابق ما يراه الإنسان في شاشة الموافقة مع البايتات (Bytes) الخام التي يستقبلها النموذج فعلياً، وهذه الفجوة بالضبط ما استغله الباحثون.

ثمانية طرق للتسلل بعيداً عن الرقابة

عبر اختبار خمس واجهات مختلفة للبيانات الوصفية في بروتوكول MCP، بنى الباحثون بيئة اختبار حتمية (Deterministic Harness) على مستوى البروتوكول، تطبّق ثماني تقنيات هجومية ملموسة. النتيجة كانت صادمة: 8 من 8 تقنيات نجحت في تمرير حمولات (Payloads) يتحكم بها المهاجم إلى سياق النموذج. أربع من هذه التقنيات تمكنت أيضاً من تجاوز أداة تنقية (Sanitizer) قائمة على مطابقة النصوص، وهي خط الدفاع الأول الشائع لفلترة أوصاف الأدوات الخبيثة.

أما النتيجة الأكثر لفتاً للانتباه فتتعلق بكتلة "التاغ" (TAG Block) في يونيكود، وهي نطاق يمتد من U+E0000 إلى U+E007F لا يحمل أي رمز مرئي (Glyph) مُعرَّف في أي واجهة طرفية (Terminal) أو محادثة أو بيئة تطوير متكاملة (IDE) شائعة. بما أن هذا النطاق لا يُترجم إلى أي شكل بصري، فإن النص المُشفَّر به لا يظهر أبداً في نافذة الموافقة التي يراجعها المطور، ومع ذلك يصل حرفياً إلى النموذج. من بين التقنيات الثماني المختبرة، كانت هذه التقنية الوحيدة القادرة على البقاء غير مرئية تماماً في الواجهة البشرية بينما تصل سليمة إلى سياق النموذج. كذلك تقدم المحارف عديمة العرض (Zero-Width Characters) آلية مشابهة لإخفاء تعليمات خبيثة داخل أوصاف أدوات تبدو عادية تماماً.

غياب شبكة الأمان عند إعادة الموافقة

الأمر الأكثر إثارة للقلق ظهر عندما حاكى الباحثون سيناريو "سحب البساط" (Rug-Pull)، حيث يتغير وصف الأداة بعد الموافقة عليها مسبقاً، في مشكلة كلاسيكية من نوع "الفارق بين لحظة الفحص ولحظة الاستخدام" (Time-of-Check to Time-of-Use). لم يفرض بروتوكول MCP إعادة الموافقة في أي من سيناريوهات الهجوم الثمانية، بمعنى أن أداة بدت غير ضارة وقت التثبيت يمكن تعديلها لاحقاً دون إثارة أي مراجعة جديدة.

ولاستبعاد فرضية أن الخلل مرتبط بتطبيق برمجي معيّن، أعاد الفريق بناء كتالوج الهجمات كاملاً على ثلاث مكتبات خوادم MCP مطوَّرة بلغة بايثون بشكل مستقل عن بعضها. تطابقت النتائج في جميع الحالات الـ32 عبر المكتبات المختلفة، وهو ما يشير إلى أن نقاط الضعف تعود إلى تصميم البروتوكول نفسه لا إلى كود مزوّد واحد بعينه. وأداة التنقية المستخدمة كخط دفاع أساسي لم تكن فاشلة تماماً أيضاً: فقد نجحت في تصنيف جميع أوصاف الأدوات الـ25 غير الضارة في مجموعة الاختبار بشكل صحيح، أي أنها لم تُنتج أي نتائج إيجابية كاذبة (False Positives)، لكنها في المقابل فوّتت نصف الهجمات الفعلية.

قُدِّمت الورقة البحثية إلى منصة arXiv في 7 يوليو 2026، في وقت يتسارع فيه تبني بروتوكول MCP عبر وكلاء البرمجة وتكاملات بيئات التطوير. تشير نتائجها إلى أن راحة طبقة موحدة لاكتشاف الأدوات قد سبقت التمحيص الأمني الذي يُفترض تطبيقه عادة على أي واجهة تُغذّي نصوصاً غير موثوقة مباشرة إلى عملية استدلال النموذج.