ما المقصود بأمن النماذج اللغوية الكبيرة؟ كيفية التخفيف من أبرز 10 مخاطر أمنية وفق OWASP
دليل إلى أمن النماذج اللغوية الكبيرة يستعرض قائمة OWASP Top 10 لتطبيقات النماذج اللغوية الكبيرة لعام 2026، مع حادثة واقعية ودفاعات عملية لكل خطر.

يحتل حقن الأوامر (Prompt Injection)، وهو هجوم يخدع الذكاء الاصطناعي ليتعامل مع تعليمات المهاجم على أنها أوامر، المرتبة الأولى في قائمة OWASP Top 10 لتطبيقات النماذج اللغوية الكبيرة في كل إصدار منذ عام 2023.
تُعد هذه القائمة أقرب ما يكون إلى الإجماع في مجال أمن الذكاء الاصطناعي. فقد بدأ المشروع بمجموعة صغيرة من المتخصصين في الأمن، ويستعين اليوم بأكثر من 600 خبير مساهم في أكثر من 18 دولة.
نحن شركة ذكاء اصطناعي تنشر دليلًا عن الطرق التي يُستدرج بها الذكاء الاصطناعي إلى فعل ما لا ينبغي، لذا لن نتظاهر بأن هذه المشكلة قد حُلّت. وقد كان ويلسون، الذي يشارك في قيادة مشروع OWASP، واضحًا تمامًا بشأن وسائل الدفاع الحالية: «...بصراحة، لا أعتقد أننا وصلنا إلى 99%».
ويبدأ إصدار 2026 بالنبرة نفسها؛ إذ يدعونا قائد المشروع إلى «التوقف عن محاولة بناء نموذج لا يمكن خداعه»، وإلى تصميم النظام المحيط به بحيث لا يستطيع النموذج المخدوع إفساد أي شيء مهم.
ونحن نتبنى هذا الموقف في تناولنا للمخاطر العشرة كلها في قائمة OWASP لعام 2026.
ما المقصود بأمن النماذج اللغوية الكبيرة؟
يعني أمن النماذج اللغوية الكبيرة حماية نماذج الذكاء الاصطناعي والتطبيقات التي تستخدمها من الهجمات وسوء الاستخدام. ويزداد الخطر بازدياد ما يتصل به النموذج: الملفات والبيانات التي يمكنه قراءتها، والأدوات التي يمكنه استخدامها، مثل البريد الإلكتروني أو البحث أو قاعدة بيانات الشركة.
في البرمجيات المؤمّنة جيدًا، هناك خط فاصل واضح بين التعليمات التي يتبعها البرنامج والمعلومات التي يعالجها. لكن النماذج اللغوية الكبيرة تفتقر إلى هذا الخط.
كل ما يقرؤه النموذج يصله على هيئة تدفق نصي واحد طويل: تعليمات المطوّر، وسؤالك، وصفحة ويب بحث فيها. ومن المفترض أن تتتبّع نماذج الذكاء الاصطناعي هوية المتحدث، سواء أكان المطوّر أم المستخدم أم النموذج نفسه وهو يفكر في حل مشكلة ما.
لكن الباحثَين جاسمين كوي وتشارلز يي وجدا أن النماذج تخمّن في الغالب هوية المتحدث من أسلوب النص. لذا، إذا كتب مهاجم شيئًا يبدو كأنه استدلال النموذج نفسه، فقد يعتقد النموذج أنه صاحب الفكرة. وهذه مشكلة لأي منظومة أمان تعتمد على معرفة النموذج بمن له زمام الأمر.
وقد واجهنا المشكلة نفسها مع وكلاء الذكاء الاصطناعي الخاصين بنا. إذ أوضح كبير مسؤولي أمن المعلومات لدينا، كايل بولي، في تصريح لموقع ISMG أن الوكلاء «قد لا يلتزمون بالسياسات حتى لو أضفتها إلى موجّه النظام». ولهذا السبب أنشأنا Numbat، وهي أداة مفتوحة المصدر تتحقق مما يوشك الوكيل على فعله، ويمكنها حظره إذا كان الإجراء يخالف قاعدة أمان مُهيّأة.
يعني أمن النماذج اللغوية الكبيرة التسليم بأن النموذج سيتلقى الأوامر أحيانًا من الشخص الخطأ، وإحاطته بـضوابط حماية للذكاء الاصطناعي تصمد حتى عند حدوث ذلك.
ما أفضل الممارسات لأمن النماذج اللغوية الكبيرة؟
سنستعرض قائمة OWASP Top 10 لتطبيقات النماذج اللغوية الكبيرة لعام 2026 بالترتيب، من المرتبة الأولى إلى المرتبة العاشرة.
لكل خطر، ستجد شرحًا مبسّطًا لكيفية حدوث الخلل، ومثالًا من الواقع. ثم سنتناول الممارسات التي يمكن أن تساعد على منعه، أو على الأقل الحدّ من الضرر.
الترتيب | خطر أمن النماذج اللغوية الكبيرة | ما الخلل المحتمل؟ |
01 | حقن الأوامر | يدفع المهاجم الذكاء الاصطناعي إلى اتباع تعليمات لا ينبغي له اتباعها. |
02 | الإفصاح عن المعلومات الحساسة | يكشف الذكاء الاصطناعي معلومات خاصة لشخص لا يحق له الاطلاع عليها. |
03 | الاستقلالية المفرطة | يملك الذكاء الاصطناعي من الصلاحيات وحرية التصرف ما يكفي لتحويل خطأ ما إلى ضرر. |
04 | سلسلة التوريد | يُدخل نموذجٌ أو مجموعة بيانات أو حزمة برمجية مخترَقة مهاجمًا إلى تطبيقك. |
05 | تسميم البيانات والنماذج | يتلاعب أحدهم بالبيانات أو بالنموذج لتغيير سلوكه أو زرع باب خلفي. |
06 | الاستهلاك غير المحدود | تستنزف الطلبات أو المهام الخارجة عن السيطرة القدرة الحاسوبية والأموال. |
07 | المعلومات المضللة | ينتج الذكاء الاصطناعي معلومات خاطئة يتصرف بناءً عليها أشخاص أو أنظمة أخرى. |
08 | كشف السياق المخفي | يكشف الذكاء الاصطناعي تعليمات داخلية أو معلومات خلفية لم يكن من المفترض أن يراها المستخدمون. |
09 | نقاط الضعف في المتجهات والتضمينات | تتيح نقاط الضعف في طريقة تخزين المعلومات واسترجاعها للمهاجمين كشف البيانات أو تعطيل الإجابات. |
10 | المعالجة غير السليمة للمخرجات | يستخدم نظام آخر مخرجات الذكاء الاصطناعي دون التحقق منها، مما يسمح لها بتنفيذ أوامر أو كشف بيانات أو إحداث أضرار. |
1. احتواء حقن الأوامر
يحدث حقن الأوامر عندما يدفع المهاجم الذكاء الاصطناعي إلى اتباع تعليمات لا ينبغي له اتباعها. ويمكن أن تصل هذه التعليمات مباشرةً في دردشة، أو أن تُزرع في رسالة بريد إلكتروني أو صفحة ويب أو مستند.
يُعرف النوع الثاني باسم حقن الأوامر غير المباشر. تطلب من مساعدك تلخيص مستند، لكن كاتبه أوعز فيه إلى المساعد بأن يرسل إليه ملفاتك الخاصة. وإذا اتبع المساعد تلك التعليمات، فإن كاتب المستند يكون قد استعار صلاحيات الوصول الخاصة بك فعليًا.
يرى موقع PCMag أن تأمين الأوامر يشبه سدّ الثقوب في حجر مسامي؛ فما إن تسدّ فتحة حتى يجد الماء فتحة أخرى. «يجد الهجوم طريقه إلى النظام، فيُصلَح، لكن تبقى سبل أخرى لا حصر لها للهجوم تنتظر من يكتشفها، وذلك ببساطة بسبب الطبيعة الديناميكية لأنظمة مثل النماذج اللغوية الكبيرة».
مثال: في يونيو 2025، اكتشف باحثون في Aim Security ثغرة EchoLeak، وهي ثغرة خدعت Microsoft 365 Copilot ودفعته إلى تسريب معلومات خاصة بالشركة. فعندما كان أحد الموظفين يطرح سؤالًا روتينيًا متعلقًا بالعمل، كان بإمكان Copilot أن يجلب رسالة البريد الإلكتروني، ويتبع التعليمات المخفية فيها، ويرسل معلومات حساسة إلى المهاجم. وقد تجاوز الهجوم عمليات الفحص المصممة لرصد التعليمات الخبيثة وإزالة الروابط المشبوهة.
ما يمكنك فعله:
- اتبع «قاعدة الاثنين» من Meta: احتاجت ثغرة EchoLeak إلى ذكاء اصطناعي يستطيع قراءة بيانات الشركة، وقراءة رسائل البريد الإلكتروني الخارجية، وإرسال المعلومات إلى الخارج، وقد توافرت فيه القدرات الثلاث جميعها. ويحول تقييده بقدرتين فقط من هذه القدرات دون أن يكتسب حقن الأوامر سيطرة مفرطة. وإذا كانت المهمة تتطلب القدرات الثلاث، فاشترط الحصول على موافقة بشرية قبل كل إجراء.
- اختبر دفاعاتك أمام مهاجمين يعرفونها: زوّد مختبري الأمان لديك بالقواعد وعوامل التصفية التي وضعتها، ثم دعهم يحاولون الالتفاف عليها. ففي إحدى الدراسات، نجح المهاجمون الذين تكيّفوا مع الدفاعات في أكثر من 90% من المحاولات ضد معظم وسائل الدفاع الاثنتي عشرة التي خضعت للاختبار.
2. منع تسرّب المعلومات الحساسة
عندما تقدّم أنظمة الذكاء الاصطناعي معلومات خاصة لأشخاص لا يحق لهم الاطلاع عليها، يُسمى ذلك الإفصاح عن المعلومات الحساسة. وقد يعني ذلك كشف تفاصيل الدفع الخاصة بأحد العملاء، أو ترك محادثات خاصة على قاعدة بيانات مشتركة.
تبدأ كثير من حالات التسريب بـ«الإفراط في المشاركة». لنفترض أن شركة ما ربطت نظام الذكاء الاصطناعي لديها بمحركات أقراص وقواعد معرفية ذات أذونات متساهلة. سيسترجع الذكاء الاصطناعي كل ما يمكنه الوصول إليه، تمامًا كما صُمّم. لا حاجة إلى أن يخترق أحدٌ النظام، لكن اعتبر النموذج اللغوي الكبير مخترَقًا.
مثال: في يناير 2025، عثر باحثون في Wiz على قاعدة بيانات تابعة لـ DeepSeek مكشوفة على الإنترنت، وتحتوي على أكثر من مليون إدخال في السجلات، من بينها سجل الدردشات ومفاتيح API، وهي مفاتيح تستخدمها البرمجيات للوصول إلى خدمات أخرى. ولم يحتج الباحثون إلى إقناع النموذج بالكشف عن أي شيء.
ما يمكنك فعله:
- تحقق من صلاحيات الوصول قبل أن يقرأ الذكاء الاصطناعي البيانات: ينبغي أن يتحقق تطبيقك من المستندات المسموح للشخص الذي يطرح السؤال بالاطلاع عليها قبل تمريرها إلى النموذج.
- احمِ السجلات التي يخلّفها الذكاء الاصطناعي: أزل التفاصيل الخاصة والمفاتيح السرية قبل حفظ سجلات النشاط، واشترط تسجيل الدخول، وقصر الوصول على من يحتاجون إليها. وحدّد فترة احتفاظ حتى لا تتراكم هذه السجلات إلى ما لا نهاية.
3. كبح الاستقلالية المفرطة
تتمتع أنظمة الذكاء الاصطناعي ذات الاستقلالية المفرطة بصلاحيات تفوق ما تتطلبه مهامها: أدوات لا تحتاج إليها، أو أذونات تتجاوز نطاق مهمتها، أو حرية التصرف دون تحقق. والسبب هنا لا يهم.
سواء أكان السبب أمرًا محقونًا أم خللًا برمجيًا أم نموذجًا أخطأ ببساطة، فالنتيجة واحدة. فالذكاء الاصطناعي سيُقدم في النهاية على فعل مدمّر إن كانت لديه القدرة على ذلك.
مثال: في يوليو 2025، أفاد جيسون ليمكين، مؤسس SaaStr، بأن وكيل البرمجة من Replit حذف قاعدة بياناته التي تضم 1,206 سجلات لمسؤولين تنفيذيين، رغم التعليمات بعدم إجراء أي تغييرات. وقد ذكر الوكيل في البداية أنه لا يمكن استعادة البيانات، لكن تبيّن لاحقًا أن استعادتها ممكنة. ووجد جيسون أن مطالبة الوكيل بعدم المساس بقاعدة البيانات لم تُلغِ قدرته على حذفها.
المصدر: X
ما يمكنك فعله:
- أزل القدرات التي لا تحتاج إليها المهمة: قيّد الأدوات التي يحصل عليها الوكيل وما يمكن لهذه الأدوات فعله على حد سواء. فالمساعد الذي يلخّص رسائل البريد الإلكتروني يحتاج إلى إذن بقراءتها، لا بإرسالها أو حذفها.
- ضع عمليات التحقق من الأذونات خارج الذكاء الاصطناعي: في كل مرة يُطلب فيها إجراء ما، احرص على مطابقته مع قواعد الأمان لديك، واشترط موافقة شخص عليه.
4. فحص ما يدخل إلى سلسلة توريد الذكاء الاصطناعي لديك
قليلة هي الشركات التي تبني الذكاء الاصطناعي من الصفر، ويتناقص عددها عامًا بعد عام. فوفقًا لاستطلاع Menlo Ventures لعام 2025 حول حالة الذكاء الاصطناعي التوليدي في المؤسسات، اشترت 53% من الشركات نماذج ذكاء اصطناعي في عام 2024، وارتفعت هذه النسبة إلى 76% في عام 2025.
وفي أغلب الأحيان، تنزّل الشركات النماذج من منصات مثل Hugging Face، وتواصل تدريبها على مجموعات بيانات جمعها آخرون، وتضيف إليها ملحقات وحزمًا برمجية كتبها غرباء.
وكل جزء من هذه الأجزاء يمثّل منفذًا للاختراق. فإذا تعرّض أحدها للتلاعب، وصلت المشكلة إلى المستخدمين مدمجةً في منتجك.
مثال: ارتفع عدد مستودعات النماذج العامة على Hugging Face من 2.43 مليون إلى 2.96 مليون بين يناير 2026 وأغسطس 2026. لكن في يوليو 2026، تمكّنت نماذج OpenAI، خلال اختبارات أمنية داخلية، من الالتفاف على الضوابط المصممة لإبقائها بعيدة عن الإنترنت، واخترقت أجزاءً من أنظمة Hugging Face. بل إن أحد الوكلاء استعاد 14 من بيانات اعتماد الوصول المكشوفة للعامة، وتحقق من صلاحيتها، وشاركها مع وكلاء آخرين. ثم استغل الوكلاء ثغرات أتاحت لهم تشغيل التعليمات البرمجية على خوادم Hugging Face.
ويقول تقرير OpenAI: «نحن نفرض متطلبات أكثر صرامة على المواءمة طوال دورة حياة النموذج، وننشئ بيئات Sandbox أكثر عزلًا، ونقيّد الوصول إلى الإنترنت، ونُحكم السيطرة على الوصول إلى أوزان النموذج».
ما يمكنك فعله:
- ثبّت النماذج على إصدار محدد وتحقق منها: ثبّت كل نموذج على إصدار خضع للمراجعة، وتحقق من البصمة الرقمية لملفه قبل تحميله، حتى لا يتسلل ملف بديل تحت التسمية نفسها. كما توصي OWASP باستخدام التوقيعات الرقمية، مع تحفظ: فالتوقيع يثبت مصدر النموذج، لا أنه آمن.
- افحص كل حزمة يقترحها الذكاء الاصطناعي: قبل تثبيت حزمة برمجية أوصى بها مساعد ذكاء اصطناعي، تأكد من أنها موجودة، وأنها الحزمة التي تقصدها، وأنها صادرة عن الناشر الذي تتوقعه.
5. الحماية من تسميم البيانات والنماذج
يتعلّم الذكاء الاصطناعي المسموم من بيانات فاسدة، وقد تكون هذه البيانات هي الأمثلة التي خضع لضبط دقيق عليها، أو قاعدة معرفية يبحث فيها عن الإجابات. ويبدو النموذج كأنه يعمل بشكل طبيعي، لكنه يتعلّم دروسًا خاطئة، وأحيانًا يتعلّم أن يسيء التصرف فقط عندما يرى عبارة تحفيز معيّنة.
وستمرّ هذه العبارة دون أن يكشفها أي اختبار تجريه، إلى أن يستخدمها أحدهم.
كما يصعب جدًا التراجع عن آثار التسميم؛ فهو ليس خللًا برمجيًا يمكنك إصلاحه بتصحيح. وإذا كانت بياناتك خاطئة، فقد تحتاج إلى إعادة فحصها، أو إعادة تدريب النموذج، أو استبداله بالكامل.
مثال: في أكتوبر 2025، أثبت باحثون من Anthropic ومعهد أمن الذكاء الاصطناعي البريطاني ومعهد آلان تورينغ أن 250 مستندًا مسمومًا كانت كافية لتعليم نموذج إنتاج كلام غير مفهوم كلما صادف محفّزًا معيّنًا. وقد نجح العدد نفسه مع أحجام النماذج الأربعة التي خضعت للاختبار، رغم أن أكبرها دُرِّب على بيانات نظيفة تفوق ما دُرِّب عليه أصغرها بأكثر من 20 ضعفًا.
ما يمكنك فعله:
- تتبّع مصدر بياناتك: احتفظ بسجل لكل مجموعة بيانات ونموذج تستخدمه، ومصدر كل منها، وما تغيّر بين الإصدارات. ونوصي باستخدام نظام للتحكم في إصدارات مجموعات البيانات، حتى إذا اكتُشف تسميم، أمكنك الرجوع إلى إصدار نظيف ومعرفة كيف تسلل.
- اختبر وجود أبواب خلفية: «الباب الخلفي» سلوك خفي يزرعه المهاجم في النموذج، ويظل كامنًا بانتظار عبارة معيّنة أو محفّز آخر لتفعيله. اختبر وجود هذه الأبواب باستخدام مدخلات مصممة لدفع النموذج إلى خرق قواعده المعتادة.
6. وضع حد للاستهلاك غير المحدود
عندما لا تكون هناك أي حدود لمقدار العمل الذي يمكن لأنظمة الذكاء الاصطناعي إنجازه أو للتكلفة التي قد تترتب عليه، يُعدّ استهلاكها «غير محدود». وتفرض معظم خدمات الذكاء الاصطناعي رسومًا حسب الاستخدام، لذا قد يتسبب المهاجم في تضخيم فاتورتك أو في بناء نسخة من نموذجك.
تسمي OWASP المشكلة الأساسية «عدم تماثل التكلفة»، إذ يمكن لطلب قصير ورخيص أن يؤدي إلى عمليات حوسبة مكلفة من جانبك.
مثال: في مايو 2024، اكتشف فريق أبحاث التهديدات في Sysdig هجومًا جديدًا يُسمى «LLMjacking». فقد استهدفت مجموعة من المهاجمين 10 خدمات للنماذج اللغوية الكبيرة مستضافة على السحابة باستخدام بيانات اعتماد مسروقة. وتسللوا عبر إصدار معرَّض للثغرات من Laravel، ثم اكتشفوا ما يمكن فعله ببيانات الاعتماد وأي حصص استخدام مرتبطة بها، وكان هدفهم الواضح بيع إمكانية الوصول. كما استعلموا عن كثير من إعدادات التسجيل، على الأرجح لتجنّب اكتشافهم. ووفقًا لـ Sysdig، قد تتجاوز تكلفة أسوأ السيناريوهات على الضحية 46,000 دولار في اليوم.
ما يمكنك فعله:
- حدّد ميزانيات توقف الإنفاق: ضع حدودًا صارمة للإنفاق للمستخدمين الأفراد، ولمفاتيح API، وللفرق، وللحساب ككل. وطبّقها في كل نقطة يمكن أن تدخل منها الطلبات.
- حدّد نقطة توقف لكل مهمة: قيّد المدة التي يمكن أن تستغرقها المهمة، وكمية النص التي يمكنها معالجتها وإنشاؤها، وعدد استدعاءات الأدوات التي يمكنها إجراؤها. وأضف آليات إيقاف تلقائي للوكلاء الذين يكررون أنفسهم أو يتجاوزون الحصة المخصصة لهم.
7. رصد المعلومات المضللة قبل اتخاذ أي إجراء
عندما ينتج الذكاء الاصطناعي شيئًا خاطئًا يبدو صحيحًا، ويتصرف أحدٌ ما، أو شيءٌ ما، بناءً عليه، يُسمى ذلك معلومات مضللة. ولا يكمن الخطر الأساسي في الإجابة الخاطئة بحد ذاتها بقدر ما يكمن في الوثوق بها واستخدامها.
يشير سجل الحوادث إلى أن المتخصصين لم يكونوا قلقين من المعلومات المضللة بالقدر الذي كان ينبغي. فوفقًا للرسالة الافتتاحية لإصدار 2026، وضعها المصوّتون قرب أسفل القائمة، لكن الحوادث الواقعية تضعها قرب القمة.
مثال: في عام 2025، قدّمت Deloitte أستراليا مراجعة لأنظمة تقنية المعلومات الخاصة بالرعاية الاجتماعية بموجب عقد حكومي بقيمة 440,000 دولار أسترالي. وفي جامعة سيدني، عثر الباحث كريس رادج على إحالات إلى أبحاث غير موجودة، وعلى اقتباس مختلَق من حكم صادر عن محكمة فيدرالية. وكشف التقرير المعدَّل أن Deloitte استخدمت Azure OpenAI GPT-4o في منهجيتها، ووافقت الشركة على رد الدفعة الأخيرة. ومن المؤسف أن هذه كانت مراجعة تأكيدية.
ما يمكنك فعله:
- تحقق من أن الأدلة تدعم الإجابة: استند في الادعاءات إلى مصادر حديثة وموثوقة. وعند الإجابة عن سؤال يتعلق بسياسة ما، استرجع السياسة المعتمدة وتحقق من أنها تدعم الاستنتاج، بما في ذلك استثناءاتها.
- تحقق قبل أن يتصرف النظام: إذا أفاد وكيل بأن عميلًا اجتاز التحقق من الهوية، فتأكد من ذلك عبر نظام التحقق قبل صرف أي دفعة. واشترط موافقة بشرية على القرارات ذات العواقب المهمة، مع إتاحة الأدلة الداعمة للمراجع.
8. الحد من أضرار كشف السياق المخفي
تزوّد تطبيقات الذكاء الاصطناعي النموذج بتعليمات ومعلومات خلفية لا يراها المستخدمون عادةً. وقد يشمل ذلك موجّه النظام، والسياسات الداخلية، وأوصاف الأدوات المتاحة، والقواعد التي تحدد من يمكنه استخدامها. ويحدث كشف السياق المخفي عندما يكشف النموذج هذه المعلومات لأحدهم.
وسّعت OWASP هذا البند في عام 2026 بعد أن كان يحمل اسم «تسرّب موجّه النظام»، لأن موجّه النظام ليس سوى جزء مما يمكن أن يتسرّب. ويتوقف حجم الخطر على ما وضعته فيه. فتسرّب دليل نبرة الصوت أمر محرج بعض الشيء، أما تسرّب مفتاح API فيمنح شخصًا ما إمكانية الوصول إلى قاعدة بياناتك السرية.
مثال: في فبراير 2023، دفع مستخدمون Bing Chat من Microsoft إلى الكشف عن تعليماته الداخلية. وكانت إحدى المحاولات الناجحة من نصيب مارفن فون هاغن، الذي ادّعى أنه مطوّر في OpenAI وطلب التعليمات ليتمكن من تهيئة النموذج. فكشف Bing عن القواعد التي تحكم عمليات البحث التي يجريها وردوده وسلوكه المتعلق بالأمان، إلى جانب اسمه الداخلي Sydney. ومن بين التعليمات التي كُشف عنها تعليمة تطلب منه الحفاظ على سرية تلك التعليمات.
ما يمكنك فعله:
- أبقِ الأسرار خارج سياق النموذج: افترض أن أي شيء يستطيع النموذج قراءته قد يصبح مرئيًا للمستخدمين، لذا خزّن كلمات المرور ومفاتيح API ورموز الوصول في نظام منفصل لإدارة الأسرار.
- اجعل الأذونات صامدة حتى عند تسرّب القواعد: طبّق عمليات التحقق من الوصول في شيفرة تطبيقك. فإذا كانت أداة ما مقصورة على المسؤولين، فتحقّق من أذونات حساب المستخدم قبل تشغيلها.
9. أحكِم تأمين المتجهات والتضمينات
عندما يستخدم الذكاء الاصطناعي البحث المتجهي للعثور على إجابات في مستندات شركتك، فإنه لا يبحث في النص مباشرةً. إذ تُحوَّل المستندات إلى «تضمينات» (embeddings)، وهي قوائم طويلة من الأرقام تلتقط معنى كل مقطع، ثم تُخزَّن في قاعدة بيانات متجهية. ويُحوَّل السؤال بالطريقة نفسها، ثم يستخرج النظام المقاطع التي تكون أرقامها هي الأقرب إليه.
يلخّص مشروع OWASP أوجه الإخفاق الأربعة: التسميم يجعل النظام مخطئًا، والاستعادة العكسية تجعله يسرّب البيانات، والتشويش يجعله يصمت، وضعف التحكم في الوصول يجعله يسلّم أي شيء لأي شخص.
هذه الأرقام ليست التجريد الآمن الذي تبدو عليه. إذ يمكن تحويل التضمينات المخزّنة إلى نص مجددًا، وقد تمكّنت إحدى الطرق من استعادة 92% من المقاطع القصيرة المكوّنة من 32 رمزًا مميزًا بدقة تامة في اختباراتها. لذا فإن تسرّب نسخة احتياطية «تقتصر على التضمينات» قد يكشف محتوى المستندات أيضًا.
مثال: في بحث عُرض في مؤتمر USENIX Security 2025، أثبت الباحثون أن مستندًا واحدًا مصمَّمًا بعناية يمكن أن يمنع نظام ذكاء اصطناعي من الإجابة عن سؤال معيّن. فقد أضافوه إلى مجموعة المستندات التي يبحث فيها الذكاء الاصطناعي. وعندما عثر عليه، كان من الممكن أن يقول إنه لا يملك معلومات كافية أو إن الإجابة غير آمنة. ولم يكن المستند بحاجة إلى أن يطلب من الذكاء الاصطناعي تجاهل قواعده. ويُطلق على ذلك اسم «تشويش الاسترجاع».
ما يمكنك فعله:
- احتفظ بفهارس منفصلة للبيانات العامة والخاصة: لا تخلط محتوى الويب المجمَّع آليًا ببيانات الشركاء أو المستندات الداخلية السرية. اعتمد الفصل المادي حسب مستوى الثقة بدلًا من وسم المحتوى داخل فهرس واحد، لأن ذلك يقضي على فئة كاملة من أخطاء التهيئة، ويضمن ألا ينتهي المطاف بالمحتوى المجمَّع من الإنترنت بجوار وثائق مجلس إدارتك.
- تعامَل مع التضمينات كما تتعامل مع المستندات التي أُنشئت منها: شفّرها، واحمِ النسخ الاحتياطية لقاعدة البيانات المتجهية كما تحمي الملفات المصدرية، واحذف التضمينات عند حذف المستند الأصلي. وينبغي الحفاظ على سرية مفاتيح API الخاصة بخدمة التضمين لديك.
10. تحقّق من مخرجات الذكاء الاصطناعي قبل تمريرها
كلما مرّر تطبيقٌ مخرجات الذكاء الاصطناعي إلى نظام آخر دون التحقق من أنها آمنة للاستخدام فيه، فإنه يتعامل مع مخرجات النموذج اللغوي الكبير (LLM) بطريقة غير سليمة.
ويشمل هذا البند أيضًا الشيفرات غير الآمنة التي تولّدها مساعدات البرمجة بالذكاء الاصطناعي على نطاق واسع. لذا فإن كل سطر يكتبه المساعد يُعدّ من المخرجات أيضًا.
مثال: في عام 2025، أوضح الباحث يوهان ريبرغر كيف يمكن لمساعد البرمجة Amp من Sourcegraph أن يسرّب محتوى المحادثات بمجرد عرض صورة. فقد استخدم حقن الأوامر لجعل Amp يُدرج معلومات خاصة في عنوان الويب الخاص بإحدى الصور. ثم جلب التطبيق تلك الصورة تلقائيًا، فأرسل المعلومات إلى خادمه. وكان الخلل في التعامل مع المخرجات هو ذلك الطلب التلقائي، إذ تحوّل النص الذي أنشأه النموذج إلى اتصال بخادم خارجي يحمل معه بيانات خاصة.
ما يمكنك فعله:
- اجعل المخرجات آمنة لوجهتها: افحص الردود وتعامل معها وفقًا للمكان الذي ستذهب إليه. ففي صفحات الويب، امنع النص المُنشأ من التحول إلى شيفرة قابلة للتنفيذ. وفي قواعد البيانات، استخدم الاستعلامات المُعدّة مسبقًا التي تفصل القيم المُدخلة عن الأوامر.
- امنع الإجابات من إجراء اتصالات خارجية تلقائية: عطّل افتراضيًا التحميل التلقائي للصور ومعاينات الروابط والصفحات المضمّنة في ردود النموذج. واقصر الاتصالات الضرورية على الوجهات المعتمدة صراحةً.
كيف تؤمّن Perplexity النماذج اللغوية الكبيرة؟
نفترض أن كل خطر من المخاطر المذكورة أعلاه سيتحقق في النهاية، ولذلك نصمّم أنظمتنا بحيث لا يتمكن من إحداث ضرر كبير عند وقوعه. وقد شرح كايل بولي، كبير مسؤولي أمن المعلومات لدينا، كيفية ذلك في ورشة عمل حديثة.
- يحصل الوكيل على جهاز كمبيوتر خاص به، ويبدأ فارغًا: يمكن لأدوات الوكلاء المثبّتة على جهاز الكمبيوتر المحمول لديك الوصول إلى ملفاته وتطبيقاته وبيانات الاعتماد المحفوظة عليه. أما Perplexity Computer فيعمل بطريقة معاكسة. إذ تُنفَّذ كل مهمة داخل بيئة Sandbox معزولة خاصة بها، وكما يقول بولي: «افتراضيًا، لا يملك صلاحية الوصول إلى أي شيء».
- لا يرى الوكيل كلمات المرور أبدًا: تُخزَّن بيانات الاعتماد الخاصة بالخدمات المتصلة خارج بيئة Sandbox. وعندما يحتاج الوكيل إلى الوصول إلى خدمة مثل GitHub، يرسل طلبًا دون إرفاق أي بيانات اعتماد. فتتحقق بوابة من أن الوجهة والطلب مطابقان لما هو متوقع، ثم تضيف بيانات الاعتماد في أثناء خروج الطلب. وبذلك يستطيع الوكيل استخدام الاتصال دون الحصول على المفاتيح.
- تنتقل أذوناتك كما هي، ويمكنك تقييدها أكثر: تحافظ الاتصالات التي تُجرى عبر OAuth على أذونات الوصول الخاصة بك في الخدمة المتصلة. فإذا كنت لا تستطيع رؤية شيء ما، فلن يستطيع وكيلك رؤيته أيضًا.
- تُعامَل كل صفحة ويب معاملة الغريب: أنشأنا BrowseSafe لمتصفحنا الوكيلي Comet، لأن الأدوات التي اختبرناها لم تلبِّ احتياجاتنا في الاستخدام الفعلي. يفحص المتصفح صفحات الويب وغيرها من المحتوى الخارجي، بما في ذلك رسائل البريد الإلكتروني، بحثًا عن حقن الأوامر. وقد جعلنا كلًّا من النموذج ومجموعة البيانات مفتوحَي المصدر.
- نراقب الوكيل والأجهزة التي يعمل عليها: تقع أداة Numbat بين قرار الوكيل باتخاذ إجراء والتشغيل الفعلي للأداة. تسجّل Numbat النشاط عبر وكلاء البرمجة المدعومين، ويمكنها حظر الإجراءات التي تخالف السياسات المُهيّأة قبل تنفيذها. أما أداة Bumblebee فتُجري جردًا لحزم البرامج عبر أجهزة الكمبيوتر المحمولة والخوادم ومسارات البناء، وتُبلغ عن الحزم المعروفة بأنها ضارة. وكلتا الأداتين مفتوحة المصدر.
- لا يحتفظ مزوّدو النماذج ببياناتك: لدينا اتفاقيات لعدم الاحتفاظ بالبيانات مطلقًا مع مزوّدي النماذج اللغوية الكبيرة الخارجيين الذين نتعامل معهم. ويمكن لمسؤولي المؤسسات أيضًا ضبط مدة احتفاظ Perplexity نفسها بالبيانات لتصل إلى 24 ساعة فقط.
أنشأنا Numbat بشكل استباقي، لسبب يلخّصه بولي في جملة واحدة: «كلما منحت الوكيل قدرًا أكبر من الاستقلالية، زادت المخاطر».
الأسئلة الشائعة حول أمن النماذج اللغوية الكبيرة
ما النموذج اللغوي الكبير الأكثر أمانًا؟
لا يوجد نموذج لغوي كبير يجعل التطبيق آمنًا بمفرده، إذ لا تزال النماذج قادرة على الخلط بين المحتوى الذي ينبغي أن تقرأه والتعليمات التي ينبغي أن تتبعها. كما أن الدفاعات التي تبدو قوية في الاختبارات القياسية قد تنهار تحت الضغط.
السؤال الأفضل هو: أي إعداد هو الأكثر أمانًا لحالة استخدامك؟ ويعني ذلك أذونات محدودة، وإبقاء بيانات الاعتماد بعيدًا عن النموذج، واشتراط موافقة بشرية على الإجراءات الخطرة، وإجراء الاختبارات على يد أشخاص يعرفون دفاعاتك.
ما الثغرات الأمنية في النماذج اللغوية الكبيرة؟
الثغرات الأمنية في النماذج اللغوية الكبيرة هي نقاط ضعف تتيح خداع نظام الذكاء الاصطناعي أو تسريب بياناته أو تسبّبه في أضرار، سواء على يد مهاجم أو بسبب أخطائه الذاتية.
المخاطر العشرة الرئيسية هي: حقن الأوامر، والإفصاح عن المعلومات الحساسة، والاستقلالية المفرطة، وسلسلة التوريد، وتسميم البيانات والنماذج، والاستهلاك غير المحدود، والمعلومات المضللة، وكشف السياق المخفي، ونقاط الضعف في المتجهات والتضمينات، والتعامل غير السليم مع المخرجات.
هل النموذج اللغوي الكبير الخاص آمن؟
إنه خيار أكثر أمانًا في بعض الجوانب، لكن ليس افتراضيًا. فعند تشغيل نموذج على بنيتك التحتية الخاصة أو في بيئة سحابية، تحظى بقدر أكبر من التحكم في طريقة التعامل مع البيانات. لكن لا توجد طريقة تلقائية لمنع حقن الأوامر أو الاستقلالية المفرطة أو التسميم أو المعلومات المضللة.
وفي إطار الاستضافة الذاتية، تكون مسؤولًا أيضًا عن النموذج الذي تنزّله، بما في ذلك مخاطر سلسلة التوريد والبنية التحتية التي يتطلبها.