شحن تطبيق LLM يعني شحن نظام أوضاعه الفاشلة ليست استثناءات أو آثار مكدس بل مخرجات — شاتبوت يسرب موجه النظام الخاص به، وكيل يمكن حجته لاستدعاء أداة لا ينبغي أن يفعل، ومساعد دعم يخترع بثقة سياسة استرجاع. لا يرمي أي من هذه خطأ. الاختبار التقليدي، الذي يؤكد أن دالة تعود قيمة متوقعة، لا يمكن أن يعبر معظمهم. الانضباط الذي ظهر لملء هذه الفجوة هو اختبار اللون الأحمر LLM: مهاجمة نموذجك وتطبيقك بقصد للعثور على المدخلات التي تنتج السلوك غير المقبول، قبل أن يفعله شخص آخر.
بحلول عام 2026 تطورت هذا من تجارب الأوامر المخصصة إلى منظر الأدوات مع طبقات مميزة. يرسم هذا الدليل هذا المنظر — garak و PyRIT في طبقة النموذج، DeepTeam و promptfoo في طبقة التطبيق، Agentic Security لتمويج نقطة نهاية بدون صندوق أسود، و Giskard و Inspect للمسح والتقييم الصارم. الخيط هو أن هذه الأدوات ليست منافسين: فهي تلتقط فئات فشل مختلفة، وتشغيل واحد فقط يترك ثغرات يمكن توقعها.
ما الذي تختبره فعلاً
قبل الأدوات، يساعد بتسمية فئات الفشل، لأنها تتطلب اختبارات مختلفة. كسور الأقفال وحقن الأوامر هي العناوين الرئيسية: الحصول على النموذج لتجاهل تعليماته، إما من خلال التلاعب المباشر ("تجاهل التعليمات السابقة") أو بشكل غير مباشر من خلال محتوى يسترجعه — وثيقة مسمومة تحمل تعليمات يتابعها النموذج بعد ذلك. الحقن غير المباشر هو المتغير الأكثر خطورة في أنظمة RAG والوكيل، لأن المهاجم لا يلمس صندوق الموجه أبداً.
تسرب البيانات يغطي الاستخراج موجه النظام أو PII رأيته النموذج في السياق، أو بيانات التدريب. الوكالة المفرطة هي فئة الفشل التي تنمو أخطر أكثر مع اكتساب الوكلاء الأدوات: النموذج اتخاذ إجراء كان ينبغي أن يرفضه، أو ربط أدوات بطريقة تتجاوز سلطتها المقصودة. المحتوى الضار هو امتثال واضح مباشر مع طلبات لا ينبغي أن يرفضها التطبيق. و الهلوسة — الاختراع الواثق — غالباً ما تكون أعلى خطر عملي حتى لو كانت الأقل درامية.
كل من هؤلاء يعيشون في طبقة مختلفة. قابلية تجاوز الأقفال هي في الغالب خاصية النموذج. الوكالة المفرطة وتسرب الموجه هي خصائص التطبيق — موجهه النظام وأدواته وحرّاسه. الهلوسة هي خاصية pipeline، خاصة جودة الاسترجاع. هذا الطبقة هو بالضبط لماذا الأدوات انقسام الطريقة التي يفعلونها.
ماسحات طبقة النموذج: garak و PyRIT
garak (من NVIDIA) هو أقرب شيء إلى nmap للنماذج اللغوية. يشغّل مكتبة كبيرة من المسابر ضد نموذج — عائلات كسر الأقفال وحقن الأوامر والسمية وتسرب البيانات وهجمات الترميز — ويقرر منها نجحت. تشير إليها نموذج (نموذج HuggingFace أو نقطة نهاية OpenAI أو خادم محلي) وتعمل خلال الفهرس. قيمتها هي الاتساع والجهد المنخفض: تتعلم بسرعة أي عائلات هجوم معروفة نموذجك عرضة، دون تصميم أي شيء بنفسك.
PyRIT (من Microsoft) يستهدف مشكلة أصعب: هجمات متعددة الأدوار والمتعددة الأنماط. العديد من كسور الأقفال الحقيقية لا تعمل في رسالة واحدة؛ يعملون بإنشاء السياق على عدة أدوار وتصعيد تدريجي. PyRIT توفر التنسيق لذلك — استراتيجيات الهجوم مثل crescendo (التصعيد البطيء) و TAP (شجرة الهجمات مع التقليم) التي تتكيف بناءً على استجابات النموذج. وهي أكثر من ماسح من SDK: تؤلف المنسقات والأهداف والمحولات والمسجلات. هذا يجعل أكثر عملاً للبدء وأقوى للبحث في الهجمات التي لا يمكن لمسبار واحد أن يجدها.
القيد المشترك هو أن كلاهما اختبارات بشكل أساسي النموذج، وليس التطبيق الخاص بك. نموذج يقاوم مسابر garak في العزلة يمكن أن تكون محرجة مع سهولة داخل تطبيقك، لأن موجه النظام، والاسترجاع، والأدوات تنشئ سطح هجوم لم يره الماسح على مستوى النموذج أبداً.
أجنحة طبقة التطبيق: DeepTeam و promptfoo
هذا هو حيث DeepTeam و promptfoo تناسب. كلاهما يختبر التطبيق الخاص بك كما نُشر، لف أي تطبيق الخاص بك هو فعلاً — موجه والاسترجاع والأدوات والحرّاسات — والهجوم تلك الحزمة الكاملة.
DeepTeam، من فريق DeepEval، يعبر عن اختبار اللون الأحمر كـ Python: توفر model_callback التي تستدعي تطبيقك، إعلان أي نقاط ضعف لاستقصاء (تسرب PII والوكالة المفرطة والانحياز وتسرب الموجه) وأي هجمات لاستخدام، وهو ينشئ وينفذ حالات معادية. تحسينات الهجوم هي الجزء الثاني — نفس الهجوم الأساسي المكتوب جديد كـ base64، بلغة أخرى، كلعب أدوار، أو تصعيد عبر الأدوار، وهي كيف يتجنب المهاجمون الحقيقيون مرشحات ساذجة. لأنه رمز، فهو يسقط في مجموعة اختبار وينفذ في CI.
promptfoo يأتي منه من التقييم: إنه CLI مدفوع بالإعدادات لاختبار مخرجات LLM التي نمت قدرة كبيرة لاختبار اللون الأحمر، توليد تلقائي للأوامر المعادية عبر عشرات المكونات الإضافية للهجوم ورسم الخلاف لأطر الامتثال. نقاط قوتها هي تكامل CI والحقيقة أن نفس الأداة تغطي كل من تقييمات الجودة والاختبارات الأمنية، بحيث يخدم واحد حديقة كلا الغرضين.
بالنسبة لمعظم الفريق التي تشحن منتج LLM، هذه الطبقة أكثر أهمية من طبقة النموذج، لأنها تختبر الشيء الذي نشرته فعلاً. المصيدة هي أنها تتطلب منك تحديد ما "غير مقبول" يعني لتطبيقك — توليد الأدوات الهجمات، لكن توفير الحكم حول أي مخرجات هي إخفاقات.
الاقتراب من الصندوق الأسود والماسح
شكلان آخران يستحقان المعرفة. Agentic Security يعامل نقطة النهاية الخاصة بك كصندوق أسود وفوازير agenticلية — توليد المسابر وملاحظة الاستجابات والتكيف — مع الإضافة المفيدة اختبار إجهاد API. هذا الجزء الأخير قليل التقدير: نسبة كبيرة من نشرات LLM تفشل على حدود معدل الطلب واستنزاف الموارد قبل أن تفشل على سلامة المحتوى، ومعظم أدوات اختبار اللون الأحمر تتجاهل ذلك تماماً.
Giskard ينقل عكس سير العمل المعتاد. بدلاً من تطلب منك تحديد ما يجب اختباره، فإنه يمسح النموذج — باستخدام وصفك لما يفعله التطبيق لإنشاء مسابر ذات صلة بالمجال — وينتج تقريراً عن نقاط الضعف المكتشفة، والتي يمكنه تحويلها إلى مجموعة اختبارات قابلة لإعادة الاستخدام. نمط المسح ثم التصديق ثمين بالضبط لأن الجزء الأصعب من اختبار اللون الأحمر يعرف ما يجب البحث عنه. Giskard يجد قضايا لم تفكر في اختبارها، ثم يأمرها كاختبارات انحدار.
وأخيراً، Inspect من معهد الذكاء الاصطناعي بالمملكة المتحدة جالس قليلاً بعيداً: وهو إطار عمل تقييم صارم بدلاً من أداة هجوم، لكن بنيته (مجموعات البيانات والحلّالات والمسجلات) وعارضه النسخ الممتاز يجعله الاختيار الصحيح عندما تحتاج إلى قياس قابل للدفاع وقابل للتكرار — بما في ذلك السلوك wucleي — بدلاً من قائمة ضعف.
بناء ممارسة متطبقة
الاستنتاج العملي هو أن هذه الأدوات تؤلف. ممارسة معقولة 2026 تبدو مثل هذا.
عندما تختار أو تحديث نموذج أساسي، تشغيل ماسح طبقة النموذج — garak للاتساع، PyRIT إذا كان قوة متعددة الأدوار تهم ملف المخاطر الخاص بك. هذا يخبرك باختيار النموذج ويخبرك ما المؤسسة تقاوم من تلقاء نفسها.
أثناء التطوير، تشغيل أداة على غرار الماسح مثل Giskard ضد التطبيق الفعلي الخاص بك لاكتشاف فئات الفشل التي لم تتوقعها، وتحويل نتائجها إلى اختبارات.
في CI، عند كل موجه أو نموذج أو تغيير أداة، تشغيل أجنحة طبقة التطبيق — DeepTeam أو promptfoo — كبوابة. هذا هو أعلى تشغيل قيمة الأتمتة، لأن الموجهات وتعاريف الأدوات هي سطح التحكم بتطبيق LLM وتتغير باستمرار. تحرير موجه يبدو غير ضار يمكن أن يزيل الجملة التي كانت تمنع تجاوز الأقفال.
قبل الإفراج، أضف تمويج اسود صندوق ضد نقطة النهاية المنشورة، بما في ذلك اختبار الإجهاد، لاكتشاف مشاكل مستوى النشر التي اختبارات مستوى الرمز تفتقد.
واحتفظ بالبشر فيها. كل أداة آلية اختبارات عائلات هجوم معروفة. الهجمات الجديدة — تلك المحددة لمجالك وبياناتك وأدواتك — تأتي من شخص يفهم منطق العمل يفكر بشكل معاكس. الأتمتة ترفع الأرضية؛ لا تحل محل السقف.
الحقن غير المباشر: الهجوم الذي يكسر النموذج
فئة هجوم واحدة تستحق معاملة منفصلة لأنها تهزم الحدس الذي يبدأ معظم الفريق. الحقن المباشر — كتابة المستخدم "تجاهل تعليماتك" — هو ما يختبره الجميع أولاً، وهو النصف الأسهل. الحقن غير المباشر هو عندما تصل تعليمات الخبيثة من خلال محتوى النظام يسترجع: وثيقة في قاعدة المعرفة، صفحة ويب يصفحها الوكيل، بريد إلكتروني يوجزه، تعليق الرمز الذي يقرأه. المهاجم لا يتفاعل مع صندوق الموجه على الإطلاق.
هذا مهم جداً لأنظمة RAG والوكلاء، لأن اقتراحهم القيمة كله هو استهلاك محتوى خارجي. مساعد دعم يجيب من التوثيق الخاص بك سيتابع بأمانة تعليمات المدرجة في وثيقة إذا كان بإمكان شخص ما الحصول على وثيقة في الفهرس — من خلال ويكي عام أو تذكرة مقدمة من العميل أو صفحة محكوم عليها. وكيل الذي يقرأ قضية GitHub يمكن أن تؤمر بتلك القضية. حدود الثقة الناس صورة ("المستخدمون غير موثوقين، بياناتنا موثوقة") لا تحمل مرة واحدة أي جزء من الفهرس يمكن تأثره.
الاختبار لهذا أصعب من اختبار الحقن المباشر، لأنه يتطلب محاكاة محتوى مسموم، وليس موجهات مسمومة — تحتاج إلى وضع نص معاكس حيث الاسترجاع سيجده والتحقق من أن النموذج لا يتصرف عليه. أدوات طبقة التطبيق تتعامل مع هذا أفضل من ماسحات طبقة النموذج، لأن pipeline الاسترجاع هو جزء مما يمارسون، لكن غالباً ما يتطلب بناء السيناريو بقصد.
التخفيفات معمارية بدلاً من الموجه. تعامل مع جميع المحتوى المسترجع كمدخلات غير موثوقة، بنفس الطريقة التي تعامل بها مع إدخال المستخدم. لا تدع النص المسترجع يصل إلى موضع حيث يمكن تفسيره كتعليمات إذا كان بإمكانك تجنب هيكليًا. ثبّت ما يمكن لوكيل استدعاء أثناء معالجة محتوى غير موثوق، واطلب تأكيد للإجراءات العاقبة. ويحافظ على الأصل: يعرف أي وثيقة أنتجت إجابة سيئة هي ما يحول حادثة إلى إصلاح.
ما اختبار اللون الأحمر لا يصلح
تحذير تستحق الحالة بوضوح: إيجاد نقطة ضعف ليس هو نفس إصلاحه، وعيوب LLM غالباً ما لا تكون قابلة للإصلاح بالكامل. لا يمكنك تصحيح نموذج بالطريقة التي تصحيح تجاوز المخزن المؤقت. الاستجابات الواقعية هي التخفيف بدلاً من الإزالة: موجهات نظام أشد صرامة و guardrails على الإدخال والإخراج مثل LLM Guard، وأذونات الأداة المحدودة، والموافقة البشرية للإجراءات العاقبة، والمراقبة للسلوك الشاذ.
هذا يغير معنى تقرير فريق اختبار اللون الأحمر. في الأمان التقليدي، يشير الإيجاد إلى إصلاح. في أمان LLM، يشير الإيجاد غالباً إلى قرار المخاطرة: هذا الهجوم ينجح بمعدل ما، هنا هو التخفيف، هنا هو المخاطر المتبقية، هل ذلك مقبول لحالة الاستخدام هذه؟ الفريق الذي يتوقع اختبار اللون الأحمر لإنتاج فاتورة نظيفة من الصحة سيخيب آماله دائماً. الفريق الذي يستخدمه لقياس وقبول واعي المخاطر يحصل على قيمة حقيقية.
النتيجة الطبيعية هي أن العمارة تفوق هندسة الموجهات للإخفاقات التي تهم أكثر. وكيل الذي لا يمكن حجته في التحويل المال لأنه هيكليًا يفتقد تلك الإذن أكثر أماناً من واحد يعتمد على النموذج لرفضه. الوكالة المفرطة تعالج أفضل بإعطاء وكالة أقل. الإخراج الأكثر فائدة لاختبار اللون الأحمر غالباً ما يكون إدراك أن القدرة يجب لم تكن معروضة في المقام الأول.
الخط السفلي
اختبار اللون الأحمر LLM أصبح تخصص حقيقي لأن إخفاقات LLM مخرجات بدلاً من أخطاء، والاختبار العادي لا يمكن أن يعبر عنها. تقسيم 2026 tooling حسب الطبقة، وهذا الانقسام هو المفتاح لاستخدامه بشكل جيد: garak و PyRIT مسبار النموذج، DeepTeam و promptfoo الهجوم التطبيق نشرته فعلاً، Agentic Security فوازير نقطة النهاية بما في ذلك حدود الموارد، و Giskard اكتشاف المشاكل لم تكن تعرف البحث عن. تشغيل أكثر من واحد، بوابة CI على طبقة التطبيق حيث تتغير الموجهات أكثر، احتفظ بالتفكير المعاكس البشري في الحلقة، وتعامل مع النتائج كقرارات المخاطرة بدلاً من الأخطاء في انتظار تصحيح — ثم إصلاح ما بإمكانك في العمارة بدلاً من الموجه.
المراجع والموارد
الأدوات
الخلفية والتحليل
- أفضل ماسحات ضعف LLM 2026: Garak و PyRIT و Promptfoo
- دليل اختبار اللون الأحمر LLM 2026: الأدوات والهجمات والمنهجية — AppSec Santa
- أدوات اختبار اللون الأحمر LLM مقارنة — QAwerk
- awesome-ai-security-tools
أوراق cheatsheet ذات صلة بـ 1337skills