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

ما هي الثلاثية القاتلة Lethal Trifecta؟

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

يتناول PCI Security Standards Council ثلاثة عناصر رئيسية:

1. الوصول إلى بيانات حساسة.
2. التعرض لمحتوى أو مدخلات غير موثوقة.
3. القدرة على الاتصال أو التواصل مع أنظمة خارجية.

المشكلة ليست في وجود أي عنصر منفرد، بل في إمكانية استخدام أحد العناصر للتأثير في الآخر.

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

العنصر الأول: الوصول إلى البيانات الحساسة

قد يحتاج نظام الذكاء الاصطناعي إلى الوصول إلى بيانات داخلية لتنفيذ مهمته.

يمكن أن تشمل هذه البيانات:

• معلومات العملاء.
• بيانات مالية.
• ملفات داخلية.
• معلومات تجارية سرية.
• بيانات شخصية.
• إعدادات الأنظمة.
• سجلات تشغيلية.
• بيانات اعتماد أو معلومات أمنية.

وجود الوصول بحد ذاته لا يعني أن التصميم غير آمن.

السؤال الحقيقي هو مقدار البيانات التي يستطيع النظام الوصول إليها فعليًا، وليس فقط ما يُفترض أن يستخدمه.

قراءة سيادة: Effective Access

يجب قياس الوصول استنادًا إلى الحدود التقنية الحقيقية:

• IAM.
• API scopes.
• Network connectivity.
• Database permissions.
• Filesystem permissions.
• Tool permissions.
• MCP servers.
• Credentials المتاحة للنظام.

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

العنصر الثاني: المحتوى غير الموثوق

تستقبل الأنظمة الحديثة محتوى من مصادر متعددة مثل:

• المستخدمين.
• البريد الإلكتروني.
• الملفات.
• مواقع الويب.
• نتائج البحث.
• Tickets.
• مستندات الموردين.
• APIs.
• أنظمة RAG.
• Agents أخرى.

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

وهنا يظهر خطر Prompt Injection.

قد لا تكون التعليمات الخبيثة واردة مباشرة من المستخدم؛ يمكن أن تكون مخفية داخل مستند أو صفحة ويب أو رسالة أو نتيجة مسترجعة من قاعدة معرفة.

العنصر الثالث: الاتصال الخارجي

قد يحتاج Agent إلى الاتصال بالخارج لتنفيذ مهمته.

يمكن أن تشمل القنوات:

• الإنترنت.
• البريد الإلكتروني.
• Messaging.
• APIs خارجية.
• Cloud services.
• Webhooks.
• رفع الملفات.
• أدوات SaaS.
• MCP servers متصلة بخدمات خارجية.

وجود هذه القنوات لا يعني بالضرورة أنها خطرة.

لكنها تصبح أكثر حساسية عندما يجتمع معها وصول إلى بيانات داخلية ومدخلات غير موثوقة.

كيف تتفاعل العناصر الثلاثة؟

يمكن تصور السيناريو التالي:

Sensitive corporate data + External document containing malicious instructions + AI Agent with external API / email access ↓ Potential data exfiltration or unauthorized action

قد يقرأ الوكيل مستندًا خارجيًا يحتوي تعليمات مخفية.

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

هذه هي قيمة مفهوم Lethal Trifecta: فهو يجبر المصمم على النظر إلى تركيب القدرات وليس إلى كل قدرة منفردة.

لماذا Prompt Injection أخطر في الأنظمة الوكيلة؟

في نظام محادثة بسيط، قد يؤدي Prompt Injection إلى إجابة غير مرغوبة.

أما في Agent يمتلك أدوات وصلاحيات، فقد تؤثر التعليمات الخبيثة في:

• استدعاء أداة.
• قراءة ملف.
• إجراء Query.
• إرسال رسالة.
• تنفيذ API call.
• تعديل نظام.
• استخدام Credential.
• تنفيذ Workflow.

ولهذا يصبح السؤال الأمني:

ما الذي يمكن للمحتوى غير الموثوق أن يدفع النظام إلى فعله باستخدام الصلاحيات الحقيقية المتاحة له؟

الثلاثية القاتلة ليست Risk Score

هذا المفهوم لا يحل محل Threat Modeling أو Risk Analysis الكامل.

وجود عنصر واحد أو عنصرين لا يعني أن النظام آمن.

كما أن اجتماع العناصر الثلاثة لا ينتج رقمًا رسميًا للمخاطر.

المفهوم هو أداة سريعة لاكتشاف تركيب معماري يستحق اهتمامًا خاصًا.

قراءة سيادة: فحص 0/3 إلى 3/3

يمكن للمؤسسات استخدام فحص تطبيقي بسيط أثناء Architecture Review.

0/3

لا يوجد أي من العناصر الثلاثة.

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

1/3

يوجد عنصر واحد.

يجب التأكد من أن الضوابط متناسبة مع البيانات أو الصلاحيات أو الاتصال الموجود.

2/3

يوجد عنصران.

هنا تصبح الحاجة أكبر إلى مراجعة الحدود، والعزل، ونطاق الصلاحيات، ومسارات البيانات.

3/3

تجتمع البيانات الحساسة والمحتوى غير الموثوق والاتصال الخارجي.

قراءة سيادة:

يجب اعتبار هذه الحالة Architecture Red Flag، ويكون إعادة التصميم هي نقطة البداية المفضلة قبل التفكير في قبول المخاطر.

هذا التصنيف إضافة تطبيقية من سيادة، وليس تصنيفًا أو متطلبًا رسميًا صادرًا عن PCI SSC.

كيف تكسر الثلاثية القاتلة؟

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

الهدف هو منع اجتماع العناصر الثلاثة داخل نفس Boundary.

يمكن كسر المسار بعدة طرق.

إزالة الوصول إلى البيانات الحساسة

استخدم:

• Data minimization.
• Tokenization.
• Redaction.
• Aggregation.
• Scoped retrieval.
• Read-only datasets.

تقليل التعرض للمحتوى غير الموثوق

افصل المحتوى الخارجي عن مسارات القرار والتنفيذ.

يمكن استخدام:

• Content sanitization.
• Controlled ingestion.
• Source allowlisting.
• Trusted retrieval boundaries.
• Input classification.

إزالة الاتصال الخارجي

قد يعمل Agent الذي يعالج معلومات حساسة داخل بيئة لا تملك Internet egress أو اتصالًا مباشرًا بالخدمات الخارجية.

يمكن أن تمر الإجراءات المطلوبة عبر نظام وسيط مستقل يطبق سياسة محددة.

Least Agency كضابط أساسي

مبدأ Least Agency يعني منح Agent أقل قدر من البيانات والأنظمة والصلاحيات والاستقلالية اللازمة للمهمة.

بدل منح الوكيل وصولًا واسعًا إلى قواعد البيانات والإنترنت والأدوات، يفضل تقييده بأقل Dataset وأضيق API وأصغر مجموعة إجراءات لازمة.

كل Permission غير لازمة تزيد مساحة الضرر المحتمل.

فصل الوكلاء

يمكن في بعض الحالات توزيع الوظائف على عدة Agents بدل منح Agent واحد جميع القدرات.

مثال:

External Content Agent ↓ sanitized output Internal Analysis Agent ↓ approved recommendation Execution Service

الفكرة ليست زيادة عدد الوكلاء بحد ذاتها، بل فصل حدود السلطة والبيانات والتنفيذ.

لكن الفصل وحده ليس ضمانة أمنية.

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

قراءة سيادة: Agentic Segregation of Duties

في الأنظمة الوكيلة يمكن تطبيق فصل للواجبات بين:

• القراءة.
• التحليل.
• التوصية.
• الموافقة.
• التنفيذ.
• التحقق.

الهدف أن لا يمتلك مكوّن واحد جميع القدرات اللازمة للانتقال من مدخل غير موثوق إلى إجراء عالي الأثر.

مثال:

بدل أن يستطيع Agent واحد قراءة مستند خارجي، والوصول إلى بيانات العملاء، ثم إرسال البيانات إلى الخارج، يمكن تقسيم المسار إلى:

1. مكوّن يستقبل المحتوى الخارجي دون وصول إلى البيانات الحساسة.
2. مكوّن داخلي يحلل ناتجًا مضبوطًا أو منقحًا.
3. خدمة تنفيذ مستقلة تطبق سياسة محددة.
4. موافقة بشرية أو آلية إضافية للأفعال عالية الأثر.

الهوية المستقلة للوكيل

من الأسئلة المهمة:

من نفذ الإجراء؟

إذا استخدمت عدة Agents نفس Credential الواسعة والمشتركة، تصبح عملية التتبع والعزل والإلغاء أكثر صعوبة.

لذلك ينبغي، عندما تسمح البنية بذلك، استخدام هوية مستقلة وقابلة للتدقيق للوكيل أو الخدمة التي تنفذ الأفعال.

قراءة سيادة: Agent Identity

هوية الوكيل يجب أن ترتبط على الأقل بـ:

• Agent أو workload محدد.
• Scope واضح.
• Credentials قابلة للإلغاء.
• سجل تدقيق مستقل.
• صلاحيات مرتبطة بالمهمة.
• دورة حياة معروفة.

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

مراقبة الأفعال لا النص فقط

التركيز على Prompt وResponse وحدهما غير كافٍ في الأنظمة الوكيلة.

قد يكون النص الظاهر للمستخدم طبيعيًا، بينما يحدث الفعل المهم عبر أداة أو API في الخلفية.

لذلك يجب أن تشمل المراقبة:

• Tool Calls.
• API Calls.
• Network requests.
• File access.
• Database queries.
• Credentials used.
• MCP tool invocation.
• Target systems.
• Human approvals.
• Resulting actions.
• Failed authorization attempts.

السؤال الأمني ليس فقط:

ماذا قال النموذج؟

بل أيضًا:

ماذا فعل النظام فعليًا؟

MCP والثلاثية القاتلة

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

قد يمنح MCP وصولًا إلى:

• الملفات.
• البريد الإلكتروني.
• قواعد البيانات.
• Git repositories.
• SaaS platforms.
• أنظمة داخلية.
• APIs.
• أدوات تشغيلية.

لذلك يجب إدخال MCP ضمن فحص Lethal Trifecta.

السؤال ليس:

هل يستخدم النظام MCP؟

بل:

ما البيانات والأدوات وقنوات الاتصال التي أصبحت متاحة للنظام من خلال MCP؟

قراءة سيادة: MCP Governance

عند مراجعة MCP Server يجب التحقق من:

• الجهة المالكة.
• مصدره البرمجي.
• الأدوات التي يعرضها.
• Credentials التي يستخدمها.
• الأنظمة التي يستطيع الوصول إليها.
• نوع البيانات التي يمكنه قراءتها.
• الأفعال التي يمكنه تنفيذها.
• Network Egress.
• Logging.
• Revocation.
• Change management.

إضافة MCP Server جديد قد تغيّر Effective Access للنظام حتى لو لم يتغير النموذج نفسه.

Kill Switch

إذا كان Agent يملك قدرة تنفيذية، فيجب أن تستطيع المؤسسة إيقاف تلك القدرة فعليًا.

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

يجب أن توجد ضوابط مستقلة يمكنها، حسب الحالة:

• إلغاء Credential.
• قطع Network Access.
• تعطيل Workflow.
• إيقاف Tool access.
• منع Write operations.
• تعطيل Integration.
• عزل Agent.
• حفظ السجلات للتحقيق.

قراءة سيادة

Kill Switch الحقيقي يجب أن يكون خارج سيطرة Agent الذي يراد إيقافه.

إذا كان الوكيل يستطيع تجاوز آلية الإيقاف أو إعادة تفعيل نفسه باستخدام الصلاحيات نفسها، فلا تكون الآلية مستقلة فعليًا.

Human Oversight

الإشراف البشري مهم، لكنه لا يعوض تصميمًا معماريًا ضعيفًا.

وجود Human-in-the-Loop لا يعني تلقائيًا وجود ضبط فعلي.

إذا كان الموظف يوافق بصورة شبه تلقائية على مئات الإجراءات التي ينتجها النظام، فقد تتحول الموافقة البشرية إلى إجراء شكلي.

يجب أن ترتبط نقاط الموافقة بالأفعال التي تستحق تدخلًا فعليًا، مثل:

• إرسال بيانات حساسة.
• تنفيذ دفعة مالية.
• تعديل صلاحيات.
• حذف بيانات.
• تغيير إعداد أمني.
• تنفيذ إجراء غير قابل للتراجع بسهولة.

مثال: مساعد بريد مؤسسي

افترض وجود Agent يستطيع:

• قراءة البريد الإلكتروني.
• الوصول إلى CRM.
• إعداد الردود.
• إرسال البريد تلقائيًا.

يصل إلى النظام بريد خارجي يحتوي تعليمات خبيثة مخفية داخل النص أو المرفق.

إذا استطاع Agent قراءة بيانات العملاء من CRM ثم استخدام البريد لإرسال معلومات إلى جهة خارجية، فإن العناصر الثلاثة قد تكون موجودة:

Sensitive data ✓

Untrusted input ✓

External communication ✓

المشكلة هنا لا تحل بصورة موثوقة بإضافة Guardrail نصي فقط.

يمكن إعادة التصميم من خلال:

• منع الإرسال التلقائي في الحالات الحساسة.
• تقييد حقول CRM المتاحة للوكيل.
• فصل تحليل البريد عن خدمة الإرسال.
• تطبيق DLP مستقل.
• طلب Approval عند تضمين بيانات حساسة.
• تقييد الجهات التي يمكن الإرسال إليها.
• مراقبة Tool Calls الخاصة بالبريد.

مثال: Agent داخلي لتحليل الثغرات

افترض Agent يقرأ معلومات داخلية حساسة عن البنية التقنية للمؤسسة.

لكن النظام:

• لا يستقبل محتوى خارجيًا مباشرًا.
• لا يملك اتصالًا بالإنترنت.
• لا يستطيع إرسال البيانات إلى خدمة خارجية.
• يعمل داخل بيئة معزولة.
• يكتب نتائجه في مخزن داخلي محدود.

في هذه الحالة تم كسر بعض عناصر الثلاثية معماريًا.

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

أسئلة يجب طرحها في Architecture Review

عند مراجعة Agent أو نظام AI، اطرح على الأقل الأسئلة التالية:

1. ما البيانات الحساسة التي يستطيع النظام الوصول إليها فعليًا؟
2. هل هذا الوصول أوسع من الحاجة التشغيلية؟
3. ما المصادر التي تستطيع إدخال محتوى غير موثوق إلى Context؟
4. هل تشمل هذه المصادر البريد والملفات والويب وRAG وAPIs؟
5. ما القنوات الخارجية التي يستطيع النظام استخدامها؟
6. هل يستطيع المحتوى الخارجي التأثير في Tool Calls؟
7. هل يستطيع Agent الوصول إلى Secrets أو Credentials؟
8. هل يستطيع قراءة البيانات واستخدام أداة لفك حمايتها ضمن المسار نفسه؟
9. هل يملك Shell أو Database access؟
10. هل يمكنه رفع ملفات أو إرسال بريد أو استدعاء Webhooks؟
11. هل يستطيع استدعاء Agents أخرى؟
12. هل تستطيع المؤسسة إلغاء هويته فورًا؟
13. ما الأفعال غير القابلة للتراجع؟
14. أين توجد نقاط الموافقة؟
15. هل مراقبة الأدوات مستقلة عن النموذج؟
16. هل يمكن تقسيم الوظيفة إلى Boundaries أكثر أمانًا؟
17. هل أضاف MCP أو Integration جديد Effective Access لم يكن موجودًا سابقًا؟

Baseline عملي عند ظهور 3/3

عندما تجتمع العناصر الثلاثة، يجب أن تؤدي المراجعة المعمارية إلى فحص جدي على الأقل للضوابط التالية:

• Least Agency.
• Data minimization.
• Scoped retrieval.
• Network egress restrictions.
• Tool permissions.
• MCP exposure.
• Agent Identity.
• Machine credentials.
• DLP.
• Segmentation.
• Logging.
• Human approval boundaries.
• Reversibility.
• Kill Switch.
• Prompt Injection testing.
• Incident-response triggers.

قراءة سيادة

وجود 3/3 لا يعني أن PCI SSC أصدر حكمًا آليًا بضرورة رفض النظام.

لكن في نموذج سيادة التطبيقي، ظهور العناصر الثلاثة داخل Boundary واحدة يجب أن يعامل كـArchitecture Red Flag.

نقطة البداية المفضلة هنا هي:

إعادة تصميم المعمارية أو كسر أحد عناصر المسار قبل الانتقال إلى قبول المخاطر.

ما الذي لا يقوله المفهوم؟

Lethal Trifecta لا يعني أن:

• كل نظام يملك العناصر الثلاثة سيتعرض للاختراق حتمًا.
• كل نظام يملك عنصرين فقط آمن.
• إزالة عنصر واحد تلغي جميع مخاطر AI.
• Prompt Injection هو التهديد الوحيد.
• الفحص يغني عن Threat Modeling.
• الفحص يغني عن Risk Assessment.
• النتيجة 3/3 هي Risk Score رسمي.
• النتيجة 0/3 تعني أن النظام آمن.
• كل External Connectivity خطر بطبيعته.

المفهوم هو عدسة معمارية تساعد على اكتشاف تركيب قدرات شديد الحساسية.

العلاقة مع Least Agency

Lethal Trifecta يوضح لماذا يصبح Least Agency مهمًا بصورة خاصة في Agentic AI.

كلما اتسع:

• نطاق البيانات.
• عدد الأدوات.
• عدد الأنظمة.
• صلاحيات الكتابة.
• الاتصال الخارجي.
• الاستقلالية.

زادت احتمالية أن يستطيع اختراق واحد أو Prompt Injection الوصول إلى أثر أكبر.

Least Agency لا يزيل جميع المخاطر، لكنه يقلل مساحة السلطة التي يمكن إساءة استخدامها.

العلاقة مع Prompt Injection

Prompt Injection يصبح أكثر خطورة عندما يمتلك النظام قدرة تنفيذية.

التعليمات الخبيثة وحدها ليست الهدف النهائي دائمًا.

الأثر يعتمد على ما يستطيع النظام فعله بعد تأثره.

لذلك يمكن صياغة الاختبار بهذه الصورة:

Prompt Injection + Excessive Access + Action Capability = Higher-impact failure path

العلاقة مع Reversibility

ليس كل إجراء ينفذه Agent متساويًا.

هناك فرق بين:

• اقتراح نص.
• إنشاء Draft.
• إرسال رسالة.
• تعديل سجل.
• حذف سجل.
• تحويل أموال.
• تغيير Credential.
• نشر محتوى علني.
• تشغيل أمر على Production.

كلما انخفضت قابلية التراجع، ارتفعت أهمية منع اجتماع القدرات الخطرة داخل النظام نفسه.

العلاقة مع حدود السلطة

قراءة سيادة: Authority Boundary

السؤال الأهم ليس فقط ما الذي يستطيع النموذج فهمه، بل ما السلطة التي يملكها النظام ككل.

يجب تحديد:

• ما الذي يستطيع قراءته؟
• ما الذي يستطيع تغييره؟
• ما الذي يستطيع إرساله؟
• لمن يستطيع الإرسال؟
• ما الذي يستطيع تشغيله؟
• متى يحتاج إلى موافقة؟
• ما الذي يستطيع فعله دون تدخل بشري؟

هذه الحدود يجب أن تفرض تقنيًا، لا أن تترك كتوجيهات لغوية فقط داخل Prompt.

متى تعيد الفحص؟

يجب إعادة فحص Lethal Trifecta عند أي تغيير يمكن أن يوسع قدرات النظام، مثل:

• إضافة Data Source.
• إضافة Tool.
• إضافة MCP Server.
• تغيير IAM Role.
• منح Internet Access.
• ربط Email.
• إضافة File Upload.
• تغيير Workflow.
• زيادة Autonomy.
• إضافة Agent جديد.
• تغيير Integration.
• إضافة API.
• تغيير النموذج إذا أدى ذلك إلى تغيير سلوكي أو تشغيلي مؤثر.

قراءة سيادة: Model Change as a Governance Event

تغيير النموذج لا يكون دائمًا تغييرًا تقنيًا داخليًا فقط.

إذا تغيرت قدرة النظام على استخدام الأدوات أو اتباع التعليمات أو التعامل مع Context، فقد يتغير ملف المخاطر حتى مع بقاء بقية البنية كما هي.

لذلك ينبغي تقييم ما إذا كان التغيير يستدعي إعادة Validation.

قائمة تحقق سريعة

يمكن استخدام الأسئلة الثلاثة التالية كبداية:

1. Sensitive Data

هل يستطيع النظام الوصول إلى بيانات أو أسرار أو معلومات حساسة؟

2. Untrusted Input

هل يمكن لمصدر غير موثوق إدخال محتوى إلى Context أو Workflow؟

3. External Communication

هل يستطيع النظام إرسال معلومات أو تنفيذ اتصال خارج Boundary الموثوقة؟

إذا كانت الإجابات:

• نعم.
• نعم.
• نعم.

فانتقل من الفحص السريع إلى Architecture Review أعمق.

الخلاصة

أمن Agentic AI لا يتعلق فقط بما يعرفه النموذج، بل بما يستطيع الوصول إليه، وما الذي يمكن أن يؤثر فيه، وما الذي يستطيع فعله بعد ذلك.

عندما تجتمع:

• البيانات الحساسة.
• المدخلات غير الموثوقة.
• قناة الاتصال الخارجي.

داخل النظام نفسه، تصبح حدود السلطة والعزل والصلاحيات جزءًا جوهريًا من التصميم الأمني.

السؤال الأفضل ليس:

هل Prompt آمن؟

بل:

إذا فشل Prompt أو تم حقنه، ماذا يستطيع النظام فعله فعليًا؟

وهذا هو السبب في أن معالجة Lethal Trifecta يجب أن تبدأ من Architecture وPermissions وIdentity وNetwork Boundaries، وليس من Prompt Engineering وحده.

المرجع

المفهوم مستند إلى:

PCI Security Standards Council Security Considerations for AI Systems — Information Supplement Version 1.0 — September 2026.

هذه المادة قراءة عربية تطبيقية من سيادة AI، وليست ترجمة رسمية ولا متطلبًا مستقلًا صادرًا عن PCI SSC.