أصعب مشكلات أمان الذكاء الاصطناعي الآن خارج النموذج

يوفر 2026 OWASP Top 10 لتطبيقات LLM منظورًا حاسمًا حول نضج الذكاء الاصطناعي الإنتاجي. إنه يلتقط تحولًا محوريًا: الصناعة تتجاوز بيئة الاختبار وتتعامل مع تعقيدات التكامل في العالم الحقيقي.

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

يعكس تصنيف OWASP Top 10 هذا التطور. ارتفع “الوكالة المفرطة” من المرتبة السادسة إلى الثالثة، بينما صعد “الاستهلاك غير المحدود” إلى المرتبة السادسة. وعلى العكس، تراجع “التعامل غير السليم مع المخرجات” إلى المرتبة العاشرة.

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

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

التصنيف يتبع الضرر

استفادت OWASP من 7,714 حادثة، 75% مدفوعة باتفاقية المجتمع، و25% من بيانات حوادث تجريبية. أجبر هذا الأساس من الأدلة على إعادة ترتيب الأولويات فعليًا.

“الوكالة المفرطة” ارتفعت لأن واقع بيئات الإنتاج لحق النظرية. تتسارع المؤسسات في نشر القدرات الذاتية أسرع من إرسائها لطائرات التحكم اللازمة. الثغرة الحرجة ليست مجرد الإجابة التي يقدمها النموذج، بل سياق التفويض الذي تُنفّذ فيه تلك الإجابة.

بينما يظل “التعامل غير السليم مع المخرجات” مصدر قلق، فقد نضجت فرق DevOps في قدرتها على تأمين المخرجات اللاحقة من خلال التحقق من المخطط والاستعلامات المعلَّمة. هذه ممارسات أمان تطبيقات راسخة.

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

عامل كل أداة كقدرة مكشوفة

تتعامل العديد من الفرق مع تعريفات الأدوات كأنها مجرد أنابيب تكامل. هذا خطأ فادح وأساسي. كل أداة أو موصل أو نقطة نهاية لواجهة برمجة التطبيقات توسع نطاق تأثير تطبيق الذكاء الاصطناعي.

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

يجب أن تفرض مبدأ أقل الصلاحيات:

• قصر الواجهة: زوِّد الوكيل بأدوات قراءة فقط بدلاً من موصلات عامة.
• سياق محدود: نفّذ الطلبات ضمن هوية المستخدم ذات نطاق OAuth.
• نقاط تنفيذ السياسات (PEP): نفّذ منطق التفويض كوسيط إلزامي بين النموذج والأنظمة اللاحقة. يجب التحقق من كل إجراء مقابل السياسة قبل التنفيذ.
• الإنسان في الحلقة (HITL): اطلب موافقة صريحة للعمليات التي يصعب عكسها أو تحمل تأثيرًا ماديًا عاليًا.

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

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

كل تشغيل ذاتي يحتاج إلى إيقاف صلب

“الاستهلاك غير المحدود” ارتفع لأن حجم الطلب ليس مقياسًا كافيًا لمخاطر الموارد. يمكن لمطالبة واحدة مختصرة أن تُطلق سلسلة متكررة من استدعاءات الأدوات تستهلك موارد بشكل كبير. لا يتوقف العداد حتى ينتهي الوكيل.

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

يتطلب نطاق العملية نفس الصرامة. حدِّد الحد الأقصى لعدد السجلات التي يمكن للوكيل تعديلها وعَرِّف حدود انتشار المهمة. إذا كان بناؤك يفتقر إلى آلية “إيقاف” حتمية، فأنت قد وفَّرت السلطة فعليًا دون تحديد محيطها.

البناء للحصول على الإجابة الخاطئة

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

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

نحن الآن نرى حقن المطالبات كقانون فيزيائي أكثر من كونه ثغرة. سيظل دائمًا متربصًا. الحقيقة هي أن النماذج نفسها لا يمكنها أن تكون صانعي قرار فعالين في الأسئلة الأمنية الحرجة. في مشروع وكيل حقيقي أقوم ببنائه، لدينا حوالي 100 اختبار “فريق أحمر” آلي. نتأكد من اجتيازها جميعًا. لكننا نفعل ذلك عبر بناء ضوابط صلبة خارج النموذج. يمكننا إيقاف ذلك ورؤية معدلات النجاح/الفشل للنموذج وحده. أضعف نموذج نختبره يفشل بنسبة 17٪. أحدث نموذج وأكبره يفشل بنسبة 2٪. تقدم كبير، أليس كذلك؟ لكن هل 98٪ كافية عندما يعني كل فشل تسرب بيانات حساسة؟ ليس حتى قريبًا.

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

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