إذا كنت تبني مسارات عمل AI تمعالج رسائل العملاء أو تقديمات النماذج أو أي نصوص ينشئها المستخدمون، فأنت على بُعد إدخال محترف واحد من تسرب البيانات أو كشف تعليماتك النظامية أو السماح لشخص ما باختراق وكيلك.
يوفر لك هذا المسار عمل طبقة أمان فعلية يمكنك اختبارها في 5 دقائق.
ما الذي يفعله
- يفحص النص عن بيانات شخصية (رسائل بريد إلكترونية وأرقام هاتفية) وحذفها باستخدام عناصر نائبة آمنة
- يكتشف محاولات حقن التعليمات باستخدام تحليل الكلمات الرئيسية ومطابقة الأنماط الهيكلية والتسجيل الاستكشافي — بدون استدعاء LLM وبدون زمن تأخير LLM وبدون تكلفة AI لكل فحص
- يتضمن 10 اختبارات هجوم خصومي حقيقية (واحد من كل فئة) مع عرض نتائج النجاح / الفشل مباشرة في مخرجات سير العمل — لا توجد بيانات اعتماد مطلوبة للتشغيل
- يعود بقرار واضح:
السماح أو المراجعة أو الحظر مع رموز الأسباب
إعداد في أقل من 5 دقائق — استيراد سير العمل والنقر على “تنفيذ سير العمل” ومشاهدة الدرع يمسك بهجوم عينة. ثم استبدل الإدخالات الاختبار الخاصة بك.
مبني للإنتاج وليس للعروض التوضيحية
- الفحوصات حتمية — نفس الإدخال ينتج دائمًا نفس القرار
- لا توجد تبعيات خارجية — يعمل بالكامل داخل عقد رمز n8n
- لا توجد بيانات اعتماد مطلوبة للعرض التوضيحي — فقط استيراد وانقر
- يفشل مغلق بشكل افتراضي — إذا حدث شيء غير متوقع فإنه يحظر بدلاً من السماح
10 فئات هجوم تم اختبارها:
الحقن المباشر والحقن غير المباشر واستخراج موجه النظام وتسرب الأسرار وتسرب البيانات الشخصية وانتحال الأدوار وإخفاء الترميز والتعليمات المخفية والعناوين المريبة وتجاوز نطاق الأعمال
تحتاج إلى المزيد؟ إصدار Pro يضيف:
- التحقق من الناتج (يمسك بـ AI تسرب البيانات أو التعليمات أو اختراع الكيانات)
- أعلام مخاطر الهلوسة (التحقق من الكناري والمراجعة المصدرية والكشف عن التناقضات)
- 66 اختبار هجوم خصومي مع مسار عمل لتشغيل تلقائي وتقرير النجاح / الفشل
- تسجيل رسائل بريد ميتة في جداول بيانات Google (مسار تدقيق يمكنك مشاركته مع العملاء)
- تنبيهات Telegram على المدخلات المحظورة / المريبة
- السياسة القابلة للتكوين: الإجراءات لكل نوع PII وعتبات الحقن وقواعد نطاق الأعمال
- وثيقة ملخص الأمان الموجهة للعميل
- توثيق نموذج التهديد
→ AI Security Shield Pro — n8n Workflow Template
Lite: 10/10 اختبارات مدمجة نجحت. جناح انحدار Pro: 66/66 تم التحقق منها. لا توجد بيانات اعتماد في ملف سير عمل Lite.
تحميل JSON لسير العمل (GitHub Gist) مجاني
إعجاب واحد (1)
حالة review هي الإضافة الأكثر فائدة هنا - من السهل تجاهلها، لكن ربط هذا الفرع بخطوة تتضمن إنسان في الحلقة (عقدة Wait + استئناف webhook، أو مجرد إشعار Slack/Telegram مع أزرار الموافقة/الرفض) يحول هذا من طبقة كشف إلى خط أنابيب تعديل كامل. شيء آخر أود إضافته أيضاً: فحص حد المعدل عند نقطة الدخول - قرارات block المتكررة من نفس معرّف المستخدم في نافذة زمنية قصيرة هي إشارة قوية على الاختبار النشط، تستحق التسجيل بشكل منفصل عن الحجب لمرة واحدة.
شيئان يستحقان الإضافة إلى هذا النمط:
سجل التدقيق إلى Google Sheets. أرسل كل قرار block وreview إلى صف إضافي في Sheets — الطابع الزمني، معرّف المستخدم، القرار، النمط المطابق، الدرجة الخام. لسببين: (1) عمليات التدقيق الامتثالي تريد سجلاً محمياً من التلاعب خارج التطبيق، و(2) بعد أسبوع من حركة المرور الفعلية يمكنك ضبط حدودك ببيانات فعلية بدلاً من التخمين. عقدة Google Sheets تجعل هذه إضافة مدتها دقيقتان.
تجاوز القائمة البيضاء للمتصلين الموثوقين. إذا تم استدعاء سير العمل أيضاً من قبل خدمات داخلية أو تكاملات معروفة، أضف خطوة Check مبكرة قبل ماسح PII/injection: إذا طابق رأس X-Internal-Token قيمة مُجزأة في متغير n8n، تخطَّ إلى المنطق الرئيسي. هذا يمنع أدواتك الخاصة من أن تكون محجوبة ويبقي طبقة الأمان مركزة على المدخلات غير الموثوقة فقط.
مجتمعة، يصبح التدفق الكامل: فحص المتصل الموثوق → تحرير PII → درجة injection → السماح/المراجعة/الحجب → سجل التدقيق. كل خطوة هي سير عمل فرعي منفصل حتى تتمكن من اختبار وتحديث كل منها بشكل مستقل.
شكل رائع. أود أن أجعل سجل التدقيق واضحًا مثل القرار: إصدار السياسة، ورموز السبب، والممثل أو معرّف المستخدم، وتجزئة المدخلات الأولية أو عينة معدّلة، والإجراء التالي الذي تم حظره أو إرساله للمراجعة.
هذا يجعل فرع المراجعة مفيدًا لاحقًا، وليس مجرد بوابة نجاح/فشل.
إعجاب واحد (1)
Exactly — the review branch is meant to be the hook for a human-in-the-loop step, and a Wait node + webhook resume is the cleanest way to do it (Slack/Telegram approve/deny works too). The rate-limit idea is good: repeated block decisions from the same source in a short window is a strong active-probing signal, worth counting separately from one-off blocks — a burst is someone mapping your filters, a single block is usually just a bad input. I keep that aggregation out of the detection layer itself (so the scan stays deterministic and stateless) and put it in a thin counter step after the decision. Thanks for the thoughtful add.
Both of these are the right moves. The Sheets append-row audit log is a great low-friction start — timestamp, decision, matched pattern, and score give you enough to tune thresholds from real traffic instead of guessing. One caution: redact or hash the raw input before it lands in the sheet, otherwise the audit log becomes its own PII store. The trusted-caller bypass is smart too — gating on a hashed X-Internal-Token in an n8n Variable keeps the layer pointed at untrusted input and stops your own tooling from tripping it. And yes, splitting it into sub-workflows (trusted-caller → redact → score → decide → log) is how I’d structure it — each stage stays independently testable. Appreciate the detailed writeup.
Completely agree — a bare allow/block is fine at runtime but useless in a post-incident review. Logging the policy version, reason codes, actor id, a hash (or redacted sample) of the input, and which downstream action was gated turns the review queue into something you can actually triage. The policy-version field especially — once you start tuning thresholds you want to know which ruleset made a given call. That’s the difference between a filter and an auditable control. Good addition.