أمن تطبيقات LLM: دليل بناء GenAI وRAG وAI Agents بطريقة أكثر أمانًا

أمن تطبيقات LLM لا يعني كتابة System Prompt أقوى أو إضافة فلتر يمنع Jailbreak فقط. التطبيق الحقيقي قد يجمع بين النموذج، System Prompt، RAG، قاعدة متجهات، ملفات، ذاكرة، أدوات خارجية، APIs، MCP Servers، حسابات مستخدمين وبيانات حساسة. كل طبقة من هذه الطبقات تضيف Trust Boundary جديدة يمكن أن تتحول إلى Attack Surface.

التصميم الأكثر أمانًا يبدأ من افتراض بسيط: النموذج قد يخطئ، وقد يتأثر بمدخل غير موثوق، لذلك يجب ألا يؤدي خطؤه وحده مباشرة إلى كشف بيانات أو تنفيذ إجراء خطير. هذا يتوافق مع الاتجاه الذي تتبعه أطر مثل OWASP GenAI LLM Top 10 2026 وإرشادات NIST الخاصة بإدارة مخاطر الذكاء الاصطناعي التوليدي.

ما الذي يجب تأمينه في تطبيق LLM؟

من الخطأ التعامل مع Model باعتبارها التطبيق كله. في نظام إنتاجي، يجب تحليل المسار الكامل الذي تتحرك خلاله البيانات والقرارات.

الطبقة	الخطر المحتمل	الضابط الأساسي
User Input	Prompt Injection أو إدخال بيانات غير موثوقة	اعتبار المدخل غير موثوق وعدم منحه سلطة مباشرة
Context وSystem Prompt	تسريب أسرار أو تعليمات داخلية	عدم تخزين Secrets داخل Context
RAG وVector Database	Poisoning أو Cross-Tenant Leakage	Source Provenance وAuthorization أثناء الاسترجاع
Tools وMCP	Tool Misuse أو تنفيذ إجراءات بصلاحيات واسعة	Least Privilege وPolicy Enforcement خارج النموذج
Model Output	SQL أوHTML أوأوامر أوURLs غير آمنة	Validation قبل استخدامها في نظام آخر
Logs وMemory	إنشاء مخزن جديد للبيانات الحساسة	Redaction وسياسات احتفاظ وعزل واضحة

ابدأ بـThreat Modeling ورسم Data Flow

قبل اختيار Guardrail أوأداة فحص، ارسم كيفية تحرك البيانات داخل التطبيق. الهدف ليس رسم مخطط جميل، بل تحديد الأماكن التي تنتقل فيها البيانات من نطاق ثقة إلى نطاق آخر.

يجب أن تستطيع الإجابة عن أسئلة مثل:

من يستطيع إرسال Prompt إلى النظام؟
هل توجد بيانات تأتي من Web pages أوEmail أوPDF أوملفات خارجية؟
ما الذي يدخل فعليًا إلى Context الخاص بالنموذج؟
من يستطيع إضافة مستند إلى Knowledge Base؟
أي مستخدم يستطيع استرجاع أي مستند؟
ما Tools التي يستطيع Agent استدعاءها؟
بأي Identity تعمل كل Tool؟
هل يستطيع النظام إجراء اتصالات Outbound إلى الإنترنت؟
ما البيانات التي يمكن أن تظهر في Logs أوMemory؟
ما الإجراء الذي يمكن أن يحدث دون موافقة بشرية؟

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

صنّف البيانات قبل أن تدخل Context

Context Window ليست مكانًا آمنًا تلقائيًا لمجرد أنها جزء من تطبيق AI. كل معلومة ترسل إلى النموذج يجب أن تكون هناك لسبب واضح.

ضع سياسة لما يمكن إدخاله من:

PII والبيانات الشخصية.
بيانات العملاء.
المعلومات المالية.
الكود المصدري الخاص.
الوثائق القانونية أوالتجارية السرية.
Credentials وTokens ومفاتيح API.

Data Minimization مهمة هنا لسبب أمني مباشر: البيانات التي لم تدخل إلى Context أصلًا لا يمكن للنموذج تسريبها من ذلك السياق.

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

لا تستخدم System Prompt كمخزن أسرار

System Prompt تحدد سلوك التطبيق، لكنها ليست Secrets Vault ولا ينبغي اعتبار محتواها حاجزًا أمنيًا سريًا.

توضح OWASP في إرشادات System Prompt Leakage أن كلمات المرور ومفاتيح الاتصال وCredentials وغيرها من المعلومات الحساسة لا ينبغي وضعها داخل System Prompt، كما لا ينبغي الاعتماد على التعليمات النصية نفسها لتطبيق Authorization.

احتفظ بمفاتيح API وDatabase Credentials وService Tokens في Secret Management Layer خارج Context، واسمح للأداة بالحصول فقط على Credential المطلوبة لتنفيذ الوظيفة المحددة.

Prompt Injection: تعامل مع المحتوى الخارجي كبيانات غير موثوقة

تعرف NIST Prompt Injection بأنها هجوم يستغل دمج مدخل غير موثوق مع Prompt صادر عن جهة أعلى ثقة. وفي حالة Indirect Prompt Injection قد تصل التعليمات الخبيثة عبر مورد خارجي بدل أن يكتبها المستخدم مباشرة، مثل صفحة ويب أوEmail أومستند.

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

كما تؤكد OpenAI في شرحها الحالي لـPrompt Injection أن المشكلة أصبحت أكثر أهمية مع الأنظمة التي تتعامل مع بيانات من الويب والتطبيقات الأخرى وتنفذ إجراءات نيابة عن المستخدم. ولا تزال مقاومة Prompt Injection مشكلة أمنية متطورة وليست مشكلة حُلّت نهائيًا بفلتر واحد.

ولأن CyberOPlus لديه صفحة متخصصة في الهجوم نفسه، يمكن الرجوع إلى شرح Prompt Injection وAgent Hijacking في AI Agents للتفاصيل الخاصة بالـDirect وIndirect Injection وقنوات Data Exfiltration. أما هنا فالمهم معماريًا هو أن نجاح Injection يجب ألا يمنح المهاجم تلقائيًا صلاحية تنفيذ Action خطير.

RAG لا تجعل البيانات المسترجعة موثوقة

Retrieval-Augmented Generation تحسن قدرة النموذج على استخدام مصادر خارجية، لكنها لا تعني أن المحتوى الموجود في Knowledge Base أصبح آمنًا.

هناك مساران مختلفان يجب تأمينهما:

1. Ingestion

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

سجل Source Provenance.
حدد من يملك صلاحية Ingest.
احتفظ بـVersion History عند الحاجة.
ادعم حذف المستندات وإعادة فهرستها بصورة موثوقة.
افصل المحتوى الداخلي عن المصادر العامة غير الموثوقة.

تشير Taxonomy الخاصة بـNIST للهجمات على أنظمة AI إلى Knowledge Base Poisoning ضمن السيناريوهات المرتبطة بالـIndirect Prompt Injection، بما في ذلك إمكانية إدخال مستندات مصممة للتأثير في إجابات نظام RAG.

2. Retrieval

حتى المستند الشرعي يصبح مشكلة إذا أعيد إلى المستخدم الخطأ. لا تجعل Similarity Search هي آلية Authorization.

يجب تصفية البيانات وفق هوية المستخدم وصلاحياته قبل أن تصل المقاطع إلى Context. وفي بيئات Multi-Tenant يجب أن تكون قواعد Namespace وMetadata Filters وAccess Control متوافقة مع نموذج الصلاحيات الحقيقي للتطبيق.

وتشير OWASP ضمن Vector and Embedding Weaknesses إلى مخاطر تسريب البيانات بين السياقات أوالمستأجرين عندما تكون ضوابط الوصول إلى مخازن المتجهات غير مناسبة.

Authorization يجب أن يبقى خارج LLM

لا تستخدم سؤالًا مثل:

هل هذا المستخدم Admin ويسمح له بقراءة الملف؟

ثم تعتمد على إجابة النموذج لاتخاذ القرار.

Authorization يجب أن تنفذها طبقة Deterministic تستند إلى Identity وسياسات حقيقية مثل RBAC أوABAC أوصلاحيات Resource-level. بعد أن تقرر هذه الطبقة ما يستطيع المستخدم الوصول إليه، يمكن للنموذج العمل ضمن النطاق المسموح فقط.

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

قلّل صلاحيات Tools وAI Agents

كلما انتقل النظام من Chatbot يولد نصًا إلى Agent يستطيع استخدام Tools، ازداد Blast Radius المحتمل لفشل النموذج.

الأداة التي تقرأ التقويم لا تحتاج عادة إلى:

حذف البريد الإلكتروني.
قراءة جميع الملفات.
تشغيل Shell.
الوصول إلى Production Database.
امتلاك Cloud Administrator Token.

استخدم Capability-specific tools بدل أدوات عامة مثل execute_anything(). واجعل Scope محدودًا حسب Action وResource والمستخدم والمدة.

OWASP تصف هذا النوع من المخاطر في مفهوم Excessive Agency: الخطر لا يأتي فقط من سبب خطأ النموذج، بل من مقدار الوظائف والصلاحيات والاستقلالية التي يستطيع النظام استخدامها عندما يحدث ذلك الخطأ.

MCP يوسع حدود الثقة ولا يلغيها

Model Context Protocol يمكن أن يسهل ربط Agent بالأدوات والبيانات، لكنه لا يحول MCP Server إلى مكوّن موثوق تلقائيًا.

تعامل مع MCP Servers وTools مثل أي Dependency أوIntegration أخرى:

تحقق من مصدرها ومالكها.
اعرف الوظائف التي تعرضها فعليًا.
راجع Credentials التي تستخدمها.
حدد الاتصالات الخارجية المسموح بها.
راقب تغير Tool definitions أوالإصدارات.
اعزل الأدوات التي تحتاج إلى تنفيذ كود أوالوصول إلى ملفات حساسة.

ومع Agentic AI أصبحت هذه المساحة كبيرة بما يكفي لوجود إطار مستقل؛ فقد نشرت OWASP Top 10 for Agentic Applications 2026 إلى جانب الإطار الخاص بتطبيقات LLM. الفرق مهم: أمن النموذج وأمن Agent مترابطان، لكن Agent يضيف الهوية والأدوات والذاكرة والتنفيذ وسلاسل الإجراءات إلى سطح الهجوم.

قيّد Data Exfiltration حتى إذا فشل النموذج

من أقوى المبادئ الدفاعية ألا تركز فقط على منع Injection، بل أيضًا على منع إخراج البيانات إذا نجحت Injection.

راجع قنوات Egress التي يستطيع Agent استخدامها، مثل:

Outbound HTTP requests.
Email.
Webhooks.
File uploads.
URLs التي ينشئها النموذج.
Markdown أوHTML الذي يسبب تحميل موارد خارجية.

استخدم Allowlisting عند الإمكان، وحدد الوجهات والبروتوكولات والبيانات المسموح بإرسالها. تطبيق DLP أوسياسات على Egress يمكن أن يقلل الأثر حتى عندما تتجاوز تعليمات خبيثة دفاعات النموذج.

Human Approval يجب أن يعرض الإجراء الحقيقي

الموافقة البشرية مفيدة عندما يستطيع الإنسان فهم ما سيحدث. زر عام يحمل عبارة «تأكيد» لا يوفر حماية كبيرة إذا كانت التفاصيل مخفية.

إذا كان Agent على وشك إرسال ملف، اعرض للمستخدم بوضوح:

اسم الملف.
الجهة المستلمة.
الإجراء الذي سيحدث.
البيانات التي ستغادر النظام.

وتوصي OpenAI عند التعامل مع Agents بمراجعة الإجراءات المهمة بعناية وتقليل نطاق ما يُطلب من Agent بدل إعطائه تعليمات واسعة وسلطة مفتوحة. كما تركز إرشاداتها لعام 2026 حول تصميم Agents المقاومة لـPrompt Injection على تقليل أثر التلاعب حتى إذا لم يمكن منع كل محاولة.

عامل Model Output كمدخل غير موثوق

نجاح النموذج في توليد نص مقنع لا يعني أن النص آمن لتنفيذه.

إذا كان Output سيستخدم كـ:

SQL.
HTML.
Shell command.
URL.
API parameters.
File path.
Configuration.

فيجب التحقق منه وفق قواعد النظام الذي سيستهلكه.

استخدم Schemas وAllowlists وParsers وParameterized Queries والقيود الخاصة بكل Tool بدل تمرير نص LLM مباشرة إلى Interpreter أومحرك قاعدة بيانات أوShell.

الفكرة الأساسية هي الفصل بين اقتراح النموذج وقرار النظام بالتنفيذ.

احمِ AI Supply Chain

تطبيق GenAI قد يعتمد على أكثر بكثير من Model API واحدة. راجع سلسلة المكونات التي تدخل في النظام، بما في ذلك:

Foundation Models وModel providers.
Open-weight models.
Fine-tuning adapters.
Embedding models.
Python وnpm packages.
Container images.
Model repositories.
MCP Servers.
Plugins وAgent frameworks.

طبّق نفس مبادئ Software Supply Chain Security المعروفة: تثبيت الإصدارات الحرجة، مراجعة المصدر، تقليل Secrets، فحص التحديثات، مراقبة Dependencies وإدارة Provenance.

وللتفاصيل الخاصة بهذه الطبقة دون تكرارها هنا، يشرح CyberOPlus في دليل هجمات سلسلة توريد البرمجيات كيف تنتقل الثقة المخترقة من Dependency أوCI/CD component إلى الأنظمة النهائية.

اعزل المستخدمين والعملاء في Multi-Tenant Systems

وجود عدة عملاء داخل التطبيق يضيف مخاطر تتجاوز مجرد فصل Conversation IDs.

اختبر أن:

استعلامات RAG لا تسترجع مستندات Tenant آخر.
Vector namespaces مرتبطة بالهوية الصحيحة.
Caches لا تختلط بين المستخدمين.
Conversation history معزولة.
Memory معزولة حسب المستخدم أوWorkspace.
Tool credentials لا تستخدم هوية عامة عالية الصلاحيات لجميع العملاء.

ولا تعتمد على Prompt تقول للنموذج «لا تعرض بيانات العملاء الآخرين». العزل يجب أن يحدث في Storage وRetrieval وIdentity Layers نفسها.

Memory تحتاج إلى Trust Model

Long-term Memory قد تحول مدخلًا لحظيًا إلى حالة دائمة. إذا استطاع محتوى غير موثوق كتابة معلومات أوتعليمات في Memory، فقد يستمر أثرها في جلسات لاحقة.

حدد بوضوح:

من يستطيع كتابة Memory؟
ما أنواع المعلومات المسموح بحفظها؟
هل تحفظ التعليمات القادمة من مصادر خارجية؟
كم تستمر البيانات؟
هل يستطيع المستخدم مراجعتها وحذفها؟
كيف تُلغى Memory أثناء Incident Response؟

Logs ضرورية، لكن لا تحولها إلى قاعدة أسرار

تحتاج إلى Telemetry لفهم ما حدث عند حدوث مشكلة، لكن تسجيل كل Prompt وContext وTool output بصورة كاملة قد ينشئ مخزنًا جديدًا للـPII والوثائق الداخلية وTokens.

ضع سياسة Logging تجيب عن:

ما الذي يجب تسجيله للتحقيق؟
ما الذي يجب Redact قبل التخزين؟
من يستطيع قراءة Logs؟
كم تستمر مدة الاحتفاظ؟
هل يتم تسجيل Tool calls والقرارات الحساسة؟
كيف ترتبط الأحداث بالمستخدم والطلب دون كشف بيانات أكثر من اللازم؟

Rate Limiting ليس لتقليل التكلفة فقط

الحدود على الاستخدام يمكن أن تساعد في تقليل Automated Abuse وMass Probing ومحاولات Extraction واستهلاك الموارد غير المحدود.

لا تعتمد على حد عالمي واحد فقط. يمكن أن تكون القيود مختلفة حسب المستخدم أوAPI key أوTool أونوع العملية أوتكلفتها.

راقب أيضًا الأنماط غير المعتادة مثل:

ارتفاع مفاجئ في عدد الطلبات.
استدعاءات متكررة لأداة حساسة.
محاولات متسلسلة لاستخراج بيانات.
Token consumption غير معتاد.
تغير مفاجئ في وجهات الشبكة التي يتصل بها Agent.

اختبر التطبيق End-to-End وليس النموذج وحده

اختبار Model في واجهة Chat لا يكشف بالضرورة المخاطر الموجودة في التطبيق الحقيقي. Red Teaming يجب أن يشمل المسارات التي تربط النموذج بالبيانات والصلاحيات والتنفيذ.

اختبر سيناريوهات مثل:

Direct Prompt Injection.
Indirect Injection عبر Web أوEmail أوDocuments.
RAG poisoning.
Cross-user وCross-tenant access.
Tool misuse.
Output غير آمن يصل إلى نظام آخر.
Memory poisoning أوPersistence.
Data exfiltration attempts.
صلاحيات Agent الزائدة.
Resource exhaustion.
Dependency أوMCP Server غير موثوق.

يوفر MITRE ATLAS قاعدة معرفة متطورة لتكتيكات وتقنيات الهجمات على أنظمة AI، وتشمل حاليًا تقنيات مرتبطة بـLLM Prompt Injection وAI Agent Tool Invocation وContext Poisoning وTool Poisoning وسلسلة توريد AI، ما يجعلها مفيدة عند بناء سيناريوهات اختبار واقعية.

لا تعتبر Prompt Filter طبقة الحماية الوحيدة

يمكن أن تكون Guardrails وClassifiers وPrompt Injection detectors طبقات مفيدة، لكنها لا ينبغي أن تكون Security Boundary الوحيدة.

حتى مورّدو النماذج الذين يستثمرون بكثافة في الدفاعات يتعاملون مع Prompt Injection باعتبارها تحديًا مستمرًا. على سبيل المثال، تشرح Anthropic أبحاثها حول الدفاع ضد Prompt Injection أثناء تصفح الويب مع التأكيد على أن المشكلة لم تُحل بالكامل، خصوصًا عندما يمتلك Agent القدرة على تنفيذ إجراءات حقيقية.

لذلك يجب الجمع بين دفاعات Model-level وضوابط Architecture تقليدية مثل:

Least Privilege.
Isolation.
Authorization.
Egress Controls.
Output Validation.
Secret Management.
Audit Logging.
Human Approval للإجراءات الحساسة.

جهّز Incident Response خاصًا بالـAI

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

يجب أن تستطيع عند الحاجة:

تعطيل Tool أوMCP Server بسرعة.
إلغاء Credential مستخدمة بواسطة Agent.
إيقاف Outbound connectivity.
إزالة Document مسمومة وإعادة بناء الفهرس.
مسح أوإبطال Memory المتأثرة.
تحديد المستخدمين أوTenants المتأثرين.
مراجعة Actions التي نفذها Agent سابقًا.
تدوير Secrets إذا وصلت إلى Context غير آمن.

القدرة على احتواء الحادث جزء من التصميم الأمني نفسه، وليست مهمة تأتي بعد النشر.

ما الإطار الأمني الذي يجب استخدامه في 2026؟

حتى 28 أغسطس 2026، من المهم عدم الاعتماد على نسخة قديمة واحدة من قوائم مخاطر LLM. أصدرت OWASP في 3 أغسطس 2026 OWASP GenAI LLM Top 10 2026 بوصفها أحدث نسخة من إطار المخاطر الخاص بتطبيقات النماذج اللغوية، بينما يوجد OWASP Top 10 for Agentic Applications 2026 لمعالجة المخاطر التي تظهر عندما تصبح الأنظمة قادرة على التخطيط واستخدام Tools وتنفيذ إجراءات.

ولبناء Threat Model أوسع، توفر NIST AI 100-2e2025 Taxonomy للهجمات وتقنيات التخفيف في Adversarial Machine Learning، بما في ذلك Prompt Injection وIndirect Prompt Injection وPoisoning ومخاطر الخصوصية. أما NIST Generative AI Profile فيضع هذه القضايا داخل إطار أوسع لإدارة المخاطر عبر دورة حياة النظام.

هذه الأطر لا تستبدل Threat Modeling الخاص بتطبيقك. فائدتها الأساسية هي مساعدتك على اكتشاف فئات مخاطر قد تنساها، ثم تحويلها إلى Controls تناسب Architecture الفعلية لديك.

قائمة فحص قبل نشر تطبيق LLM

ارسم Data Flow وحدد Trust Boundaries.
صنّف البيانات التي يمكن أن تدخل Context.
أخرج Credentials وSecrets من Prompts.
طبق Authorization قبل Retrieval وقبل Tool execution.
عامل Web وEmail والملفات وRAG content كمصادر غير موثوقة.
استخدم Least Privilege لكل Tool وAgent.
قيّد Egress والوجهات الخارجية.
تحقق من Model Output قبل تمريره إلى نظام آخر.
اعزل Tenants وMemory وCaches وVector data.
راجع Models وPackages وMCP Servers كجزء من Supply Chain.
سجل الأحداث المهمة دون الاحتفاظ بأسرار غير ضرورية.
طبق Rate Limits ومراقبة للاستخدام غير الطبيعي.
اختبر Prompt Injection وRAG وTools وAuthorization معًا.
جهّز آليات تعطيل Tools وسحب Credentials والاستجابة للحوادث.

الخلاصة

تطبيق LLM الآمن لا يعتمد على أن النموذج سيتصرف بصورة صحيحة في كل مرة. التصميم الأفضل يفترض إمكانية وجود Prompt خبيث أوDocument مسمومة أوOutput خاطئ أوTool غير موثوقة، ثم يمنع هذا الفشل من عبور حدود الصلاحيات والتحول مباشرة إلى Data Breach أوتنفيذ أوامر أووصول غير مصرح به.

لهذا فإن LLM Security في 2026 هي في الأساس Security Engineering حول النموذج: Identity وAuthorization وData Minimization وIsolation وLeast Privilege وOutput Validation وEgress Controls وSupply Chain Security وMonitoring وIncident Response. Prompt Engineering قد يساعد، لكنه لا يستطيع وحده أن يحل محل هذه الضوابط.