لماذا تكون وكلاء الذكاء الاصطناعي عرضة لهجمات حقن الأوامر (prompt injection)، وكيف يمكن حمايتها على مستوى البنية المعمارية

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

المشكلة الجوهرية هي أن وكلاء الذكاء الاصطناعي يجمعون بين ما كان دائمًا منفصلًا — مستوى التحكم (control plane) ومستوى البيانات (data plane). في التطبيق العادي، تُعالج أوامر المستخدم بواسطة كود حتمي (deterministic)، ولا يمكن للبيانات أن تعيد كتابة المنطق. أما في نظام LLM، فإن أي نص موجود في نافذة السياق قد يؤثر فعليًا على سلوك النموذج.

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

المبدأ الأول: فصل الثقة كعنصر أساسي في البنية المعمارية

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

لا يعمل النظام مع نصوص موجّهة (prompt) متلاصقة، بل مع كتل سياق مُصنَّفة. تحصل كل كتلة على بيانات وصفية تتعلق بمصدرها (provenance) ومستوى ثقتها: التعليمات النظامية تُصنَّف trusted، والبيانات من قاعدة البيانات الداخلية تُصنَّف internal، والمحتوى الخارجي ووثائق RAG تُصنَّف untrusted. وتتحقق الأدوات من هذه التصنيفات قبل أي تنفيذ.

تسمي OWASP هذا المبدأ «segregation of trust» وتؤكد في عام 2026 أنه لم يعد مجرد ممارسة جيدة، بل أصبح شرطًا معماريًا.

المبدأ الثاني: عزل الأدوات والحد الأدنى من الصلاحيات

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

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

المبدأ الثالث: التحكم في الذاكرة ومجموعة بيانات RAG

تُعدّ مجموعة بيانات RAG جزءًا من سطح الهجوم، وغالبًا ما تكون أخطر من الأمر الموجّه (prompt) نفسه. أظهرت دراسة WARP أنه يمكن حقن وثائق «مسمومة» في مجموعة بيانات البحث، وعند حدوث المحرّك المناسب، يسترجع نظام RAG هذه الوثائق بالضبط. وقد نجحت دراسة AgentPoison في 82% من الحالات بمعدل تسميم أقل من 0.1% — فقد تكفي وثيقة واحدة ضارة من بين كل ألف وثيقة.

تشمل الحماية ثلاث طبقات: التحقق من مصدر كل وثيقة عبر بيانات وصفية وتجزئات (hashes) للمحتوى، وعزل نتائج البحث بوضع علامة untrusted عليها، ومراقبة الانحراف — أي اكتشاف ما إذا بدأ البحث يُعيد وثائق لم يكن يُعيدها من قبل.

المبدأ الرابع: مبدأ الإنسان في حلقة الاتخاذ كعنصر معماري

لا يتعلق الأمر بميزة واجهة مستخدم تحتوي على زر تأكيد، بل بعنصر مُدمج في بيئة التشغيل (runtime). تُصنَّف الإجراءات بحسب مستوى الخطورة: LOW (قراءة فقط، بيانات داخلية)، MEDIUM (كتابة في بيئة معزولة sandbox، إشعارات داخلية)، HIGH (حذف، استدعاءات API خارجية، عمليات مالية). وتتطلب الإجراءات ذات الخطورة HIGH تأكيدًا بشريًا — ولا يستطيع الوكيل تجاوز ذلك.

تؤكد حوادث حقيقية هذه الضرورة: الثغرة CVE-2025-32711 (المعروفة باسم EchoLeak) — وهي حقن أوامر في Microsoft Copilot أدت إلى تسريب بيانات دون أي تفاعل من المستخدم (zero-click)؛ والثغرتان CVE-2025-54135 و CVE-2025-54136 — وهما تنفيذ كود عن بُعد (RCE) عبر حقن الأوامر في تطبيق بروتوكول MCP ضمن بيئة التطوير Cursor IDE. وجميعها نتجت عن أخطاء معمارية، لا عن قصور في النموذج نفسه.

لا يتعلق الأمر بجعل النموذج آمنًا. بل يتعلق بتصميم الأمان على مستوى بنية النظام نفسها.