الأدوات واستدعاء الدوال

القيد الأساسي للـ LLM

من دون أدوات متصلة أو شيفرة في التطبيق، لا يُنتج الـ LLM النصي سوى مخرجات النموذج. وهو وحده يعجز عن:

• تصفّح الويب
• إجراء حسابات مضمونة الدقّة (يمكنه التفكير في الحساب، لكنه ليس آلة حاسبة دقيقة دائماً)
• الوصول إلى قواعد البيانات
• إرسال الرسائل
• قراءة الملفات
• استدعاء الـ APIs

يبقى محصوراً في عالم النص. اسأله "كم حاصل 7,392 × 8,451؟" فقد يخطئ تخمينٌ سريع مبنيّ على الأنماط، وحتى حين يستنتج الإجابة خطوةً خطوة، فهو ليس آلة الحساب المضمونة الدقّة التي تمنحك إياها الأداة. واسأله عن طقس اليوم، فمن دون مصدر حيّ لن يستطيع إلا توليد إجابة من السياق المُرسَل وأنماط التدريب.

الأدوات تحلّ هذا

الأدوات (وتُعرَف أيضاً بـ function calling) تتيح للمطوّرين أن يمنحوا النموذج قائمةً بالإجراءات التي يمكنه اتّخاذها.

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

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

مع الأدوات مقابل بدونها

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

من الـ tool calling إلى الـ agents

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

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

هنا يبدأ الـ agentic behavior. فبدلاً من ذهاب وإياب واحد، يدور النموذج في حلقة:

أترى الفرق؟ مخطّط الـ tool calling خطّ مستقيم. أمّا مخطّط الـ agentic ففيه حلقة، حيث يواصل النموذج المضيّ، مستدعياً أداةً بعد أداة، حتى يقرّر أنّ المهمّة اكتملت.

مشكلة الصلاحيات

هنا تصير الأمور جدّية.

إن منحت النموذج أدواتٍ لإرسال الرسائل وحذف الملفات، ثم نفّذت الـ backend طلباته بلا تحقّق فعّال من الصلاحيات، فالضرر حقيقي. تُرسَل الرسالة فعلاً، ويُحذَف الملفّ فعلاً.

يتحوّل التلاعب بالنص إلى فعل ملموس في العالم الحقيقي.

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

تخيّل نموذجاً يملك هذه الأدوات:

• send_email(to, subject, body)
• delete_file(path)
• query_database(sql)

يتصرّف النموذج بوصفه نائباً، فيتّخذ الإجراءات نيابةً عن المستخدم. لكن إن التبس عليه ما يريده المستخدم حقاً (عبر التلاعب، أو غموض التعليمات، أو بيانات محقونة)، صار نائباً مُضلَّلاً (confused deputy) ينفّذ إجراءات لم يقصدها المستخدم قطّ.

لماذا يهمّ هذا

تحوّل الأدوات الـ LLMs من ألعاب طريفة إلى أنظمة قوية تتصرّف في العالم الحقيقي. وقد تضخّم الـ agentic loops المخاطر حين ينفّذ التطبيق طلبات النموذج تلقائياً؛ إذ يمكن لتعليمة مُتلاعَب بها أن تطلق سلسلة من الإجراءات الحقيقية. وهكذا تتراكم آثارها الأمنية:

• كيف تعمل الـ LLMs: النموذج في جوهره يتنبّأ بالنص دون أي فحص مدمج لما هو هذا النص، لذا يمكن خداعه
• الـ system prompts: التعليمات ذات الأولوية الأعلى تُشكّل السلوك، لكنها ليست حدّاً للصلاحيات
• الـ RAG: البيانات الخارجية تتدفّق إلى الـ prompt، وقد تحمل تعليمات خفيّة
• الأدوات + الـ agents: قد يُحدِث النموذج المتلاعَب به ضرراً حقيقياً إذا امتلك أدوات قوية، وقد تستمر الحلقة المستقلّة حتى تبلغ حدّاً أو بوابة موافقة

تبني كل طبقة على ما قبلها، ولهذا احتجت إلى إتقان الأساسيات أولاً.

جاهز لوحدات الأمن

صرت الآن تفهم اللبنات الأربع:

1. الـ LLMs متنبّئات بالنص، ذات context window محدود
2. الـ system prompts تُشكّل السلوك لكنها ليست حدوداً أمنية
3. الـ RAG يحقن مستندات خارجية في الـ prompt
4. الأدوات تتيح للنموذج إطلاق إجراءات في العالم الحقيقي، والـ agentic loops تتيح له تسلسلها

ستُريك وحدات الأمن كيف تستغلّ كلاً منها، وكيف تحلّل الضوابط التي تخفّف مخاطرها.

المصادر

• Model Context Protocol: Tools: مثال عملي لبروتوكول اكتشاف الأدوات واستدعائها
• OWASP LLM06: Excessive Agency: أقلّ الصلاحيات، والتحقّق، والموافقة البشرية على الإجراءات عالية الأثر