حقن الأوامر لا يُحل بأمر أقوى: قيّد أدوات الوكيل وصلاحياته

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

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

افصل المحتوى الخارجي عن سلطة التعليمات

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

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

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

اربط قائمة الأدوات بهوية المستخدم والمهمة

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

تذكر خريطة ضوابط Microsoft لـCopilot Studio الوصول إلى الأدوات ضمن صلاحيات المستخدم، وتحكم المسؤولين في الموصلات والأفعال المتاحة، والموافقة البشرية والعزل والتسجيل؛ وهي تصف ضوابط ذلك المنتج وتكاملاته، وقد يختلف توافرها. في بنية وكيل مستقل، يقابل ذلك حساب خدمة محدود النطاق وقواعد تحقق عند تنفيذ كل استدعاء. راجع الصلاحيات عندما تُضاف أداة أو يتغير عمل موصل قائم، لأن اسم الأداة القديم قد يخفي عمليات جديدة.

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

اجعل الموافقة على الفعل نفسه واضبط الإخراج الخارجي

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

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

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

اعزل التنفيذ واحتفظ بما يكفي للتحقيق والإيقاف

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

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

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

اختبر انحراف الوكيل واكتمال هدف المهاجم كلًا على حدة

لا تقِس الدفاع بسؤال واحد من نوع «هل تجاهل النموذج التعليمة الخبيثة؟». يختبر معيار WASP لوكلاء الويب هجمات داخل بيئة ويب معزولة وبأهداف محددة للمستخدم والمهاجم، ويميّز بين انحراف الوكيل عن هدف المستخدم وبين تحقق النتيجة النهائية التي يريدها المهاجم. قد يظهر الانحراف في سلسلة الأفعال من دون اكتمال الهجوم؛ ولا يجوز اعتبار ذلك نجاحًا لضوابط الصلاحية ما لم تُفحص نقطة التوقف الفعلية.

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

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

اقرأ أيضًا:

• Salesforce يفتح منصته للوكلاء عبر أربع أدوات MCP فقط
• Claude يفتح مخطط وكلاء التجارة، لكن الدفع يبقى خارج الوكيل
• Arga Labs تجمع 10 ملايين دولار: الوكيل يتعطل داخل نسخة لا الإنتاج