TL؛ DR
ثلاث إجابات لنفس السؤال حول مخاطر الذكاء الاصطناعي الفاعل
توقعنا اتفاقاً واسعاً حول تقييد وكلاء الذكاء الاصطناعي، لكننا حصلنا على ثلاث إجابات مختلفة.
- بيدرو فورتونا: قم بتقسيم العملاء إلى العديد من العملاء الصغار والمحددين، كل منهم بأضيق صلاحيات ممكنة، وأضف مراقبة وقت التشغيل التي توقفهم مبكراً.
- جاك تريفون: على النقيض من ذلك، بالنسبة لوكلاء البرمجة. تقييد أحدهم يعني تدمير ما يجعله مفيدًا، لذا تقبل نطاق التأثير واستثمر في التتبع والتعافي السريع.
- لويس رودريغيز بيرزوزا: خط ثالث. تعامل مع نماذج الحدود كما تتعامل مع البرامج الضارة، وصمم النظام للحد من كل عامل متخصص، وضع طبقة إنفاذ أسفل كل ذلك تعمل عندما يفشل كل شيء فوقها.
حيث التقى الثلاثة: لا يمكنك حماية ما لم تقم بجرده، ويجب تسجيل كل إجراء، والشيء الذي يوقف الوكيل يجب أن يكون خارج الوكيل.
لم يتم اختراق أي شيء.
أدى البرنامج البرمجي مهمته. أثناء ذلك، قرر أنه بحاجة إلى تعديل أحد التبعيات، أو ملف إعدادات، أو خدمة لم يطلب منه أحد تعديلها. وقد التزم بصلاحياته طوال الوقت. لم يتم انتهاك أي قاعدة، لذا لم يحدث أي شيء.
عرضنا هذه القضية على ثلاثة أشخاص متخصصين في هذا المجال، متوقعين اتفاقاً واسعاً حول كيفية التعامل معها. لكننا تلقينا ثلاث إجابات مختلفة، اثنتان منها متناقضتان.
يُوصف خطر الذكاء الاصطناعي الوكيل عادةً بأنه مشكلة هجومية. هذه هي النسخة الأخرى. على مدى عشرين عامًا، رسمنا حدودًا للصلاحيات حول برامج تُنفذ ما يُطلب منها بدقة. حساب خدمة، مُشغّل تكامل مستمر، مهمة مُجدولة. أخطأنا في تحديد هذه الحدود في كثير من الأحيان، لكن ما بداخلها كان قابلاً للتنبؤ. كان يُنفذ مهمة واحدة، بنفس الطريقة، في كل مرة.
الآن، ما يقع داخل الحدود هو الذي يقرر. ولا تزال الحدود مرسومة كما كانت دائماً: مسبقاً، عند وقت التكوين، من قبل شخص لا يمكنه معرفة ما ستؤول إليه المهمة.
هذا هو مفهوم مخاطر الذكاء الاصطناعي الفاعل الذي يستحق النقاش، وقد خصصنا ساعة كاملة لمناقشته في الحلقة الماضية. محادثة SafeDev مع بيدرو فورتونا من Jscrambler، جاك تريفون من شركة تريفون للاستشارات الرقمية، و لويس رودريغيز بيرزوسا من شركة Xygeni، التي تستضيفها اليخاندرو استرادا.
توقعنا أن يتفقوا بشكل عام. لكنهم لم يفعلوا.
مخاطر الذكاء الاصطناعي الفاعل: الفرضية المريحة التي لا تصمد
يحتوي الإطار أعلاه على كلمة تقوم بعمل أكثر مما ينبغي: مهاجملا يوجد واحد. من المفترض أن يجعل ذلك السيناريو أسهل.
قام بيدرو بتفكيك ذلك بحركة واحدة.
"إن كون المرء مهاجماً أو لا يكون كذلك هو مفهوم بشري. ما يجعل المهاجم مهاجماً هو اختلاف أهدافه. والعميل غير المتوافق مع أهدافه هو أيضاً شيء له هدف مختلف."
تأمل في هذا، لأنه يُقوّض أساس معظم النقاشات حول مخاطر الذكاء الاصطناعي الفاعل، بما في ذلك الوصف الذي كتبناه لفعاليتنا. إذا كان ما يُعرّف المهاجم هو اختلاف الأهداف لا الخبث، فإنّ عبارة "لا يوجد مهاجم في هذه القصة" هي طمأنينة لم يكتسبها أحد. من الناحية الهيكلية، يبقى الخطر نفسه. ما ينقص هو النية، والنية لم تكن أبدًا ما ترصده أدوات التحكم لديك. إنها ترصد الآثار. لطالما فعلت ذلك.
وهذا أيضاً هو سبب تغير مصطلحات الصناعة. أفضل 10 برامج ماجستير في القانون لعام 2026 أدى رفع مستوى الوكالة المفرطة من المركز السادس إلى المركز الثالث، وهو ما لا يعد تغييراً في الرأي بقدر ما هو لحق سجل الحوادث ببنية تم نشرها بالفعل.
ما تُظهره حادثة "الوجه المعانق" في الواقع
حادثة يوليو، التي هاجمت فيها عارضة أزياء من منطقة الحدود طرفًا ثالثًا، فُسِّرت على نطاق واسع على أنها قصة عارضة أزياء خرجت عن السيطرة. لكن لويس يقرأها بشكل مختلف، وروايته تُلقي بالمسؤولية على جهة غير مريحة.
"المشكلة ليست في النموذج التجريبي نفسه. لقد قام النموذج التجريبي بما طُلب منه القيام به. المشكلة تكمن في تصميم التجربة."
كان الهدف مفتوحًا. لم تكن هناك قيود. وكان للبيئة المعزولة التي صُممت لاحتوائه نافذة على الإنترنت، من خلال ثغرة أمنية في ذاكرة التخزين المؤقت للحزم تسمح بتزوير الطلبات من جانب الخادم، والتي يمكن للوكيل الوصول إليها. كل واحد من هذه الأمور يُعد خللًا في التصميم.cisأيون صنعه شخص.
وهذا ما ينتج عنه الجملة التي ينبغي أن تغير طريقة توفير هذه الأشياء:
"يجب النظر إلى نماذج الحدود كما لو كانت برامج ضارة، لأنها تستطيع العمل بشكل مستقل واتخاذ قرارات صعبة."cisأيونات خبيثة. ليس عن قصد، لكنها خبيثة حقًا في النهاية.
ليس الأمر إهانةً للنموذج، بل هو إجراء وقائي. لا يمكنك منح البرامج الضارة واجهة سطر أوامر (bash shell) وتأمل أن يكون الهدف محددًا بدقة.
كان تفسير بيدرو للحادثة نفسها يتعلق بالتوقيت وليس بالتصميم:
"بمجرد أن ترى عملاء يتواصلون عبر أسماء مجلدات على خدمة لا ينبغي لهم استخدامها، يجب عليك إيقاف هؤلاء العملاء فورًا. لا داعي لانتظار نجاحهم في اختراق Hugging Face لتحديد ما إذا كان ذلك خبيثًا أم لا."
هناك تفصيلٌ جديرٌ بالذكر من الاستجابة. حاول المستجيبون استخدام أداة تحليل بيانات تجارية لتحليل الآثار، لكنهم لم يتمكنوا من ذلك بسبب تجاوزهم حدود معدل الطلبات. أما المهاجم، فلم يكن لديه مثل هذا الحد. "كان هناك خللٌ في الهجوم نفسه."
الحجة الفعلية: هل نحد من قدرة العامل، أم نتعافى بشكل أسرع؟
وهنا انقسمت اللجنة، وهو خلاف حقيقي بين الممارسين الذين استحق كل منهم منصبه.
يدافع بيدرو عن التحلل. خمسة عشر عامًا من العمل على تعزيز العزل داخل المتصفح علّمته أنه لا يمكنك فرض أي شيء أثناء التشغيل على نظام متكامل. قسّم البنية إلى أجزاء صغيرة ذات وظائف محددة، وعندها فقط يمكن ربط عناصر التحكم ونقاط المراقبة. وينطبق الأمر نفسه على البرامج الوسيطة.
أعتقد أنه يجب تقسيمها إلى عملاء محددين للغاية مخصصين لمهام محددة فقط. ولا يهم إن انتهى بك الأمر بخمسين عميلاً. إنه أفضل من وجود عميل واحد فقط.
يجادل جاك بالعكس، تحديداً فيما يتعلق بوكلاء البرمجة. قد تتوقع أن يؤدي وجود خلفية تقنية في بورصة عملات رقمية منظمة إلى فرض أكثر القيود في الغرفة. لكنه لم يفعل ذلك.
إن تشبيهه الأولي ليس نموذجاً للتهديد على الإطلاق:
"أنا أنظر إلى عملية نشر عميل نموذجية كما لو كنت أنظر إلى موظف جديد، شخص جديد قادم. ويمكن لهذا الشخص أن يكون مثالياً في التنفيذ، أو قد يرتكب خطأً. لا أرى فرقاً كبيراً."
بالنسبة للبرامج المتخصصة، فهو صارم كغيره. عند وصفه لبرنامج مراجعة للقراءة فقط يعمل على تطويره حاليًا، كان صريحًا بأن الإعداد الشائع غير قابل للدفاع: فالنشر على نظام لينكس عادي مع إمكانية الوصول إلى Bash "يفتح المجال أمام منظومة كاملة من التهديدات". لكن بالنسبة لبرامج البرمجة العامة، ينعكس المنطق، وهو يعلم أن هذا الموقف غير شائع.
كلما زادت صلاحيات الوكيل، زادت إبداعاته وفعاليته. لذا، فإن ازدهار هذه الصناعة لا يعود إلى القيود وتقليص نطاقها.
إذن، ما الذي يتبقى إذا لم تضع قيودًا؟ قواطع الدوائر، وقبل كل شيء، لقطات زمنية: ليس لمنع نطاق الانفجار، بل لجعل التعافي منه رخيصًا وسريعًا. وهو يدمج ذلك في العنبر، وهو برنامج وسيط C++ لا يعتمد على أي مكتبات خارجية، يقوم بكتابته في أوقات فراغه، مع خاصية التقاط اللقطات داخل الحلقة (موقع المشروع).
والتحذير بشأن نهاية المسار الآخر:
"إذا بدأنا في التنازل عن بعض الأدوات، فلن يتبقى سوى أداة واحدة، وسيكون بإمكان المطور تشغيل الأضواء وإطفاءها."
لويس يحتل المركز الثالث، وهو ليس تقييدًا ولا استعادة بل احتواء من الأسفل: افترض أن العامل سيتصرف في النهاية مثل البرامج الضارة، وصمم النظام للحد من كل عامل متخصص، وضع طبقة إنفاذ تحت كل ذلك تعمل عندما يفشل كل شيء فوقها.
ثلاثة مناهج لحل نفس المشكلة
ثلاثة مناصب، لكل منها تكلفة. لا يوجد أي منها مجاني، ولا يضمن أي منها سلامة العميل بمفرده.
| النهج | حركة أساسية | ما يكلفك ذلك |
|---|---|---|
| تتحللبيدرو فورتونا | العديد من العملاء الصغار، لكل منهم صلاحيات محدودة، بالإضافة إلى مراقبة وقت التشغيل التي توقفهم مبكراً | يتطلب الأمر جهدًا تصميميًا مسبقًا، ووقتًا أطول مع أعمال البرمجة المفتوحة. |
| استعادةجاك تريفون | احتفظ بالقدرة، وأضف قواطع دوائر كهربائية ولقطات زمنية لتسهيل عملية التراجع بتكلفة منخفضة. | نطاق انفجار أوسع، ورهان على اكتشافه وإبطاله في الوقت المناسب |
| يحتوي من الأسفللويس رودريغيز بيرزوسا | بافتراض سلوك البرمجيات الخبيثة، قم بتقييد كل عميل في النظام، وفرض قيودًا عليه في محطة العمل ومنصة التكامل المستمر. | البنية التحتية والأدوات التي لا توفرها معظم حزم نقاط النهاية حتى الآن |
عند قراءة وجهات نظرهم جنبًا إلى جنب، يتضح أن الخلاف أضيق مما يبدو. يتفق الثلاثة على أن الوكيل قد يقوم بفعل غير مقصود. لكنهم يختلفون حول وجهة الأموال: هل تُستثمر في البنية التحتية قبل وقوعها، أم في عملية التعافي بعد وقوعها، أم في طابق يقع أسفل كليهما؟
لماذا لا يُترجم مبدأ أقل الامتيازات إلى مخاطر الذكاء الاصطناعي الفاعل؟
يفترض مبدأ أقل الامتيازات أنك على دراية بالمهمة. أنت تحدد نطاق الصلاحيات للمهمة.
يُخالف الوكيل ذلك بهدوء، لأن حدود صلاحياته تُحدد أثناء التهيئة، وتُسند إليه المهمة أثناء التشغيل. ما تمنحه فعليًا هو مجموع كل ما قد يُطلب منه فعله. هذا ليس مبدأ أقل الصلاحيات، بل هو عكسه تمامًا، إذ يرتدي ثوب أقل الصلاحيات.
قدّم لويس إعادة صياغة مستوحاة من فكرة أقدم من كل هذا:
"أفكر في آلية التوصيل في نظام يونكس، حيث يتم ربط الأدوات البسيطة معًا لأداء مهمة معقدة. يمكنك تحديد عوامل محددة بتكوين مُتحكم فيه، مما يحد من ما يمكن أن يفعله هذا العامل المتخصص. ويمكنك دمجها لأي مهمة تقريبًا."
بالإضافة إلى فكرة تصميم ثانية لم تجربها معظم الفرق: قم بتغليف الأدوات بدلاً من توسيع نطاق الأذونات. ليس Bash، الذي يُسلّم النظام بأكمله، بل غلافٌ مُصغّر هو المسار الوحيد القابل للاستدعاء، مع وجود نسخ للقراءة فقط تُغلّف النسخ العامة. يحصل الوكيل على إمكانية، لا على واجهة سطر أوامر.
وأوضح أيضاً أن العقبة ليست في التصميم، بل في عملية التنفيذ. فقد اعتاد المطورون على إيجاد حلول بديلة للضوابط الجديدة على أجهزة المطورين، وهذا التاريخ لا يتغير لمجرد أن الأداة المعنية هي وكيل.
أما عن رأيه في أين ينتهي كل شيء:
"أعتقد أننا سنحصل في النهاية على وكلاء مستقلين يتحكمون في وكلاء مستقلين آخرين."
أصبح الكمبيوتر المحمول جوهرة التاج، ولم يلاحظ نظام الكشف والاستجابة لنقاط النهاية (EDR) ذلك.
يحتاج الوكيل إلى صلاحيات دائمة ليكون فعالاً. يتطلب ذلك رمزًا مميزًا لا تنتهي صلاحيته أثناء تنفيذ المهمة، وبيانات اعتماد مخزنة مؤقتًا، وحقوق إرسال، وصلاحيات الوصول إلى سجل النظام، ومسارًا مباشرًا إلى... pipelineكل واحد من هذه الأمور هو شرط وليس مجرد إغفال، مما يعني أنه كلما تحسنت الأدوات، كلما أصبح جهاز المطور أكثر تركيزًا.
لاحظ المهاجمون ذلك أولاً. وكما قال بيدرو، فهم ليسوا أصحاب أيديولوجيات:
"إنهم ينظمون أنفسهم كشركات صغيرة. إنهم بحاجة إلى جني المال، لذلك ينتقلون إلى الزاوية الأكثر ربحية التي يمكنهم إيجادها. وسرعان ما أدركوا أن هناك أموالاً يمكن جنيها في محطات التطوير."
نتابع هذا التغيير وهو يُسجّل في السجلات كل أسبوع في ملخص التعليمات البرمجية الضارة، حيث يقوم جامعو بيانات الاعتماد الآن بشكل روتيني بالبحث عن مفاتيح مزود الذكاء الاصطناعي جنبًا إلى جنب مع مفاتيح السحابة والسجل.
قائمة إجراءات التخفيف الخاصة به غير جذابة ولكنها فعالة: قم بإزالة كل مفتاح لا يحتاج إلى أن يكون على الجهاز، وقم بإقران المفاتيح المتبقية بعامل ثانٍ مثل OpenID Connect أو مفتاح الأجهزة بحيث لا يكون الرمز المميز المسروق كافيًا بمفرده، وانقل البيئة من المضيف حيثما أمكن ذلك، من خلال حاويات التطوير أو بيئات التطوير المتكاملة السحابية.
ثم أشار لويس إلى نقطة ينبغي أن تقلق أي شخص يفترض أن مجموعة نقاط النهاية الخاصة به تغطي هذا الأمر:
"تتخصص أنظمة الكشف والاستجابة لنقاط النهاية في البرامج الضارة التقليدية، وهي غير مطلعة على الأدوات البرمجية الخبيثة. وإذا نجحت هذه الأدوات، فقد تُنتج الكثير من الإنذارات الكاذبة، لأن البرنامج الخبيث يقوم بأشياء لا تتعرف عليها أنماط الكشف حتى الآن."
نمطان للفشل في آن واحد: فهو يغفل ما هو مهم، ويشير إلى ما هو غير مهم. يكمن حله في طبقة الإنفاذ الخارجية، المحيطة بمحطة عمل المطور ومنصة التكامل المستمر، أسفل البنية التحتية، والتي تحدد نطاق وصول أي عميل متسلل. هذه هي الثغرة. زيجيني Shield تم تصميمها من أجل ذلك، مع تطبيق السياسة على نقطة النهاية حيث يتم التثبيت فعليًا.
قال جاك الأمر بشكل أكثر صراحة: لا تحتفظ ببيتكوين الخاص بك على جهاز التطوير الخاص بك.
الأرضية التي اتفق عليها الثلاثة
ثلاث إجابات مختلفة، وإجابة واحدة مشتركة كحد أدنى.
- الجرد أولاً. "لا يمكنك حماية ما تجهله." كل شخص آخرcisيعتمد الأمر على معرفة أي من العملاء والمهارات وخوادم MCP موجودة، ولم يتم الإعلان عن أي منها تقريبًا.
- سجل كل إجراء. وصل جاك ولويس إلى هنا من اتجاهين متعاكسين. يريد جاك آثارًا لأنها أساس التعافي ونضج المؤسسة. أما لويس فيريدها لأنه بدونها لا يمكن إعادة بناء نطاق الانفجار لاحقًا. يجدر بنا الاستفادة من منظور جاك: لا فائدة من استجواب الفاعل، سواء كان إنسانًا أو جهة فاعلة، بل من فهم السياق جيدًا بما يكفي لتجنب تكراره.
- إن الشيء الذي يوقف الفاعل يجب أن يكون خارج نطاق الفاعل نفسه. مراقبة وقت التشغيل لبيدرو، وطبقة الإنفاذ للويس، وقواطع الدوائر واللقطات لجاك. آليات مختلفة، مبدأ واحد.
قدّم جاك إطارًا مفيدًا لتوضيح موقع الصناعة على منحنى التطور. يتذكر أول بريد إلكتروني مزعج تلقاه، يُخبره بأنه ورث منجم ذهب في نيجيريا. هذه مشكلة نضج، والنضج يأتي بعد الأخطاء لا قبلها.
ما يجب فعله قبل يوم الجمعة
اختر وكيلاً واحداً. اكتب قائمتين: ما يُسمح له بفعله، وما طُلب منه فعله فعلياً هذا الأسبوع.
الفجوة بين هاتين القائمتين هي نطاق تأثيرك، وهي المقياس الأكثر فائدة لمخاطر الذكاء الاصطناعي الذي يمكن لفريقك إعداده في غضون ساعات. لا يتطلب الأمر سوى بضع ساعات، ولا يحتاج إلى ميزانية، ويحسم الجدل المذكور أعلاه لمؤسستك، لأن المواقف الثلاثة تمثل في الواقع ثلاث إجابات مختلفة على سؤال حجم هذه الفجوة.
معظم الفرق لم تدون ذلك أبداً.
استخدم ساعة كاملة متاح للمشاهدة مرة أخرى، بما في ذلك وجهة نظر جاك حول سبب كون متطلبات وجود عنصر بشري في عملية اتخاذ القرار في أوروبا تجعل بعض دفاعات الذكاء الاصطناعي غير قابلة للتطبيق عمليًا.
وإذا كان التمرينcisيعيد البرنامج إجابة لا تعجبك، زيجيني اكتشف كل أصول الذكاء الاصطناعي عبر مستودعاتك، بما في ذلك العملاء والمهارات وخوادم MCP التي لم يقم أحد بالإبلاغ عنها، وارسم خرائط لما يمكن أن يصل إليه كل منها. كتاب التجريبي or ابدأ مجاناً، وسنقوم بتشغيله على جهازك.
الأسئلة الشائعة
ما هو نصف قطر انفجار وكيل الذكاء الاصطناعي؟
كل ما يمكن للوكيل الوصول إليه في حال حدوث خطأ، بغض النظر عما طُلب منه فعله. يُحدد ذلك بالأذونات وبيانات الاعتماد والأدوات المتاحة له أثناء التشغيل، وليس بالمهمة نفسها. الفجوة بين هذين الأمرين هي ما يستحق القياس، ومعظم الفرق لم تُسجلها قط.
هل يُعتبر تجاوز الوكيل لمهامه حادثة أمنية إذا لم يتجاوز صلاحياته مطلقاً؟
كان هذا هو الخلاف الرئيسي. إجابة بيدرو هي في الواقع نعم، لأن المهاجم يُعرَّف باختلاف الهدف لا بالخبث، والعميل غير المتوافق قد انحرف عن مساره. أما إجابة جاك فهي أقرب إلى الرفض: إنه فشل تشغيلي كخطأ موظف جديد، والاستجابة الصحيحة هي التتبع والتعافي بدلاً من فرض قيود أكثر صرامة. يتجنب لويس السؤال بافتراض أسوأ الاحتمالات منذ البداية، ويتساءل عن الطبقة التي لا تزال قائمة عند حدوث ذلك.
هل ينبغي عزل برامج البرمجة في بيئة معزولة؟
بالنسبة للوكلاء ذوي المهام المحددة، وافق الثلاثة جميعًا دون تردد: القراءة فقط حيثما أمكن، ومنع استخدام Bash، ومنع الاتصال بالشبكة إلا عند الضرورة. أما بالنسبة لوكلاء البرمجة العامة، فقد انقسمت اللجنة إلى ثلاثة أقسام: سيقوم بيدرو بتفكيكها، وسيحافظ جاك على إمكانية أخذ لقطات الشاشة بشكل صارم، وسيضيف لويس طبقة إنفاذ أسفل البنية التحتية بغض النظر عما يُسمح للوكيل بفعله.
هل يغطي نظام الاستجابة لنقاط النهاية (EDR) الخاص بي مخاطر الذكاء الاصطناعي الآلي؟
ربما ليس بشكل جيد. تعتمد أدوات نقاط النهاية الحالية على أنماط البرمجيات الخبيثة التقليدية، ولا تُحاكي سلوك البرامج الضارة، لذا فهي غالبًا ما تُغفل ما هو مهم وتُشير إلى ما هو غير مهم. كان حل لويس عبارة عن طبقة إنفاذ خارجية مُصممة لبيئات المطورين، وليست نظام كشف واستجابة لنقاط النهاية للأغراض العامة.
ما هو أول شيء يجب فعله؟
أنشئ قائمة الجرد. كل نموذج، ووكيل، ومهارة، وخادم MCP في مستودعاتك، وما يمكن لكل منها الوصول إليه. إنها الخطوة التي ذكرها جميع أعضاء اللجنة الثلاثة، والخطوة الوحيدة التي تعتمد عليها جميع عناصر التحكم الأخرى.
