يطيع مساعدك المدعوم بالذكاء الاصطناعي تعليماته بنسبة 99% تقريبًا، ولكن تلك الـ 1% المفقودة هي المكان الذي يضرب فيه المهاجمون. من خلال تقديم أمر (prompt) مصاغ بعناية، يمكن لمستخدم خبيث جعل النموذج يستدعي وظائف لا ينبغي له استدعاؤها، مما يؤدي إلى سرقة البيانات أو تنفيذ إجراءات ذات صلاحيات. الحل ليس في استخدام صياغة أكثر تهذيبًا، بل في التعامل مع الخلل كمشكلة تفويض وإزالة الأدوات الخطيرة من متناول النموذج.
لماذا لا يعد حقن الأوامر مجرد مشكلة صياغة
يحاول المطورون غالبًا تحصين الوكلاء (agents) باستخدام تحذيرات مكتوبة بأحرف كبيرة، أو قواعد مرقمة، أو بنود مثل "لا تستدعي وظائف المسؤول". تفترض هذه الدفاعات أن النموذج سيلتزم بجملة تقول "لا تفعل X". ولكن في الممارسة العملية، يمكن إغراء النموذج لتجاهل التعليمات عن طريق إعادة صياغة الطلب، أو تقمص شخصية مختلفة، أو ببساطة إضافة سياق إضافي. الحدود اللغوية قابلة للتفاوض؛ أما أمر المهاجم فهو غير محدود ولا يكلف شيئًا لاختباره.
تكمن الثغرة الحقيقية في قائمة الأدوات التي يتلقاها الوكيل. عندما يحتوي مخطط الأوامر (prompt schema) على وظيفة تمنح صلاحيات المسؤول، يصبح لدى النموذج الآن خارطة طريق لتلك القوة. حتى لو قال الأمر "لا تستخدمها للعملاء"، لا يزال من الممكن إقناع النموذج باستدعائها لأن الوظيفة موجودة في بيئة التنفيذ الخاصة به. لذا، فإن المشكلة هي فجوة في التفويض: النظام يكشف عن قدرات ذات صلاحيات لمستخدم ليس له الحق في الوصول إليها.
تأمين الوكلاء عن طريق الحد من التعرض
أبسط طريقة لسد هذه الفجوة هي التوقف عن منح النموذج إمكانية الوصول إلى الأدوات التي ليس مخولاً باستخدامها. فكر في قائمة الأدوات كمفتاح API: إذا لم يكن المفتاح موجودًا، فلا يمكن إجراء الاستدعاء. لا يمكن لأي صياغة ذكية أن تستدعي وظيفة ليست موجودة في السياق الحالي.
الطريقة الخاطئة
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
لا يزال النموذج يرى adminDeleteUser في صندوق أدواته ويمكن خداعه لاستدعائها.
الطريقة الصحيحة
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
لا تظهر adminDeleteUser أبدًا، لذا لا يوجد مسار للنموذج لاستدعائها.
ثلاث قواعد عملية للمطورين
- بناء قوائم الأدوات لكل طلب – قم بإنشاء كتالوج الوظائف ديناميكيًا، بناءً على أذونات المستخدم المصادق عليه. يرى العميل فقط الوظائف التي يحتاجها؛ بينما يرى المسؤول المجموعة الكاملة.
- الفشل الآمن (Fail closed) – إذا تعذر التحقق من هوية المستخدم، فقم بإرجاع قائمة فارغة بدلاً من استخدام خيار افتراضي عام مثل "جميع الأدوات متاحة". هذا يضمن عدم اكتساب طلب غير مصادق عليه لقوة غير متوقعة أبدًا.
- تجنب الحالة المشتركة (Avoid shared state) – عند تخزين تعريفات الأدوات مؤقتًا، لا تكتب أبدًا بيانات خاصة بالمستخدم على كائن مشترك. استخدم تقنية "النسخ عند الكتابة" (copy-on-write) أو نسخًا لكل جلسة حتى لا تتسرب أذونات مستخدم واحد إلى طلب مستخدم آخر.
إذا بدا المخطط المقدم للمستخدم العادي مطابقًا للمخطط المعروض للمسؤول، فإن الحدود الأمنية لا تزال هي نص الأمر، والأوامر ليست آلية أمنية موثوقة.
ما الذي أوصلنا إلى هنا
ظهر حقن الأوامر عندما بدأ المطورون في دمج النماذج اللغوية الكبيرة (LLMs) في سير عمل الإنتاج الذي يتطلب من النموذج استدعاء واجهات برمجة تطبيقات (APIs) خارجية، أو تشغيل كود، أو تعديل قواعد البيانات. يتم توجيه "تفكير" النموذج بواسطة أمر يتضمن أيضًا قائمة بالأدوات المتاحة. افترضت النماذج الأولية أن النموذج سيلتزم بقاعدة لغة طبيعية مثل "لا تحذف السجلات لغير المسؤولين". لكن المهاجمين أثبتوا بسرعة أن بضع جمل إضافية يمكن أن تتجاوز تلك القواعد، مما يدفع النموذج لاستدعاء وظيفة الحذف نفسها على أي حال.
كان رد فعل المجتمع الأول هو تشديد لغة الأوامر، أو إضافة بنود مثل "لا تفعل X أبدًا"، أو تضمين فلاتر regex لإزالة الرموز المشبوهة. قللت هذه الإجراءات من سوء الاستخدام العرضي ولكنها لم توقف خصمًا مصممًا يمكنه ببساطة إعادة صياغة الطلب. وظلت المشكلة الأساسية — وهي كشف الوظائف ذات الصلاحيات لمستخدم غير موثوق — قائمة.
من يربح ومن يخسر
المؤسسات التي تتبنى تحديد نطاق الأدوات لكل طلب تكتسب حدودًا واضحة وقابلة للتنفيذ. يمكن نشر وكلائها على نطاق واسع دون خوف من أن يؤدي أمر واحد مشوه إلى فتح قدرات المسؤول. كما تقدر فرق الامتثال سجل التدقيق: فقائمة الوظائف المرسلة إلى النموذج هي أثر ملموس يمكن تسجيله ومراجعته.
المطورون الذين يعتمدون على حواجز الأوامر فقط يستمرون في مواجهة هدف متحرك. قد تبدو وكلائهم وظيفية أثناء الاختبار ولكن قد يتم اختراقها في الواقع، مما يؤدي إلى خروقات البيانات، أو معاملات غير مصرح بها، أو انتهاكات للامتثال. تكلفة الاختراق تفوق بكثير الجهد المبذول لبناء قائمة أدوات ديناميكية.
الحجة المضادة: "الأوامر الأفضل كافية"
يجادل البعض بأنه من خلال هندسة تعليمات كافية — مثل المطالبات متعددة الطبقات، ورسائل النظام، والتعلم المعزز من التغذية الراجعة البشرية — يمكن جعل النموذج يحترم بنود "عدم القيام بـ". والواقع هو أن النماذج اللغوية هي مولدات احتمالية؛ فهي تزن الاحتمال الأكثر ترجيحًا للتكملة، وليس قاعدة أمنية صارمة. وحتى مع وجود حواجز حماية (guardrails) مضبوطة بدقة، يمكن لصياغة مبتكرة أن تتسلل، خاصة عندما يتمكن المهاجم من التكرار بلا نهاية وبتكلفة صفرية. تُعد حواجز الحماية مفيدة لتقليل الضجيج، ولكن لا ينبغي أن تكون خط الدفاع الوحيد.
ما يجب مراقبته لاحقًا
- أطر العمل التي تبرز تحديد نطاق الأدوات (tool scoping) كواجهة برمجة تطبيقات (API) من الدرجة الأولى – توقع ظهور مكتبات جديدة تتيح لك تحديد القدرات لكل مستخدم وتقليم قائمة الوظائف تلقائيًا قبل بناء المطالبة (prompt).
- "بيانات الوظائف" (function manifests) الموحدة – قد تحدد مجموعات الصناعة مخطط JSON يفصل بين الوظائف العامة والوظائف ذات الامتيازات، مما يسهل إنشاء بيانات خاصة بكل طلب.
- الفرض أثناء وقت التشغيل (Runtime enforcement) – تجري بعض المنصات تجارب على التنفيذ في بيئة معزولة (sandboxed execution) تتحقق من رمز (token) المستدعي مقابل الوظيفة التي يتم استدعاؤها، مما يضيف طبقة ثانية تتجاوز تحديد نطاق المطالبة.
الخلاصة واضحة: تعامل مع حقن المطالبات (prompt injection) كخلل في التصريح (authorization flaw). من خلال إزالة الأدوات غير المصرح بها من صندوق أدوات النموذج، فإنك تقضي على سطح الهجوم الذي تسعى مطالبة مصاغة بذكاء إلى استغلاله. يمكن للمطالبات توجيه السلوك، لكنها لا يمكن أن تحل محل التحكم المناسب في الوصول.